With the iOS 5 looming there are a couple of items that you will need to look at to have your apps ready for the public availability of iCloud and the OS. Let us review.
iCloud will back up app’s documents folder and also reinstall apps over the air. Apple has been testing published apps for how much data they put in the documents folder. With apps where they found the usage excessively they emailed the developers to remedy this until mid of October.
Users have only 5 GB free iCloud storage and we cannot have developers eating this up with unnecessary files. So what is truly necessary to be put in the documents folder? Documents!
Documents! Documents! Documents!
Documents are all files that contain user generated data that cannot be recreated or downloaded. Imagine turning on iTunes file sharing: which files would you like the user to see in iTunes? Dozens of cached images? Plist files with settings? Probably not. The user should only see the actual documents he created.
Since you have to clean out the documents folder anyway, why not also add iTunes file sharing now as a bonus feature to your users?
There are two other locations that don’t get backed up. The tmp and the Library/Caches folder for your app are located right under the application folder on disk. In tmp you would put temporary files that you remove after you are done with them. In Caches you put everything that is cached to speed things up. Like magazine content or downloaded images.
This leaves us with on type of content that we don’t yet know where to put: user data that we WANT backed up, but don’t want the user to see in iTunes, possibly because it is a CoreData DB or some other proprietary representation of the data.
The place to put this is in your own custom folder under Library. Going with the traditional Mac naming scheme you could name it “Application Support”. Or you can name it anything you like. Any folder under Library that is not named Caches will be backed up.
At this point you might also want to review if it wouldn’t make sense to keep the document data in file bundles in documents instead of having them in a centralized DB. iOS 5 brings us a structured method to deal with documents and document versions: NSDocument on Mac and UIDocument on iOS.
Granted, that does not apply to iOS 4 compatible apps, but you could still keep the documents as bundles (i.e. Folders with an app-specific extension). If you start a new app you should plan with this document model right from the start.
Legal Problems?! WTF?
The other thing that confused my developer was a question you would have to answer when submitting a new app version. Are you updating your app because of legal problems? What sort of bullshit question is this?
It is not as bad as it sounds and it does not at all have to do with Lodsys. Apple is using this information to know if they can allow users to install certain older versions of your app. Say you had a problem where you infringed on “third party rights” with something in your app 1.0. You submit a new version 1.1 that replaced the infringing content. By specifying that you update because of a legal problem with 1.0 you tell Apple that they should no longer allow users to install 1.0. It’s just to protect YOU from legal problems by only allowing users access to the trouble-free newer version.
One thing we don’t know is if it is really possible to downgrade apps to earlier versions, but this mechanism certainly suggests that this will be the case. At least Apple now has a flag in their Database which app versions are ok and which have problems.
And now you also know what this is about. Usually you want to answer this question with NO, but in the rare case that there was a legal problem with earlier app versions you choose YES.
Container View Controllers
Your app might contain containers, that is customized view controllers that are providing similar functionality as e.g. UITabBarController or UISplitViewController. Until iOS 5 that was always a nasty hack because you did not have access to the native mechanism of forwarding rotation and presentation events.
One thing you should review now is where you can replace the ugly hacks with the now-available public methods. If you are keeping iOS 4-compatibiliy then you can make this dependent on the iOS version the app is running on.
Ideally you will end up with two hierarchies: a hierarchy of view controllers and a hierarchy of views. Never should you find that you are adding a view that belongs to one view controller’s hiererchy to the view hierarchy belonging to another.
Under iOS 4 it was fine to create a standalone view controller and add it’s view to your main view controller hierarchy which has it’s top in the window’s rootviewcontroller. Under iOS 5 this additional view controller should also be a having a parent view controller.
If you at all tested your apps under iOS 5 (and built against the iOS 5 SDK) then you will definitely have seen some exceptions happening because of this intermingling of hierarchies.
Speaking of Hacks…
Another plethora of hacks is related to customizing the look of your app. Did you by any chance override the drawrect of UIToolbar or UITabBarController via category?
If the answer is yes, then you have two steps to perform. Get rid of category hacks on standard UIKit classes first. If you must, you can subclass them and override it there. The second step is to make your custom code dependent in iOS 4 and use the new appearance customization methods available in iOS 5.
There are other hacks which cannot be substituted as easily. For example you can no longer modify the delegate of an UIScrollView’s native gesture recognizers. If you had to do that you have to rethink your gesture strategy as this now causes an exception (i.e. your app crashes)
3.2 be GONE!
I previously reported on how it makes almost no sense any more to support 3.x devices. The launch of iOS 5 should give the final death blow to this old old OS version.
If the past is any indication we can assume that we have around 6 months now until the majority of users will be on iOS 5. So there will be a big market for solutions that can dynamically work on iOS 4 and still use the specific enhancements of iOS 5.
But iOS 3.x no longer fits in here. iOS 4 brought us GCD and blocks and the whole operating system is making heavy use of those. For example NSOperationQueue was rearchitected to use GCD under iOS 4 transparently. While this does not necessitate any code changes there are many other scenarios that would require separate code for iOS 3.x and 4.x/5.x.
Then there is the question of tools support. The Xcode versions that can support a 5.0 iPhone Simulator no longer support a 3.2 Simulator. The only useful way would be to keep some old device on 3.x to test on.
Conclusion and Apple Assistant
If the rumors are true then we will see the public launch of iCloud and iOS 5 round about the mid of October. Getting a GM build of iOS 5 one or two weeks before that (read: TODAY) is highly likely, especially sonce there was no BETA build for a month now.
There is another prospect that excites me besides all the great new iCloud features: Apple Assistant.
If Apple is putting something like this into iOS then most definitely we will also be getting an API for it. It is rumored that the iPhone 5 will have sufficient hardware specs to run the voice recognition on the device, but this might not be coming this year.
Most likely there will be a fall back mechanism for older devices to also be able to use Assistant: over iCloud. iPhone 4’s voice commands will be enhanced to do morre complex voice recognition on the iCloud servers, similar to how Google is doing it in Android. iPhone 5 will then be able to short cut the recognition on the phone hardware. But with a good 3G or WiFi connection you probably won’t notice the difference.
I imagine we just have to add a couple of new delegate methods into our apps to allow interaction with the Assistant API. The more such enabled apps you have the smarter your assistent will get. A large eco-system of Assistant-enabled apps right on your device might be the most fascinating prospect of iOS 5.
Get the snacks ready for an awesome iOS 5 launch party.
Categories: Apple
Great writeup! I’d just add that storyboarding and improved core data threading is reason enough for wanting to drop iOS 4 support! 😉 iOS 5 is a very exciting release, and I think we’ll have a great evening, and a very nice discussion once the NDA is lifted and we can all discuss our favorite parts. 🙂
Yes, we’ve had this request to move magazine content into caches folder. I’d like to know under what circumstances will iOS delete cache data? My concern is that our app believes that a magazine is available, but that the resources are incomplete. Suspect that we’ll need to start using bundles?
iOS does not delete anything by itself.