Stay on Top of Emerging Technology Trends
Get updates impacting your industry from our GigaOm Research Community
When Steve Jobs told the media at the July 16 Press Conference that Apple (s aapl) loves its customers, he meant it. When 5,000 developers gathered in San Francisco for the WWDC a few months earlier to discuss how to build apps for these customers that Apple loves so much, the company provided training, as well as several new tools called instruments, to help developers build the best possible applications for users of Apple devices.
There were no less than a dozen sessions at this years WWDC on how to improve apps throughout the development process, with another handful showing how to move processes off of the main thread using Blocks and Grand Central Dispatch. The message was loud and clear: Build apps that do what they say they will do; build apps that do not use any private or undocumented APIs; and oh yeah, most importantly, build apps that don’t crash. When developers have ignored these three basic things, their apps were most likely rejected from the App Store.
This year, however, developers quickly discovered that the stakes were a little higher. With Multitasking in iOS 4, the apps must also play well with others. There’s an omnipresent watchdog monitoring apps as they try to do their thing. If the app takes too long to perform certain tasks (like launching), or consumes too much memory (especially when suspended), it may be forced to quit. Fortunately, there is a series of tools that developers can use to ensure that the apps they build are of the highest quality possible, and behave as good little apps in the iOS kingdom.
Writing Better Code
Xcode’s Build and Analyze. The first line of defense is the static analyzer. Xcode’s built-in static analyzer is based on the open-source Clang Static Analyzer, a source code analysis tool that find bugs in C and Objective-C programs. This static analyzer works like a compiler and examines source code, looking for logic flaws and instances where certain coding best practices are not followed. This can help a great deal in cutting down on unused variables and other memory management issues.
Bug Hunting in the Simulator
Allocations Instrument. The Allocations instrument can be used to take snapshots of the heap as apps perform their tasks. If taken at two different points in time, it can be used to identify situations where memory is being lost, not leaked. The test case would be to take a snapshot, do something in the app, and then undo that something, returning the state of the app to its prior point. If the memory allocated in the heap is the same, no worries. It’s a simple and repeatable test scenario of performing a task, and returning the app to its state prior to performing the task.
Leaks Instrument. The Leaks instrument will look for situations where memory has been allocated, but is no longer able to be used. The most common situation where this occurs is with buried or overly complex logic that’s supposed to release memory, but under certain circumstances doesn’t get executed. These memory leaks can lead to the app crashing or being shut down. If an app is holding on to too much memory when the user decides to suspend the app, the watchdog may have no choice but to quit the app in order to free memory. By keeping a lean application, the chances of this happening are minimized.
Zombies Instrument. The majority of crashes are caused by trying to access an object that doesn’t exist. Memory gets allocated and released all the time, and if an app releases something before the app is done using it, the app may crash. This is usually a very difficult scenario to track down with just the debugger. The Zombies instrument keeps an empty or ‘dead’ object alive (in a sense) in place of objects that have already been released. These ‘dead’ objects are later accessed by the faulty application logic and halt execution of the app without crashing. The ‘zombie’ objects receive the call and point the instrument to the exact location where the app would normally crash.
On Device Performance
Time Profiler Instrument. Although the Time Profiler instrument can be used in the simulator, it’s recommended for use on a device. The main reason for this is that performance will vary greatly between the simulator on a Mac and various iOS devices. Apple recommends developers try to perform time measurements on the slowest supported device, which would undoubtably be an iPhone 3G with iOS 4 installed. When used, the Time Profiler will illustrate how much time is being spent in each code segment. This allows developers to prioritize which bit of logic needs to be refactored prior to release. Some things may not be fixable, but it’s possible other factors could be reviewed in order to see if there’s a better way to address the issue at hand, possibly by moving logic off the main thread using Blocks and Grand Central Dispatch. As easy as Apple has tried to make this programing task, developers still don’t want to waste time optimizing the performance of code that’s already performing well.
Use In the Field
Energy Diagnostics. The Energy Diagnostics instrument is potentially the most exciting tool that Apple gave to developers. This instrument allows for field testing that’s as close to real world scenarios as possible. The data collected can later be analyzed to see how much of the device’s battery life each function consumes. It will tell the developer how long each of the devices various components is used. If you need to know the user’s location, it will tell you which devices were turned on and for how long. GPS is a particular resource hog and consumes much of the device’s battery life. Turning off location services once a location is obtained is ideal. The Energy Diagnostics instrument will help identify optimum use of the device’s resources.
Monitoring Customers Experiences
Crash Reports. iTunes Connect is used by developers to interact with Apple’s App Store, and is used to submit apps to Apple. It’s also where Apple collects crash data from users of each developer’s apps. These Crash Reports can be analyzed by the developer and used to pinpoint where users are having bad experiences. The reports indicate when there is a watchdog timeout during a launch, resume, or suspend event, as well as when the user force-quits the app or the system performed a low memory termination. You can’t always rely on the user to submit bug reports or inform developers of a bad experience. With as many alternative solutions out there for similar tasks, it’s much easier to simply install a similar app than inform the developer of a bug and wait for a solution. Crash Reports may be the only means to rectify bugs that were not caught during field testing.
These are a few of the tools that Apple has to offer developers, and are most were emphasized during WWDC this year. While Steve Jobs can’t hold all third-party developers to the same high standards he does his internal staff, he can provide the tools necessary for developers to build the best-possible apps. When Apple released all the WWDC sessions via iTunesU to all registered developers, you could sense that Apple was serious about helping developers provide the best possible apps for customers who choose to buy products on Apple’s platforms.
- Apple Developer Connection – WWDC 2010 Sessions on iTunesU
- Mac OS X Reference Library – Introduction to Instruments Guide
- iOS Reference Library Technical Note TN2151 – Understanding and Analyzing iPhone OS Application Crash Reports