- Creating New Projects
- Building Hello World the Template Way
- Using the Simulator
- The Minimalist Hello World
- Converting Interface Builder Files to Their Objective-C Equivalents
- Using the Debugger
- Memory Management
- Recipe: Using Instruments to Detect Leaks
- Recipe: Using Instruments to Monitor Cached Object Allocations
- Analyzing Your Code
- Building for the iOS Device
- Detecting Simulator Builds with Compile-Time Checks
- Performing Runtime Compatibility Checks
- Pragma Marks
- Preparing for Distribution
- Over-the-Air Ad Hoc Distribution
- Submitting to the App Store
Analyzing Your Code
The LLVM/Clang static analyzer automatically helps detect bugs in Objective-C programs. It’s a terrific tool for finding memory leaks and other issues, especially with Core Foundation and MRR code. In Xcode, choose Product > Analyze (Command-Control-B). The issue markers shown in Figure 3-15 guide you through all suspected leaks and other potential problems. Use the Issue Navigator pane to dive into each issue and walk through the logic that leads the analyzer to raise a flag of concern.
Figure 3-15. The Clang static analyzer creates bug reports for source code and embeds them into your Xcode editor window. Clang is useful for both MRR (as shown here) and ARC and provides reports specific to each compilation style.
Issues found by the static analyzer are not necessarily bugs. It’s possible to write valid code that Clang identifies as incorrect. Always critically evaluate all reported issues before making any changes to your code.
From Xcode to Device: The Organizer Interface
Choose Window > Organizer (Command-Shift-2) to open the Xcode Organizer window shown in Figure 3-16. This window forms the control hub for access between your development computer and your iOS testbed. It allows you to manage your credentials, add and remove applications, examine crash logs, and snap screenshots of your unit while testing your application.
Figure 3-16. Xcode’s Organizer window provides a central hub for managing your devices, certificates, and provisions.
The Organizer consists of two primary sections, the Library and the Devices, which have overlapping functionality. The library offers what is, basically, a merged inbox of device logs, provisioning profiles, and screenshots. These are broken out on a per-device basis in the Devices section.
In addition, the library has a Developer Profile section for organizing your developer certificates and a Software Images section for managing firmware bundles. The Devices list adds per-device consoles and per-device application management.
The Devices list shows the name and status of those devices you’ve authorized as development platforms. The indicators to the right of each name show whether the device is attached (green light) or not (white light). A blank to the right of the device name indicates a unit that has not been set up for development or that has been “ignored”—that is, removed from the active list. An amber light appears when a device has just been attached. Should the light remain amber colored, you may have encountered a connection problem. This may be due to iTunes syncing, and the unit is not yet available, or there may be a problem connecting with the onboard services, in which case a reboot of your iOS device usually resolves any outstanding issues.
A disclosure button appears to the left of each device, offering access to device information specific to that device. The items you find here mirror many of those listed in the Library section of the Organizer, including device logs, screenshots, and provisioning profiles. In addition, you have access to the device console and an application list.
Selecting a device name offers an overview of that device, including the capacity, serial number, and identifier of your unit. Here is also where you can load the latest firmware onto a device. Select a firmware version from the software pop-up and click Restore. Other items on this screen include overviews of current provisions, applications, device logs, and screenshots.
Be warned. Device downgrades are not always possible when you’ve upgraded to a newer (especially beta) iOS version. Downgrades must be authorized by Apple’s signature servers, even when you have stored the older firmware locally on your computer. These servers allow Apple to control which older firmware they will and will not allow to be installed, essentially providing them with a rolling firmware recall system that disallows older firmware over time.
Each developer license allows you to provision your personal or corporate iOS devices for testing. The Provisioning list shows a list of application provisions available to your unit. You can add or delete provisions from this screen.
Provisions determine which applications may or may not be run on the device. As a rule, only development and ad hoc distribution provisions are listed here, which makes sense. Distribution provisions are used to sign applications for the App Store, not for any specific device.
Get direct access to your crash logs by selecting a particular crash (labeled with the application name and the date and time of the crash) from the scrolling list on this screen. The crash details, including a stack trace, thread information, exception types, and so forth, appear in the right-hand pane. You can import and export logs using the buttons on this screen.
In addition to crash logs that you generate yourself, you can also retrieve crash reports from users from their home computer and from iTunes Connect. The iPhone automatically syncs crash reports to computers when units back up to iTunes. These reports are stored in different locations depending on the platform used to sync the device:
- Mac OS X—/Users/UserName/Library/Logs/CrashReporter/MobileDevice/DeviceName
- Windows XP—C:\Documents and Settings\UserName\Application Data\Apple Computer\Logs\CrashReporter\MobileDevice\DeviceName
- Windows Vista—C:\Users\UserName\AppData\Roaming\Apple Computer\Logs\CrashReporter\MobileDevice\DeviceName
iTunes Connect collects crash log data from your App Store users and makes it available to you. Download reports by selecting Manage Your Applications > App Details > View Crash Report for any application. There you find a list of the most frequent crash types and Download Report buttons for each type.
Copy reports into the Mac OS X crash reporter folder and they load directly into the Organizer. Make sure to load them into the device folder for the currently selected device. The reports appear in LIBRARY > Device Logs.
Once in the Organizer, Xcode uses the application binary and .dSYM file to replace the hexadecimal addresses normally supplied by the report with function and method names. This process is called “symbolication.” You don’t have to manually locate these items; Xcode uses Spotlight and the application’s unique identifier (UID) to locate the original binary and .dSYM files so long as they exist somewhere in your home folder. Xcode’s archive feature offers the best way to keep these materials together and persistently available.
As with crash logs in the Organizer, the reports from users provide a stack trace that you can load into Xcode to detect where errors occurred. The trace always appears in reverse chronological order, so the first items in the list were the last ones executed.
In addition to showing you where the application crashed, Crash Reports also tell you why they crashed. The most common cause is EXC_BAD_ACCESS, which can be generated by accessing unmapped memory (KERN_INVALID_ADDRESS) or trying to write to read-only memory (KERN_PROTECTION_FAILURE).
Other essential items in the crash report include the OS version of the crash and the version of the application that crashed. Users do not always update software to the latest release, so it’s important to distinguish which crashes arose from earlier, now potentially fixed, versions.
Each device offers a browseable list of installed applications. Use the ∇ button to remove selected applications. To install an application, drag it onto the list or use the + button to browse for it. Make sure your application is compiled for iOS and that the device is provisioned to run that application. If you self-sign an application and install it to a device—the how-to process for doing so is described later in this chapter—your application uses your team provision. When added, applications immediately sync over to the device. Applications installed from the App Store do not appear in the application list any more, the way they did in Xcode 3.
To download the data associated with an application, click the Download button to the right of its name. Choose a destination and click Save. Xcode builds an archive bundle and populates it with the contents of the sandbox—namely the Documents, Library, and tmp directories. Xcode also adds the folder to the Projects and Sources list, where you can browse the contents directly from the Organizer.
You can reverse this process and add edited sandboxes back to the device. Locate the bundle you created. Drop new items into any of the enclosed subfolders and then drag the entire folder back onto the application name at the bottom of the Summary pane. Xcode reads the new items and instantly transfers them to the device. This is a great way to prepopulate your sandbox with test material.
Use the console to view system messages from your connected units. This screen shows NSLog() calls and other messages sent to stderr (standard error output) as you’re running software on the tethered iPhone. You need not be using Xcode’s debugger to do this. The console listens in to any application currently running on the device.
In addition to the debugging messages you add to your iPhone applications, you also see system notices, device information, and debugging calls from Apple’s system software. It can be viewed as basically a text-based mess, but there’s a lot of valuable information you can gain. Click Save Log As to write the console contents out to disk or click Clear to empty the Console backlog.
Snapshot your tethered iPhone’s screen by clicking the New Screenshot button on the Screenshot display. The screenshot feature takes a picture of whatever is running on the iPhone, whether or not your applications are open. So you can access shots of Apple’s built-in software and any other applications running on the iPhone.
Once snapped, images can be dragged onto the desktop or saved as an open project’s new Default.png image (“Save as Launch Image”). Archival shots appear in a library on the left side of the window. To delete a screenshot, select one and press the Delete key to permanently remove it. Other features on this screen allow you to export images and compare images to highlight differences between separate shots.