Native is a behaviour, not a framework.

The first mobile decision is where the product needs platform fidelity, device access and independent release control. We choose Swift and SwiftUI, Kotlin and Jetpack Compose, React Native with Expo, or an explicit hybrid shell from those requirements. Code reuse matters, but it follows the interaction, hardware, lifecycle, performance and team constraints rather than overruling them.

We can work inside other serious mobile stacks. These are current choices, not the edge of our capability.

A mobile codebase has to remain understandable through view recreation, process death, intermittent connectivity and years of SDK changes. We separate presentation state, domain rules, data access and platform capabilities, then decide which layer can be shared. Native UI can sit over common Kotlin domain and persistence code; React Native can isolate Expo and native APIs behind typed adapters; a hybrid shell can keep its bridge contract independent of its screens.

• One observable state model drives each screen and makes loading, empty, error and recovered states explicit Unidirectional stateMVVM
• Domain behaviour stays independent of view controllers, composables and React components Use casesState reducers
• Network, storage, clock and device services enter through replaceable interfaces RepositoriesPlatform adapters
• Cross-platform logic is shared only where both platforms have the same contract Kotlin MultiplatformTypeScript
• Design tokens can be shared while touch targets, typography and controls respect each platform TokensNative components
• White-label, environment and product variants share modules without sharing mutable configuration Expo configGradle flavorsXcode schemes

A shared codebase should reduce duplicate decisions. It should not hide platform behaviour behind conditionals spread through the UI.

A cross-platform SDK is a compatibility surface across several runtimes: the underlying iOS and Android frameworks, the Swift and Kotlin adapters, the React Native bridge, the JavaScript or TypeScript API, and every consumer build. We design that surface deliberately, preserve platform differences where they matter, and release it with the documentation, sample applications, testing hooks and version evidence expected of a maintained product.

A native module is not finished when it compiles in the example app. It is finished when a consumer can integrate, upgrade, diagnose and test it without reading its internals.

Mobile sessions are repeatedly paused, resumed, recreated and entered from outside the app. Navigation therefore has to be a restorable product state rather than a stack of incidental screen calls. We map universal links, app links, push payloads and internal routes through one parser, preserve safe state, and make foreground, background and terminated launches converge on the intended destination.

A cold launch from a notification and a warm in-app navigation may share a route, but they do not share the same lifecycle.

Bluetooth, camera, location, motion, notifications, biometrics and background work are not library checkboxes. Each capability has permissions, unavailable states, operating-system limits and privacy consequences. We isolate it behind a narrow interface, request access in context, explain the value before the system prompt, and design the useful path when access is denied or hardware disappears.

• BLE discovery, connection, GATT services and packet handling kept behind a device state machine Core BluetoothAndroid BLE
• Camera, image selection and media capture with bounded file and privacy handling AVFoundationCameraXExpo ImagePicker
• Location, motion and geofencing modes selected from the actual foreground or background need Core LocationFused LocationActivity Recognition
• Push registration separated from notification routing and user preference state APNsFCMExpo Notifications
• Credentials and sensitive local material kept in platform-protected storage KeychainKeystoreBiometrics
• Background work scheduled within power, network and operating-system constraints BGTaskSchedulerWorkManager
• Continuous sensing recovers after process loss, device restart and application replacement Foreground serviceBoot receiverBackground session
• Battery, permission and sensor restrictions become actionable settings health DiagnosticsSettings handoff

The operating system owns the final permission decision. The product owns whether that decision is understandable and recoverable.

Offline is not a banner shown after a failed request. It is a decision about which data is authoritative, which actions can be queued, how freshness is communicated, and what happens when two devices change the same record. We keep a bounded local model, record pending operations durably, make retries safe, and reconcile against the server without silently discarding user intent.

A cache accelerates a read. An offline model preserves a user workflow. They require different guarantees.

A serious hybrid application is a native host with a governed web runtime—not a full-screen browser. We define the bridge as a versioned API, keep native capabilities narrow, permit only trusted origins, and supervise both document loading and web-app readiness. Navigation, external URLs, process termination, slow starts and bridge incompatibility all receive explicit policy and recovery UI.

• Typed request, response and event schemas shared by native and web consumers Bridge contractRuntime validation
• First-party origin allowlists and separate policy for frames, external links and development Origin policyNavigation guard
• Document-load, hydration-readiness and liveness signals monitored independently WatchdogsHealth probes
• Hardware back, deep links and push destinations translated into product routes Route bridgeHistory contract
• Media, browser, telephone and other specialised flows handed to native surfaces Native playbackSystem browser
• Content-process eviction and renderer failure recover without trapping the user Reload policyBounded retry

A WebView reduces duplicated interface code only if the bridge, lifecycle and failure states are engineered as first-class mobile behaviour.

Mobile performance includes launch time, frame stability, memory pressure, battery, radio use and package size. We measure on representative physical devices, keep image and list work away from the critical interaction path, stream large media, and move playback or capture into native components when the web or JavaScript runtime cannot meet lifecycle and resource requirements.

• Cold and warm launch paths measured through the first usable interaction Launch tracingReadiness markers
• Long lists virtualised and recomposition or re-render boundaries kept narrow Lazy listsMemoisation
• Images resized, cached and decoded for the rendered target rather than the source asset Image pipelineResponsive assets
• Video streamed and handed to platform playback where backgrounding or controls require it AVPlayerExoPlayerExpo Video
• Large uploads resumable, observable and decoupled from one foreground session Multipart uploadProgress state
• CPU, network and sensor polling constrained to protect battery and thermals ProfilingBackoff

A smooth simulator is not a performance result. Low-memory devices, slow storage, poor networks and background transitions are part of the benchmark.

The fastest mobile tests hold domain rules, route parsing, bridge policies and sync decisions outside the UI. Integration tests then prove storage, permissions, native modules and network adapters; a smaller UI suite protects critical journeys on supported OS versions and devices. Accessibility is part of those contracts, including semantics, focus order, dynamic type, contrast, reduced motion and touch targets.

A screenshot-perfect UI can still be unusable with a screen reader, large text, one hand, a hardware keyboard or an interrupted network.

Mobile delivery combines source, native dependencies, environment configuration, signing identity, store metadata and server compatibility. We automate reproducible builds, separate product and environment variants, distribute betas early, stage production rollout and connect crashes and performance regressions to the exact release. Because rollback is constrained by store review, compatibility and remote controls are designed before launch.

• Deterministic iOS and Android builds from reviewed configuration EAS BuildXcodeGradle
• Signing credentials and provisioning isolated from source and scoped to release automation App Store ConnectPlay signing
• Native libraries and cross-platform modules published with compatible artifacts and types CocoaPodsGradleNPMSemantic versioning
• Beta lanes publish to internal testers before store submission TestFlightFirebase DistributionFastlane
• Staged rollout, feature flags and server compatibility reduce blast radius Phased releaseRemote config
• Crashes, hangs, launch failures and performance tied to version and device context Crash reportingRelease health
• Support can collect bounded on-device logs and state without exposing unrestricted user data Rolling logsDiagnostic bundle
• Minimum-version and data-migration policy handles clients that cannot update immediately Version gatesBackward compatibility

On mobile, “roll back” often means waiting for another reviewed binary. Safe releases depend on compatibility, staged exposure and remote containment.