Why most applications should be cross-platform

I know this is a hot take, and not everyone will agree. Some of you may even “strongly disagree” 😅.

Still, I want to make the case that most applications should be cross-platform - and that users should care about this too.

I’m biased and I admit it

First, I should be honest: I’m biased.

In two major ways:

1. I’m a Flutter developer. Of course I think that Flutter (or cross-platform development in general) is the right way to go for most applications.
2. I tend to switch platforms regularly. Android and iOS, macOS and Linux mostly and I hate it when I cannot use an application that I like on my target platform.

So yes, I have strong feelings from both a developer and user perspective.

What I mean by “most applications”

I don’t mean every app.

I mean the large middle: business apps, productivity tools, social/community apps, many consumer apps, CRUD-style products, and most content-driven software.

I do not mean apps where getting the last inch of performance is critical or deeply platform-specific capabilities are the product itself.

What I mean by “cross-platform”

I mean apps that are available on multiple platforms.
For large teams and big budgets that can mean separate native apps.
For indie developers or smaller teams (and that’s the focus for this blog post) that means using a cross-platform framework to have a single codebase that can be built for multiple platforms.

It’s time

We are no longer in the early days of mobile or desktop app development. Cross-platform tooling is mature enough to ship high-quality products with very good performance and user experience.

Resources

Today’s devices are extremely powerful. For most app categories, hardware is no longer the bottleneck.

Maybe it is easier to get off the track and build a slow app with bad UX with a cross-platform framework, but even if that would be the case you can easily build a slow app with bad UX with native tech as well.
A bad app is a bad app and a good app is a good app regardless of the tech stack used.

And if your app is 30 MB instead of 5 MB, most users won’t care nowadays. They care about reliability, speed, polish, and whether the app exists on their platform.

Team and product reality

Cross-platform is also a business and team decision, not only a technical one.

For many teams, one shared codebase means:

• faster feature delivery
• lower maintenance overhead
• fewer platform parity bugs
• more predictable release cycles

That tradeoff is often worth far more than small theoretical performance wins.

Even if your business has so much money to spare that you can target each platform with a separate native app and team, you still have to ask yourself: is this the best use of resources? Or could we ship more features, faster, and reach more users with a single codebase?

But the same is true (even more so) for smaller teams or indie devs.
If you are a solo developer you most probably can’t build for more than one platform.

via GIPHY

So you need to choose and most of the time you will just pick the platform that you are using yourself (of course! That’s what I did as well).
That’s fine, in the end it’s your product 😀 but just think about the potential user base you lose and potential long-term implications (you lock yourself and the users in).

And no, don’t tell me that you just AI generate for the other platforms.
We are not there yet.
Maybe one day we can do that but if you have an app of a medium complexity then maintanance of the generated code will be a nightmare.

Digital sovereignty

Platform and regulatory environments can change over time. Building with portability in mind reduces long-term dependency risk.

You can build a beautiful app inside one ecosystem, but that doesn’t help much if users (or your own team) need flexibility later and you can’t move.

The key is resilience through flexibility.

Let’s just take Apple as an example (and I mean that. You can replace Apple with whatever ecosystem owner you have).
They have a strong track record of putting privacy and user experience first and foremost. But they also have a history of locking down their ecosystem. A tightly controlled ecosystem can be a good fit - until product, policy, or market conditions shift.

Just imagine theoretical scenarios. What if Apple…

• stops setting privacy as a selling point for their devices
• stops allowing certain apps that do not please the government
• stops selling iPhones in Europe because of some regulatory dispute
• locks out certain users due to sanctions or policy constraints

I’m not saying this is happening now (I mean, some of them do, to some degree), or that it’s likely tomorrow. I’m saying teams should include ecosystem dependency in long-term product planning, even if near-term risk feels low.

I’m not saying everyone should abandon Apple, Google, or Microsoft tomorrow. I’m saying our software ecosystem should make it easy to switch when needed.

That matters for users and developers alike:

• as a developer, you stay flexible to reach users on their preferred platforms and adapt to changing market conditions
• as a user, you can choose the best device for your current needs and switch across platforms easily when needed

The tools are ready

In the past, the tradeoff was harsh:

• build multiple native apps with excellent UX but high cost
• or build one cross-platform app with lower cost but clearly worse UX

Today, that gap is much smaller. Flutter is one option, but there are others: React Native, Kotlin Multiplatform, Avalonia, and web-based approaches depending on your goals and preferences.

Performance and UX have improved dramatically, and devices are fast enough that most users won’t notice the difference when the app is built well.

So for many products, the default should now be: start cross-platform unless there is a clear reason not to.

And yes, personal ideology, organizational politics, or ecosystem preferences can still drive decisions.

Even if you need some very specific platform integration, it is less of a blocker than before. Most cross-platform stacks let you bridge native code for the specific features you need.
Want that Dynamic Island integration on iOS? Sure - go for it. Just write the bridging part in native code and integrate it with your app.

There are still reasons to go native

via GIPHY

There are absolutely cases where native is the right choice:

• apps that need the absolute maximum performance (e.g. high-end games, pro video editing)
• apps built around very specific platform-only APIs
• products where platform look-and-feel differences are a strategic requirement

Example: my PaperLaunch app on Android relies on APIs that simply don’t exist on iOS. In that case, native is the only reasonable path.

Conclusion

From both a developer and user perspective: default to cross-platform for most products.

As a user, prefer tools that are available on multiple platforms. Don’t lock yourself in unnecessarily.

Simple examples:

• use an email account that is not tied to a single device ecosystem
• use a password manager available across platforms
• use note-taking and browser tools you can keep when switching devices

As a developer, reach as many users as you can and let them stay flexible in their device choices.

Even if you strongly prefer one ecosystem, try to build in a way that doesn’t make your product - and your users - dependent on a single vendor.

And if you’re already doing cross-platform work: keep going. You’re helping build a healthier software ecosystem for users and yourself.

This was a bit of a rant, but one I felt was worth writing.
If it made you reflect on your own software choices - whether as a user or a developer - then it did its job.

via GIPHY