Every mobile project I have seen go sideways had the same origin story: the framework was chosen in the first meeting, before anyone had written down what the app actually needed to do. Someone had a favourite stack, someone else had read a benchmark thread, and the decision was locked in before the requirements existed.
This post is the opposite approach. It treats "native or cross-platform?" as an engineering decision that falls out of your requirements, not a preference you defend. It is aimed at developers and technical founders planning an app that has to live on both iOS and Android, with a bias toward marketplace and transactional products where payments, real-time state and integrations dominate the work.
The short version, borrowed from the original Journeyhorizon guide: the technology should follow the product requirements, not the other way around.
Step 0: Confirm you actually need both platforms on day one
Before comparing stacks, check the premise. Supporting both platforms widens your reach. Android has the larger global user base, while iOS carries particular weight in markets like the US, Australia and parts of Europe. Users also expect the same core features, account access, performance and update cadence regardless of the device in their pocket.
But "both platforms eventually" is not the same as "both platforms at launch". Plenty of teams ship on one OS, validate demand, then expand. That is a legitimate strategy. The one thing you should not do is pick a single-platform architecture while your roadmap clearly says "Android in Q3". If both platforms are on the roadmap, your technical decisions should assume it from the first commit.
Q: Is the second platform on the roadmap within the next year?
no -> optimise for the first platform, keep the backend API-first
yes -> evaluate native vs cross-platform now, not later
The two options, stated plainly
Native means two separate apps: typically Swift for iOS and Kotlin for Android. You get maximum control over the platform and the best possible access to hardware and new OS features. You also get two implementations of every feature, two sets of bugs and two release pipelines.
Cross-platform (Flutter or React Native, most commonly) means a large share of the codebase is common to both platforms. Duplicated work drops and feature parity becomes much easier to keep, because there is one implementation of the business logic and most of the UI. You still test on both OSes, and you will occasionally write a native module for something the framework does not cover.
A requirements-first decision matrix
Instead of arguing about frameworks, list your requirements and see which column they push you toward.
| Requirement | Leans native | Leans cross-platform |
|---|---|---|
| Heavy use of platform-specific hardware | ✅ | |
| Demanding graphics or rendering | ✅ | |
| Needs brand-new OS features at release | ✅ | |
| Speed to market on both stores | ✅ | |
| Long-term maintainability with a small team | ✅ | |
| Consistent UX and feature parity | ✅ | |
| Standard flows: auth, payments, booking, chat | ✅ |
Most marketplace and SaaS-style apps land heavily in the right-hand column. Most games, AR experiences and hardware-centric apps land on the left. If your list is genuinely mixed, that is a signal to spend a few days on a spike rather than guess.
Cost is a lifecycle number, not a build number
The comparison that misleads teams most is the initial estimate. A native build may need separate expertise per platform, more QA and more coordination between two release trains. A cross-platform build cuts duplication, but it does not eliminate testing on both operating systems, and the occasional native module still costs time.
Then there is everything after v1, which is where most of the money goes:
- [ ] App Store and Google Play releases
- [ ] OS updates and breaking platform changes
- [ ] Security patches
- [ ] Backend infrastructure and API maintenance
- [ ] Analytics and monitoring
- [ ] Ongoing QA
- [ ] New features
The cheapest option up front is often not the cheapest across the product's life. Weak architecture and inexperienced implementation are what quietly inflate maintenance costs, whichever stack you choose. The team matters as much as the framework.
Architecture checklist before you write UI code
Whatever you pick, these decisions come first, because the mobile client is only as good as what sits behind it.
1. API readiness
Your app needs reliable APIs to reach authentication, payments, databases, your CRM and third-party services. If you already have a web product that was not designed around APIs, expect backend work before mobile work. Budget for it explicitly.
2. Real-time surfaces
Mark every feature that needs live updates. In a marketplace that usually includes:
realtime:
- messaging
- live_tracking
- booking_status
- payment_status
- notifications
Each line adds infrastructure requirements. Knowing them early prevents a late scramble for sockets or event streams.
3. Offline behaviour
Decide what the app does without a connection. Some content can be cached safely. Payments and significant account changes usually need a live server round trip. Write this down per feature instead of discovering it in QA.
4. Scope discipline
A focused app that handles the core workflows reliably beats a large app full of half-finished features. Trim to the flows that prove the product works.
Integrations: plan them in the architecture, not after it
Mobile apps rarely stand alone. Expect connections to your website, CRM, analytics, payment provider, booking software, support desk and internal tools. A few that deserve early attention:
- Payments: Stripe, PayPal, Apple Pay, Google Pay or regional methods, each with its own rules.
- Authentication: Sign in with Apple, Google, email, phone or biometrics.
- Push notifications: must be reliable on both platforms while respecting permissions and user preferences.
- Analytics: consistent events across platforms for acquisition, activation, conversion, retention, feature usage, crashes and performance, defined before launch rather than retrofitted.
Release engineering is a feature
Shipping to the stores is its own workstream. Apple and Google have different submission requirements covering privacy, payments, permissions, functionality and metadata. Test on representative real devices, not only simulators.
One architectural trick pays for itself repeatedly: keep frequently changing business logic on the backend. Web deploys are instant; app updates may need store review and a user download. Every rule you can change server-side is a store release you do not have to wait on.
After launch, wire crash data, analytics, user feedback and support tickets back into planning. That loop is what makes v2 better than v1.
Where Flutter fits
Flutter is a strong option when you need iOS and Android without maintaining two fully separate codebases. It shares a large portion of UI and business logic and still lets you drop to native code where needed. It handles authentication, payments, notifications, APIs, custom interfaces and integrations in production, which covers most startup, SaaS, booking and ecommerce products.
The caveat is the same as everywhere else in this post: choose it because your requirements point there, not because "cross-platform" sounds efficient. A good partner should be able to walk you through the trade-offs between Flutter, React Native and native for your specific product.
Timeline expectations
There is no honest single number. A focused MVP can take several months. Apps with payments, real-time features, AI, multiple integrations or heavy backend work take longer. If someone quotes you a firm date before seeing your requirements list, treat that as a red flag.
Takeaway
Write the requirements list first. Score it against the matrix. Plan APIs, real-time, offline and integrations before UI. Push volatile logic to the backend. Then pick the stack.
The full original guide on native vs cross-platform iOS and Android development covers the same ground from a founder's angle. If you want a team to pressure-test your requirements before choosing a stack, Journeyhorizon builds production apps through its Flutter mobile app development service, with a focus on marketplaces.
Top comments (0)