Which is the Best App Development Platform?

Last week, during a cup of coffee with a friend, she asked me this question, looking for a name. I returned his question: “What are you building, anyway?” He didn’t like that answer, but it’s the truth. No platform wins across the board. While a mobile app development company is shipping out a weekend MVP and a bank-rolling software to 40,000 employees, they aren’t addressing the same issue, even if both are referred to as “an app development.

But instead of choosing a winner, I want to explain how they really differ in practice, where they tend to fall apart, and what typically goes wrong when people choose based on hype rather than fit.

Begin with the project you are creating, NOT with what everyone is talking about.

More projects have gone off the rails because of too hasty a platform decision than bad code. Both a recipe app and a hospital scheduling app are technically very different yet covered under the same “mobile development” category when people select a stack to add to their cart.

There are three questions that are important here. Does the app need to function in areas with no signal? Is it getting in touch with hardware in unexpected ways: camera, Bluetooth, sensors? In 3 years, are you still going to be the one doing this? Then answer them truthfully, and the debate of native versus cross-platform versus low code is solved.

It’s the same performance as native, and the same price.

Good Swifty, Kotlin to Android. Native is the destination that will be achieved sooner or later if your app relies on real-time video, a ton of animation, or anything that extracts performance from the hardware.

The difficult part is staffing it. I remember seeing one team of 10 people that took 6 months only to get parity between iOS and Android builds. No deliveries for six months, only following two increasingly divergent codebases. That’s not cheap, either, and now you need two good native developers or two teams of good native developers.

When the performance really can’t bend, or your users are already well entrenched in one platform, then this is the right call. If you’re designing an app for a surgeon who uses an iPad in an operating room, it’s not the same app as the one designed for a consumer who wants to shop from her phone.

So, if you’re torn between the two, both React Native and Flutter offer a compromise.

Write once, ship twice. Reduce your team size by about half by going native twice. Flutter is really beginning to look good and render the same UI on all devices, and Google continues to invest in it, which is saying something.

The real benefit of using React Native is the pool of people that are willing to work with it. The transition from React for the web to React Native isn’t that big a leap if your team is already familiar with React for the web. That is more important than any other feature comparison.

The part people don’t want to see is the final piece of an application, the piece that requires some arcane native API or must meet a certain frame rate, invariably requiring one to return to native code. You are not avoiding it you’re just reducing the amount of it that you write. This is an area that I have seen teams blow the numbers right in the middle of the eighth month, when they were just about finished.

Bubble and the no-code folks fly faster than people think.

One friend I know is a solo startup who created a functional marketplace app in 3 weeks using Bubble. A regular dev team would still be in planning meetings.

When it comes to renting someone else’s infrastructure, however, there are limits and they’ll be strong limits when you hit them. These tools are good for a few thousand users, but when the business logic becomes complex, there’s a lot of analysis going on. If it’s just going to scale beyond that, it’s going to struggle to do that. I would never attempt to create the next Uber on Bubble. Say, an inventory system for a 12-person warehouse team, yes, by Friday.

Before you get carried away with the builder, one question you should ask yourself is how painful it will be to leave later? There are some of these platforms that make migration brutal. Don’t wait to read that fine print for six months after writing your business logic on top of it.

Enterprise platforms are for an entirely different purpose.

Mendix, OutSystems, Microsoft’s Power Platform. No one chooses to wear these for excitement. They are there because fifteen legacy integrations, a change that can be approved by an IT department without having to pull a developer off of something else, and audit trails are desperately needed in large organisations.

When you work at a place where there is a compliance team that has its opinions about everything, then this doesn’t sound boring anymore but rather necessary. Not so quick to get going, yes. But it’s the one that passes the audit test, which may be the only one that counts.

Once I saw a project where the CTO of a medium-sized insurance company attempted to create an in-house claims system using a popular cross-platform platform, based on a report he had heard somewhere. A year and a half later, legal found that the application did not generate the audit logs regulators desired, and the entire project was reconstructed from the ground up on OutSystems. That’s not a knock on the framework. It just wasn’t designed for that use. No one asked the right question at the beginning.

On the cost: No one talks honestly about that

All the comparison charts you will find out there include it in a bullet list, typically a generic one. As a practical matter, the “sticker price” of a platform is not as important as what happens after the launch. The native apps are costly to create and relatively inexpensive to keep running, as long as they work. Cross-platform app development is less expensive front-end, and accumulates cost over time with the native bridge work that no one planned for.

No-code tools are almost free to get started and then suddenly charge you based on how many users you have, sometimes with the bite that you are feeling the sting as soon as you exceed a few thousand users. Enterprise platforms are costly; it’s usually not developer hours that are the cost, it’s the license.

This is not reflected on a feature comparison table. It only gets noticed eighteen months in when someone is cutting the budget and wondering “why the cheap one is still not cheap?”

What I would actually say to you to do

When validating an idea, don’t second-guess and go cross-platform or no-code. At that time, speed takes precedence over architectural beauty. If your MVP gets you ten thousand users, then nobody is going to remember what it was built on.

If performance is key, or you are happy to be dealing with a user base that already loves native, pay for native development. Expensive now, but will save you compromises later.

If you’re working within a large company that has compliance demands, don’t grizzle about boring enterprise tools because they’re not cool. There is not a single exception that I have seen where boring will win there.

The vast majority of bad platform decisions I’ve seen have not been around technology. They were not even the projects that were most needed, but rather they were the ones that garnered the most applause at a conference three weeks before sitting down and determining what the project needed to be. In most teams, that’s a 5-minute discussion they don’t have. Have it first.

FAQ’s