Start With What the App Has to Do
The question usually gets asked as native or cross platform, and it usually gets answered by whichever developer is in the room, according to what they last built. That is a preference wearing a suit rather than advice.
There is a better starting point and it takes one sitting. Write down everything the app has to do with the phone itself, as opposed to with your server. Camera. Location, and whether it is needed while the app is closed. Bluetooth, and whether it talks to a specific piece of hardware. Notifications. Working offline. Audio. Files. Payments. Anything to do with health or fitness data. A widget on the home screen. Sensors.
That list decides the answer, because most business apps are screens, lists, forms and a connection to a server, and every serious toolkit handles those well. The apps where the choice genuinely matters are the ones that touch hardware hard, run work in the background, or need every frame drawn on time.
Once you have the list, the conversation stops being about which technology is better and becomes a specific technical question with a specific answer. That is a much shorter meeting.
What Cross Platform Actually Gives You
One codebase, two apps. The pitch is real and it mostly holds. The screens, the validation, the business rules, the calls to your server, the offline handling: written once, running on both.
It does not halve the cost, and any quote that assumes it does is going to be wrong. Sharing the code does not share the store submissions, the testing on both platforms, the platform specific bugs that appear on one and not the other, or the design differences between how the two systems expect things to look and behave. Expect a real saving. Do not expect it to be total.
The bigger benefit shows up later. One team can fix a bug in both apps in an afternoon and ship both, rather than two teams scheduling the same fix twice. Over the years an app is alive, that matters more than the saving on the initial build.
On maturity, the honest position is this. For ordinary apps the mainstream cross platform toolkits are no longer a compromise. Rendering, animation, navigation, camera, notifications and the common device features work properly. The old argument about apps feeling wrong applies far less than it did, and where it still applies it usually points at how the app was designed rather than what it was built with.
Where Cross Platform Stops Being the Cheaper Option
When you need a platform feature the day it ships. New operating system releases add capabilities each year, and the bridging layer for a cross platform toolkit follows behind. If being first with something is the point of your app, you are waiting for somebody else.
When the app is deeply tied to hardware. Sustained camera processing, audio with tight timing, bluetooth talking to a specific device protocol, or continuous background location on a battery budget. All of these can be done, and all of them tend to end up written natively anyway, which means you pay for both.
When the feel of the app is the product. A drawing app, a game, a video editor, anything built around custom gestures. If people will judge you on how it responds under their finger, the extra control is worth the extra cost.
And the one nobody warns you about: when the bug is in the framework rather than in your code. You cannot fix it, you cannot pay to have it fixed faster, and you are waiting on somebody else's release schedule while your customers wait on you. It does not happen often. It is very uncomfortable when it does.
What Native Actually Costs You
Two codebases means two of everything. Two builds, two sets of bugs, two release cycles, two skill sets to hire for and keep busy. The build cost is the visible part and the smaller part.
The real cost is drift. A feature ships on one platform and slips on the other. A bug gets fixed in one and forgotten in the other. Behaviour differs in small ways nobody chose, then somebody notices that the Android app has been calculating a total slightly differently for four months. Keeping two codebases genuinely in step is a management job that never appears in a quote.
Hiring is the other constraint, and it is a practical one for most businesses. It is much harder to keep two specialists usefully busy than one team, and if either of them leaves you have lost an entire platform rather than a portion of a team.
There are cases where native is obviously right and they are easy to spot. You already have an in house team for one platform. Or the app only needs to exist on one platform at all, which is common for internal apps where every member of staff carries the same handset. Building two versions of an app for your own drivers because it feels more complete is money set on fire.
The App You May Not Need to Build at All
A great many things that get specified as apps are websites that people would like on their phone. If it does not need the camera, notifications, or genuine offline use, a well built mobile website is cheaper, has no store review, updates the moment you deploy, and requires nobody to install anything.
Installation is a much bigger barrier than people inside a company believe. Persuading somebody to install an app for a task they do twice a year is very hard. Persuading them to open a link is not. If your usage pattern is occasional, an app is a wall you have built in front of your own customers.
The middle option is worth knowing about. An installable web app covers more ground than most people expect, including working offline and, on some platforms, notifications. Support is uneven, particularly on iPhone, and the unevenness is the thing to check carefully before choosing it rather than the marketing.
The test we use is repeat use. Apps earn their place through habit. If somebody would open it weekly, it deserves an icon on their home screen. If they would open it twice a year, build a good web page and spend the difference on making the page excellent.
The Server Behind It Costs the Same Either Way
This is the part that gets left out of the comparison and it is often the larger half of the project. Whichever way the app itself is built, there is a server, a database, accounts and sign in, an interface for the app to talk to, a way of sending notifications, somewhere for uploaded files to live, and a way of deploying all of it safely.
None of that changes with the choice of app technology. It is identical work under both options. Which means the framework decision moves a smaller share of the total budget than the length of the argument suggests.
It also gives you a way to read quotes. If two proposals differ wildly and one is native and one is cross platform, check what each has assumed about the server before concluding that the framework is the reason. Usually it is not.
And if you have an existing system the app must talk to, price that work separately and early. Connecting to software that was never designed to be talked to by a phone is its own project, and it is the item most likely to be underestimated in the whole plan.
Mixing the Two Deliberately
You do not have to choose one for the whole app. Every mainstream cross platform toolkit lets you write native code for one screen or one feature and call it from the shared code. This is normal, supported, and how a lot of production apps actually work.
It works well when one or two things need native treatment: a scanner, a map with unusual behaviour, an accessory. It stops working when half the app needs native code, because then you have the cost of both approaches plus the cost of the bridge between them. That tipping point is worth naming out loud during planning.
The other common pattern is to start cross platform and rewrite natively later if the product earns it. That is a perfectly reasonable plan, and it only causes trouble when nobody says it out loud, because then version two arrives as an unwelcome surprise rather than as a milestone somebody expected.
How to Decide in an Afternoon
Take the device feature list from the first section. Against each item, mark one of three things: standard and supported everywhere, available through a well maintained plugin, or genuinely needs native code written by somebody who knows the platform.
If nothing lands in the third column, build it cross platform and stop having the argument. That covers most business apps, most internal tools, and most apps that are mainly a front door onto a service you already run.
If several things land in the third column, or if the feel of the app is the product itself, get both priced properly. Properly means including the server work and at least the first two years of maintenance, because the maintenance is where two codebases start to hurt.
Then ask the question that decides more projects than any technical factor: who is going to keep this running, and can you actually hire or keep those people where you are. The best technical answer that your business cannot support is worse than the second best answer that it can.
