Smartphones & Lighting Consoles

Before I started this whole programming lark, I used to work in theatres designing, rigging, and programming lighting. Just as we’ve seen smartphones bring rapid developments to the mobile space, the same technology (touch interfaces and embedded technology) has brought a lot of change to lighting.

For example, here’s a couple of desks I used to program on a lot - an ETC Express and a Strand 300.

They have a couple of things in common: lots (and lots) of buttons and faders, and a user interface that is a little…functional (think ASCII and DOS).

But here’s the latest and greatest in lighting control - the ETC Eos Ti:

…what’s changed? Well, a lot fewer faders for one thing. And there’s the two giant touch-screens up top (think two iPads glued into a lighting console). Oh, and the secondary touch-screen used as a color palette amongst other things on the right hand side. The rise of tablets and touch interfaces has brought benefits far beyond the world of mobile.

ITV, Samsung, and Exclusivity Deals

For a very long time, I used a Samsung Galaxy S2 as my Android phone (I engineer iOS apps, but it’s good to know what’s going on the world outside Cupertino). Unhappy with the long, long waits for software updates from Samsung, I switched a few months ago to the Nexus 4.

Being produced by Google, the Nexus 4 is the flagship Android device - so naturally you’d expect it to be an advertisement for all things Android. Unless, that is, you want to watch ITV on it.

For the benefit of those not in the UK, ITV is one of the largest TV networks in the country. Last week, they made a change to their Android app: for the next few months, at the very least, it is exclusive to Samsung devices. Here’s what ITV had to say:

> The fragmentation of the Android ecosystem is well known. Therefore, as a commercial broadcaster, it makes sense for us to partner with the leading manufacturer of Android devices to further increase our technical knowledge of the operating system.

This makes little sense: the Nexus 4, for example, is the recommended device for the development of the Android OS itself. If I was developing an Android app and wanted to maximise compatibility I’d probably target the reference device as standard.

Although ITV frame this as a technical decision, we should probably be realistic - maybe Samsung provided financial or development support to maintain some level of exclusivity. Either way, I personally don’t see an benefit for either party.

Why it’s not great for Samsung

Personally, I don’t see Samsung getting their money’s worth here. Are people going to buy Samsung handsets so they can download the ITV Player app? Presumably not, because the exclusivity period ends in a few months. People will buy Samsung handsets because Samsung spend far more money than anybody else advertising them. And, as other people have noted, it doesn’t do Samsung many favours with regards to their Google relationship.

Why it’s not great for ITV

The ITV Player app isn’t exactly doing very well on the store:

…if you are going to limit it to select handsets on the basis that you want a more stable experience then you’d better have made some improvements. Unfortunately, this doesn’t seem to be the case judging from the reviews. Additionally, many existing users who are running older versions of the player on non-Samsung devices are providing one-star reviews expressing their displeasure.

It comes down to this: exclusivity deals are not, in of themselves, a bad thing (although Trusted Reviews has a great article that offers a counterpoint to this). They can provide cash-limited companies with money to develop interesting and exciting apps. But turning a previously widely available app into an exclusive deal: that’s not so good. Users don’t like it, and I don’t see the benefit for brands…especially if your disgruntled, locked out users start giving you bad press.

A Guide to BaaS

Introduction

Some of my most popular posts are those about mobile backend providers Parse and StackMob. It’s been a few months since I last looked at them, and since then much has changed - so I’ve decided to take a comprehensive look at both the large and small players in the mobile backend space.

What is BaaS?

BaaS stands for backend as a service, and is used to describe a company that provides a way for front-end developers to ‘plug in’ to cloud storage, user management, push messaging, and the like without having to write and support their own server architectures.

If you’ve read some of my other blog posts you’ll know I’m a fan of BaaS. It’s not for everyone - large apps with millions of users, in particular, will of course benefit from their own internal systems - but if you’re starting out and need a quick and efficient data storage system that works across multiple platforms you can’t go wrong with BaaS.

The BaaS industry has come to be quite closely associated with mobile, partly because many companies sprung up in response to a need by native application developers for secure, reliable data management systems. There’s nothing to stop you using a BaaS provider to power your desktop web apps, but I’ll be mainly focusing on mobile here since that’s my field of interest.

BaaS Providers

Wikipedia lists some fifteen different BaaS providers - some large, and some very tiny. There are two main players in the market, the Facebook bound Parse, and StackMob. In addition, a number of smaller players are all vying for your business.

I’ve chosen to look at five different BaaS platforms and compare their strengths and weaknesses. Each provider has a brief review, followed by a pricing comparison and some general recommendations for what to look out for. Hopefully you’ll find it useful - and I’m always happy to answer questions either through Tumblr or Twitter (@objclxt). You can either read on, or jump to the provider you’re interested in:


image

Parse

Although not the oldest in the game, Parse is probably by far the most well known BaaS provider, if only due to it’s acquisition by Facebook last week.

Features

As standard, Parse offers support for data synchronisation, push notifications, social integration, and custom code via server-deployed JavaScript. Parse has official client libraries for iOS, OS X, Android, JS, Windows 8 (desktop and phone), and .net. There are also many third party libraries available for languages such as Ruby, PHP, Python, Go, and the like. Currently, Parse’s first-party libraries are all closed source, which is a shame (hopefully this will change under Facebook). Parse is also well known for its excellent documentation, which includes complete sample applications and walk-throughs.

Server-side code is supported through Parse’s Cloud Code feature, which is JavaScript based. In addition to your own custom code, you can also plug into third-party modules to directly integrate with services such as SendGrid, Stripe, Twilio, Mailgun, and the like. Parse also recently added support for static hosting, which allows static and JS based pages to be served up quickly and easily.

Pricing

Parse charges on a per-API request model, plus storage. Anything below 1 million requests is free, which for many low-usage projects will be more than sufficient. Their standard ‘pro’ plan provides 15 million API requests, 15 million push notifications, and 10GB of storage for $199 per month. Enterprise plans are also available with dedicated SLAs and the like.

To put that in some perspective, 15 million API calls a month lets you support 50,000 active users at 300 calls per month.

Who Uses It?

I do! Also, a number of large brands and agencies, including IDEO, Cisco, Hipmunk, BBDO, and Deloitte (it should come as no surprise that agencies tend to be big users of BaaS - they often lack backend expertise at scale, and many of their apps are for short-lived campaigns).

Pros

  • Acquired and backed by Facebook (…or a con, depending on your viewpoint)
  • Wide range of well supported SDKs
  • Excellent documentation

Cons

  • Acquired and backed by Facebook (…or a pro, depending on your viewpoint)
  • Client libraries are closed source
  • Custom ‘cloud’ code somewhat limiting compared to other providers
image

Stackmob

Stackmob has been in the BaaS business for a while, and along with Parse are one of the bigger players in the space. They aggresively compete, to the point where StackMob posted a “migrate from Parse tutorial” the day after Parse’s acquisition.

Features

Stackmob offer broadly the same feature-set as Parse, but with a few additions such as distinct production / development environments, API versioning, and a more comphrehensive custom code framework that supports server-side Java or Scala. Many of these advanced features are made available on a modular basis in the StackMob marketplace (but more on that below). Both the Android and iOS client libraries are open source, and available on GitHub.

Pricing

StackMob recently changed their pricing model from a usage based to a more generous ‘freemium’ model. Basic API access is both free and unlimited, but additional functionality can be ‘unlocked’ through the StackMob marketplace (if you’ve used Heroku this marketplace model will be familiar to you).

The downside of this is that depending on what you need this can end up being very expensive. For example, let’s say we want to support custom code and 5 million push messages a month. Both of these features are included in Parse’s Pro package, but with StackMob you’ll need to purchase each module separately. This ends up costing $399 for the push and $199 for the custom code, or a total of nearly $600. That’s three times as expensive as Parse for broadly equivalent functionality.

As a result, using StackMob could require some careful planning to make sure you only use the modules you absolutely require. Don’t forget to think about your future requirements when pricing up or you might have a very expensive surprise!

Who Uses It?

According to StackMob’s rather limited case studies page, the platform is used by Atari, ShopKeeper, and Meexo, amongst others.

Pros
  • Unlimted API calls as standard
  • Open source client libraries
  • Good documentation
Cons
  • Free plan has unlimited API calls, but missing functionality such as HTML5 hosting
  • Paid modules quickly add up
image

Kinvey

Based out of Boston (woo), Kinvey have been around for a couple of years with their BaaS offering. They were recently selected as a Facebook Technology Partner.

Features

Kinvey offers the usual plethora of data storage, user management, push notifications, and social integrations. They also offer versioned APIs and usage analytics. Additionally, Kinvey’s enterprise plans support existing authentication systems such as LDAP or OAuth, along with data links into products such as Salesforce CRM.

Pricing

Kinvey bases their pricing on the number of active users. An ‘active user’ is defined as one that has made an API request that month. I’m not the biggest fan of this model, because it can makes apps with large numbers of users but with small backend requirements rather expensive. Kinvey do offer API pricing as an alternative, but you’ll need to get in touch with them directly to discuss further.

Who Uses It?

A number of marketing agencies use Kinvey, presumably on behalf of their clients, as well as Johnson & Johnson.

Pros
  • Enterprise-level features such as LDAP, Orcale, Salesforce, and OAuth support (for those on enterprise plans)
  • Agencies can benefit from Kinvey’s referral program
Cons
  • Default ‘active user’ pricing model not suitable for all apps
  • No ‘custom code’ support a la Parse or StackMob, although backend business logic is supported
image

FatFractal

FatFractal also seem very responsive to customer requests and feedback - I actually got in touch to ask whether they supported bulk data export whilst writing this post, and they implemented it into their system overnight.

Pricing

Currently, FatFractal provide up to 3 million requests and 5GB of storage free of charge whilst in public beta. Their gold plan provides 12 million API requests and 15GB of storage for $200 per month. You should, however, be aware that unlike other providers, FatFractal charge for outgoing bandwidth overages. The gold plan include 12GB of outgoing bandwidth, and it’s $0.15/GB after that. I doubt for most people this would be a problem, but if you’re building an app that’s going to require significant bandwidth (video sharing, perhaps) you’ll need to take this into account.

Who Uses It?

In FatFractal’s defence, they are still in beta and have a limited client list as a result. They have a number of testimonials from smaller developers and agencies, and list a couple of minor apps in production.

Pros
  • Responsive customer service, and quick to reply to feedback
  • Very developer-centric business, which may appeal to some
Cons
  • A smaller player in the business
  • At the time of writing, still in beta
image

QuickBlox

QuickBlox’s unique selling point is its discrete ‘modules’, such as video and text chat, leaderboards, and the like. More experienced developers may find this restricting.

Pricing

QuickBlox’s pricing is probably best described as ‘opaque’. Their free tier offers unlimited API calls, and a 10GB traffic/storage limit. If you exceed this limit you’re offered three options - switching to an enterprise account (which requires a sales call for a quote), paying the hosting costs your app is consuming plus a 10% management fee (which, again, requires a sales call to get a quote), or cross-promotion sponsorship (…yep, that needs a sales call too).

It is a shame that QuickBlox are not willing to put any pricing information above their free tier on their site.

Who Uses It?

A variety of small apps, mainly being developed by marketing agencies, including the Official Dane Cook App(?) and a fan app for Liverpool FC.

Pros
  • Modular approach may be appealing to novice developers
Cons
  • Must call their sales team to get any pricing information
image

Helios

Helios is Heroku’s answer to the rise of ‘all in one’ BaaS providers. It’s an open-source backend framework that you can deploy directly to Heroku, or your own hardware if you prefer. It’s written by the highly respected Mattt Thompson, and combines data synchronization, push notification, in-app purchase, analytics, and passbook management into a single attractive GUI. There’s no single client library - rather, a collection of existing libraries such as AFIncrementalStore that integrate into the backend system.

Pricing

As an open-source framework, Helios is completely free. You’ll need to pay for hosting though - either on your own hardware, or through a provider such as Amazon Web Services or Heroku. Since Helios is backed by Heroku I’m going to use that as a benchmark for pricing - a basic setup with a production database and several dynos will be around $120 per month.

Who Uses It?

Many popular apps use Helios’s discrete client libraries - I’m not aware of any apps currently using Helios itself.

Pros
  • It’s free!
  • Totally open source, with hosting flexibility
  • Created by one of the best mobile developers out there
Cons
  • OK, not really BaaS as you’re going to have to manage it!
  • Currently best suited to iOS apps only
  • If you’re not comfortable with basic server admin this isn’t for you

Cost Comparison

I’ve tried to break down both the free tier limits and the price you might expect to pay for ‘typical’ use with each provider. I’ve defined ‘typical use’ as an app with 40,000 active users, 12 million API calls per month (or 300 per user), and 500,000 push notifications.

Parse StackMob FatFractal Kinvey QuickBlox
Free Tier Limit 1m calls ‘unlimited’ * 1m calls (whilst in beta) 100 app users 10GB traffic
‘Typical’ use $199 $399+ * $200 $293 Unknown

* StackMob’s free tier has unlimited calls, but additional functionality that is free with other providers (such as HTML5 hosting or custom code) may cost extra. I have included StackMob’s Push module ($399) in estimating typical cost, but other modules such as custom code will add on to this figure.

Conclusion

FatFractal seems to be quite developer focused and led, whereas QuickBlox seem to be going after marketing agencies and judging by their lack of clear pricing information aren’t particularly interested in the indie space. I think Kinvey have a pretty exciting product, and their focus on enterprise integrations mean those building internal B2B apps may want to consider them.

I was initially very excited with StackMob’s new pricing structure, but the modular model they’re going for means it becomes very expensive to match Parse’s $199 plan functionality. Once you’ve added collaboration, push messaging, custom code, and hosting into StackMob’s package it becomes a very expensive proposition.

Finally, of course, there’s Parse. If you harbour negative feelings torwards Facebook you might have already made up your mind - personally, I’ve been really impressed with the speed at which Parse have added to their product, and I enjoy working with their client libraries. Who knows exactly what Facebook will do with Parse long term, but post-acquisition they’re still adding new features such as HTML5 hosting.

Don’t forget, the usability of the client libraries is just as important as the features and pricing. You’ll be working with your chosen provider’s APIs and SDK a lot - you want the experience to be pleasurable. I recommend taking a look at sample code, and maybe trying out the various libraries yourself.

Q:Hi Nick, I am considering using Parse for a project and I read your post evaluating backends. You seem to really love Parse and have really looked at the other platforms too. Basically my biggest concern is getting started with Parse and finding out half way through that I can't finish my app. What is your experience with scale on Parse? It seems like you can also do a lot with StackMob but what about Parse makes it your top choice? I have to say I am not a dev...

svartan

This is a good question - I use Parse for large-scale apps with 500,000+ user accounts, and I haven’t noticed or had any reports of poor performance. Parse do limit you to around 40 API calls per second on their Pro plan, although that’s more than enough for most use cases. If you architect your app smartly you can always reduce the number of calls you need to make.

In terms of architecture, both Parse and StackMob are pretty solid. To be honest, Parse and StackMob are pretty comparable, and it’s more personal preference than anything else that means I use Parse. StackMob have changed their pricing structure quite a bit since I last compared them though - I am writing a very long comparison of a number of BaaS providers to get on the blog later this month.

The issue you’re more likely to run in to, on both Parse and StackMob, is that you’ve designed your app to manipulate data in some way that isn’t very easy to do on a BaaS platform (versus having direct access to your own database). But if you go in up-front knowing that you’re only really able to get at your data via a REST API / client libraries (vs stored procedures, direct DB access, etc) you’ll probably be fine.

Hope that helps you out!

Parse / Facebook: What Now?

You’ve probably read that this week Facebook acquired Parse, the mobile BaaS service. I’ve been using Parse for quite a well in production, and if you’ve read any of my previous posts you’ll know I quite like the service (see here, here, and here).

So what now? Does Facebook acquiring Parse change anything? Well, if you go by the press releases, no - it doesn’t. But perhaps there’s more too it than that. What should you be doing if you’re either an existing customer (like me), or someone who’s been thinking of using the service? Here’s my own thoughts on the subject.

You Already Use Parse

A lot of what you do next is going to depend on your own gut feeling. Some people have quite a visceral reaction to Facebook - I’m not one of them. What I will say is that the last time Facebook bought something I used (face.com) they ended up shutting down the APIs. But Parse is considerably bigger, and more importantly is used by some sizable customers. I personally don’t see Facebook cutting them off - and I suspect new customers will be welcomed for some time as well.

The bottom line is this: whenever you use any third-party provider to manage critical infrastructure in your apps you’d better have an escape plan. Companies get acquired, go bust, or retire products all the time. This isn’t an issue unique to Parse. If you’re not planning for the worst you’re sowing the seeds for a big headache in the future.

Parse already offer a mass-export feature that gives you all your data in JSON. You can use this, along with the Parse APIs, to migrate over to another provider fairly easily (although some scripting on your part may be required). One provider (Stackmob, who I’ve reviewed here before) even have a semi-automatic migration tool available.

You’re Deciding on a BaaS Provider

Again, this is going depend on how you feel about Facebook. If you’re not a fan, you’ve probably already made your choice. Here’s my two cents: even if Parse keep supporting existing customers, it’s almost certain that at some point in the future the product is going to change in a fairly significant way. I don’t see Facebook gaining any value from running Parse as an entirely separate entity.

I really like Parse as a product - I’ve used it in several production apps. Would I use it now? I’m not sure. I don’t necessarily think any of the competitors out there (Stackmob, Appcelerator, Kinvey, Fat Fractal, to name a few) are any more secure. If anything, financially speaking Parse is now top of the pile.

So…what?

I appreciate I haven’t really provided many direct answers. One thing this should really re-inforce, regardless of your BaaS provider, is that you need a back-up plan. To help with that I’ll be posting a new backend-as-a-service comparison in the coming weeks, updated to take into account all the recent changes in the marketplace.

Mantle: Easy JSON Models in Objective-C

OK, so it’s not a very exciting topic - but still, it can often be a pain to convert JSON into Objective-C objects. There’s a lot of boilerplate code, and you invariably end up with something like this:

…and that’s just to decode from JSON. If you need to subsequently archive your object back to JSON you’ll end up with even more brittle and lengthy code, thanks to encodeWithCoder and its counterparts. Finally, you’d better hope your JSON never changes, because in the example above if there’s no url field in the dictionary an exception is going to get thrown.

I had to deal with this problem recently - I was working with a quite complex JSON API, and I needed something to help me manage my models. Fortunately, Github have open-sourced a framework used in their own Mac application called Mantle. Mantle aims to simplify the process of working with JSON in Objective-C, particularly in places where something like Core Data might be overkill. It works without NSCoder, and uses @property declarations to provide default implementations.

Here’s an implementation of the Article example above, but rewritten to use Mantle:

A really simple JSONKeyPathsByPropertyKey method maps JSON to properties, and reversible transformers allow things like dates, URLs, or other custom formats to be both encoded and decoded easily. The value transformers also handle missing or nil fields, meaning you don’t have to worry about exceptions.

I’m really enjoying using Mantle, and it’s made my code cleaner to read and easier to maintain. The source for Mantle, along with pretty comprehensive documentation, is available on GitHub, and you can use it in your own projects via the ever reliable CocoaPods.

iOS Debugging: Three Timesaving Tools

Debugging is twice as hard as writing the code in the first place
Brian Kernighan - The Elements of Programming Style

Debugging your own code may be a chore, but debugging somebody else’s can be downright painful. A particularly bad experience last week reminded me that debugging is as much a skill as writing code itself - and just like programming, there are lots of tools that can make it both easier and even enjoyable.

Here are three really useful tools that I use when debugging iOS applications.

Technical Note 2239

Hidden away on Apple’s developer site is Technical Note 2239, or iOS Debugging Magic. It’s packed full of tips and tricks to help the frustrated iOS debugger get to grips with XCode. Unfortunately, it’s also slightly out of date, written for iOS 4.1, XCode 3, and GDB (rather than the newer LLDB debugger now standard for iOS development).

Still, it’s still broadly applicable, and it’s the only place on Apple’s site where recursiveDescription, a category extension on UIView that lets you print out a view’s complete hierarchy, is documented. This alone justifies its existence:

DCIntrospect

Command line debugging is extremely powerful, but as many web developers will tell you being able to visually debug can be just as useful. Although Apple provide some tools to do this (such as the Core Animation Instrument), a number of third party options are available to help with layout problems.

DCIntrospect is one such popular library - designed to be used with the iOS simulator, it enables a number of keyboard shortcuts to allow dynamic manipulation of views.

Installation is particularly straightforward, so DCIntrospect is a good option if you need to quickly debug more complex view hierarchy or display problems.

PonyDebugger

PonyDebugger is one of the more complex iOS debugging tools - it requires both a client on device and a server on your development machine - but it’s arguably worth it in the long run. Once installed, you can remotely debug network traffic, Core Data, and view hierarchies using Chrome’s Developer Tools. It’s maintained by the good people at Square.

The networking traffic tools in PonyDebugger supplement, rather than replace, a traditional proxy. Because networking traffic is forwarded rather than sniffed traffic sent over HTTPS/SSL is viewable without needing any special certificates. The Core Data browser is also a nice touch, and is directly integrated into the traditional Chrome dev tools ‘resources’ tab. One particularly nice feature of PonyDebugger is its ability to convert an app’s view hierarchy into a HTML-like format that can be immediately edited, just as you would a normal web site within Chrome’s developer tools.

All of these features do come at a cost, namely a somewhat complex installation - I’d recommend using CocoaPods to handle the client library. You should take care for both DCIntrospect and PonyDebugger to only enable them in your debug builds, as you definitely don’t want either library to end up in your production code.

Helios: A New iOS Open Source Backend

If you’ve read my previous posts you’ll know I’m a big fan of Parse and other Backend-as-a-Service providers. However, they’re not for everybody - especially if you need control of your own servers, or aren’t comfortable with out-sourcing your application’s data to a third-party.

With that in mind, I’m really excited about Helios, from Heroku and Mattt Thompson. Helios provides data synchronisation, push notifications, passbook, in app purchase, and analytics support ‘out of the box’. It’s open source, and - importantly - instantly deployable to Heroku (naturally). This means developers who are not willing or able to manage a full backend server stack can quickly get a full mobile backend platform running on a managed provider or hardware of their own.

Full source code and documentation is available on GitHub, and it integrates well with many standard libraries such as AFIncrementalStore. It’s good to see Heroku moving into the mobile backend space, and I’m sure there will be a number of Helios backed app in the iTunes Store soon.


Helios, the God of the Sun. Not the mobile backend.

State Preservation & Restoration

One of the new features in iOS 6 that hasn’t exactly been shouted out from the rooftops is state preservation, probably because on paper it’s far from exciting. However, having implemented it into an app I’ve realised there are some great benefits - not least of which is making your users happier.

What it does

State preservation is designed to solve the problem of app termination. The majority of iOS users don’t know the difference between application backgrounding and application termination. Anecdotally, many people who test the apps I work on are unaware that removing apps from the ‘recent apps’ list terminates them completely.

This can result in quite a confusing and frustrating experience: sometimes coming into an app will take you back to where you were last, and at others you’ll be back to square one. Some developers had attempted to solve this by keeping track of the current app state and attempting to restore it upon relaunch. Inevitably this led to a number of different approaches, some good and some bad.

The good news is that iOS 6 now offers state preservation out of the box, and enabling it is a simple two step process:

How to enable it

Step 1: Label your Controllers

To keep track of a user’s journey through an app you need to provide restoration identifiers for your view controllers. You can identify as many or as few controllers as you wish, but only controllers with restoration identifiers present will automatically instantiated and navigated to by iOS upon launch.

If you’re working with XIBs you can add identifiers within Interface Builder - and with Storyboards it’s even easier (since Storyboards already track a user’s progress through an app). In code you can simply set the restorationIdentifier property.

Step 2: Opt In to Restoration and Preservation

Currently, state preservation is ‘opt in’. To opt in you need to implement three methods in your application delegate, described below:

- (BOOL)application:shouldRestoreApplicationState:
Sometimes you might not want iOS to automatically restore the user’s state: perhaps your app has had a major UI update, and the area of the app your user was last in no longer exists. You should return YES to enable restoration.

- (BOOL)application:shouldSaveApplicationState:
As above, except this method is called when you application is terminated. Again, return YES to allow iOS to save the most recent state information.

- (BOOL)application:willFinishLaunchingWithOptions:
To support state restoration a new launching method has been introduced that complements the more traditional didFinishLaunching. willFinish is called before the state is restored, and didFinish is called afterwards. You’ll probably therefore want to split your launching code across these two methods: code that is required for your app to run should go in willFinish. Final completion code should go in didFinishLaunching. What counts as ‘final completion code’? Things like checking whether a user is logged in, where you might want to display a modal login page rather than your app itself, for example.

Backwards Compatibility

If you’d like to support iOS 4 and 5 users (where state preservation is not supported) you’ll need to watch out for a few things. Firstly, be sure to test that restoration identifiers are supported using respondsToSelector (if you’re using IB you can skip this step):

if ([self respondsToSelector:@selector(restorationIdentifier)]) {
        self.restorationIdentifier = @"Home Controller";
}

However, a more serious issue is how to deal with the new willFinishLaunchingWithOptions method, which is only available on iOS 6, into which you’ve moved most of your launching logic. You could put your launch code into both willFinish and didFinishLaunching and conditionally test the current version of iOS, but this is unnecessary duplication.

Instead, you can use this great little trick which Apple recommend in their WWDC videos:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];

    // Code that must execute in didFinishLaunching whether state restoration is enabled or not
    return YES;
}

- (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [self commonLaunchInitialization:launchOptions];
    return YES;
}

- (void)commonLaunchInitialization:(NSDictionary *)launchOptions {
    static dispatch_once_t pred;
    dispatch_once(&pred, ^{
    // Your launch code here
});

If you are not familiar with Grand Central Dispatch you’re probably wondering what this code does. The dispatch_once GCD call is a clever method that is typically used when doing singleton work: it will execute it’s code block once only, and no nothing for any subsequent calls. This allows us to guarantee our launch logic will only be executed once, even though we’re calling commonLaunchInitialization in both didLaunch and willLaunch.

A Note on Testing

For reasons that will become quickly apparent, there are a few ‘gotchas’ involved with testing state restoration. Confusingly, terminating an app from the app switching pane disables restoration. Why? To prevent a mis-behaving or broken app from keeping a user stuck inside a loop. Perhaps the app has some terrible networking code that keeps the user locked inside a loading screen - resuming to that state would not be beneficial. Similarly, as you might expect state will not be resumed if your app didn’t terminate cleanly (i.e, it crashed).

So how do you test app switching? Well, when attached to the debugger you will want to exit to the home screen (by pressing the home button) and then terminate the app from Xcode (by hitting the ‘Stop’ button).