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.
Before you read this
This article builds a real system end to end, so vocabulary from every category of the series turns up. If IT vocabulary is unfamiliar, reading the primers "How a Web Service Works" and "Servers and the Cloud" first makes it far easier to follow. You can also look anything up in the glossary as you read.
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
Here are the six most dangerous of the typical ways a mobile-only product goes wrong.
| Forbidden move | Why it is bad → what to do instead |
|---|---|
| An app that is nothing but a WebView | Apple rejects it as a “thin app” → move the main features onto native UI |
| Wiring digital payments straight to Stripe | it breaks the App Store guidelines and is force-rejected → digital goods go through in-app purchase |
| Asking for push-notification permission immediately on launch | once refused it is hard to ask again → ask in a moment that has context |
| Hard-coding an API key inside the app | decompilation leaks it → fetch it via the server |
| Building natively for both operating systems when little depends on new OS features | twice the staffing cost, which is fatal → Flutter or React Native is enough |
| A schedule with no buffer for store review | a one- to two-week delay from human review is normal → keep at least a week of buffer before the marketing date |
Shipping without crash reporting (Crashlytics), aiming for pixel-identical UI on iOS and Android (which breaks both platforms’ human-interface guidelines), and firing off forced updates are the other standard failures.
AI decision axes — Flutter and RN have high AI generation accuracy
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
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.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (91/95)