Ole Begemann: iOS Development

The icon of an iPhone app must be 57×57 pixels, and iPad app icons must be 72×72 pixels. How to specify both icons in your Info.plist, given that the CFBundleIconFile property only allows one value?

Apple’s documentation on this is a little hard to find but the solution is very simple: add a CFBundleIconFiles (note the plural) key of type Array to your Info.plist. The items in the array should be string values containing the filenames of all the icons your app needs. In a universal app, you should provide at least the two main icons (57×57 and 72×72). Optionally, you can also add two smaller icons used for your app in the Settings app and Spotlight search. These should be 29×29 pixels for the iPhone and 48×48 for the iPad.

The filenames of the icons and the order of the items in the array are arbitray. The system automatically chooses the file with the correct dimensions based on the device type. You should keep the CFBundleIconFile key and have it point to your iPhone icon for 3.0/3.1 compatibility.

It’s always a good idea to build apps that make use of new features when they come out. Competition is likely to be less fierce in the beginning, and since Apple is likely to introduce those features that have been requested most by users or have been deemed most interesting by Apple’s own market research, you can count on the fact that there will be considerable user demand for the new functionality. So let’s have a look at the public information that we got from yesterday’s iPhone OS 4.0 introduction event and what new app ideas could come out of it. Rather than talking about the things that Steve Jobs already highlighted in the presentation, I want to focus on some of the other new APIs that Apple showed us on this slide:

Some of the new APIs in iPhone OS 4.0

All things photos

At the moment, third-party apps have no direct programmatic access to the user’s photo library. The only thing they can do is present an image picker to the user who can then pick one (and only one at a time) photo that gets forwarded to the app. If “Photo Library access” means what I think it means, namely full programmatic access to the photo library, it could enable us to build full-fledged photo organizing apps similar to iPhoto or even Aperture and Lightroom and thereby solve “The Photography Question” (Fraser Speirs, see the bottom of that article). I hope the access to the Photo Library includes access to the images’ EXIF metadata (which currently does not get through the image picker) and the ability to modify, create and delete photo albums.

We know that the iPad already supports photos in RAW format so with this addition I predict that an iPhoto-like app on the iPad will be a huge hit. The fact that Apple also mentions support for ICC profiles on the slide suggests that they really mean to provide everything that’s necessary to write a professional RAW converter for iPhone OS.

And though Core Image isn’t mentioned and presumably not part of OS 4.0, the hardware-accelerated math library “Accelerate” that Steve Jobs mentioned could make it quite easy to write advanced photo filters with decent performance without having to resort to full OpenGL rendering (what I had to do in Picture Effects to get realtime updating). I see a Photoshop clone for the iPad on the horizon.

Full access to still and video camera data

Direct access to the camera’s video feed can be used for:

• New forms of Augmented Reality apps (based on image recognition instead of sensor data).
• Video chat (if we assume the next iPhone also gets a front-facing camera; if I were Skype, I would count on it).
• Realtime manipulation of the live video. I will certainly look into this for Picture Effects. Hopefully it can become more like Photo Booth with effects being applied in realtime to the live video from the camera.
• Better performance for Barcode scanning apps and others that currently have to rely on the private-but-tolerated UIGetScreenImage() API.
• Apps like Google Goggles.

Calendar access and Local notifications

Access to the device’s calendar has to be one of the most-requested features since day one of the iPhone SDK. Now that it is coming, it will make a lot of existing organizer apps even more useful. Assuming developers can not only read existing calendar entries but also have write access, that is. I see a lot of apps integrating web data (like events from upcoming, the match schedule of your favorite football team or the date of the next solar eclipse) with the calendar.

Many developers presumably asked Apple for a calendar API in order to schedule alarms at a certain time that worked even if their app was not running. Until now, you would have to use push notifications for this, with all the additional overhead that requires: you would have to maintain a server and your app would have to communicate with it. With iPhone OS 4.0, this is no longer necessary and you don’t even have to add your alarms to the calendar where they might confuse the user. Apple added local notifications that, from the user’s perspective, seem to work just like push notifications but don’t travel through the cloud. Presumably, your app just tells the notification service to alert the user at a specified date and that’s it. For example, a to-do app can use local notifications to tell you about a task that is due. A travel companion app could alert you when your train is about to arrive.

Location-based alerts

If I remember correctly, one of Android’s signature apps when it came out was a shopping list app that could remind you to buy groceries whenever your location was near the supermarket. Until now, apps like that weren’t possible on the iPhone, but with OS 4.0, you can use the low-power cell-tower-based background location service that Scott Forstall mentioned in the presentation. Same with a travel companion app that should alert you when you are on a train and your destination station comes up.

What are your ideas?

That’s it for my ideas of what new things we can do on iPhone OS 4.0. What are yours? Please share some in the comments. Ideas are worthless, after all. It’s the execution that counts.

John Gruber was the first to notice that Apple has apparently updated a crucial section of the iPhone Developer Agreement that practically crushes Adobe’s and other companies’ plans to offer cross-compilers that would enable apps developed on platforms like Flash or .NET to run as native iPhone apps. Thinking further about this, Gruber concludes that this is generally a good thing, not only for Apple but also for iPhone developers and users:

I can see two arguments here. On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy. On the other hand, perhaps iPhone users will be missing out on good apps that would have been released if not for this rule, but won’t now. I don’t think iPhone OS users are going to miss the sort of apps these cross-platform toolkits produce, though.

My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles.

Consider, for one example, Amazon’s Kindle clients for iPhone OS and Mac OS X. The iPhone OS Kindle app is excellent, a worthy rival in terms of experience to Apple’s own iBooks. The Mac Kindle app is a turd that doesn’t look, feel, or behave like a real Mac app. The iPhone OS Kindle app is a native iPhone app, written in Cocoa Touch. The Mac Kindle app was produced using the cross-platform Qt toolkit.

I disagree. And not because I think that a Flash-to-iPhone cross-compiler or MonoTouch is great to have (I really couldn’t care less), but because of other languages and environments the iPhone platform could profit from in the future. For example, I’d love to use Ruby both for iPhone development and even more as a dynamic language on the iPhone. To say it with David Heinemeier Hansson:

Jeff LaMarche on Apple’s iPhone OS 4.0 event:

I thought some of the answers given during the Q&A period were just outright disingenuous. The most blatant case in point was when Steve was asked about distributing apps without the App Store, His response was to point out that Android has a “porn app store that your kids can get to”, and then state that Apple “didn’t want to go there”. Whisky. Tango. Foxtrot?

Kids can get to any number of porn web sites on a Mac, iPad or iPhone.

Apple does absolutely have a right to do this: It’s their walled garden. I just wish they’d be more upfront about their reasons when asked rather than giving stupid responses like “think of the children” (which has already become a bit of a joke from its use in censorship discussions). [...]

If Steve had stood up on stage and said “we want our 30% cut, so that’s why you can’t distribute outside the App Store”, it would have felt like it was an honest answer. If he had said “we want to control the experience in any way we can”, I would have bought it. I might not have liked it, but those would have felt like honest answers.

The answer we got today felt like a big “fuck you” disguised as a smarmy “we know better than you”.

When Apple started talking about building universal apps that run on both iPhone and iPad, I immediately thought of the universal binaries that were the cornerstone of the PowerPC to Intel transition. I just assumed that a universal iPhone and iPad app was technically just the same as a universal binary when in fact, this is not true.

While the PowerPC and Intel platforms are totally different and incompatible architectures, the iPhone and iPad are both based on the ARM architecture. That means that, unlike a universal PowerPC/Intel binary, a universal app in the iPhone OS sense does not need to consist of two separate binaries. After all, all devices can run the same code. And this is exactly what Apple is doing. A universal app is just a “normal” iPhone OS app with some special keys in its Info.plist.

The consequence of this for developers is that, because both versions run the same binary, you cannot use conditional compilation directives (#if ... #else ... #endif) to generate different code for iPhone and iPad. All device-type-dependent branching must happen at runtime. Apple recommends we use the new UI_USER_INTERFACE_IDIOM() macro for this:

if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
    // The device is an iPad running iPhone 3.2 or later.
}
else
{
    // The device is an iPhone or iPod touch.
}

And this works great. You set your project’s Base SDK to iPhone OS 3.2 and the Deployment Target to 3.0 or 3.1 and you can build and run this code for an iPad device or the iPad simulator (running 3.2) or an iPhone device (running 3.0/3.1). Caveat: you can no longer test the iPhone version of your app in the Simulator. The reason for this is that the 3.2 Simulator always defaults to iPad mode if a universal application is run. And you cannot build your app for the 3.1 Simulator anymore because the 3.1 SDK does not know the UI_USER_INTERFACE_IDIOM symbol.

To remedy this, we need to use a conditional compilation block. Jeff LaMarche wrote about this approach a few days ago and I am reposting his solution here with a small change because I think there’s a bug in his code (see my comment on his post):

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 30200
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
    {
        // The device is an iPad running iPhone 3.2 or later.
    }
    else
#endif
    {
        // The device is an iPhone or iPod touch.
    }

My universal app Picture Effects running on the iPhone Simulator 3.1 and the iPad Simulator 3.2

Update April 13, 2010: Jim Dovey has discovered another solution that does not require adding the conditional compilation directives: build your app for the 3.2 Simulator SDK first, then switch your target to the 3.0 Simulator SDK, then run (don’t build).

Update April 9, 2010: Chris has asked me in the comments to prepare a starting point for a universal app. Sure, no problem. UniversalViewBasedApp.zip is a very simple app that runs on iPhone and iPad. It contains separate NIBs for iPhone and iPad, and both version run on the same view controller code. To understand how the system knows which NIB files to load on which platform, see the NSMainNibFile and NSMainNibFile~ipad keys in the Info.plist.

Here’s how I created the app:

• Create a standard view-based app for the iPhone using Xcode’s built-in project template.
• Choose Project > Upgrade Target for iPad... and select the option to create a Universal app.
• Open MainViewController.xib in Interface Builder, choose File > Create iPad Version and save the resulting NIB file as MainViewController-iPad.xib and add it to your project.
• In MainWindow-iPad.xib, set MainViewController’s NIB name property to MainViewController-iPad.

After yesterday’s post about the changes in iPhone SDK 3.2, let’s have a look at what’s new in Xcode 3.2.2. Contrary to the minimal jump in the version number from 3.2 to 3.2.2, Apple has made some major improvements for iPhone/iPad developers.

Support for iPad development and universal apps

This is a given. After all, the iPad launch is the sole reason for the release. Xcode 3.2.2 includes new project templates for iPad apps and has a menu command (Project > Upgrade Current Target for iPad…) that helps you get the project settings setup correctly when you want to add iPad support to your existing iPhone project. The Upgrade command gives you two options:

1. Upgrade your existing iPhone app to a universal application that runs on both iPhone and iPad. Customers buy such an app once and can install it on multiple devices. The code that runs on the iPhone and iPad is identical and device-dependent branching in your code happens at runtime.
2. Create a separate iPad target based on your existing iPhone target. Both targets will use much of the same codebase but in the end, you compile two separate apps. Customers who want to use both the iPhone and iPad-optimized apps have to buy both of them. Since you end up with different binaries, device-dependent branching in your code can be handled with conditional compilation directives.

Apple has explained this process very well in the iPad Programming Guide so I’m not gonna go into more detail here. See Creating a Universal Application or Using a Single Xcode Project to Build Two Applications, respectively.

Build and Archive

The new Build > Build and Archive command builds your app as usual, creates an .ipa file (the zip archive of your app bundle you need to create to submit your app to iTunes Connect) and then archives the app bundle, the .ipa file and the associated .dSYM file (containing the debug symbols you need to debug crash logs) in a subfolder of ~/Library/MobileDevice/Archived Applications. These archives also appear in the new Archived Applications view in the Organizer.

An application build in the Finder as archived by Xcode 3.2.2

Archived Applications in the Xcode 3.2.2 Organizer

Unless you already have another automated method in place to archive your distribution builds (such as a custom build script), I encourage you to use Build and Archive for all Distribution builds, both for Ad Hoc and App Store distribution. That way, you won’t have to manually copy the all-important .dSYM file to a safe location and it also saves you the hassle of manually creating the .ipa zip archive. Whenever you want to distribute an Ad Hoc build to your beta testers, just set your build config Distribution, choose Build and Archive, and you’re done.

iTunes Connect integration: Build validation and uploading

The Organizer now also helps you with the next logical step after you have created a distribution build: sharing your Ad Hoc app with beta testers or uploading the final version to iTunes Connect. Take another look at the screenshot of the Organizer window above and note the three buttons at the bottom:

• Share Application lets you sign the build with an Ad Hoc distribution certificate and then save the signed .ipa file to disk or put it directly into an e-mail for distribution to your beta testers. Very handy.
• Validate Application will, in Apple’s words, “run all of the validation tests that will be run upon submission to the App Store so that you can fix any problems before submitting your app.” It’s not quite clear to me what exactly these tests consist of, but it will definitely give you an error message if you failed to include an icon in your app (or if it has the wrong size) or if your code signing identity does not match the app’s bundle identifier in iTunes Connect. When I first read about this feature, I was very excited because I figured that the tests also include Apple’s apparently automated testing for use of undocumented APIs, but now I doubt this is the case. Does anybody know more?
• Finally, Submit Application to iTunes Connect will sign the app with your App Store code signing identity and upload the binary directly to Apple. Before you do this, you must have set up the application with all its metadata (screenshots, 512×512 icon, keywords) in iTunes Connect (this also true for the Validate Application step). Make especially sure that all your keywords are correct because you cannot change them afterwards unless you reject the binary.

Transfer your iPhone developer identity to a new computer

With all the certificates and provisioning profiles Apple requires iPhone developers to manage, it can be quite a hassle to reinstall everything correctly after switching to a fresh install of OS X. In Xcode 3.2.2, there is a new Developer Profile item in the Organizer window that allows you to export all your provisioning profiles and code signing certificates into a single file which you can then import on a new computer with a single click.

Developer Profile view in the Xcode 3.2.2 Organizer

Redesigned documentation

Finally, the 3.2 API documentation has gotten a new look. I quite like the design. Functionality-wise, the help system seems to be unchanged.

Xcode 3.2.2 API Documentation view

Now that the final version of the iPad SDK is available and the NDA is lifted, let’s have a look at what is new. I will give an overview of the new features in this post and elaborate on some of them in more detail in the coming days.

It’s called iPhone SDK 3.2, but it’s not for the iPhone

When Apple released the first beta version of the iPhone SDK 3.2 after the iPad announcement in January 2010, nobody was surprised that it only supported iPad development at the time. However, many (including me) expected the new features to come to the iPhone as well once the final version arrived. Turns out this isn’t so and we will have to wait at least until the next SDK version (4.0 in the summer?) for a unified release. And while certainly not all of the new UI features for the iPad would make sense on the iPhone, the 3.2 SDK includes many changes that I’d love to have on the iPhone, too (CALayer drop shadows anyone?).

Now let’s start with the overview of the new features:

New iPad-specific user interface elements

Apple has introduced two fundamentally new UI paradigms that make use of the iPad’s larger screen: popovers and split views. Both of them will possibly never make their way to the iPhone because they simply make no sense on the iPhone’s small screen.

• Popovers will be ubiquitous in many iPad apps. You often use them where you would go with modal view controllers or deep navigation controller hierarchies on the iPhone. Popovers are managed by the new UIPopoverController class.
• Split views allow you to display a master-detail hierarchy side by side on one screen as opposed to the multiple-screen hierarchies managed by UINavigationController on the iPhone. The new UISplitViewController takes two of your view controllers and helps you manage their master-detail relationship.
• In addition to the new UI paradigms, modal view controllers on the iPad can not only be presented in full screen, but also as page sheets (full screen in portrait but only portrait width in landscape orientation) and form sheets (centered on screen but smaller than full screen; more like oversized alert views). This is all to reduce full-screen transitions to a minimum, which would be irritating to users on the large iPad screen.

Major non-iPad-related new features

The following features could in principle also work great on the iPhone and I hope that all or most of them make it to the small screen in the next SDK.

• Gesture recognizers will finally liberate us from the tedious and error-prone work of trying to reimplement common gestures like swipes and pinches in our own custom views. Never was it easier to write a custom scroll view that only responds to two-finger swipes. This is one of my favorite features in the new SDK. UIGestureRecognizer FTW!
• Custom input views means that you are not limited to the system-provided keyboard layouts anymore for data entry. You can provide completely custom-made input interfaces and make any view or control able to interact with them. That still means a lot of work if all you want is to replace one button on the system keyboard (because you would have to reimplement the whole thing) but it’s great for custom data entry interfaces as Apple demonstrates in their Numbers app.
• Core Text and more (with limitations)
  • The rendering of rich text with different fonts and formatting is quite hard in the iPhone SDK 3.1, and supporting not only rendering but also rich text editing is an almost impossible task. You would basically have to reinvent everything. The new SDK makes this a whole lot easier with its support for Core Text, Apple’s C-based rich text rendering and layouting framework.
  • Still missing, though, is an enhanced UITextView that actually made use of the new capabilities. So if you want to write a Pages competitor, you get the rendering engine (almost) for free but you still have to write the rich text editor. The difference is that Apple makes this possible now, though not exactly easy. Implementing the massive UITextInput protocol is quite a lot of work. I haven’t seen an iPad app on the App Store that has pulled this off yet.
  • CATextLayer lets us easily render rich text on a Core Animation layer.
  • We can now include custom fonts in our app bundles and use them just like the system-provided fonts. Yay! Register your fonts with the system by including the UIAppFonts key in your Info.plist.
  • UITextChecker is a new class that provides us with a spell checker.
  • NSString got regular expression support in its search methods (rangeOfString:options: et al.).
• File sharing support I still haven’t figured out how well this works in practice. Basically, all you need to do is add a UIFileSharingEnabled key to your Info.plist and then your app will be able to share its documents with its host computer via iTunes. Still sounds awfully complicated to me. Instead of relying on iTunes, Apple should mount an app’s Documents folder on the host computer directly. And not just when the USB cable is plugged in but also when both are on the same WiFi network.
• Register supported file types Your app can now tell the system which file types it supports (again via Info.plist) and receive notifications when a file of this type needs to be opened. This is used by apps like Mail that should be able to send arbitrary files they downloaded to the right application to open them. If your app needs to handle files of unknown types, you can use a UIDocumentInteractionController to display those files to the user and let them preview and open them. This is a much-needed step to facilitate interaction between apps on the iPhone OS platform.
• External display support The built-for-Keynote feature. If an external display is connected to the iPad, the UIScreen class will return more than one screen and your app can create multiple UIWindow instances and assign each one to a specific screen.
• UIMenuController allows you to create custom popover menus like those that are used for the Copy & Paste functions since OS 3.0. I hope this will make it to the iPhone, too. Until then, Oliver Drobnik has written a replacement called DTMenuController (not free, though).

Smaller enhancements

• PDF generation UIKit includes new functions for generating PDF files in your application: UIGraphicsBeginPDFContextToFile, UIGraphicsBeginPDFContextToData, UIGraphicsBeginPDFPage, UIGraphicsBeginPDFPageWithInfo, and UIGraphicsEndPDFContext.
• This is cool: CALayer supports drop shadows with these new properties: shadowOpacity, shadowRadius, shadowOffset, shadowColor, and shadowPath.
• Videos played with MPMoviePlayerController can now be displayed in arbitrary views and not just full screen. For the old full-screen behavior, use MPMoviePlayerViewController.
• UIBezierPath is an object-oriented wrapper for CGPathRef.
• MapKit’s reverse geocoder now provides us with a placemark property to access the results of the reverse geocoding process after they have been reported to the delegate.
• UIScrollViewDelegate got two new methods: scrollViewWillBeginZooming:withView: and scrollViewDidZoom:.

Next steps

That’s it for the overview. You can still find a few more changes in the iPhone OS 3.2 API Diffs. In the next post, I will document what changed in Xcode 3.2.2, and after that, I will pick out some of the new features and talk about them in more detail.

A quick demo of the realtime editing in Picture Effects:

Picture Effects demo on YouTube.

My new app, Picture Effects, is now available on the App Store. It is a fun photo editor inspired by Apple’s Photo Booth on the Mac. You can distort your photos with some awesome effects like Twirl, Squeeze, Fisheye, etc. And all editing is done in realtime by dragging and pinching across the picture. I am really happy how it turned out. You can buy Picture Effects on the App Store for $2.99.

While this app started out as an iPhone-only project, I have used the last couple of weeks to design a special iPad version and make it a universal app that looks great on both devices. Porting the project to the iPad went quite smoothly. Apple really has done a good job with the new iPhone SDK and the documentation. I am going to write a separate article about my learnings later.

Picture Effects was also my first project that involved OpenGL. To achieve the necessary performance for the realtime manipulation of the photos, I implemented the distortion filters as Open GL fragment shaders. And while it was surprisingly simple (after I had found some inspiration on the net) to write the actual filter algorithms, the integration of OpenGL rendering with standard UIKit controls and the MVC pattern posed some problems on its own that also deserve a separate article in the future.

Screenshots

Here are a few screenshots of Picture Effects on both the iPhone and iPad:

If you decide to try Picture Effects, I’d be very interested in your feedback.

…be prepared to write a lot more code than in your typical “scripting” language. Three examples (I am using Ruby for comparison because it is the scripting language I am most familiar with; things would look very much the same with Python or PHP):

1. Declare a small hash/dictionary of key-value pairs

Ruby:

person = { 
  :name           => "John Appleseed", 
  :age            => 30, 
  :favorite_fruit => [ "apple", "banana", "kiwi" ]
}

Cocoa:

NSDictionary *person = [NSDictionary dictionaryWithObjectsAndKeys:
                        @"John Appleseed",               @"name",
                        [NSNumber numberWithInteger:30], @"age",
                        [NSArray arrayWithObjects:@"apple", @"banana", @"kiwi", nil],
                                                         @"favoriteFruit",
                        nil];

Now which of these is easier to read?

2. What day of the month is today?

Ruby:

today = Date.today                       # => #<Date: 4910525/2,0,2299161>
puts "Day of the month: %d" % today.day  # => Day of the month: 7

Cocoa:

NSDate *today = [NSDate date];                        // => 2010-03-07 15:15:26 +0100
NSCalendar *calendar = [NSCalendar currentCalendar];  // => <__NSCFCalendar: 0x100400160>
NSDateComponents *components = [calendar components:NSDayCalendarUnit
                                           fromDate:today];
NSLog(@"Day of the month: %d", [components day]);     // => Day of the month: 7

3. Fetch something from the data store

Ruby on Rails (Active Record):

result = Person.find(:all, :conditions => { :first_name => "John" }, :order => "created_at DESC")

Cocoa (Core Data):

NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
 
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Person" inManagedObjectContext:self.managedObjectContext];
[fetchRequest setEntity:entity];
 
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"firstName == %@", @"John"];
[fetchRequest setPredicate:predicate];
 
NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"creationDate" ascending:NO];
[fetchRequest setSortDescriptors:[NSArray arrayWithObject:sortDescriptor]];
[sortDescriptor release];
 
NSError *fetchError = nil;
NSArray *fetchResult = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
[fetchRequest release];

Now I know this is not a fair comparison, Objective-C/Cocoa has many advantages over Ruby et al., you can’t compare Core Data to Active Record, etc. Still, I find the differences very striking, especially regarding the readability of the code.