Blog Post

Apple’s Instruments for Developers

Stay on Top of Enterprise Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the 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

XcodeXcode’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

AllocationsAllocations 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.

LeaksLeaks 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.

ZombiesZombies 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 ProfilerTime 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 DiagnosticsEnergy 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

iTunes ConnectCrash 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.


10 Responses to “Apple’s Instruments for Developers”

  1. Well, Objective-C DOES support garbage collection. It’s just not implemented on the iPhone to save battery life. Although it could be a debatable decision it does not lack its logic.

    But saying that not suporting GC is obsolete or a relic is even more debatable. When I’m programming a game or some resource intensive application the last I want is to have a GC thread lurking on the background taking decisions for me about when is the best moment to release memory.

    • Even languages such as Java with Garbage Collection will crash when they encounter a null pointer exception. Developing in a language that supports Garbage Collection alone does not prevent the types of crashes that the Zombies Instrument can help track down.

  2. @Nick: Insofar as automatic garbage collection is a Good Thing, it is not a replacement for a developer’s brain… I started in x86 assembler (Darn, .com executables. Do i MUL or bit shift? Which JMP is the best?) then moved to VB and PHP…
    The young’uns have never heard of code optimisations, fights between programmers over algorithms that could have saved 1 or 2 bytes (oh, the PDP11…). Heck, I’m dottering and I’m only 32!

    What people have forgotten is that mobile devices have a different set of constraints compared to a desktop system, and is much similar to a games console: No upgradability and no OS choice, and from there, all the apps must play nice with what is today a third world computing platform. The platform/OS supplier must force the users to play nice or else, because they don’t want problems 10 years down the road.

    The current set of design tools are not perfect, then again, none are. They could be better, and these tools are a step in the right direction.

    The other problem is that for the time being, Apple is stuck with a legacy of system development tools, and this is what their developers are currently using, just with an extended internal-only API. Given time, they may come around and end up building an iPhone version of Visual Studio for Mobiles that MS designed yonks ago (and abandonned?).

    Desktop computing has come in 20 years from assembler to full GUI’s (and horribily unoptimised code). Borland, CodeWarrior, Microsoft, Apple, RealBasic, all have pushed the envelope in app development for the desktop platform, but mobile computing has had a new bar set by the iPhone, and there is only 3-4 years of development tool investment by only 1 company…

    Apple is not whiter than white, and I personally have no qualms in bashing them over iphone jailing, restricting MacOS on Apple Mac’s only and a lot of other things, but for once, I’ll side with them and say cut them some slack and give them a few more years… the technology is still moving :)

  3. Those debugging applications have (almost) all been around for the Mac for quite some time, so I’m not surprised that they ported it over to the iPhone. I doubt they’re as helpful as you claim them to be, though. I haven’t developed on Apple products for a year or so now, but I remember attempting to do so being the worst development experience I ever had. It’s not like I was a new developer; I’d been writing applications for about 5 years then, but it just really didn’t fit well. I’ve since moved on to platforms and languages which suit me much better.

    • The most interesting new instrument for mobile is definitely the energy diagnostics. Being able to collect data in the files based on real world usage and taylor your application best on optimum battery performance is something that Apple must take seriously if they invested in the development of tools to help developers make more energy efficient apps.

  4. It’s amazes me that apple put so much effort into these instruments apps. Why should the dev have to spend all that time tracking down bugs and memory leaks when apple themself are responsible for forcing devs to use obsololete programming language like objective-c with no GC for iOS development. The rest of the world have automatic garbage collection on there mobile os:es helping the devs. Objective-c overcomplicated syntax and lack of GC makes iOS development a not so fun environment to be in. Trust me you may have seen some great apps for your iPhone and iPad but the process behind could be so much better and fun if apple just would let go of the relic from 1985 that is objective-c.

    • Every language has its weak points, and not all of Apple’s instruments are used to track down language specific errors/bugs in developed code. Regardless of platform or language, resources are scarce. Profiling one’s app is essential on any platform. Instruments like the Time Profiler or the Allocations Instrument are tools that are applicable to any/all languages and/or platforms. Almost all code (in any language) can be refactored to perform better, and any code (also in any language) can run our of system memory if not designed carefully.