Every Mobile UX Patterns Audit check

Touch targets below 44x44 points fail WCAG 2.2 SC 2.5.5 (Target Size) and SC 2.5.8 (Target Size Minimum), exposing the app to accessibility audit failures and App Store rejection for accessibility non-compliance. Beyond compliance, undersized targets cause systematic mis-taps — users hit adjacent controls, trigger unintended navigation, or simply abandon interaction entirely. Apple HIG and Material Design both specify 44pt minimums precisely because human finger-pad contact areas average 44-57 points; anything smaller forces compensatory precision that degrades usability for all users and sharply increases error rates for users with motor impairments.

Why this severity: Critical because mis-taps on undersized targets trigger unintended actions and are non-recoverable without user-visible error handling, directly degrading user retention and failing mandatory accessibility standards.

Adjacent touch targets with zero or sub-8pt gaps produce mis-taps on every interaction — users hit the wrong button in a settings screen, delete the wrong row in a list, or cancel when they meant to confirm. This is the dominant source of rage-taps and one-star reviews on mobile, and it violates the Apple HIG 44pt target and Material Design 48dp target guidance that app store reviewers check against.

Why this severity: High because mis-tap rates compound across every session and directly drive refund requests, negative reviews, and churn.

A `PanGestureHandler` wired to the root view or main screen swallows the iOS edge-swipe-back gesture — users can no longer navigate back and file crash-level bug reports. Globally-scoped swipe handlers also fight with `ScrollView` momentum, producing frozen scrolls and ghost taps. Apple's HIG explicitly reserves edge gestures for the system, and conflicts here are a common rejection reason during App Store review.

Why this severity: High because breaking system navigation gestures strands users on a screen with no visible way out.

When async operations — API calls, uploads, data fetches — complete with no visual feedback, users perceive the app as frozen and repeat taps or abandon the action entirely. ISO 25010:2011 performance-efficiency attributes explicitly cover responsiveness perception, and loading indicators are the primary signal that work is in progress. Missing indicators also mask real failures: users cannot distinguish a slow network from a crashed operation, so they have no signal to wait, retry, or report a bug. Custom animations that diverge from platform conventions (native `ActivityIndicator` on iOS, material progress patterns on Android) erode platform coherence and increase cognitive load without adding value.

Why this severity: Low because the failure is perceptual rather than data-loss or security-impacting — users experience confusion and may repeat actions, but no state is corrupted.

When a feed of dynamic data has no `RefreshControl`, users have no way to force fresh content — they back out of the screen and re-enter just to trigger a fetch, or they assume the app is broken. A stuck `refreshing={true}` that never resets is worse: the spinner burns indefinitely, users wait, then force-quit. Both patterns inflate perceived load time and trigger abandonment before the real content loads.

Why this severity: Low because the app still functions, but the friction drives repeat navigation and degrades perceived freshness.

Without `SafeAreaProvider` and `SafeAreaView`, content renders underneath the iPhone notch, Dynamic Island, and home indicator — login buttons land under the status bar, close icons end up behind the camera cutout, and the first row of a list is clipped. This breaks the app on every iPhone from the X onward and most modern Androids. App Store reviewers flag notch collisions as a functional defect, not a visual polish issue.

Why this severity: Critical because core UI becomes unreachable on the majority of modern devices shipped in the last five years.

Hardcoding widths above 320pt cuts off content on iPhone SE and any small-screen Android — users see clipped headlines, overlapping buttons, and horizontal scroll on what should be a vertical feed. On the large end, 430pt+ devices get awkwardly stretched layouts with orphaned white space. The App Store SE-class device tests and Google Play pre-launch reports both flag these as blocking issues, and review screenshots fail silently when text overflows.

Why this severity: Critical because content cut off on the smallest supported device makes features functionally unreachable.

Scrollable content without safe-area insets disappears under the notch, status bar, and home indicator during scroll — the top row of a feed vanishes behind the Dynamic Island, and the bottom action bar slides under the home indicator where it cannot be tapped. Users perceive this as content loss, not a styling bug, and the bottom home indicator collision is specifically called out in the Apple HIG as a reviewer-blocking issue.

Why this severity: Medium because scrollable overlap degrades readability but the rest of the screen still functions.

Leaving `orientation` unset in `app.json` lets users rotate the device, but if layouts use column-only flex or fixed heights, the landscape view clips inputs and stacks the tab bar on top of content. Tablet users — who default to landscape — see a broken experience on first launch. Locking to portrait without justification blocks accessibility use cases like one-handed reading on a stand and fails Google Play's large-screen quality signals.

Why this severity: High because rotation bugs break entire classes of devices and hurt tablet and foldable quality rankings.

Status bar icons and clock rendered at insufficient contrast against the app background fail WCAG 2.2 SC 1.4.3 (Contrast Minimum) and SC 1.4.11 (Non-text Contrast), both of which apply to UI component contrast. In practice, light icons on a white header or dark icons on a dark screen become invisible — users lose time reference, network status, and battery indication. Apps that support both light and dark themes but hardcode a single `barStyle` will fail on exactly one theme for every user, creating a systemic failure that is easy to reproduce and difficult to miss in App Store review. The fix takes one line but its absence signals that light/dark support was never tested end-to-end.

Why this severity: Low because the status bar is ambient UI — invisible icons degrade experience and violate WCAG 1.4.3/1.4.11 but do not block task completion or expose data.

A dark app with `barStyle="dark-content"` renders dark icons on a dark background — time, battery, and signal become invisible. On Android, omitting `backgroundColor` means the status bar inherits theme colors that may not match the navigation, producing a visible seam between system and app UI. Users perceive this as a rendering bug and submit screenshots to support, inflating ticket volume for a single-line fix.

Why this severity: Medium because status bar icons are system-level and users still recover, but the polish signal hurts conversion.

iOS users swipe from the left edge to go back without looking — it is the most frequent navigation gesture in the OS. Replacing it with a custom back button forces users to reach up to the top-left corner one-handed, which is physically uncomfortable on phones above 6 inches and drives session abandonment. On Android, a broken hardware back button is an Android Vitals crash-class signal and directly lowers Play Store visibility.

Why this severity: High because navigation is the most-used control in the app and breaking it degrades every session.

Material elevation shadows and ripple effects on iOS look foreign — users immediately read the app as cross-platform slop. iOS expects flat text buttons with subtle borders; Android expects filled buttons with elevation. Apple's HIG and Material Design 3 are explicit about these patterns, and mismatched styling is one of the top three signals App Store reviewers use to flag low-quality cross-platform apps during manual review.

Why this severity: High because mismatched platform styling immediately signals a cheap port and hurts review scores and approval rates.

Setting `gestureEnabled: false` on a stack screen disables the iOS edge-swipe-back gesture for that route only — users learn to swipe back on every other screen, then hit one where it silently fails. They assume the app is broken. This pattern is most common when developers copy-paste screen options without realizing the flag's scope, and it is a specific anti-pattern called out in Apple's HIG navigation section.

Why this severity: Medium because the back button still works, but the inconsistency trains users to distrust navigation.

iOS users expect modals to slide up as a sheet with a dismissible drag handle — a centered Material dialog on iOS feels foreign and users miss the close button. On Android, a slide-up sheet where a centered dialog is expected looks like a bug. Using `Alert.alert()` for simple confirmations inherits the correct system styling for free; building custom-styled replacements almost always gets the platform convention wrong.

Why this severity: Low because modals still work, but the wrong presentation style undermines the native feel throughout the app.

Sub-20pt tab bar icons are below the WCAG 2.2 SC 2.5.5 target-size threshold (44x44pt minimum) and the Apple HIG 49pt tab bar height — users with average thumb size mis-tap, and users with motor impairments cannot hit the target at all. Missing labels force users to memorize pictographs, which harms first-session discoverability and is specifically flagged by Google Play's user experience quality signals.

Why this severity: Low because mis-taps self-correct, but the accessibility failure still excludes users with motor impairments.

When the keyboard opens and covers the active `TextInput`, users type blind — they cannot see validation errors, cannot confirm the autofill suggestion, and often submit the wrong value. Login and signup screens are the worst offenders because the password field is typically the last field and therefore the lowest on screen. Field-blind submission produces silent wrong-password lockouts that users attribute to the app, not the covered field.

Why this severity: High because keyboard occlusion blocks the primary interaction on forms, which are the conversion path.

A `TextInput` for email without `keyboardType="email-address"` hides the `@` under a long-press, forcing users to tap-and-hold on every signup. A phone field with the default keyboard hides the numeric pad entirely. These mismatches slow data entry by several seconds per field and inflate typos, which show up as invalid-format errors and failed signup conversions. It also breaks autofill integration with `autoComplete` hints.

Why this severity: Medium because users can still complete the task but friction and typo rates measurably degrade conversion.

The generic `return` key on a password field gives no signal that pressing it will submit the form — users tap the submit button anyway, making the return key dead weight. On a search field, the wrong label leaves users guessing whether return submits or inserts a newline. Contextual return keys (`done`, `go`, `search`, `send`) are a zero-cost signal that matches the platform convention and reduces form completion time.

Why this severity: Low because the wrong return key slows users but does not block form completion.

A keyboard that lingers after form submit covers half the destination screen — users reach the home feed and see only the top row, then tap elsewhere to dismiss before they can scroll. On slow networks, this creates the impression that nothing happened after submit. Leaving the keyboard open during navigation transitions also makes screen-transition animations stutter on low-end Android because the keyboard reposition competes with the transition on the UI thread.

Why this severity: Low because users can dismiss the keyboard manually, but the lingering state degrades perceived submit success.