Mobile Screens and Navigation

The platform's native toolkit gives each screen the platform's behavior for focus, text input, and accessibility without extra work. A WebView or a cross-platform layer reimplements that behavior and lags behind it, so the screen feels foreign on its own platform. One toolkit also keeps every screen testable through the platform's own device tests.

Reviewed forWhich product screens render in a WebView or a cross-platform UI layer instead of the platform's native UI toolkit? Look in the screen implementations.

Marked guidance: a reviewer answers this question.

One controller holding the current screen, the open overlay, and the history gives every navigation question one answer. A screen that navigates on its own hides a second history no other screen can read, so back behavior and deep links disagree with what the screen shows. Events keep screens decoupled from the controller, so the controller alone decides what each event opens.

Reviewed forWhich navigation state lives outside the one controller, and which screens navigate instead of raising events? Look in the controller and the screens.

Marked guidance: a reviewer answers this question.

A journey that starts outside the app, in a message or a browser page, lands on the screen the link names rather than on the first screen with the work still to find. The controller resolves the link, so a cold start and a link that arrives while the app runs open the same screen with the same history behind it. Each stack page names how its platform delivers the link to the controller.

An approval message for expense EXP-1042 carries an app link that opens the approval screen for EXP-1042, with the expenses list behind it for back.

Reviewed forWhich journey entry screens open the first screen instead of the screen and record their app link names, and which links resolve outside the one controller? Look in the app link handling and the controller.

Marked guidance: a reviewer answers this question.

Users learn one back behavior per platform: the gesture dismisses what is on top before it leaves where they are. An app that leaves from a deeper screen, or that traps the gesture on the first screen, breaks a habit the whole platform teaches. Overlay first, then one screen back, then out from the first screen matches that habit on every screen. Each stack page names how the platform's back signal reaches the controller.

Reviewed forWhich back gestures skip the overlay, jump more than one screen, or leave the app from a deeper screen? Look in the back handling.

Marked guidance: a reviewer answers this question.

Drawing under the system bars uses the whole display, but controls and text under a bar or a cutout are unreadable and untappable. Applying the system bar and cutout insets moves controls and text into the visible area while backgrounds keep the full-bleed look. Each stack page names the inset source for its platform.

Reviewed forWhich screens clip controls or text under the system bars without applying the insets? Look in the screen layouts.

Marked guidance: a reviewer answers this question.

Some users turn animations off because motion causes discomfort, so a screen that keeps looping motion ignores an explicit request. A still state shows the same content without the movement: the final frame, the resting layout. Applying the system's setting on every screen keeps the whole app honoring one choice.

Reviewed forWhich screens keep looping motion or video with animations off instead of showing a still state? Look in the screens with animations off.

Marked guidance: a reviewer answers this question.

Media holds memory and hardware the app no longer shows once its view leaves the window. A player that keeps playing, or a decoded image that stays resident, drains the battery and starves the screen the user now sees. Releasing with the view ties each resource's life to the screen that uses it.

Reviewed forWhich players, animators, or decoded images survive their view leaving the window? Look in the view teardown.

Marked guidance: a reviewer answers this question.

A view without a content description is silent to a screen reader, and a target below the platform minimum is missed by the finger it was drawn for. Text fixed at one size ignores the reader who enlarged the system font to read at all. Meeting the platform target size and scaling with its font scale keeps every screen usable with the platform's own accessibility settings. The device tests on the Mobile Testing page prove each screen against this rule.

Reviewed forWhich interactive views lack a content description or the platform-minimum touch target, and which text ignores the system font scale? Look in the views, the text styles, and the accessibility device tests the Mobile Testing page names.

Marked guidance: a reviewer answers this question.