mobile-development

Mobile Development

One skill for building mobile apps on iOS and Android — with per-framework depth for native (Swift/SwiftUI, Kotlin/Jetpack Compose) and cross-platform (Flutter, React Native) stacks. All four share one agent workflow — scaffold, build and sign, test on devices and emulators, and ship to stores — so they live in ONE family skill with per-framework references, following the frontend-engineering precedent. Load the shared workflow below, then pull the reference for the framework you are actually building.

When to use

Load this skill when the task involves any part of the mobile lifecycle:

• Scaffold — creating a new mobile project for iOS, Android, Flutter, or React Native: choosing the framework, initializing the project, and setting up the platform toolchains.
• Build and sign — compiling a debug or release build, configuring code signing (certificates, provisioning profiles, keystores, app signing), or producing distributable artifacts (.ipa, APK, AAB).
• Test on devices and emulators — running and debugging on iOS simulators, Android emulators, or physical devices, including device provisioning, connectivity, and platform-specific runtime behavior.
• Ship to stores — submitting to the App Store (TestFlight, App Store Connect) or Google Play (internal/closed/open testing tracks, Play Console), and reasoning about store review readiness.
• Mobile-specific behavior — app lifecycle and backgrounding, offline storage and sync, push notifications, deep links, and mobile testing (unit, widget, UI, and device-farm testing).

When not to use

• Web frontends — component architecture, state management, and browser behavior belong to frontend-engineering; this skill covers apps that run on iOS and Android devices.
• Backend services and APIs — server-side logic, API design, and data persistence on the server belong to backend-engineering. Mobile apps consume those APIs; they do not replace them.
• Desktop or web platform targets — Flutter for desktop/web and React Native for web (React Native Web) have different delivery and testing surfaces; this skill is scoped to the iOS and Android app store platforms.
• Cross-platform web-first development — if the deliverable is a website or PWA, use frontend-engineering instead.

The Mobile Engineer's Domain

The Shared Mobile Workflow

Every mobile task follows the same four steps regardless of framework. Deep framework-specific detail is deferred to the per-framework reference — read it at the step where it matters.

1. Scaffold

Pin down what the app is before generating code:

• Platform and framework — native iOS, native Android, Flutter, or React Native. Choose based on team skills, target audience, and per-feature needs (see Core Principles).
• Minimum OS versions — the oldest iOS and Android versions you will support; every decision below (APIs, dependencies, testing) flows from this.
• Project initialization — generate the project with the framework's canonical tool (xcodebuild/Xcode template, Android Studio/Gradle, flutter create, npx @react-native-community/cli init or create-expo-app), and commit the scaffold before adding app code so toolchain upgrades stay reviewable.
• Source of truth — a single project root that builds both platforms when using a cross-platform framework, so the artifact is reproducible from the repository.

2. Build and sign

A build that only works on your machine is not a build:

• Build once, in CI — the release build must reproduce on a clean machine or CI runner, not just in your IDE. Pin toolchain versions (Xcode, JDK/Gradle, Flutter SDK, Node).
• Signing is separate from building — keep signing assets (certificates, provisioning profiles, keystores) out of the repository; reference them via environment or secure secret storage. See the per-framework reference for where each platform expects them.
• Distinguishable artifacts — version numbers and build numbers must increment per release so testers and crash reports can identify the build.
• Know your artifact format — .ipa for iOS, APK and AAB for Android, and the framework-specific intermediates. Store submission has hard format requirements (for example, Google Play requires AAB for new apps).

3. Test on devices and emulators

Test where the code runs, not where it is convenient:

• Emulators/simulators for speed, devices for truth — simulators and emulators are fast and scriptable, but physical devices reveal real networking, battery, memory, and sensor behavior. Cover both.
• Cold install — test a fresh install (not just a rebuild over the old version) to catch first-launch, storage, and migration bugs.
• Device matrix — cover the OS versions and screen sizes you declared in scope, plus low-memory and low-storage conditions. Use a device farm (Firebase Test Lab, BrowserStack, Xcode Cloud) when the matrix outgrows local hardware.
• Debug and release parity — the debug build and the release build are different programs (proguard/minification, stripping, optimization). Smoke test the signed release artifact before store submission.

4. Ship to stores

Submission is a checklist, not an afterthought:

• Test track first — distribute to TestFlight (iOS) and an internal or closed testing track (Android) before production; the store will not be your first real device feedback loop.
• Store readiness — metadata, screenshots, privacy policy, data-collection declarations, and privacy nutrition labels must match what the app actually does. Review requirements change; re-check them near submission time.
• Review expectations — both stores reject apps for missing privacy disclosures, misleading metadata, crashes on launch, and broken sign-in or in-app purchase flows. Run the app through the platform's review checklist before uploading.
• Rollout — prefer staged rollouts (phased release on Play, gradual release on App Store Connect) so a regression reaches few users before it reaches everyone.

Mobile-Specific Concerns

These concerns are where mobile engineering differs from web and desktop work.

App lifecycle and backgrounding

Mobile OSes kill and suspend apps aggressively; the lifecycle is not optional:

• Lifecycle states — iOS (foreground/background/inactive, scene-based lifecycle) and Android (activity/fragment states, process death). State that is not persisted across these transitions is lost.
• Background execution is a privilege — both platforms restrict background work. Use the platform's sanctioned mechanisms (background modes, WorkManager, background fetch, push-driven wakeups) instead of fighting the OS.
• Process death — the OS can kill the app at any time. Save in-progress state, and restore UI state from storage on relaunch, not from memory.

Offline and sync

Mobile networks are unreliable; offline is a first-class mode:

• Offline-first storage — local persistence (Core Data, Room, SQLite-based stores, or key-value stores) is the source of truth while disconnected; the network is a sync channel, not a dependency.
• Sync semantics — define conflict resolution (last-write-wins, per-field merge, or explicit conflict UI), idempotent writes, and retry with backoff. Never blindly overwrite newer remote data with stale local data.
• Queue mutations — writes made offline must be queued and replayed in order when connectivity returns, with a clear sync state surfaced to the user.

Mobile-specific testing

Beyond unit tests, mobile code needs platform-aware testing:

• Unit and widget/component tests — framework-level logic, reducers, and state without a device (XCTest, JUnit, Flutter widget tests, Jest).
• UI/instrumentation tests — drive the real UI on a device or emulator (XCUITest, Espresso/Compose UI tests, Flutter integration_test, Detox).
• Device-farm coverage — run the UI suite across the device matrix on a farm; a test that passes on one device is not a guarantee.
• Performance and battery — measure launch time, frame rate, memory, and network on device, not just functionality.

Core Principles

Pick the framework by the constraints, not the hype — native iOS and Android give the deepest platform integration; Flutter and React Native give shared code across platforms. The right choice depends on team skills, the device APIs the app needs, and how much per-platform work is acceptable. Match the decision to the app's actual requirements.

The OS lifecycle is part of the contract — mobile apps are suspended, killed, and backgrounded constantly. Any feature that assumes the app is always alive and online will break. Design for process death and disconnection from the first commit.

Signing and builds are release engineering, not CI garnish — an app that cannot be reproducibly built and signed cannot be released, patched, or audited. Keep signing assets secret, pinned, and scriptable, and treat the release pipeline as production infrastructure.

Test the artifact you ship — the signed release build, not the debug build, is what users and reviewers see. Smoke-test it on a real device before it reaches TestFlight, Play, or the App Review team.

Store requirements are moving targets — privacy declarations, target API levels, and submission formats change every year. Verify requirements against the current store documentation near submission time rather than relying on remembered rules.

Related skills

• frontend-engineering — web frontend methodology; the sibling family-skill precedent this skill mirrors, and the routing target for browser-based UI work.
• backend-engineering — the APIs and services mobile apps consume; the routing target for server-side work.
• release-engineering — release orchestration, versioning, and rollout methodology; store releases are one instance of the discipline.
• qa-methodology — test strategy and quality gates; the routing target for product-wide test planning.
• platform-engineering — CI/CD pipelines and build infrastructure for shipping mobile builds at scale.