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.
flowchart TB
APP[Mobile-app dedicated]
A[1. 2-OS support<br/>iOS + Android]
B[2. Store reviews<br/>Apple / Google]
C[3. 30% fee<br/>in-app payment obligation]
D[4. Push / device-specific<br/>sensors, camera, location]
APP --> A
APP --> B
APP --> C
APP --> D
classDef root fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef cons fill:#fee2e2,stroke:#dc2626;
class APP root;
class A,B,C,D cons;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
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)