They all work pretty much the same.
No, they don’t all do the same thing, obviously. But the look and feel—the size and shape of buttons and controls, the way things behave when you tap or swipe them, and the iconography of common functions—are consistent from app to app within one platform. If you can use one iPhone app, you can use them all.
This is not by accident. One of the characteristics of a successful app is that it is easy to use. And a good way to make an app easy to use is to ensure it follows the conventions that users are accustomed to—that is, they don’t have to learn a new interface style with each app. App designers make this happen by knowing, understanding, and following the platform’s human interface guidelines.
Human interface guidelines are the documented standard user interface conventions for a given platform. Apple maintains one for iOS, and the Android development community maintains one for Android.
The high-level principles of the iOS and Android human interface guidelines are quite similar, and include such notions as:
At a lower level of abstraction, the human interface guidelines describe the specific conventions related to visual design, controls, icons, and more. At this level, the iOS and Android guidelines take slightly different approaches. Because Apple controls both the hardware and the operating system for the iOS environment, and thus has a vested interest in exerting more control over the user experience, the iOS human interface guidelines are more detailed and prescriptive than the Android guidelines.
For example, the iOS guideline for buttons implores designers to “use verbs in titles,” “use title-case for titles,” and “keep titles short,” among others, and has lots of information about branding, color, typography, and icons. Android, by contrast, does not go to that level of detail on those topics, but goes to great lengths on more nuts-and-bolts descriptions on topics such as in-app and between-app navigation, when to require user acknowledgement, and the like.
In that sense, the iOS and Android human interface guidelines complement each other quite well, in certain ways. Apple’s guidelines on buttons are certainly applicable to Android apps, and Android’s flowchart regarding user acknowledgement works just as well in iOS apps. Some things don’t translate well, such as the discussion around Android’s “Back” hardware button, which iPhones don’t have. But overall, it’s wise for any app designer to be familiar with both sets of guidelines—especially when cross-platform development is involved.
Obviously, the guidelines are not legally binding and designers are free to do the exact opposite of everything that the guidelines recommend. But doing so would risk alienating potential users, who have a certain set of expectations, reinforced by other apps, regarding the behavior of any new apps that come along. (And in the case of iOS, an app that willfully ignores the guidelines may not pass muster at the Apple Store.) So, as a designer, even if you know that breaking one of the guidelines will result in a more elegant or “cooler” design, ask yourself if it’s really worth the potential negative ramifications. In most cases, a less elegant design that follows the guidelines will be better in the long run than a design that doesn’t.