Mobile Platform Differences

"The phone runs your code, but it does not run your assumptions. The desktop habits are exactly what break."

A Harsher Lifecycle

On desktop your app runs until the user quits it. On mobile the OS is in charge: it suspends your app when backgrounded and may kill it outright to reclaim memory — without warning. The consequence is concrete: never hold important state only in memory. Persist anything that matters (through the store plugin or Rust) as it changes, so a killed-and-relaunched app restores cleanly. Treat 'the OS will kill me at any moment' as a design constraint, not an edge case.

The Screen Fights Back

Mobile screens have notches, rounded corners, home indicators, and on-screen keyboards that shove your layout around. Use the CSS env(safe-area-inset-*) variables so content doesn't hide under a notch or the home bar. Input is touch, not mouse — hover doesn't exist, tap targets must be bigger, and the soft keyboard covers half the screen when it opens. The desktop multi-window model is also gone; a phone app is effectively one window. Your frontend layout needs genuine mobile design, not a shrunk desktop view.

Webviews and Capabilities Differ Too

The mobile webviews (WKWebView on iOS, Android's System WebView) aren't identical to their desktop cousins, so re-test rendering on real devices — the cross-engine caveat from the foundations track is even sharper on mobile. Capabilities also gain mobile-specific schemas: some permissions and plugins are desktop-only, others mobile-only, and the capability files can be platform-scoped so a permission applies only where it makes sense. Check that each plugin you depend on actually supports mobile before assuming it's there.

Code

Safe-area insets keep content off the notch·css

/* Respect notches, home indicators, and rounded corners. */
.app-shell {
  padding-top: env(safe-area-inset-top);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
  padding-right: env(safe-area-inset-right);
}

/* Needs the viewport meta with viewport-fit=cover for insets to apply. */
/* <meta name="viewport" content="width=device-width, viewport-fit=cover"> */

Exercise

Take your app's main layout and make it survive a phone: add safe-area-inset padding, set the viewport-fit=cover meta, and identify one piece of state you currently keep only in memory that would be lost if the OS killed the app — then persist it. You're hardening the two things mobile breaks most: layout and lifecycle.

Hint

Safe areas need both the env() padding AND viewport-fit=cover in the viewport meta. For lifecycle, anything in useState/Zustand-in-memory or a Rust Mutex that isn't written to disk is at risk — route it through the store plugin.