Xcode 4.2 building for iOS 3.1.x and older devices

the extra effort it takes to maintain backward compatibility with iOS 3.1.x is getting a little greater with each update to Xcode and iOS. The release of Xcode 4.2 and iOS 5 added a couple of extra hurdles if you want to support older devices and pre-iOS 4.2 releases.

Xcode iOS Simulator and Debugging Support

When Apple released iOS 5 and Xcode 4.2 they removed iOS Simulator support for iOS versions prior to iOS 4.3. If you upgraded from an earlier version of Xcode you may not have noticed but they also made the iOS 4.3 simulator an optional download. If you do not see the iOS 4.3 simulator in the run destination popup you need to use the More Simulators option to download it.

Since the simulator no longer supports iOS versions prior to iOS 4.3 the only way to test apps on those earlier releases is to test on a device. That assumes of course that you still have a device running the iOS 3.1, 4.1 or 4.2 release that you need.

There is an additional step required if you are targeting iOS 3.1 or iOS 4.1 devices in that you also need to download the device debugging support. There are separate installs for iOS 4.x and iOS 3.x devices. When you plug in a development device running a pre-iOS 4.2 version you get prompted to download the appropriate package:

You can also check and install the packages from the Downloads tab of the Xcode preferences:

Building for armv6 Devices

Having got all the optional Xcode support files downloaded you may think you are done but if you build and run on older armv6 devices you may still hit a problem. Typically the build succeeds but fails to launch on the device. The problem is with older armv6 devices such as the second generation iPod touch and the iPhone 3G.

The default for iOS is now armv7 - otherwise referred to as $(ARCHS_STANDARD_32_BIT). To build for the older devices you need to add armv6 to the Architectures build setting. The default in Xcode 4.2 is now as shown below:

To add armv6 select the existing architecture setting and then using “Other…” to bring up the dialog and add an entry with the value “armv6 armv7” to return to building the “fat” binary. Ensure you do this for each target in the project. The setting should look as follows once you are done:

Now you should finally be able to build and run on pre iOS 4.2 devices.

Xcode 4 DerivedData and cleaning the build directory

The added capabilities in Xcode 4 can at first be a bit overwhelming to anybody migrating from Xcode 3. For me this most often leads to frustration at not being able to quickly do something in Xcode 4 that I could previously do easily in Xcode 3. However with time this frustration goes away as I develop a greater understanding of why Xcode 4 works a certain way (or I find a workaround).

To give a simple example, when building an iOS app for distribution with Xcode 3 I always liked to completely delete the build directory from the project to be sure that I got a clean build. Of course you could always clean a target (or all targets) from the Xcode menu but there is something reassuring about knowing that you are absolutely building everything from scratch.

Deleting the build directory in an Xcode 3 project was easy as the build directory was located inside the project directory so there was never any confusion about what to delete. With Xcode 4 if you take a look inside the project directory the build directory has disappeared.

Derived Data

With Xcode 4 came the concept of a workspace that allows multiple projects to be grouped together. Each workspace gets a unique set of symbol indexes, build products, window layouts, etc., otherwise referred to by Xcode as derived data. Since a single project can belong to more than one workspace this derived data is no longer contained under the individual project directory.

By default Xcode stores this data for all projects in a single shared folder under your home directory at the following location:

~/Library/Developer/Xcode/DerivedData

You can change this location from the Xcode preferences if you wish. If for some reason you want to go back to storing this data under the individual project directories you should change the Derived Data path to “Relative” and specify the directory name:

If you do go back to a project specific directory you may want to add the directory name to your .gitignore (or equivalent) file so that you do not check the files into your source code repository.

The actual directory name used for each projects derived data is named from the workspace name and a hash of the directory path so you end up with directory names such as AirPrinter-bcewjhqefskmeegzucuwvqazdjlo for a workspace named AirPrinter. Inside this directory are subdirectories for Build, Index and Logs containing all of the derived data:

Cleaning

In Xcode 4 the Product > Clean menu option cleans up the build directory for all targets by deleting the app and dSYM files along with the precompiled headers. If this is not enough for your peace of mind you could navigate down to the correct DerivedData directory for your current workspace and manually delete the build directory. Luckily the Xcode team has taken pity on the paranoid and added a menu option to completely delete the build directory. To access the option open the Product menu and use the Option key to show the Clean Build Folder option.

After it is done the Build sub-directory no longer exists under the DerivedData directory so you can clean build with confidence…

Xcode Project Modernization

The rapid pace of change in the world of iOS development means that it is easy for old projects (which is just about anything more than about 6 months old) to get left behind. Each time a major new version of iOS is released there are SDK methods which become deprecated and project and compiler settings which if not obsolete may no longer be considered best practise.

A new feature added with Xcode 4.1 makes it easier to check a project for outdated settings and if you choose update any that are considered to be issues. If you have a project that Xcode considers is in need of modernization it will flag the issues the first time you open the project. You can use the Issue navigator to see the issues and bring up a dialog window showing the full details similar to the one below:

The issues that I have seen so far relate to projects created with an older 3.x version of Xcode and also to GCC compiler settings. In this example, Xcode offers to upgrade the project from using GCC to LLVM GCC and at the same time remove some now obsolete GCC compiler settings.

You can deselect any of the changes if you want and then have Xcode apply the changes. Xcode will offer to take a snapshot of the project before making the changes if you want though I consider that unnecessary if you are using source control.

If you decide you do not want to make the change right now you can deselect individual changes. This removes the project issue until you run the Modernize Project command again using the button at the bottom of the project settings page or from the menu (Editor > Modernize Project).

Hello Lion, Goodbye Xcode 3

So today was finally the day that Lion went public. I was thinking earlier in the week that I would avoid the hype, wait a few days and let everybody else find all the problems. Of course, that was never going to happen. So here is my experience of upgrading from an iOS developer perspective.

First Things First

Before attempting a major OS upgrade I first made sure I had a bootable backup of my current Snow Leopard install on an external firewire drive. I use Super Duper to create regular, bootable backups so this is no big deal. Just to be sure I kicked off an extra backup and once done did a test boot using the external drive to ensure I had an easy return path to Snow Leopard if things went badly wrong.

The Mac App Store Experience

The actual download and upgrade of Lion via the Mac App Store was a slow but painless process. It took me nearly an hour to download the over 3GB installation file. The actual upgrade process was also very slow.

For the first twenty minutes or so the installer seemed to be stuck with the estimated time remaining indicating 33 minutes. Eventually it started to move so if this happens to you don’t panic. I am not sure if it made any difference but I unplugged all my external peripherals (drives, USB devices and second monitor). Also note that once the upgrade is complete Spotlight starts indexing the files on your drive so expect it to remain sluggish until it is finished.

Overall the upgrade via the Mac App Store was a painless experience but I will feel happier when I have a Lion installer burned to a DVD for emergency use.

Xcode 4.1

Now that I had Lion installed the fun really began. At this point I had three versions of Xcode installed on my system none of which actually worked with Lion. For the record the versions I had were as follows:

• Xcode 3.2.6 - installed in /Developer
• Xcode 4.0.2 - installed in /Xcode4
• Xcode 4.2 beta - installed in /Xcode42

Now as the title of this post suggests Xcode 3 is not supported on Lion so it is finally time to wave it goodbye. To be honest I have not used Xcode 3 for months so I will not miss it but if you have a reason why you need to remain with Xcode 3 you should probably avoid upgrading to Lion. On the other hand if you are still using Xcode 3 only to avoid the Xcode 4 learning curve it is time to make the switch.

At the time of writing this post the latest, released version of Xcode on the iOS Dev Center is Xcode 4.0.2 but that is a Snow Leopard only version of Xcode. For Lion you need to download Xcode 4.1 from the Mac App Store. If you try to run Xcode 4.0.2 it will complain that it requires OS X 10.6.

Xcode 4.1 is a free download and what is actually downloaded is the Xcode installer. Once the download is complete it gets added to the dock (I hate that the Mac App Store does that) but you can also find it in the Applications folder. The interesting thing to note is that it will only install to /Developer. The installer spotted that I already had an existing version of Xcode (Xcode 3.2.6) installed in /Developer which it moves to /Developer-old.

One issue I had with installing Xcode 4.1 is that it blocked at a certain point with a dialog indicating that I needed to exit iTunes. This is fairly normal for an Xcode installation and normally when you exit iTunes the installation continues. For some reason this did not seem to work this time and I had to manually kill the iTunesHelper process to get it to continue.

The other more serious problem I had was that Xcode 4.1 crashed with an internal logic error whenever I tried to run it. In some ways this is not surprising given that I had three previous versions of Xcode installed on my system. To clean things up I first uninstalled the developer tools as follows:

sudo /Developer/Library/uninstall-devtools

I then rebooted and rerun the Xcode installer (in the Applications folder) which then offered to update the development tools on my boot drive. After this Xcode 4.1 worked fine.

Beta Versions

Since I am experimenting with the iOS 5 beta I also had the iTunes 10.5 ad Xcode 4.2 beta versions installed on my system. These are covered by the usual Apple NDA so I will just say that you also obviously need to download the latest Lion versions of these and reinstall.

After all of that I am back to having a working system. I just need to get use to scrolling in the opposite direction on my trackpad…

Update on Friday, August 5, 2011 by Keith

The installation issue with iTunes which requires you to manually kill the iTunesHelper process should be fixed in the Xcode 4.1.1 update now available in the Mac App Store

Passing Arguments with Xcode 4

The very first post on this blog was a tip on debugging core data on the iPhone that relied on launching the application with an argument. The very next post on Finding memory leaks relied on setting some environment variables. That was well over a year ago and a lot of have changed in the world of iOS including Xcode. The release of Xcode 4 brought a huge number of changes but that inevitably means you have to hunt around a lot at first until you figure out where various settings have ended up.

A big change with Xcode 4 was the introduction of schemes which has taken a number of settings which were spread across Xcode 3 and brought them all into a single place. Schemes also simplify things by dividing the settings into various phases (e.g. build, run, test, profile, archive). The ability to launch an application with a command-line argument or with an environment variable set is now found in the run settings of the scheme.

To access the current scheme use “Product > Edit Scheme…”, select the “Run” phase and then use the “Arguments” tab to set the “Arguments Passed on Launch” and any “Environment Variables you need.

I should add that the way Instruments has improved over the last year neither of these tricks is really necessary any more. The Leaks and Allocations tools in Instruments make it much easier to track down leaking objects and the Clang static analyzer helps prevent leaks in the first place. It took some time for Instruments to support core data running on iOS devices but now that it does there is also not much need to enable the SQLDebug argument.