About this article
As an addendum to the “Case Studies” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains the mobile-app dedicated case.
Unlike Web, mobile apps have unique structures of “2 OSes (iOS/Android),” “store reviews,” “payment-platform fees,” “expectations of E2E encryption.” This article organizes native vs cross-platform decisions, store-review traps, push-notification design, and In-App Purchase realities.
What is mobile-app architecture in the first place
Imagine a food truck. Unlike a brick-and-mortar restaurant (a web app), you face unique constraints: “permits needed from two municipalities,” “vehicle-size limitations,” and “a cut of revenue taken as location fees.” You can’t just transplant a restaurant’s design and expect it to work.
Mobile-app architecture is the same: you need to design around simultaneous iOS/Android support, store reviews, 30% fees, and device-specific features — structures that don’t exist on the Web.
If you design with a Web mindset, you’ll hit unexpected walls like store-review rejection or 2x development costs for 2 OSes.
Why mobile-specific design is necessary
Because the constraints are fundamentally different from Web
Web apps reach all users with a single codebase, but mobile must simultaneously support 2 OSes — iOS and Android. On top of that, store reviews, 30% fees, and device-specific features (camera, GPS, push notifications) — constraints that don’t exist on the Web — dictate the entire design.
Because you can’t control the release cycle
Web apps can deploy fixes immediately, but mobile store reviews taking 1-2 weeks is not uncommon, and there’s no guarantee users will update. Since instant bug-fix deployment is difficult, you need to build in Remote Config, Feature Flags, and forced-update mechanisms from the design stage.
Because the cost of fixing a tech-selection mistake is higher than Web
On the Web, you can gradually swap frameworks, but on mobile, migrating from native to Flutter or vice versa is effectively a full rewrite. The initial tech selection (native vs cross-platform) echoes for years, so careful judgment is essential.
Mobile-app unique constraints
The biggest difference from Web is simultaneous provision to 2 OSes. The first decision is whether to build the same features on different tech stacks or cover 2 OSes with a common stack.
Native vs cross-platform
| Approach | Representative tech | Strengths | Weaknesses |
|---|---|---|---|
| Native | Swift (iOS) / Kotlin (Android) | Instant OS-new-feature support, top performance | 2x effort with 2-OS separate dev |
| Cross (React Native) | TypeScript | Repurpose Web talent, abundant UI libraries | Lag in OS new features, hard tuning |
| Cross (Flutter) | Dart | Single codebase, good UI performance | Thin Dart talent market |
| Cross (Kotlin Multiplatform) | Kotlin | Kotlin for iOS too, logic-sharing-specialized | iOS UI separately needed |
| WebView wrapper (Capacitor) | TypeScript | Maximum Web-asset reuse | UX degradation, review risk |
The 2026 front-runners are Flutter or React Native, with the rational answer of narrowing native to areas needing instant OS-new-feature uptake (finance, camera, maps). WebView wrappers are easily rejected by Apple review, so safer to avoid for new projects.
Recommended stack
| Area | Recommended | Reason |
|---|---|---|
| Client | Flutter / React Native | 2-OS simultaneous dev, thick talent market |
| Backend | Node.js / Go + Firebase / Supabase | Speed-focused, auth/Push integrated |
| Auth | Firebase Auth / Auth0 / Clerk | Social linkage, phone-number auth |
| Push notifications | FCM (Firebase Cloud Messaging) | iOS/Android common |
| Billing | RevenueCat | Absorbs App Store / Google Play differences |
| Crash reports | Firebase Crashlytics / Sentry | Grasp per-OS crash patterns |
| Distribution | TestFlight / Firebase App Distribution | Standard for beta distribution |
| CI/CD | GitHub Actions + Fastlane | Automate store distribution |
Store-review traps
App Store Review has human reviewers seeing it, so 1-2 week delays naturally occur per guideline interpretation. Grasp typical rejection reasons.
| Rejection reason | Countermeasure |
|---|---|
| Insufficient features (“thin app”) | Build minimum native UI even for MVP |
| Excessive WebView usage | Lean main features to native implementation |
| Payment not using In-App Purchase | Digital content forces IAP (30% fee) |
| Unclear purpose for personal-info collection | Privacy-manifest explicit |
| Ad SDKs in kids-targeted | SDK restrictions in Kids category |
Build schedules premising “1-week stop in review” just before release. 1+ week buffer between marketing day and review-completion day is required.
In-App Purchase and fees
| Revenue scale | Apple fee | Google fee |
|---|---|---|
| Annual under $1M | 15% | 15% |
| Annual over $1M | 30% | 30% |
| Subscription year 2+ | 15% | 15% |
Physical goods and service reservations allow external payment, but for digital content / subscriptions, platform payment is forced. Using subscription-management SaaS like RevenueCat absorbs both stores’ differences while centralizing revenue analytics.
| Billing type | Platform payment required |
|---|---|
| Digital goods (coins, stamps) | Yes |
| Subscriptions (unlimited reading etc.) | Yes |
| Physical goods (EC) | No (Stripe etc. OK) |
| Travel / lodging reservations | No |
| Donations | No |
What to decide — what is your project’s answer?
| Item | Choice examples |
|---|---|
| Client tech | Native / Flutter / React Native |
| Backend | Self-built server / Firebase / Supabase |
| Auth method | Email / SMS / SNS login / Passkey |
| Billing | In-app payment / external (physical only) |
| Push notifications | FCM / APNs direct / OneSignal |
| Offline support | Yes / no / partial |
| Device-specific features | Camera / GPS / Bluetooth / NFC |
| Distribution strategy | Phased release / full deployment |
Pitfalls and forbidden moves
| Forbidden move | Why it’s bad |
|---|---|
| WebView-only app | Apple “thin app” rejection, bad UX too |
| Direct Stripe integration for digital payment | App Store guideline violation, forced rejection |
| Lower OS-version bound at latest only | Existing users can’t use, past-2-version support is standard |
| Request push-notification permission immediately on launch | Hard to re-acquire if rejected, request in contextual scenes |
| Don’t put crash reports | Production failures invisible, Crashlytics required |
| Hardcode API keys in app | Leaks via decompile, retrieve via server |
| Spam forced updates | User attrition, design preserving compatibility |
| Aim for complete UI match between iOS and Android | Violates both OS HIG, lean to each’s practice |
| ”Native for both OSes” with 2x effort | If OS-new-feature dependence is low, Flutter / RN is enough — 2x talent cost is fatal |
| ”Store review will pass instantly” with no buffer | Apple review is human review, 1-2 week delays are normal, 1+ week buffer before marketing day is required |
AI decision axes
| AI-favored | AI-disfavored |
|---|---|
| Flutter / React Native (abundant training data) | Niche cross-platform |
| TypeScript / Dart type-safe | Dynamic-typing-centric |
| Firebase / Supabase (high code-generation accuracy) | Custom-protocol unique implementation |
| OS-standard APIs (HealthKit, StoreKit2) | Custom Bridge implementation |
- Identify new-feature dependence — native if Apple Intelligence / HealthKit instant support
- If choosing cross, narrow to Flutter / RN — minor gets stuck on talent
- Decide payment from billing type — digital is forced IAP
- Put Push, crash reports, distribution CI from start — adding later is accident-prone
Flutter / React Native have high AI generation accuracy
In cross-platform FW selection for mobile apps, Flutter and React Native are clearly advantaged from an AI-utilization perspective. Both frameworks have large user bases with massive public code on GitHub and Stack Overflow answers, giving AI rich training data.
React Native especially uses the same TypeScript + React syntax as frontend web, so web-dev knowledge transfers directly, and AI can apply React web knowledge to mobile. Flutter has a unique language (Dart), but high-quality official documentation and abundant Flutter-specific training data make AI generation accuracy fully practical.
On the other hand, minor cross-platform FWs like KMM or MAUI have scant training data, causing frequent errors in AI-generated code. They’re disadvantaged in both talent acquisition and AI utilization, so avoiding them without a specific reason is the safe call.
Store reviews and AI-generated code caveats
App Store / Google Play store reviews involve human (+ automated scan) review, so AI-generated code doesn’t carry special risk per se. However, some code patterns AI tends to generate can trigger store review flags.
A typical example: if AI generates code implementing most functionality via WebView, there’s risk of violating Apple’s review guideline 4.2 (Minimum Functionality). Apps not sufficiently using native features get rejected, so even when delegating UI generation to AI, verifying appropriate use of native components is necessary.
Also, apps with billing must implement In-App Purchase (IAP), which must strictly follow the store SDK. AI-generated IAP implementation code sometimes references older SDK versions, so always verify consistency with official documentation.
Related Articles
https://en.senkohome.com/arch-intro-case-ai-product/ https://en.senkohome.com/arch-intro-case-enterprise/ https://en.senkohome.com/arch-intro-case-public/
Summary
This article covered the mobile-app dedicated case, including 2-OS support, store reviews, IAP fees, Push notifications, and AI-era on-device inference.
Tech: Flutter / RN as front-runner, native only for new-feature-dependent areas, 1-week buffer for store reviews, premise forced IAP for payments. That is the practical answer for mobile-dedicated in 2026.
Next time we’ll cover the “AI-product startup” case. Plan to handle special circumstances of LLM API dependence, inference cost, and data setup.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (85/89)