My first iOS app, WALT, went live recently, and I wanted to share some of my thoughts on the development experience. Overall, there were two big differences from past projects I have worked on.
First, since most of my past Cocoa development has been focused on the Mac, building and shipping an iOS app meant learning a new app framework and some new ways of going about things. It has been an enjoyable, but odd, combination of exploring things which are a good deal different, yet simultaneously very familiar—like walking into someone else’s kitchen for the first time, but already knowing where they keep most everything.
Second, shipping an app as an independent developer is a very different experience than shipping a product as part of a large team at Apple. Intellectually, I knew this from the start. Even so, knowing about it doesn’t necessarily prepare you for all of the implications until you’ve lived through them.
One implication, of course, is that I was able to build the app I wanted to create. I had a few specific goals for a first app:
Create an app that I wanted to use
Focus on frameworks and fundamentals
Build a solid, speedy, polished app
Ship it
Create an app that I wanted to use
Since childhood I’ve been a fan of Disney (and later Pixar) animation as an audience member—suspending disbelief and just enjoying the experience. Over time, I’ve increasingly come to appreciate the incredible amount of artistry, collaboration and process that goes into each film.
One source of this growing appreciation is The Walt Disney Family Museum in San Francisco, which describes the evolution of animation as part of its narrative. I’m inspired by things such as the incredible advancements and innovations in animation from the late 1920s to the late 1930s. Over a ten year period, animated films progressed from being black and white series of sight gags using ‘rubber hose’ animations to lush multi-plane technicolor films with animated characters conveying personality and eliciting emotion.
I’m also inspired by the work of Pixar—and am amazed at the analogous progress of 3D animation from the mid-80s to the mid-90s.
Together, Disney and Pixar have produced over 640 animated shorts and features. With almost all films released on disc, I wanted to keep track of what I had seen. I also wanted a quick, mobile reference with some basic information on each film. And so, I built WALT so I could use it, and hopefully other Disney and Pixar animation fans would enjoy using it as well.
Focus on framework and fundamentals
The features of my desired app lined up nicely with the core functionality common in most iOS apps: present a set of data, navigate, search, sort, filter, summarize.
Since this first app is relatively straightforward, I wanted to take the stock iOS frameworks out for a spin and see just how far they would take me, and how quickly.
My past experience in working with Cocoa frameworks is that it is good practice to use the highest level of abstraction that meets your needs. On the flip side, it can be treacherous to try to force a framework to be something that it isn’t. If you must twist the higher abstraction into a pretzel knot of ugly bad practices to meet your needs, it’s usually best to drop to a lower layer and implement what you need (and, of course, file enhancement requests so that a future release might meet your needs).
In the spirit of using the highest level of abstraction available, WALT uses standard UIKit controllers and views, with a handful of custom views. The app hits just about all of the UIKit highlights: tabs, navigation, tables, custom table cells, search results, modal view controllers.
For data management, WALT uses Core Data. A key consideration in this choice was the ability to do incremental fetches and updates. It had also been a while since I had done Core Data development on the Mac, so it was a good opportunity to reacquaint myself.
I tend to exercise caution when adopting version 1.0 technologies and frameworks – especially if an app will be immediately pushing the limits of the new technology. In WALT, I adopted two relatively new technologies: Storyboards and Automatic Reference Counting (ARC).
Since I planned to support iOS 5.0 and later, the straightforward layout of the app made Storyboards seem to be a very good fit. The Storyboard abstraction seemed useful and held promise to simplify development and eliminate code. In the end, I encountered a severe accessibility bug which required much of the eliminated code to be added back in one form or another. Overall using Storyboards was a slight net win for the project, but the experience definitely reinforced my attitude of caution.
I had no intention of moving to ARC, but a few conversations with former Apple colleagues led me to give it a try on a development branch. It went without a hitch. My project was in an early stage, so there was not much code to convert, and I did not anticipate writing much code that would hit known ARC ‘sore spots’, such as frequent conversions between Core Foundation and Cocoa. So, I merged the ARC changes into my main development branch and have not regretted doing so at all.
Finally, I was able to add a bit of social media support in WALT very quickly. The Twitter framework in iOS 5 made it trivial to add support for tweeting about films you have watched.
Build a solid, speedy, polished app
These three, of course, should be goals of any app since they map to quality, performance, and user experience. They can also be somewhat subjective areas – how responsive is responsive enough? How polished is polished enough? In these areas, I set some specific goals and worked towards them.
First, for me, solid means not crashing, not losing data and not leaking memory. I don’t have enough programmer hubris to claim there are no bugs in the app, but hours of use without an issue made the app feel pretty solid to me and my testers. Instruments came in handy to check for leaks—ARC seemed to live up to its promise. I also periodically ran the Xcode static analyzer, which is excellent at catching potential problems.
Being speedy meant focusing on app launch, scrolling, navigating and searching. I focused on how responsive the app felt to the user rather than using timed code benchmarks. The criteria were that the app should launch within a count of ‘One-Mississippi Two-Mississippi’; scrolling should not lag—even in longer lists; navigation should be smooth and search results should feel immediate.
I did hit some scrolling performance issues and found Instruments to be a valuable tool in tracking down the problems. Most turned out to be cases where I was unnecessarily fetching data repeatedly, which the Core Data instruments made very obvious. In the end, the app feels snappy.
Making an app ‘polished’ is perhaps the most subjective and all-encompassing—it includes everything from user interaction, to the look of the app; from providing retina graphics, to how the app behaves for VoiceOver users. Since I was already on the road of seeing just how far the stock frameworks would take me, much of the app polish is provided by the frameworks themselves.
But even leveraging what the frameworks have to offer, there are lots of subtle things that make an app feel better. WALT contains touches like adjusting the display of a table index and sections depending on the contents of a list, restoring the user’s previous navigation and scrolling state if the app is terminated, and minor but important things like making the tap target size on a checkbox larger than its graphic.
Polishing the app was a process of using the app as I developed it, refining the behavior as the app evolved. With polish, often the code you end up writing is not particularly difficult or time-consuming, the bulk of the work is in determining exactly how an app should behave.
Ship It
When working on a large project like OS X, someone else sets the schedule and decides that the product is ready to ship. As an independent, those decisions are yours, but so is the responsibility for those decisions.
I found one of the keys to shipping was to guard against feature creep by choosing a core set of features for version 1.0 and focusing on them. The process was fairly lightweight. First, record every issue, enhancement and feature idea. Then, decide which items absolutely need to be in the 1.0 milestone and move the rest to a Later milestone.
The lists were not immutable. As work progressed, it became clear some things were more important than originally thought, and some things less so. I periodically revisited the lists of issues and as time went by became more and more hard-nosed about which features remained in 1.0.
Another hurdle was deciding when the app is ready to ship. In addition to the feature set, there is so much that can be tweaked—the exact wording of labels, the default layout of tabs, which icons represent which tabs, tweaks to graphics. At a certain point, I needed to stop tweaking and send the app out into the world.
Wrap Up
I am very excited to have released this first app, WALT, both as a user and as a developer.
As a user of WALT, I’m currently tracking my progress through the Silly Symphony film series where the Disney studio tested many of the animation technologies and techniques that were used in the first animated feature film Snow White.
As a developer, each project brings new learning and insights and this one was no exception. But, there is also no denying it is a very good feeling when something you have created is released into the world.
And for beginner iOS developers taking those first steps towards building an app, I invite you to join me as I lead a Full Day iOS Tutorial at CocoaConf in Portland, OR on October 25th.
I welcome your comments on this or any other blog post, or the app WALT itself at comments@jamesdempsey.net.
Last week, I moved one of my projects over to use the new Objective-C literals for NSNumber, NSArray and NSDictionary as well as the new syntax for boxing expressions into NSNumber and NSString objects. Here are a few comments on how it went.
In a nutshell, the new language features allow code like [NSNumber numberWithInteger:7] to be replaced by a more compact syntax like @7. The LLVM site has a full description of the new syntax and usage.
Refactoring in Xcode
I ran the ‘Convert To Modern Objective-C Syntax’ refactoring tool in Xcode 4.4 to do the conversion. There is no option to choose which modern syntax features you wish to adopt before the conversion begins, but in Xcode 4.4, you can choose diff by diff which changes you wish to keep. Xcode seems to think my Objective-C syntax is already modern enough in other respects, since the only changes the refactoring made was to move to Obj-C literals.
Even if you want to introduce the new literals into your code manually, you might find it interesting to run the refactoring tool just to browse through its proposed changes. You can cancel the changes rather than apply them, but just by reviewing the proposed diffs, you might see use cases for Obj-C literals that may not have occurred to you.
There were more places than I was expecting where my code creates NSNumber instances from integer expressions and enums. Also, before running the refactoring tool, it had not occurred to me how often the expression being boxed would just be a single variable holding a scalar value.
So there were numerous places where the updated code did something similar to the following:
NSInteger myValue = 0;
// Do some stuff that changes myValue
[myArray addObject:@(myValue)];
Before doing the conversion on my own code, I definitely underappreciated the power and usefulness of boxed expressions.
Overall, I found the refactoring in Xcode 4.4. to be easy and straightforward. The Xcode project I converted was a medium-sized Objective-C project using the iOS 5.1 SDK.
A crashing issue to watch out for
There is a potential crashing issue that I ran into that you should be aware of. In one spot, the code was relying on a nil value terminating the list of arguments to create an array. So something like:
-useRequiredValue:(id)requiredObj optionalValue:(id)optionalObj {
NSArray *array =
[NSArray arrayWithObjects:requiredObj, optionalObj, nil];
// Do something useful with array
}
The method +arrayWithObjects: stops processing arguments when it hits the first nil argument. The code above relies on that fact to create a one-object array when optionalObj is nil, and a two-object array when optionalObj exists.
The conversion changed the array creation to:
NSArray *array = @[requiredObj, optionalObj];
With array literals, relying on a terminating nil does not work. Behind the scenes, a literal NSArray is created with +arrayWithObjects:count: which requires non-nil values. So, after converting to Obj-C literals, an exception was thrown whenever the optional argument was nil.
A similar issue arises with dictionaries if you are relying on early nil-termination with +dictionaryWithObjectsAndKeys: and then move to use an NSDictionary literal.
Note that this issue is not flagged by the refactoring tool or the static analyzer, so it is something to watch out for when converting to use Objective-C literals.
To address the issue, the options are either to revert to the previous code or change the code to something else.
I decided to stop using the ‘early nil’ approach for a few reasons. The first is that I know I will be tempted to change that line of code to use a literal array every time I look at it, which will reintroduce the crash. I could guard against that by adding an emphatic comment explaining the situation, to prevent myself from changing that line of code. So, everytime I look at the code, I’ll be tempted to convert the line of code, and then have to read about why I can’t convert that line of code.
It seemed more maintainable to move to a different way of doing the same thing. In addition, the new code is less tricky/clever than the old code and more explicit about what the result will be; no comment is needed. I am a big fan of well-commented code, but I’m also a fan of code that is obvious enough that the code can clearly speak for itself.
Readability
In most cases, the new literal syntax leads to code that is both more compact and more readable. In the above example, the new code is not much more compact than the original code, but, the intent is clearer, which I find more readable. With numbers, @3.6 is more readable and compact than [NSNumber numberWithFloat:3.6]. For arrays and dictionaries, I find that my eyes are not yet parsing literal array and dictionary creation as smoothly as more familiar Objective-C code, but I suspect that will change as I use and see the new constructs more often.
Boxed expressions may cause readability to suffer to some degree. When you encounter something like @(someVariable), it is ambiguous whether you are creating a number or string. You need to know the type of the expression to know for certain. In practice, descriptive variable names should make this less of an issue.
I find the code becomes less readable as the boxed expression inside the parenthesis becomes more complex and when Objective-C literals and boxed expressions are combined and nested. We are moving from code that had giant billboards of [NSString stringWith… or [NSNumber numberWith… proclaiming just what is being creating, to code which is definitely more compact, but may also be more difficult to read. For example:
Even after such a short time using the new syntax, I find that on balance, the literals and boxed expressions make for more readable and compact code, with a few cases where readability seems to suffer a bit. It is also early in the game, in terms of using the new syntax on a day to day basis. My opinion will continue to evolve as I use the new constructs more.
Backward binary compatibility and a little BOOL wrinkle
The new Objective-C literal functionality is handled in the compiler, so you must be using a recent version of the LLVM compiler to use this syntax. Since the compiler generates code that uses existing object creation methods, the code you write and compile can run on previous versions of OS X or iOS.
So, even if you are targeting releases of your app on OS versions earlier than OS X 10.8, or iOS 6, you can use the new literals along with the new version of the tools.
I did encounter one wrinkle with BOOL literals. To enable the compiler to properly deal with @YES and @NO to represent NSNumber BOOL values, two new language keywords were added to the Objective-C headers.
The iOS 5.1 SDK does not include these new keywords. So, if you are using Xcode 4.4 and the iOS 5.1 SDK, you need to ‘box’ the BOOL values as expressions to compile: @(YES) and @(NO).
The Mountain Lion 10.8 SDK does have the new keywords as will SDKs moving forward, so this is just a minor transitional oddity.
Conclusion
Overall, I think the new Objective-C literals and boxed expressions are an excellent addition to the language. I found converting to the new syntax using Xcode 4.4 refactoring to be a smooth process. The only real bump I hit was in code where I was relying on early nil termination of arguments when creating an array. The other wrinkle I encountered was the need to box BOOL values using Xcode 4.4. and the iOS 5.1 SDK. I’m looking forward to using these new language features moving forward.
Like a tropical breeze arriving on the shores of a faraway isle, the new single from James Dempsey and the Breakpoints is here—gliding onto the scene just in time for WWDC 2012.
The Liki Song is a fun, breezy tune with Hawaiian style that recounts a brief history of memory management in Cocoa.
Memory management is a topic as old as computer science itself, and Cocoa has had its share of evolution in this fundamental area.
So mix up a Mai Tai, don your Hawaiian shirt, fire up the Allocations instrument, and take a trip down memory lane.
Over the past few months, a number of people have asked if there would be a new song for WWDC this year, and I found myself wondering the same thing.
Then, driving into the studio one afternoon, a song started to take shape somewhere between Mountain View and Palo Alto. So, I’m very happy to announce that there will be a new song this year.
The new single is a fun, breezy tune with Hawaiian style—singing it always brings a smile to my face. Beyond that, I don’t want to give away too much more until folks can hear it for themselves.
LIVE near WWDC 2012
The show venue John Colins already has the Hawaiian spirit for the LIVE near WWDC 2012 show on June 13th.
You can hear the new song, along with old favorites, at what we’re calling James Dempsey and the Breakpoints LIVE near WWDC 2012 on Wednesday, June 12th.
I’ll have final and full show details next week. I’m really looking forward to a fun evening and playing the new song for everyone. Also, thanks to all the folks who have retweeted and passed the word along about the show.
One Night, One Song
Another great event that week is the Looking Back at NeXTSTEP fundraiser for the Cartoon Art Museum. The sold-out evening will have many luminaries from the NeXTSTEP days in attendance, all for a great cause.
I’m looking forward to attending the event as a sponsor, but I’m particularly excited, as well as honored, to be participating in the event as the special musical guest.
So, amidst the talk of days before NSString and autorelease pools, attendees will hear the public performance debut of the new single, done as a very ‘unplugged’ version. Thanks to Dr. Michael Johnson for hosting the event, and for including me in the proceedings.
Fun week coming up fast
WWDC week looks like it will be a fun and busy one with the live show, new single, conference sessions, and maybe best of all, meeting new folks and catching up with friends.
I’ll also be taking requests during the week, so feel free to say hello—and no, we don’t know Free Bird. •
How Much?Free Admission! No Cover! Cash Bar.
The show is free, but the drinks you have to pay for.
What: An evening of James Dempsey and the Breakpoints songs performed live, including favorites such as Hold Me, Use Me, Release Me; I Love View; Model View Controller and more.
Anything else? No WWDC Ticket Required!
A great open event for all developers hanging out in SF that week!
Why all the exclamation marks? Because this is shaping up to be a fun show and I’m very excited about it! Tell your friends! Tweet like the wind!
Other things to know:
• There are no tickets for this event.
• Arrive early for best spots.
• The venue is a bar—you must be 21+ years old to attend.
• Limited # of t-shirts available. Early birds get their size!
• Don’t take ‘cash bar’ literally. Credit cards also accepted.
• Hang out after the show and say hello.
• Follow @jamesdempsey on Twitter for show updates.
