Build mobile features with ak:mobile-development

Use ak:mobile-development to plan, implement, debug, or verify a mobile feature for React Native, Flutter, native iOS with Swift/SwiftUI, or native Android with Kotlin/Jetpack Compose. The Skill emphasizes mobile constraints: small screens, intermittent networks, device resources, platform conventions, secure storage, accessibility, real-device testing, and staged release.

Choose one platform boundary

Use ak:mobile-development when

• The target is an iOS or Android app and the framework is known.
• You need a native-versus-cross-platform decision grounded in team, feature, device, and maintenance constraints.
• You are implementing offline sync, authentication, notifications, deep links, accessibility, performance, or a platform-specific capability.
• You need a mobile debugging or release-readiness workflow with device evidence.

Choose another workflow when

• The target is a responsive website or PWA rather than an installed mobile app. Use ak:frontend-development or ak:web-frameworks.
• You need product or visual direction before implementation. Use ak:brainstorm or ak:frontend-design.
• You are integrating a payment provider. Use ak:payment-integration for that provider contract alongside the mobile SDK boundary.
• You need only an independent code review or test pass. Use ak:code-review or ak:test.

Prepare the toolchain, devices, and services

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the current runtime and scope.
• Name exactly one primary stack: React Native/Expo, Flutter, Swift/SwiftUI, or Kotlin/Compose. Read its installed framework, language, SDK, build-tool, package-manager, and minimum OS versions from the project.
• Identify supported devices, screen classes, accessibility needs, offline behavior, data-conflict policy, background work, battery budget, and performance targets.
• Use development backends, test accounts, simulator/emulator fixtures, and approved physical devices. Keep signing keys, certificates, provisioning profiles, keystores, API tokens, push credentials, user data, and production logs out of prompts, source control, screenshots, and unprotected artifacts.
• State whether dependency installation, native project generation, pods or Gradle changes, device control, network proxies, analytics/crash services, signing, store upload, or rollout is authorized.

The bundled references describe a 2024–2025 toolchain snapshot. Store SDK requirements, framework versions, device support, APIs, review rules, and submission deadlines must be verified against current official sources.

See Runtime adapters for component-level differences.

Run the Skill

The declared argument shape is [platform] [feature]. Start with react-native, flutter, ios, or android, then name the supported OS/device matrix, network behavior, tests, and release boundary.

/ak:mobile-development "react-native Add an offline-capable saved-articles screen to the existing app. Reuse its database, navigation, state, and design system; define sync conflicts and retry states; test accessibility and low-connectivity behavior; do not add analytics, use production data, sign, upload, or release."

/ak:mobile-development "react-native Add an offline-capable saved-articles screen to the existing app. Reuse its database, navigation, state, and design system; define sync conflicts and retry states; test accessibility and low-connectivity behavior; do not add analytics, use production data, sign, upload, or release."

$ak:mobile-development "react-native Add an offline-capable saved-articles screen to the existing app. Reuse its database, navigation, state, and design system; define sync conflicts and retry states; test accessibility and low-connectivity behavior; do not add analytics, use production data, sign, upload, or release."

Observe the mobile stages

1. The run verifies the actual stack and device matrix. It reads project versions, native modules, generated areas, build variants, and minimum OS support before choosing a pattern.
2. The run defines mobile states and constraints. Touch, safe areas, system navigation, permissions, offline data, conflicts, background work, accessibility, battery, memory, and network behavior stay explicit.
3. The run selects platform-compatible architecture. It preserves the project’s state, navigation, storage, dependency injection, and native-module boundaries rather than introducing a generic architecture.
4. The run implements the smallest feature slice. Code, native config, localization, permissions, migrations, and generated artifacts remain within the approved ownership boundary.
5. The run verifies progressively. Static and unit checks run first, then emulator/simulator, approved physical devices, constrained networks, accessibility services, profiling, and E2E as required.
6. The run reports release readiness. Changed files, packages, permissions, services, device coverage, measurements, signing needs, store metadata, and unperformed upload/rollout steps are listed.

Keep devices, data, signing, and stores under approval

• Package, CocoaPods, Gradle, code-generation, and native-build commands can run scripts, rewrite project files, download large toolchains, and create sizable caches or artifacts.
• Network proxies and crash/session-replay tools can capture tokens, user data, request bodies, screens, and interactions. Use synthetic data, redact logs, and obtain privacy approval before external telemetry.
• Store tokens in Keychain, KeyStore-backed storage, or the project’s approved secure abstraction. Do not hardcode credentials or assume biometric success equals backend authorization.
• Offline writes need durable identity, retry, conflict, deletion, and rollback behavior. Optimistic UI must expose unsynced and failed states.
• Real-device testing is required for release confidence, but it does not authorize using a personal device, production account, or real customer data.
• Signing, TestFlight/internal-track upload, phased rollout, store submission, production release, and rollback are separate approvals.

Verify the result

A complete result should provide:

• The platform, installed toolchain evidence, minimum OS/device matrix, and user-visible state contract.
• Exact changed files, native configuration, permissions, packages, generated output, local schema, environment names, and external services.
• Focused static, unit, component/widget, integration, E2E, accessibility, localization, permission, offline, conflict, and recovery test results.
• Comparable launch, frame, memory, network, battery, or app-size evidence when performance is in scope, measured on named environments and devices.
• Device coverage and gaps, crash/log evidence with sensitive data removed, and confirmation that signing/upload/release did not occur unless authorized.

Troubleshoot or continue

Continue with ak:test for independent verification, ak:devops for a separately approved CI/CD workflow, or the Engineer Kit overview for coordinated delivery.

Know the current limits

• Framework comparisons, adoption figures, performance percentages, budgets, SDK requirements, and store timelines in the source are dated guidance, not current guarantees or universal acceptance criteria.
• The Skill does not include Xcode, Android Studio, SDKs, emulators, devices, developer accounts, signing identities, store credentials, or device farms.
• Its references do not prove support for every OS, device, architecture, native SDK, background mode, accessibility service, or store policy.
• The Skill provides patterns, not a bundled mobile test suite, security audit, privacy review, crash service, build pipeline, or release monitor.
• Stable and beta contain identical Skill content and resources for this release pair. Beta Codex Hook diagnostics do not change this workflow.