A Taller iPhone is a Giraffe

Blogger Mark Gurman from 9to5Mac caused quite a stir when he showed screen shots showing that Apple had secretly updated the iOS Simulator to be able to deal with the rumored higher resolution of the next iPhone. His hack involved some nasty code injection that had previously been used to demo iPad on Retina resolution long before the iOS Simulator supported that.

The point of his article was that the main visible difference between the 5.x and 6.0 springboards when having more screen space available. On iOS 5 you always get 4 evenly spaced rows of icons there while on iOS 6 you will get an extra row of icons with no increase in spacing.

Because Mark did not give detailed instructions as he achieved the result (to “protect his sources”) developers all around started to investigate and Cédric Luthi beat everybody to the punch, revealing a method that is so simple, even I was able to follow it.

Cédric inspected the iOS Simulator app with a disassembler and found references to a File.txt and names of secret keys to add to the device settings that would enable the higher resolution. The code words are: “Eagle” and “Giraffe”.

Seriously! I kid you not!

How To Make The Giraffe Fly

Since these modifications work on released software which is no longer under NDA I can publish the steps below. They work with Xcode 4.4.1 which was published as a 47.48 MB incremental update just yesterday. What their effect is with unreleased future Xcode versions I cannot comment on (NDA) but you can easily find out yourself.

So first, I updated my Xcode to Version 4.4.1 (4F1003).

Then I created a File.txt in ~/Library/Application Support/iPhone Simulator with these contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>E</key>
<string>Well, this was fun to discover. But don't change this magic value!</string>
<key>EagleEnabled</key>
<true/>
<key>GiraffeEnabled</key>
<true/>
</dict>
</plist>

This file with this exact contents and at this exact location tells the iOS Simulator to enable the two secret Eagle and Giraffe settings.

The next step is to modify the Info.plist of the iPhone Retina device settings. Those are found in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app/Contents/Resources/Devices/iPhone (Retina).deviceinfo folder.

The simplest way to modify this file – since it is write-protected and owned by root – was to drag a copy to the desktop. Then double-click on it to open it with Xcode’s plist editor and make the modification. Saving keeps it as a binary plist and then you can drag it back to the original location and replace the original Info.plist.

Quit the iOS Simulator if it is running and the next time you start it you’ll find that the display is higher. If you have sufficient screen size for the simulator to show the chrome then you will see that the view in between has grown larger, like in this screen shot posted by PSPDFKit creator Peter Steinberger.

My 13″ MacBook Air does not have sufficient resolution to show the chrome and thus falls back to the chrome-less version. Here’s a screenshot of my 5.1 simulator at 50% scale. You can easily see that the 4 rows on springboard stretch apart and why it is a better design choice to add another row in a possible future version of the OS.

I also wanted to see if you can run your own apps at the higher resolution and it turns out you can, albeit with a caveat.

The problem only becomes apparent if you try to switch to other tabs of this UITabBarController. The underlying UIWindow does not get resized to the larger resolution and thus taps at the bottom corner get clipped. You can only interact with the upper region that falls into the “normal” resolution.

You can probably work around this by modifying the UIWindow’s bounds at run time. Here my experiments ended, because the point was to validate Cédric’s find. Especially because of the hilarious code names that I couldn’t believe at first.

Conclusion

In any case this does not prove that “the new iPhone” will have a different resolution and we should not publicly comment about the features of iOS 6 that are still under NDA. But we’re glad that this hack exists and allows us to tinker with the different resolution.

Cédric Luthi is our hero for telling us way in advance of anything “official” that we can test our apps for different resolutions. Apps that display something of variable size (i.e. a table) should have no problems adapting, they would simply show more scrollable content.

Giraffe, Long Neck, get it?

If anything then this can serve as a gentle reminder to never hard-code resolutions in your iOS apps. You should make proper use of autoresizing masks or auto-layout to have our interfaces adapt to different resolutions automatically.

Categories: Recipes