Native or cross platform
Native means a separate program for each operating system in that system own language, and cross platform means one codebase that runs on both. For an app whose job is showing content and taking forms, cross platform is usually the right choice, and pitching native in that situation is overselling.
- Lesson 2 of 8
- Beginner
- Free, no signup
Two columns, no winner
Native
- Kotlin for Android and Swift for iOS
- Two codebases, so every feature twice
- The performance ceiling and full platform access
- Higher upkeep, especially from the second year
- When you have continuous graphics or sustained hardware work
Cross platform
- One shared codebase across Android and iOS
- Build once, test once, maintain once
- Fast enough for lists, forms and content
- Dependent on a layer that wraps the platform capabilities
- When the team is small and the maintenance budget is limited
There is no red cross here because neither column is wrong for everybody. The second column is the right answer for a large share of this page readers, and a later section says where it reverses.
Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.
What exactly is the difference between native and cross platform?
Native means writing the program with the tools and the language of that operating system itself. Google own documentation is explicit: since 2019 Android development has been declared increasingly Kotlin-first, and the same page recommends starting with Kotlin if you want to build an Android app. On the Apple side it is Swift. The consequence is that one app on two operating systems is two separate programs.
Cross platform means writing one codebase and running that same code on both. The two common families take two different routes and that difference is the thing worth understanding. The React Native documentation says that at runtime it creates the corresponding Android and iOS views, and that because its components are backed by those same native views, the apps look, feel and perform like any other apps. Flutter goes another way, and its supported platforms page shows a reach beyond Android and iOS that takes in Windows, macOS and Linux as well.
So the argument is not about speed, it is about how many times you do the same piece of work. A team on native builds each feature twice, tests it twice and maintains it twice. A team on cross platform builds it once and writes an exception wherever a platform behaves differently. The real cost of both routes is inside that sentence.
The four things that actually change the decision
The performance ceiling. For lists, forms and content screens both routes are fast enough and the user sees no difference. The ceiling shows itself when the work is continuous and heavy: sustained animation, live processing of the camera image, games. That is where native pulls ahead, and only if the program genuinely does that kind of work.
The size and the knowledge of the team. This is the biggest factor and the least talked about. One person who knows Kotlin goes faster and safer in Kotlin than in a framework they are learning as they go. Two people who have to maintain both Android and iOS can breathe with a single shared codebase. The right question is not which technology is better, it is who opens this code tomorrow.
Budget, and above all the second year budget. The first cost is building and the cost that kills projects is upkeep. Two codebases mean every small change twice, every bug twice and every release twice. If the maintenance budget is not enough for one of the two, the decision has effectively been made already.
Reaching both stores. This is the line repeated most often in favour of cross platform, and for the Iranian market it is exactly the one that has to be examined again. The next section does that.
The question that settles the decision more than any framework comparison
Does the program spend most of its time on continuous graphics or hardware
Native earns its cost
- games, an image editor, a heavily animated interface
- live use of the camera or the sensors
- widgets, background services and deep integration
Take cross platform
- lists, forms, search, content screens
- sign in, orders, messages, notifications
- a small team and a limited maintenance budget
This question is about what the program does, not about the quality of the technologies. Cross platform can do the left hand jobs too, only with a lower ceiling and with native code you end up writing alongside it.
For the Iranian market, what does reaching both stores mean?
Google official page titled supported locations for developer and merchant registration carries a table of 215 countries and territories. We read that page today: Iraq is in the table and the word Iran does not appear once in the whole page. Which is to say that the official developer registration route for someone in Iran is not defined in that table. We neither suggest a way around it nor claim that no route exists; what we state is what Google own document says.
So when somebody sells publishing to both stores as the main advantage of cross platform, the question has to be changed for the Iranian market. An Android app here is installed from Cafe Bazaar and Myket, and sometimes straight from a file on the site itself, while the iOS version is a separate story. The detail of that belongs to the publishing lesson on this path.
Now the conclusion the adverts do not state: if in practice you only publish for Android, a large part of the reason for choosing cross platform disappears, and Kotlin becomes a perfectly sensible choice again, because you have that single codebase anyway and you get the performance ceiling and full platform access with it.
The reverse holds too. If this same app is meant to have an iOS version next year, going back and writing it from scratch costs more than having one shared codebase from the start. The right decision depends on whether that iOS version is a real plan or a sentence in a meeting.
Where cross platform does not work
Four situations. First, anything with continuous graphics: games, an image editor, any interface redrawn dozens of times a second. Second, sustained work with the hardware, such as live use of the camera or sensors you have to read in the background. Third, deep integration with the operating system: a home screen widget, a background service, behaviour tied to the system version.
The fourth is more technical and it catches out more projects than the other three. Cross platform depends on a layer that wraps the platform capabilities for it. As long as that wrapper exists, everything is fine. The moment a new or rarely used capability is needed and no wrapper for it exists, that piece has to be written natively, once for Android and once for iOS. At that point you have three codebases instead of one. This cost never appears in the first estimate.
And a fifth situation which is not technical at all: a team that only knows native and is not going to change. Learning a new stack in the middle of a real project is a cost that usually exceeds the saving that stack was chosen for.
Answer these five questions before choosing a stack
Where does your user install the app from? What does the app spend most of its time on, content and forms or the camera and graphics? Who maintains it in the second year? If an iOS version is needed tomorrow, is the budget there? And what does the team genuinely know today?
Put the five answers side by side and the decision usually shows itself, without anybody having to take it for you. What you should not do is start from a framework comparison list; those lists are all correct and none of them is about your project.
Our position, the one written on our app development services page and standing there before this lesson existed: for an app that works with content and straightforward forms, cross platform is the more sensible pick, and we do not propose the most expensive option by default. If you are still unsure which group your app falls into, the lesson on how an app actually works shows the border this grouping comes from.
Which question changes the answer and which only costs time
The second column matters more. Most meetings that end without a decision spent all their time on it.
These questions change the decision
- Where the user installs the app from
- What the program spends most of its time on
- Who opens this code in the second year
- Whether the iOS version is a real plan or a sentence
These questions only cost time
- Which framework is more popular
- Which was faster in benchmarks found online
- Which one the large companies use
- Which one has the better future
The questions in the second column are not wrong, their answers simply do not move your decision. If you have a project where one of them genuinely is decisive, that one moves to the first column.
The fast path, with AI
Models are not bad at answering native or cross platform, they are terrible at it: each gives a confident recommendation that comes from the volume of writing about that technology rather than from your project. The move that actually works is changing the question. Instead of asking for a recommendation, make the model turn the decision into something falsifiable.
- Instead of which is better, write down the real constraints of the project: how many people are on the team and what they know, the second year maintenance budget, where the user installs from, and what the program spends most of its time on.
- Take a judgment class model and give it the recipe below. The fast cheap class is for mechanical and bulk work, and this is neither.
- The most important part of the output is not the recommendation; it is the list of three facts that would reverse the answer if they changed. Take that list and see which of them is simply not known about your project. Those are your work for today.
- Run the same recipe once more with the two options written in the reverse order. If the recommendation changes, the model answer depended on the order you wrote them in rather than on the project, and it should be thrown away.
Copy-ready recipe
Role: a technical adviser whose job is to make the decision falsifiable, not to give an opinion.
The project:
What the program does: {two sentences}
Where the user installs from: {a store or a direct file}
Team: {number} people, they know: {technologies}
Second year maintenance budget: {small / medium / large}
iOS version: {a firm plan / only a possibility / not needed}
Give the output in exactly four parts:
1. The recommendation: native or cross platform, in one sentence, with no explanation.
2. Three facts that would reverse this recommendation if they changed. One sentence each.
3. What you do not know about this project and would need for the decision.
4. The question I should ask the team and have not asked yet.
Rules: write no number about performance, percentages or development time. Quote no benchmark. If you have nothing for part three, say that this itself means I have not given enough information.Before you trust the output: The output of this recipe is not a decision, it is minutes of a meeting that still has to be checked with real people. Go through the three facts in part two with the team rather than with the model, because the only person who knows who opens this code tomorrow is you. And if the model writes a number anyway despite the explicit rule, throw that number away; it is a sign that it is speaking from memory rather than about your project.
AI in this kind of work
This is the one topic on this path where models get it wrong predictably, and the reason is plain: the right answer depends on things the model does not know and that are written in no text. So the role left to them is reading vendor documentation and producing a falsifiable set of meeting notes. Our position: ask the model to make the decision refutable, not to take it.
Tools that actually help
- Claude Suited to the four part meeting note the recipe above asks for, especially part three where it has to say what it does not know. Iran is on neither of Anthropic two supported-countries lists; we read that on their own page rather than measuring it.
- NotebookLM When the question is what a framework official document exactly says, this tool beats an ordinary chat because it answers only from the source you gave it. The Flutter supported platforms page and the React Native components document can be put side by side this way. Google own help says it works in the same regions as the Gemini app, and Iran is not on that list.
- Gemini Useful for following the long Android and Apple documents that keep changing. This lesson itself took the Kotlin-first sentence from the official Android documentation rather than from somebody summary. Google own page says the Gemini web app works in more than two hundred and thirty countries and territories, and Iran is not on that list.
Where it backfires
The risk here has a particular shape and it should be stated plainly. The question native or cross platform has no answer inside the texts of the internet, because it depends on your team, your budget and your market. Yet a model always answers, and its answer is effectively a reflection of how much has been written about each technology; Anthropic own guidance on reducing hallucination describes this same class of problem and its remedy is to make the model say what it does not know. If a model writes a performance percentage or a development time, it has almost always made it up.
The practical rule: accept no number about this decision from a model. Take the names of the languages and platforms from vendor documentation, and take the decision from the five questions in the last section. How to pay for these tools from Iran is in the buying guide.
Sources: Anthropic: reduce hallucinations Anthropic: supported countries Google: where the Gemini web app is available
Where this advice stops
This lesson is about business apps and not games; for a game the question is not this one at all and the choice of engine takes its place. There is also a limit about us that has to be stated: we have not run our own benchmark between Flutter and Kotlin and we are not going to pretend otherwise. Everything on this page about the frameworks themselves is quoted from the vendor own documentation, and our first-hand experience is the server side of this work. And a note about time: the store country tables and the supported platform versions change; the date this page was checked is printed above this lesson, and if you are taking a large decision, look at them yourself on the day.
From our own work
The first lesson on this path measured on this same server that our own API returns 403,152 bytes for a ten row list screen in its default shape and 3,780 bytes once four fields are named, and that its first byte arrives with the headers x-flying-press-cache: MISS and cf-cache-status: DYNAMIC, meaning with no cache at all. Not one of those numbers moves with the framework chosen on the phone. For most small business apps that is what sets the speed, rather than the thing this page is about. The second item is about us and is checkable: our services page has taken this same position in public since before this lesson was written, that for a content and forms app cross platform is the more sensible pick and that we do not propose the most expensive option by default. Writing it here is not advertising; it is so that anyone can see whether we say the same thing when we are selling and when we are teaching.
Real follow-up questions
Does cross platform mean the app will be slow?
For lists, forms and content screens no, and the user sees no difference. The React Native documentation says its components are backed by the same native Android and iOS views, which is why the apps look, feel and perform like any other apps. The ceiling shows itself where the work is continuous and heavy, such as a game or live image processing.
If I change my mind later, can I move from cross platform to native?
You can, but the interface has to be rewritten and that part is the most expensive of the job. What carries over is the backend and the API contract, provided they were properly separated from the start. That is exactly why it is worth not burying logic inside interface code, whichever stack you pick.
Does this decision matter for publishing in the Iranian stores?
The output of both routes is an Android package, so in that respect it makes no difference. What does make a difference is that if you only publish for Android in practice, the main saving of cross platform, one codebase for two platforms, disappears. The detail of publishing itself belongs to the publishing lesson on this path.