And now: random thoughts on iPhone UI issues and things and such. Fabulous!

The documentation Apple provides is more extensive than you think. You've probably seen the class references, since that's the thing Xcode searches by default when you choose Help > Documentation. However, Apple also provides conceptual documentation that accompaines most of the classes; you can find a link to such documentation inside the "infobox" at the top of the class reference doc.

Also: symbols are not the only thing you can look for. Switch the bar to Titles or Full-Text to look for more conceptual documentation, or use the docs home page to browse. It's surprisingly well-organized, once you understand where to look.

Because the app bundle is read-only, damnit!

This is one of the most asked things on #iphonedev. Your application bundle is signed. Any changes to its contents will break it. Treat it as a read-only area. Have a SQLite database? Copy it out to a suitable directory before using it. (Suitable directories are the Documents and Library directories in your application sandbox — you can get a path to them via the NSSearchPathForDirectoriesInDomain() function. See the docs for more.)

A common segue to this question is, "But it works in the simulator!". Yes, but your app is a Mac app while running in the simulator. On the Mac, .app bundles should be read-only, but the OS does not require this to be the case. (It's still more than just a good idea, because .app bundles may find themselves in situations where they're read-only — for example, if an account installs an application and another uses it.) So: you were doing it wrong, but Mac OS does not devote cycles to enforce this thing. iPhone OS does. You've been warned.

What I call "action-long modality" is one form of modal behavior of iPhone OS that is rarely seen in other software environments, although it could be easily replicated elsewhere.

"Modality", in software UI design, is the tendency to limit the user's available commands and ways of interactions, usually to direct them to perform a particular task before continuing with the regular use of the program. In desktop operating systems, it usually takes the form of "modal dialog boxes", which prevent the user from interacting with the rest of the application until they are dismissed; in most OSes, it is discouraged to use such an interaction model (especially under Mac OS X). In contrast to desktop OSes, in iPhone OS, given the limited screen real estate, it is common that the application performs "modal switches", removing previous commands to display new ones (with modal controllers, flipping to settings in utility applications and navigation via the navigation bar). iPhone OS also provides UIAlertView, which works just like a modal dialog box does on desktop OSes.

Alongside fully modal interactions, the system encourages developers to use a slightly different kind of behavior I dub "action-long modality". Action-long modality is a mode switch that happens apparently "without leaving the previous mode"; the UI changes to display additional controls and waits for the user to make a choice. If the user appears to make a choice that does not use the additional controls, the action-long mode is immediately and effortlessly dismissed (rather than trying to block the choice as it happens with traditional modality). Most examples of this kind of interaction are dismissed immediately after the uses performs a choice — hence, action-long.

The most immediate example of this interaction is swipe-to-delete: if the user swipes over a row of a UITableView, a "Delete" button appears. If the user presses it, the table asks its delegate to remove the row. If the user tries to perform any other action on the view, like for example scroll it, he will succeed, and the Delete button will quickly fade away.

Another application that makes use of this interaction model is atebits's Tweetie. Swiping over a message in any message view slides it away to reveal additional commands tied to that message in its place. If the user scrolls away or moves from the current view, the message will immediately scroll back into place. This allows the user to perform an action without having to press the message first and switch modes, or by adding another always-visible set of controls for performing these actions in the main view.

Action modality reduces the "modality switch load" on the user, making some interactions easier and faster and providing shortcuts for power users. Consider using some form of it in your application rather than requiring navigation before a command can be reached.

Pickers are odd. They don't have a defined role; they feel right in a number of places. However, there are a number of situations where they are not the right tool for the job.

A picker is the right tool if:

• You want to allow picking while also presenting contextual data above the picker. (See Safari.)
• You want to allow the user to pick a combination of possible inputs. (A common one is date/time, which even has its own unique picker, UIDatePicker.)

If you don't have either of these needs, however, consider not using the picker. In particular, if you just want the user to choose between items on a list, use a UITableView spanning the whole of the screen.

When using the picker, always place it at the bottom of the screen. You might notice it has the same size as the keyboard; this is done for a reason — just like the keyboard, it is expected to provide input to whatever lies at the top of the screen. For this, you should avoid placing the picker elsewhere.

A keyboard toolbar is a bar that is presented just above the keyboard. It is used for one of these purposes, in order of preference:

• Provide the user with the text field on which to write. This happens if the current screen is not wholly devoted to text input, as in the Text (SMS) application.
• Provide the user with tools that directly deal with the input; for example, a way to add a picture to the input.
• Provide the user with commands that act on the whole mode, for example to send the text or cancel the sending, when a navigation bar would be unavailable or reduce the available screen real estate. This includes commands to dismiss the keyboard (thus ending the current input mode) or allow the user to navigate to other input fields when the "return" key has another meaning, as in Safari.

You usually implement a keyboard toolbar via an appropriately configured UIToolbar that is moved up or down with the keyboard (which can be accomplished by responding to the notifications named UIKeyboardWillShowNotification and UIKeyboardWillHideNotification).

Keep this in mind when implementing a keyboard toolbar:

• The keyboard toolbar need not remain onscreen after the keyboard hides. If it does, it should slide to the bottom of the view.
• If the toolbar obstructs a view that contains useful information (for example, a web view as in Safari), then it should be translucent. If screen real estate is sufficient to show all needed editing views, you should instead consider making it opaque.
• If the view contains an input text field, do not use UIToolbar. Also, consider having the text box grow dynamically as the amount of text increases. You can use NSString's font-size category methods to calculate whether a string fits in that much space or if the text box needs to be shrunk or expanded. Avoid making the user use the loupe for scrolling.
• Screen space is at a premium. If the only available action is to accept the input, and the "return" key of the keyboard isn't required for anything else, use it instead of a keyboard toolbar.
• If you have a navigation bar, consider placing commands there instead of a toolbar; also, do not hide the bar to present a toolbar with navigational commands on it.

Finally: a toolbar can also appear over other input mechanisms that appear on the lower part of the screen, like pickers. Consider following similar guidelines for such bars, too.