• 9-Dec-2008
• Renaissance Seattle Hotel

I went to an iPhone Tech Talk last year before the iPhone SDK was released. At that talk they covered web applications to some extent, but a large portion was centered around usability and design. Those are still important aspects with the SDK, and perhaps even more so due to the greater possibilities for applications. While I don’t personally own an iPhone, I found the seminar very useful.

I’ll just cover concepts and details about the development products which were covered, rather than talking about the conference itself (it wasn’t completely clear to me what parts of the conference were under a confidentiality agreement, but it was explicitly said that the products themselves are OK to discuss).

Business overview

Apple has sold 13 million iPhones as of last quarter, not including iPod touch devices. The app store has sold 10,000 applications with 300 million downloads in 150 days. The developer of the game Trism sold 27,000 copies in three weeks.

Updates to the developer program:

• SDK for released versions of the iPhone software no longer are under NDA
• Only users who purchased an app can leave a review on the iTunes app store
• App store can show top paid or free apps in different categories, and the top app for each has its icon on the category listing page
• University program allows teachers to allow up to 200 students to develop for iPhones without cost
• Developer forums were created which should make for better user interactions compared to email lists

Making great iPhone apps

To make a great iPhone app, you need to be very familiar with the device and its capabilities, as well as what frameworks, etc. are available to you. Knowing how people use iPhones is also important, since that will help with the UI design.

Some applications which stand out:

• Dizzy Bee – Has a very engaging look and gameplay. It’s inviting and makes you just want to use it.
• Shazam – Play a song into your iPhone’s microphone and Shazam will figure out what it is. You can even hum into it. It’s a very innovative application.
• Colors! – A painting program which has really great design.
• MIM – This app is used by oncologists to blend multiple medical scans into the same view so you can see more than by looking at just one scan. It’s integrated really well into the multi-touch interface.
• Enigmo – The app was ported almost directly from the Mac as a first pass, then adapted for the iPhone and highly optimized to the point where it’s extremely fluid, even though there’s so much happening on the display.
• Smug Mug – Automatically geotags photos and places their positions on a map. It’s an app which takes advantage of the connected nature of the iPhone.
• Remember the Milk – This task management app is translated into 18 different languages. The US is only about half the iPhone market, so translating apps gives you a competitive advantage.

User Interface design

The hallmark of Apple products is design, all the way from the hardware to how buttons appear on the screen. Applications which apply good design have a better chance to be really successful.

The iPhone Human Interface Guidelines are a good place to start. It describes things all the way back to planning an application. The first thing you should do is work on a solid Product Definition Statement. In it, you should narrow down not only what your product should do, but the target audience, since that can change how an application is designed. For example, many times map programs are used closer to arm’s length than right in front of the user’s face.

When you design an app, a lot of effort should be put into conforming to the interface guidelines, especially since they represent how users tend to work with applications (especially the built-in ones). For example, users tend to click on the top-right corner to add an item to a table, even if the icon isn’t there. Likewise, if they’re in a series of nested menus, they’ll try to click on the top-left corner to go back to the previous menu. Apps should conform to that, rather than changing the model (such as adding a Home link or using full breadcrumbs, which would quickly fill up the navigation bar).

The screen shouldn’t be crammed with information. Not only does that make the app harder to use, it makes items harder to tap (Apple recommends a tap area of at least 44 pixels square).

Some other design guidelines come out of the design of the phone itself. For example, text entry should be minimized, since typing is relatively difficult. If you can save preferences or, even better, make a reasonable guess as to a default, the user has that much less typing to do.

Of course, one can stray from strictly following the interface guidelines if the type of application merits doing that. Games often fall into this category.

iPhone web applications

I’ve been following updates for Safari on the desktop, but not all of the iPhone changes. What clicked for me at the Tech Talk is many of those changes makes iPhone web applications pretty close to built-in applications.

Feeling built-in

Icons on the iPhone home screen can make a web page look just like an application. We’ve had one for http://www.washington.edu for quite a while (if apple-touch-icon.png exists at the top level it is used), but they can be added for individual web pages, also (put <link rel="apple-touch-icon" href="image.png" /> in the head of the document). They should be 57 pixels square and will get the rounded corners and reflection added. If you really want to apply your own reflections you can use apple-touch-icon-precomposed instead.

With iPhone OS 2.1, web applications can hide the Safari UI (URL bar, etc.) with <meta name="apple-mobile-web-app-capable" content="yes" /> in the document head. The color of the status bar (where the phone signal strength, etc. are displayed) can be changed between the default grey, black, and a translucent black, again with the meta tag apple-mobile-web-app-status-bar-style. Once a web app follows a link to another page, the Safari UI will reappear. Also, the Safari UI only gets hidden when the application is launched from the home screen, so navigating to the app will still show the UI.

You can be notified whether the device has been rotated with the orientationChange event. You can listen for that event on the body of the document.

Touch and gesture events

While the iPhone will respond to mouse events, much more information is available when you use touch (single finger) and gesture (multiple finger) events. For touch events, you can track each individual finger (in addition to getting a cancel event when the Home button is pressed). Gesture events tell you if the fingers have been rotated, pinched, or spread; the event returns the degrees of rotation since the event started (positive for clockwise, negative for counterclockwise) and the relative distance of the fingers (less than 1.0 for pinched, > 1.0 for spread).

CSS visual effects

All of these CSS effects are available for Safari on the desktop.

Transforms (the -webkit-transform property) allow you to rotate, scale, or translate (change X and/or Y position) an object. You can also skew an object in either or both of the X and Y directions. All transformations originate from the center of an object, so it’s possible that an object will suddenly appear off the screen if you rotated a block which only has content to the left (such as <div>foo</div>). Apple has added the -webkit-transform-origin property if, for example, you wish to use the top-left corner as a pivot.

Transitions are simple animations between two sets of CSS values. You can specify which properties to animate and how long the animation should last (different properties can be animated at different rates). You can also specify the animation timing (starts slow, ends slow, etc.) and whether there should be a delay before the transition starts.

Animations give you more control over timing of transitions. You can define a set of keyframes and label it with a name. Objects use one or more of the predefined animations and can specify duration, iteration counts, and timing functions (independently for each animation). DOM events are available for when animations start, end, and when an iteration begins.

Storing data locally

Safari has the ability to use SQL with a local data store. This has the advantage of reducing the number of calls to a server, which would require using one of the radios (either cell or WiFi), more quickly draining the battery. In addition, cell networks have high latency which would make a web app quite a bit slower.

The database interface uses callbacks so all programming can be asynchronous.

All DB access is transaction-based, so several statements can be rolled together. Results for individual queries also have their own callbacks, and a callback is provided for error handling.

In addition to local databases, a web application can also store static content on the local device. This is enabled through a cache manifest which has a list of URLs to objects which should be locally cached. If the manifest has changed, new values for the cache are set up. During all these steps, many events are triggered so the application has plenty of opportunity to give feedback to the user about what’s happening. Once all the new files are downloaded, a final updateReady event is sent so the application can swap in the new cache.

Integrating iPhone with IT

A big push with the iPhone 2.0 software was to offer more features for enterprises. What they’ve done is much more than just support Exchange.

Exchange ActiveSync support is the one Apple touts the most, but they also support Cisco IPSec VPNs and WPA2 Enterprise (which includes Raduis). Certificate support is built in, and CA roots can be added with an email attachment, a web site, or via configuration profiles. IMAP is supported for email.

iTunes is needed for activation, but you can limit what’s allowed in iTunes for end users on Windows with startup flags. In addition, you can enable the parental controls with configuration files for both Windows and the Mac.

There’s a separate iPhone Configuration Utility which lets you set up different profiles. Multiple profiles can be applied to a phone, so you can have, as an example, an enterprise-wide profile and team-specific profiles. These profiles can be applied either by central IT or made available for installation by the end user. They can contain password policies, application restrictions, email accounts, certificates, VPN and WiFi configurations, and Exchange account information. They can and should be signed so the users can see that they’re valid. Once the profiles are loaded, the user can begin to enter passwords.

Backups and Sync are viewed as separate features; the profile information and device-specific settings and history are backed up, while media and shared desktop data is synced via iTunes.

When a user migrates from one iPhone to another, a restore does not recover certs and passwords, but they can be reentered or reapplied with a profile.

Maximizing iPhone application performance

After design, Apple seems to care most about performance, since bad performance makes for a really bad user experience on a mobile device. While the iPhone can do a lot, it’s still has nowhere near the power of a desktop system.

Memory management

While there is a lot of flash memory in the iPhone, there’s only about 128mb of RAM. After the operating system and frameworks are loaded, the application ends up having about 15-25mb of real memory available. Therefore, memory management on the iPhone is very important. Even though there’s virtual memory, there’s no swap file so everything needs to fit into RAM. You can, however, map files from flash memory using mmap(). No garbage collection is available (it would be a performance hit because GC in Objective-C uses a separate thread; the iPhone is single threaded).

One easy thing to do to optimize an application is to use the default -mthumb compiler flag, which uses a 16-bit subset of the ARM instruction set and reduces code size by about 35%. Another is to use PNG files (the files themselves are optimized when they’re bundled for use in an iPhone application) and plist files (coverted to binary when bundled). For small amounts of structured data, plist files can work well since the data then doesn’t need to be parsed on the phone.

To optimize memory usage, one should allocate wisely. Objects can be cached, which is a good thing, but cached objects should also be released if needed (such as when the application gets a low memory warning). Objective-C autorelease can be expensive to use, but if you do need to do a lot of autoreleases, you should use an autorelease pool which you periodically drain. That way you control when objects get released.

When memory does get low, the iPhone gives you several levels of warnings and several ways to receive them. You should avoid just putting up a window saying that memory is getting low, since a user generally has no control over how the application is using memory. If the application ignores all the warnings, it will be summarily killed.

Using the supplied Instruments performance tool is a good way to keep an eye on memory allocation and can help point out leaks. It can be used either with the iPhone simulator or with a connected device, but it’s pretty slow with the latter.

Drawing and scrolling

The iPhone SDK has lots of frameworks and technologies to make it more efficient to draw to the display, such as Core Animation, OpenGL ES, Quartz, and UIKit. These frameworks should be used wherever possible since they’re already highly optimized.

When doing custom drawing, the first thing to do is to make sure a view is opaque whenever possible so the system doesn’t have to compute transparency (Instruments can be used to mark areas which are drawn, such as with Quartz Debug on the Mac). In addition, while developers on the Mac are used to having enough computing power to just redraw everything, iPhone developers should take drawing rectangles to heart and only update what’s necessary.

For scrolling table views, the iPhone Table View has a mechanism where you can cache cells which are no longer needed. Instead of allocating a table cell when it scrolls into view and deallocating when it scrolls out of view, the unused cells are dequeued and marked as reusable. This dramatically reduces the number of alloc/dealloc calls and improves performance.

To eke out the best performance, however, it’s best collapse the cell/view layer hierarchy. This forgoes nested views (the most natural way to draw content into a table cell) and forces the developer to do all the text, path, and image drawing “by hand”. It’s probably best to stick with nested views for the design phase and switch to the collapsed layer hierarchy when the design is close to final.

Launch, files/data, power/batter life

Applications should be designed for fast launch. The UI should be put onto the screen as quickly as possible so the user can start interacting with it. You should delay loading data until you really need it, to further improve speed.

Memory mapping should be used for large files to use less RAM. For large data sets, SQLite should be used since it’s more efficient with random accesses.

You should minimize the amount of data you write. It helps to only write changed data, so if you have preferences that you save, only save the parts that have changed instead of writing the whole thing every time.

Transmitting is the most expensive thing you can do on the iPhone, so it should be avoided where possible. If you coalesce transmissions into bursts, you allow the antenna to sleep in between (30 seconds is a good interval to use). Compact formats should be used, and chatty protocols (ones with a lot of request/response transactions) should be avoided.

Core location can be expensive (to find your location on the map). You should only request the accuracy which is necessary; no need to ask for 10 meter accuracy when you want to find the location to calculate sunrise and sunset times.