We are going to use a very simple application to showcase different technigues used to test iOS and Android apps: an integer calculator, implemented in the most naive and simple way.

This application uses an MVC architecture, using a class named AKOIntegerCalculator for iOS and IntegerCalculator for Android, encapsulating the calculation logic, and an AKOViewController class (respectively, MainActivity for Android) to drive the user interface. [image_ios_sample_app] and [image_android_sample_app] show the UI of the application running in both the iOS Simulator and the Android Emulator, which offers basic operations and will be tested throughout the following chapters.

An assertion is code that’s used during development that allows a program to check itself as it runs. When an assertion is true, that means that everything is operating as expected. When it’s false, that means that it has detected an unexpected error in the code. They are specially useful in large, complicated programs and in high-reliability systems.

Exceptions, as the name implies, are used to signal exceptional events that threaten the correct execution of an application, and are most probably due to programming errors or runtime conditions out of reach from the developer.

The times you would @throw your own NSException are when you definitely want it in a release build, and in things like public libraries/interface when some arguments are invalid or you have been called incorrectly. Note that it isn’t really standard practice to @catch an exception and continue running your application. If you try this with some of Apple’s standard libraries (for example Core Data) bad things can happen. Similar to an assert, if an exception is thrown the app should generally terminate fairly quickly because it means there is a programming error somewhere.

NSErrors should be used in your libraries/interfaces for errors that are not programming errors, and that can be recovered from. You can provide information/error codes to the caller and they can handle the error cleanly, alert the user if appropriate, and continue execution. This would typically be for things like a "File not found" error or some other non-fatal error.

First of all, why does the Objective-C compiler (or compilers in general) output “warnings”? Many developers are puzzled the first time they encounter them, since even if the compiler complained, the application usually runs anyway without (perceptible) problems.

Warnings are used to signal specific issues in the source code which could potentially lead to crashes or misbehavior under some circumstances, but which should not (pay attention to the verb “should”) block the normal compilation and (hopefully) execution of your code (otherwise, it would be a compiler error).

It’s the way used by your compiler to say:

Not removing warnings, as I said above, is a problem that originates both in the programming background of the developer, and specific technical issues.

Culturally speaking, many other programming environments either do not have compilers at all (at least not “visible” ones, like Ruby or PHP) or simply do not spit warnings for anything else than deprecated methods (like C# or Java); this situation has made many developers new to the iPhone platform to blatantly ignore them.

Technically, given the fact that Objective-C is the “other” object-oriented superset of C, and that it behaves as a coin with both a static and a dynamic side, compiler warnings convey a great amount of precious information that must never be ignored.

In this sense, Objective-C has a lot in common with C. Ignoring warnings in C is strongly discouraged, and Scott Meyers explains this in chapter 9 of his book “Effective C++”, stating that (third edition, page 263):

In the case of Objective-C, this can be done by setting a particular value named GCC_TREAT_WARNINGS_AS_ERRORS (-Werror) to true in your build settings, as shown in the figure below.

Steve McConnell takes this advice to another level of importance in his classic book “Code Complete” (second edition, page 557):

To give a concrete example of the importance of warnings, many of us have had to migrate applications developed for iPhone OS 2.x to the 3.0 operating system, mostly because failure to run on the new version of the OS was ground for removal from the App Store. That moment of truth, the rebuild of the Xcode project, unveiled a plethora of compiler warnings, most due to deprecated methods, like the tableView:accessoryTypeForRowWithIndexPath: method of the UITableViewDelegate protocol, or the initWithFrame:reuseIdentifier: method of the UITableViewCell class (which, incidentally, are properly marked as such in the documentation, too).

Compiler warnings in Objective-C have a multitude of reasons:

Each @implementation *.m file should always present methods in this order:

Each logic group of methods should be separated from each other using the following lines (just type “#p” and hit the TAB key in Xcode to speed up the process):

The advantage of this approach is that later, you can use those #pragma marks to generate an automatic layout in the symbols pop-up of Xcode, as shown in the figure below.

You can get this pop-up window clicking on the “Jump Bar” of the current Xcode editor.

This means putting private methods definitions in a (Private) category on top of the *.m file. This will remove all compiler warnings (about “this class might not respond to this selector”) and will cleanly separate what’s public from what’s not.

describes a scientific method for debugging sessions, which is useful to remind in this context:

At the end of this document, [chapter_ios_coding_guidelines] contains generic and important coding conventions. You can start from this document to create your own.

The C preprocessor provides a number of standard macros that give you information about the current file, line number, or function. Additionally, Objective-C has the _cmd implicit argument which gives the selector of the current method, and functions for converting selectors and classes to strings. You can use these in your NSLog statements to provide useful context during debugging or error handling.

All Cocoa objects (everything derived from NSObject) support a description method that returns an NSString describing the object. The most convenient way to access this description is via Xcode’s Print Description to Console menu command. Alternatively, you can use LLDB’s print-object (or po for short) command.

Xcode 4 offers a simple way to generate a breakpoint whenever an exception occurs. A great idea when you need to track down application crashes.

In the break point navigator click the plus (+) symbol in the lower left corner. Choose "Add Exception Breakpoint". The exception breakpoint options are shown in [image_ios_exceptions_breakpoint].

Beware though that all exceptions will be logged by this breakpoint, not only uncaught exceptions, but also those surrounded by @try / @catch statements. You might want to check the "Automatically Continue after Evaluating" checkbox to avoid stopping too often.

You can use -retainCount to get the current retain count of an object. While this can sometimes be a useful debugging aid, be very careful when you interpret the results. For example:

The system maintains a set of singleton strings for commonly used values, like the empty string. The retain count for these strings is a special value indicating that the object can’t be released.

Another common source of confusion is the autorelease mechanism. If an object has been autoreleased, its retain count is higher than you might otherwise think, a fact that’s compensated for by the autorelease pool releasing it at some point in the future. You can determine what objects are in what autorelease pools by calling _CFAutoreleasePoolPrintPools to print the contents of all the autorelease pools on the autorelease pool stack:

A common type of bug when programming with Cocoa is over-releasing an object. This typically causes your application to crash, but the crash occurs after the last reference count is released (when you try to message the freed object), which is usually quite removed from the original bug. NSZombieEnabled is your best bet for debugging this sort of problems; it will uncover any attempt to interact with a freed object.

The easiest way to enable zombies is via Instruments, as shown in [image_ios_zombies_instruments]. However, you can also enable zombies in Xcode, as shown in [image_ios_zombies_xcode]. To do that, hit the "Option-Command-R" key combination (or select "Product / Run" while holding the "Option" key) and select the "Diagnostics" tab; check the "Enable Zombie Objects" option in the dialog.

If you’re using Key-Value Observing and you want to know who is observing what on a particular object, you can get the observation information for that object and print it using using LLDB’s print-object command.

You can set the NSShowNonLocalizedStrings preference to find strings that should have been localized but weren’t. Once enabled, if you request a localized string and the string is not found in a strings file, the system will return the string capitalized and log a message to the console. This is a great way to uncover problems with out-of-date localizations.

UIView implements a useful description method. In addition, it implements a recursiveDescription method that you can call to get a summary of an entire view hierarchy.

If you’re working on an app that uses Core Data, it’s inevitable that you’ll end up in the debugger and need to dig around in the object graph. You’ll also quickly realize that Core Data’s -description of an object isn’t terribly helpful:

Core Data’s documentation is excellent, but surprisingly doesn’t cover some of the tricks you can use to examine managed objects in the debugger.

The first trick is to fire a fault on the object using -willAccessValueForKey. After that, you can see what’s really there:

You might also be surprised when you try to access one of the properties of the object:

Remember that these properties are defined as @dynamic and there’s a lot of work done by Core Data at runtime to provide the implementation. The solution here is to use the KVC accessor -valueForKey: to get the object’s value:

Often, you’ll want to examine the relationships between objects. As you can see in the output above, the attribute itemContainers, which is a to-many relationship, is a fault. To fire the fault, get all the objects from the set:

Finally, you may be using Transformable attribute types. The state attribute above is an example. If you’d like more information than (…not nil…), use the KVC getter and you’ll see that it’s an empty NSDictionary:

To test your applications in your simulator under different network conditions, you can use the Network Link Conditioner, available as a separate download from Apple.

Get the Hardware IO Tools for Xcode. To do this, go into the Xcode menu, then choose “Open Developer Tool” and finally “More Developer Tools…”. You’ll be taken to Apple’s developer downloads site; you should download the “Hardware IO Tools for Xcode”.

The resulting disk image will contain (amongst other things) a preference pane called “Network Link Conditioner”. Double-click the prefpane file and authenticate to allow it to be installed. You’ll then see the pane in System Preferences, as shown in [image_ios_network_link_conditioner].

You can choose from various different types of network conditions using the Profile popup menu, shown in [image_ios_network_link_popup].

QuincyKit is an open source system for automatic crash reporting, composed of client iOS and OS X clients and a PHP + MySQL server backend application. The client frameworks are able to report, upon restart, a complete crash report to the backend application, as shown in [image_ios_quincy_dialog].

To install a working version of QuincyKit, the following steps are required:

Server application:

Client framework:

QuincyKit can also symbolicate crash logs, but this requires a more complex setup, taking care of the following steps:

QuincyKit can even be configured to push notifications to developers whenever a certain number of crashes is met, via email or using Growl.

NSLogger is a very powerful open source utility that allows developers to monitor in real time the log messages of their applications, as testers of beta users interact with the application in a local network. Applications that include the NSLogger code can interact automatically with a desktop OS X application, displaying not only text but also binary data such as images.

[image_ios_nslogger_window] shows a typical NSLogger session.

To include NSLogger in an Xcode project, follow these steps:

The desktop OS X application is bundled as an Xcode project, that can be built and run off the box. When the application detects a new instance of the application running, it opens a new log window, and each session can be saved and viewed separately. The log output can be filtered and searched very easily.

It is very easy to use; whenever you create a new project, Xcode prompts the developer whether to add unit tests to it, as shown in [image_ios_sentest_dialog].