Platform Guideline

When smartphones first spread, companies had to ship the same app on iPhone and Android at once, and most of them drew one set of screens. There was neither the time nor the headcount to draw two, and the prevailing instinct was that one product should look like one product everywhere.

Users then got stuck in the same places in the same ways. Android users reached for the hardware back gesture instead of the arrow in the top-left corner of the app, and instead of stepping back one screen the whole app closed. iPhone users looked for a menu bar along the bottom edge, did not find one, and walked right past the three-line icon tucked into the top-left corner. Even the share icon split: one platform draws an arrow leaving a box, the other draws three dots joined by lines, so picking either one for both audiences left half the users unsure that the button was a share button at all.

Support tickets came in saying the button was missing. The button was not missing. It was somewhere other than where every other app on that person's phone kept it. People do not learn an app; they learn the device in their hand. If someone uses ten apps a day and the eleventh follows different rules, the app is the one that looks broken.

The problem also showed up at review time. Whoever runs the store where apps get downloaded is the same company that makes the operating system, so screen layout started appearing as a rejection reason during submission review. After a few teams pushed a launch date two weeks because of one rejection email, there was a strong reason to know in advance what counts as grounds for rejection.

The need is not limited to devices you hold. On desktops, the button that closes a window sits top-left on a Mac and top-right on Windows, and preferences open from different places. When hundreds of thousands of programs run on one company's operating system, the same demand appears: whatever a person learned in one program should still work in the next one.

So the companies that make operating systems published, in writing, how an app on their platform should look and behave. The documents say what goes where, how large a tappable area has to be, and which kind of alert suits which situation, with pictures alongside. For the team building the app, one recurring argument disappears. Instead of an hour spent debating whether the delete confirmation should appear in the middle of the screen or slide up from the bottom, somebody finds the sentence that says which one this platform does.

The terms under platform guidelines fall into two groups: the documents the platforms themselves publish (guides), and the way of deciding what to guarantee first in the situations those documents don't cover (principles).

Guides divide by who wrote them, and there are two.

1. Material Design — Google's system, released in 2014. It starts by treating every screen element as a sheet of paper, using shadow depth to show which sheet sits above which, so a floating card and the panel covering it read as separate layers at a glance. The round primary action button in the bottom-right corner, the strip that rises briefly from the bottom edge with a short message, and the ripple that spreads out from wherever you press all come from here. It began as an Android system, but because colors, type sizes and spacing were all given names that code can reference, plenty of products that are not Android apps use it as-is. Recent versions go as far as pulling colors from the photo a user picked as their wallpaper and tinting the app to match, which also means the color you chose may not be the color that appears on the device.
2. Human Interface Guidelines — Apple's version, usually shortened to HIG. It has separate chapters for iPhone, iPad, Mac and Watch, because a screen you touch with a finger and a screen you point at with a cursor need different things even from the same company. Numbers and positions are stated outright: at most five tabs along the bottom, a tappable target at least 44 points on a side, back navigation in the top-left. It also covers what a screen should look like for someone who switched to a dark appearance or enlarged the system text size. Because store review leans on this document, some of what it contains is not advice but a condition for shipping.

Three habits cover most real use. Read the relevant chapter before drawing a screen. Quote it as evidence when a design review splits over where something goes. Skim only the changed entries when the operating system ships a new version, since default component shapes and recommended layouts shift quietly about once a year. None of the three involves reading the document front to back — it behaves more like a dictionary you open when you need it.

One more thing worth knowing about both documents: they are written for the platform's benefit as much as for yours. A phone maker wants every app on its device to feel like part of the device, because that consistency is a reason to buy the next phone from the same company. That alignment is usually harmless — an app that feels native is easier to use — but it explains why the documents sometimes push a pattern that serves the platform more than the product, such as promoting a newly introduced control before anyone has had time to learn it.

Put the two documents side by side and the places where one feature splits into two shapes become visible. A dialog asking whether to delete a file slides up from the bottom edge on iPhone and appears centered on Android. Moving back through screens happens with a swipe from the left edge on one and with the device's own back gesture on the other. So shipping one feature to both platforms means one written spec and two sets of screens. Inventing a third way that neither document describes leaves users on both platforms lost.

Principles divide by which direction they approach environment differences from, and there are also two.

1. Progressive enhancement — finish what works in the poorest environment first, then add capability only where there is room for it. For a document list, that means text and links render over a slow connection, and preview images and live updates get layered on only for wide screens and current browsers. Because the floor is already standing, the product keeps working when anything stacked above it fails to load.
2. Graceful degradation — the opposite direction. Build against the best environment available, then decide what survives where that environment is missing. If live cursors showing where each collaborator is editing don't run in an older browser, the answer is to hide the cursors while reading and saving continue to work, rather than letting the screen break.

The two often end up in a similar place, but the order of decisions differs. The first settles what must be guaranteed before anything else is built; the second settles what can be given up after the fact. A screen being built from scratch suits the first. Extending something that already exists to a wider range of devices suits the second.

The two groups connect in a line. A guide is an answer the platform prepared in advance, so inside its coverage there is nothing to debate — but something always falls outside it. A three-year-old budget phone, a connection that drops in a subway tunnel, a system font size set to double. Principles are how a team decides what to stand up first in those gaps, which is the same ground accessibility work stands on. Once both groups are packaged as reusable parts and values inside a company, the result is a design system. The parts that split by platform get built as two sets of UI components; the colors and wording that don't split stay as one.

"This screen doesn't match the iOS guidelines. Put back navigation in the bottom-right and iPhone users won't find it."

The layout we picked runs against a habit the device already trained into its users.

"On Android let's use the Material components as they come and only put our colors and wording on top."

Take what the platform provides and add nothing but a thin layer where the brand shows.

"That's a recommendation, not a violation. It won't block review."

Inside one guideline document, some entries stop a release and others don't.

At Pagedeck, this came up constantly during the quarter the web-only collaborative document tool was turned into a mobile app. Noa brought mockups made by shrinking the web layout, with the share button in the top-right of a document exactly where it sat on the web. Theo pointed at that corner and said the top-right is where an iPhone user expects "Done" for editing — meaning a user reaching for share would be as likely to end their editing session instead.

They split the screens in two. Share moved to a share icon beside the bottom tabs on iPhone, and into the three-dot menu in the top-right on Android. Mia asked whether that meant two sets of help documentation, and the answer was two screenshots and one set of words, because the flow after the share button is pressed stays identical on both platforms. In effect they drew a line: the device decides where the button lives, and the product decides what happens once it's pressed. That line saved them from re-litigating the same question on every screen that came afterward.

The most common belief is that following a guideline makes every app look the same. Since the documents hand over ready-made parts, the worry sounds reasonable. But what the documents settle is mostly skeleton — where things sit and how they respond when pressed — while color, typeface, imagery and wording are left almost entirely open. That is why apps on the same platform look nothing alike in practice. Left uncorrected, the belief pushes teams to create distinction by moving the skeleton: the tab bar migrates to the top of the screen and back navigation moves to the right, and what the team earns is not personality but first-session drop-off. The place to express a brand is the part the document deliberately left blank.

The second misreading treats the whole document as a list of rules that must be obeyed. The phrase "rejected in review" attaches to it, so every line looks like a condition for shipping. In reality, mandatory and advisory entries sit mixed together, and the mandatory ones — payment flows, permission prompts for personal data — are not many. The rest reads closer to "we recommend doing it this way," and for some products the recommendation is worth breaking. Skip the distinction and the damage comes from both directions: a team that reads everything as mandatory copies layouts that don't fit its product, and a team that reads everything as advisory gets the rejection email the night before launch. A team shipping to a platform for the first time is safest spending an hour on where the document says "must" and where it says "should."