mobile-architecture-director

Mobile Architecture Director

Choose the platform that best satisfies the product's hard constraints and organizational ability to operate it. Do not convert team preference into architecture evidence.

Trigger boundary

Use this skill for:

• deciding Flutter versus Expo/React Native versus native or another approach;
• reviewing whether an existing mobile platform choice still fits new constraints;
• defining shared/native boundaries, delivery model, offline/data architecture, and prototype risks before implementation;
• producing a mobile architecture decision record with disqualifiers and validation.

Do not trigger for:

• implementing Flutter—use flutter-production-builder after selection;
• implementing Expo/React Native—use expo-react-native-builder after selection;
• general web responsive work;
• a choice already constrained by an approved platform decision unless new evidence invalidates it.

Required inputs

Capture:

1. target users, countries, devices, OS/platform minimums, and accessibility obligations;
2. core flows, UI/brand demands, release cadence, and expected product lifetime;
3. device APIs, background execution, widgets/extensions, media, graphics, maps, payments, identity, notifications, and deep links;
4. offline duration, sync/conflict, local data sensitivity, and backend contracts;
5. latency, startup, animation, memory, battery, binary/download, and reliability needs;
6. app-store, enterprise, web/desktop, over-the-air update, and compliance constraints;
7. team skills, hiring, ownership, CI/build infrastructure, native support, and migration budget;
8. existing code/assets and the amount that is genuinely reusable.

Replace “cross-platform” with the exact surfaces that must share behavior, UI, domain logic, or release timing.

Safety baseline

• Inspect and preserve the repository, prototypes, approved product decisions, and uncommitted user work; do not replace an existing app merely to simplify the comparison.
• Do not select from popularity, one benchmark, or a preferred language alone.
• Verify current platform/framework support from primary sources and date the record.
• Treat third-party plugin/native-module compatibility as a prototype question, not a promise.
• Do not assume over-the-air updates can change native code or bypass store policy.
• Do not reduce security to “use secure storage”; model trust, data, device compromise, transport, auth, and backend authorization.
• Never claim feature parity without platform-specific acceptance criteria.