← Back to Mobile application starters · project planning pack

Skill · Version 1.0.0

Verify mobile implementations

Combines relevant static checks, behavior tests and honest device evidence without equating a bundle build with a working app.

mobile-verification

Agents using this skill

See how it helps

When is it useful?

Use before claiming a mobile change works on its target platforms.

What does it help you do?

  • Runs project-specific analysis, generated-code and build checks.
  • Tests affected loading, error, offline and lifecycle behavior.
  • Reports simulator, physical-device and unverified-platform coverage separately.

Try asking this

Verify a new upload flow and distinguish Android-device results from an iOS build that was not launched. Interrupt upload on a physical Android device and reopen the app. Report the observed result separately from static checks and the unexecuted iOS scenario.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Mobile Verification & Build

Verify mobile changes with the project's typechecker, static analyzer, test runner and bundler/compiler, and state explicitly what was verified on iOS, Android, simulator/emulator or only at the code level.

1. Static analysis, codegen and bundle/build verification

  • React Native / Expo:
    • Run npx tsc --noEmit and ESLint.
    • When package.json, app.json or native config plugins change, run npx expo-doctor and verify bundle compilation (npx expo export --dump-sourcemap or Metro bundle check) catches missing assets, broken imports or New Architecture incompatibilities.
  • Flutter:
    • When @freezed, @JsonSerializable, @riverpod or @HostApi (Pigeon) definitions change, run dart run build_runner build --delete-conflicting-outputs first.
    • Run flutter analyze (zero warnings/errors) and dart format --output=none --set-exit-if-changed.
  • Native iOS / Android:
    • When native manifests, Podfile or Gradle files change, verify xcodebuild / ./gradlew assembleDebug or testDebugUnitTest when the toolchain is available in the environment.

2. Targeted automated tests across states

  • React Native (Jest + React Native Testing Library):
    • Render screens/components with required providers (navigation, query client, safe area), query by accessible role/label (getByRole, getByLabelText, findByText), trigger interactions via userEvent / fireEvent, and mock native modules at the service boundary.
  • Flutter (flutter test):
    • Write unit tests for repositories/notifiers/blocs (ProviderContainer or blocTest) and widget tests (testWidgets, pumpWidget, pumpAndSettle) with fake/overridden repositories.
  • Required test matrix: verify not only the happy path, but also loading state, empty state, network/server error + retry, form validation errors, and permission-denied fallback.
  • Never weaken security settings (NSAllowsArbitraryLoads, usesCleartextTraffic), skip failing tests or silence type errors to force a pass.

3. Honest platform reporting and release guardrails

  • State verification scope explicitly: distinguish what was verified via automated tests, iOS Simulator, Android Emulator or physical hardware. Hardware-dependent features (camera, biometrics, APNs/FCM push delivery, background task throttling, thermal/60fps behavior) must be flagged for physical device QA if only tested in a simulator or unit test.
  • Never alter signing certificates, keystores, bundle IDs or store credentials, never send push notifications to production topics, and never trigger eas submit, fastlane deliver or production OTA publishes without explicit permission.

Before you finish

  • Typecheck, analyzer, linter, codegen and bundle/compile checks executed and clean.
  • Automated unit and component/widget tests cover happy path + loading, empty, error/retry and permission states.
  • Handoff states clearly what ran on iOS, Android, simulator or unit tests, and lists device-only checks for QA.

Included files 2

  • LICENSE.txt
  • SKILL.md