When you write an iOS app, you always use the “Latest iOS SDK” as your Base SDK and choose a older iOS version as your deployment target. As on date, you would probably use iOS 6.1.2 as your based SDK and iOS 5.1 as your target.

Because your Base SDK is 6.x, you are free to use APIs and frameworks that were introduced in iOS 6. However, its your responsibility as a developer to ensure that you either fallback gracefully on older versions of iOS either by providing alternatives or disabling the feature altogether.

For example, if the feature that you are implementing is “Sharing on Facebook”, you should be using the built in Facebook sharing (SLComposeViewController) on iOS 6 and fallback gracefully by sharing using the Facebook’s official SDK for iOS 5 devices.

Failing to do this will result in your app crashing on a older operating system.

Preventing crashes

When your deployment target is not the same as your Base SDK, you need to ensure three things to prevent your app from crashing.

1. Check if every framework you are linking against is available in all versions of iOS you are deploying to.

2. Check if every class you are using is available in all versions of iOS you are deploying to,

3. Check if every function you are using is available in all versions of iOS you are deploying to.

Framework Availability

See if all the frameworks you are linking against are available on all operating systems you are deploying to. If a specific framework is not available in For example, if you are linking against Social.Framework introduced in iOS 6, on an app that is deployed on iOS 5, your app will crash immediately at start up. The way to fix this crash is to weak-link the framework.

Fairly straight forward. You might be linking against a fairly limited number of frameworks and it’s easy to check them.

Class Availability

Sometimes an existing framework like UIKit or Foundation will have additional classes added. UICollectionView is a good example. If you use UICollectionView, you should ensure that, you either hide those UI on older devices, or using alternative UI on older devices by conditionally checking for availability of class.

You do that by

if([UICollectionView class]) {
 // iOS 6 specific code
} else {
 // iOS 5 specific code

Slightly tricky.

Method Availability

Sometimes an existing class will have new methods added. An example would be registerClass:forCellReuseIdentifier: in UITableView. This method is available only from iOS 6. You normally check for method availability using respondsToSelector and use it if the method is present.

Keeping track of method availability is arguably harder than the other two.

Meet Deploymate

Deploymate is a third party solution to free you from worrying about the last kind of crash, method availability check. All you need to do is to open your project in Deploymate and “Analyze” it. Deploymate will report if you are using any APIs that are not available in your deployment target operating system version.

By default Deploymate runs your code against the “Deployment Target” you set in your project. You can even change this setting without changing your project setting and “Analyze” again. So, even if your project’s deployment target is 5.1, you can try if it runs on iOS 5.0 using Deploymate and even change your project to deploy to iOS 5 devices.

Features missing

While the guys behind Deploymate has indeed done a great job, (in fact Deploymate is something that I would expect Apple to do) Deploymate, as on date doesn’t track wrong class usage or missed weak-linking on frameworks. I seriously wish those features are their highest priority. Nevertheless, the app is kind of complete now.


You can read more about Deploymate on their website here. The app is on sale for $9.99. I just bought it and this is probably the best $10 you would have ever spent on an app. Get it now.


Follow me on Twitter