PS: Keep in mind that the contents of the videos are still confidential, just as they were for WWDC attendees. Apple will not be amused if we share any non-public information we learn from the sessions.

iBooks on the iPad doing a page curl

Apple uses private APIs

The problem is that the page curl animation used by Apple is not exposed in a public and documented API. Steven Troughton-Smith did a great job at documenting how Apple’s implementation works in his post Apple’s iBooks Dynamic Page Curl. Although Steven’s sample code is a bit rough (as Steven himself admits), the inner workings become clear: Apple has written a custom Core Image filter that is accessible with the undocumented kCAFilterPageCurl constant. (Yeah I know, Apple actually tells us in the documentation that “Core Image is not available in iPhone OS”. They lied.)

This filter accepts to input values, inputAngle and inputTime, to control the angle from which the layer is curled up and the magnitude of the curl. For a page curl animation, we would animate inputTime from 0.0f to 1.0f. To attach the filter to a layer, simply add it to an array and assign the array to the layer’s filters property (ignoring that the documentation says this leads to undefined behavior. In this case, undefined behavior is exactly what we want.).

From Steven’s code (edited for clarity):

@class CAFilter;
extern NSString *kCAFilterPageCurl; // From QuartzCore.framework
 
static CAFilter *filter = nil;
 
...
 
// In -touchesMoved:
filter = [[CAFilter filterWithType:kCAFilterPageCurl] retain];
[filter setDefaults];
[filter setValue:[NSNumber numberWithFloat:((NSUInteger)fingerDelta)/100.0] forKey:@"inputTime"];
 
CGFloat _angleRad = angleBetweenCGPoints(currentPos, lastPos);
[filter setValue:[NSNumber numberWithFloat:_angleRad] forKey:@"inputAngle"];
pageView.layer.filters = [NSArray arrayWithObject:filter];

The App Store-safe way

I hope Apple makes this public in the future (and if you want to have it, too, you should file a bug and request it). In the meantime, Tom Brow has written Leaves, a simple component that achieves a page curl effect through a very smart combination of mirrored and shaded layers (for translucent pages) and gradient layers (for shadows). Basically, Tom adds to the layer that contains the page content (topPage):

1. an overlay to shade the page during the curl animation (topPageOverlay),
2. a gradient layer that acts as the top page’s shadow during the curl (topPageShadow),
3. a mirrored image of the page that will be displayed on the back of the topPage layer during the curl (topPageReverseImage),
4. a nearly-white overlay to soften the topPageReverseImage,
5. and the page below the current page that will become the new topPage after the curl has finished.

The end result is not quite as stunning as Apple’s solution but it is a very good workaround.

As I played around with Tom’s code (I encourage you to take a look at it, it is very clean), I noticed that LeavesView did not support displaying two pages side by side in landscape mode, so I modified Tom’s code accordingly. At first, I planned to duplicate the entire layer hierarchy for the second page, but then I noticed that even in the side-by-side view it is enough if only the page on the right is animated. It was enough to add a leftPage layer, modify the page skipping algorithm (skip two pages instead of one) and the display of the topPageReverseImage layer (display an image of the next page instead a mirrored image of the current page). This is what you get:

Page curl in the Leaves project in side-by-side view

The code is not yet perfect: the topPageShadow is not aligned correctly and I struggled a bit with Tom’s implementation of the page image cache so the code in that section is quite rough. Tom has not yet integrated my modifications into his repository but you can already check out my twopages branch (I love GitHub!). When there is time, I hope we can improve it even more.

Update June 21, 2010: John from maniacdev.com made a nice screencast of the effect in action. Thanks!

UIWebView PDF display bug on the iPad (iPhone SDK 3.2)

The PDF appears to be split in half vertically along an edge that was right in the middle of the page while the device was in portrait orientation. The right half is vertically offset from the left half. Other people have also noticed it so I believe it is a genuine bug.

To reproduce it, try the following:

1. Create a UIWebView and set scalesPageToFit = YES.
2. Embed the web view in a view controller that supports both portrait and landscape orientation.
3. Load a PDF file into the web view.
4. Rotate the iPad from portrait to landscape or vice versa.

Or download the sample project I have created.

I can reproduce this consistently with a number of different PDF files using iPhone SDK 3.2 both in the iPad Simulator and on an actual iPad. The bug does not appear with HTML content nor is it present on the iPhone. It also disappears if you zoom into the page just a little bit or if you set scalesPageToFit = NO.

Workaround: Reload the document after rotation

The only workaround I have found so far is to reload the document after the device has been rotated. It is not very pretty because reloading can take some time and the user can still see the buggy display for a second, but other than that it works. The best place for the reloading code seems to be your view controller’s -didRotateFromInterfaceOrientation: method.

Reported to Apple as Radar #8065859.

Update June 12, 2010: Apple has confirmed this bug as a duplicate to #7790957.

Update June 7, 2010: There is a bug in the first version of the spreadsheet that results in a wrong team being selected for the seventh game in the Round of 16. Thanks to @galdo for pointing it out. The download link below points to a fixed version.

I haven’t had the need to use a spreadsheet since I quit my job a few years ago, but after getting the iPad I wanted to try out Numbers and so I built a spreadsheet for tracking the 2010 World Cup yesterday. Inspired by Fraser Speirs, who published his World Cup Tracker Spreadsheet last week. Since Fraser’s version requires a little bit of manual effort (it doesn’t automatically determine the winners of the group stage), I thought I could do better and make it fully automatic. I hope you like it:

Download: World Cup 2010 Spreadsheet for Numbers (1.4 MB)

All you need to do is enter the scores for each on the fixtures sheets (one sheet per group) and, later, on the Knockout Stage sheet. The trickiest part of automating the calculation of the group rankings are the complicated tie-breaking criteria. To rank the teams, the spreadsheet considers the number of points, the goal difference, and the number of goals scored. If two or more teams are still tied on these criteria, the calculation will break. Let’s just hope that won’t happen. (FIFA then considers the match(es) between the teams to break the tie.)

(Beware: I haven’t tested the spreadsheet very thoroughly so there might well be some bugs in the formulas. If you find one, please tell me and I’ll fix it.)

Thoughts on Numbers on the iPad

We already know that the iPad is far more than a consumption-only device and that it has a lot of potential for content creation, as well. That said, it took me a lot longer to build this spreadsheet on the iPad than it would have with Excel or Numbers on a “real” computer. I spent about 4 hours to make this yesterday and I estimate that I could have gotten the same result in about 1 hour with a desktop app. I think the main reasons for this discrepancy are:

• The iPad’s smaller screen makes it harder to navigate and formatting your content takes more time as you always have to switch back and forth between your content and the inspector.
• The touch interface is just not as well suited to a spreadsheet app as mouse and keyboard (with powerful keyboard shortcuts) are.
• As amazing as it is how much functionality Apple managed to put into Numbers on the iPad, it does lack some key functionality (to me), namely multiple selections and the ability to move content between tables without breaking the references (dragging between tables does not work and cutting-and-pasting breaks the references).

Let’s start with this one: How can I debug an app that was started by an external event such as a push notification or a URL handler? You don’t click on Build and Debug in these cases, so how do we get the debugger to notice? You have two options here:

1. Use NSLog statements and inspect them in Console.app

The output of your NSLog() calls not only show up in the Debugger Console in Xcode but also in the system logs. To look up the logs for the simulator (useful for testing a custom URL scheme), open Console.app in OS X, select Console Messages in the left pane and then search for the name of your app in the Filter field. To see the Console messages on the device (e.g. to test how your app handles an incoming push notification), open the Organizer in Xcode, select your device and switch to the Console app before your app gets launched.

2. Ask the debugger to wait for your app to launch

Sometimes, NSLog() is just not enough and you want the full power of the debugger. No problem:

1. Set a breakpoint where you want it e.g. in application:didFinishLaunchingWithOptions:.
2. Select Project > Edit Active Executable. On the Debugging tab, select the “Wait for next launch/push notification” checkbox:
   
3. Build and Debug as you normally would. The Console will show you a message that the debugger is waiting for your app to launch.
   
4. Launch your app by invoking your custom URL or sending a push notification. The debugger will automatically attach to your app’s process and stop at the breakpoint.

https://developer.apple.com/iphone/prerelease/library/releasenotes/General/iPhoneSeedAPIDiffs/index.html (iPhone developer account required)

This URL seems to remain constant between beta releases. In other words, it always lists the differences between the most recent beta release and its predecessor. If you follow the SDK betas it’s a good idea to bookmark that page.

Unfortunately, MapKit on the iPhone does not include a way to set the zoom level. Instead, the zoom level is set implicitly by defining the MKCoordinateRegion of the map’s viewport. When initializing the region, you specify the amount of distance the map displays in the horizontal and vertical directions. The zoom level is set implicitly based on these distance values.

Instead of dealing with this region business, I wrote a category that adds support for setting the zoom level of an MKMapView explicitly.

Troy also wrote an extensively detailed post on the mathematical background of his code. Great stuff!

Ich bin ab sofort auch für Freelance-Aufträge als iPhone- und iPad-Entwickler verfügbar. Wenn Sie einen erfahrenen Entwickler suchen, der bereits eine iPad-App und eine sehr erfolgreiche iPhone-App (Songtext war für einige Zeit die Nr. 1 im deutschen App Store) veröffentlicht hat, kontaktieren Sie mich bitte unter ole@oleb.net. Ich wohne in Berlin, bin aber auch für auswärtige Projekte offen.

OBGradientView is a very simple UIView subclass that wraps the functionality of CAGradientLayer in a view. It exposes all of the layer’s gradient-related properties (colors, locations, startPoint, endPoint, and type) as its own properties. Calls of the setters and getters are simply forwarded to the underlying CAGradientLayer so you can use the same syntax to define the gradient. In addition, to make it more UIKit-friendly, OBGradientView allows you to set the colors property with an array of UIColor instances instead of CGColorRefs.

Dealing with a view instead of a Core Animation layer is especially useful when you want to use autoresizing masks, which are not available for CALayer on the iPhone. For example, adding a subtle background gradient to your view controller’s main view that autoresizes automatically is very simple:

OBGradientView *backgroundGradient = [[OBGradientView alloc] initWithFrame:self.view.bounds];
backgroundView.colors = [NSArray arrayWithObjects:
                         [UIColor lightGrayColor], 
                         [UIColor darkGrayColor], 
                         nil];
backgroundView.autoresizingMask = UIViewAutoresizingFlexibleWidth | 
                                  UIViewAutoresizingFlexibleHeight;

Get the code for OBGradientLayer from GitHub. I am releasing it under the MIT License.

The new web site

I have lowered the price for Picture Effects to $0.99 today, so now is a great chance to get it. This is basically an experiment for myself to see how sales will develop compared to the former price tag of $2.99. I haven’t yet determined how long it will last. I’ll leave the price at $0.99 for at least a week and then reevaluate. I think it’s really good value, especially if you consider that Picture Effects is a universal app. I still haven’t had the chance to see the app on an actual iPad myself, but from the feedback I’ve received it seems to work really well.

Working on updates

I’ve also been working on the first update that will bring some small UI improvements and a German translation. And to top it off, I improved the pictureeffectsapp.com site today. The design is now cleaner, I added a screencast of the iPhone version in action, and I switched from embedded YouTube videos to HTML 5 video elements. Now the site renders very nicely on the iPad, too (at least on the iPad Simulator).

Can I ask you for a customer review?

If you have purchased Picture Effects and you would like to see it improve in the future, could I kindly ask you to leave an honest rating and/or review on the App Store? Having a number of meaningful reviews would help me tremendously in getting more exposure to Picture Effects. Thank you very much!

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.

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.

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:

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”.

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.

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

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.

Picture Effects demo on YouTube.

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.

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.