The truth about cross-platform development that no sales pitch will tell you
Flutter, React Native, MAUI: what they really are and when they make sense. Why we teach native Swift at AC Academy.
Nobody's going to tell you this in the sales presentation. Not on the tech podcast where the guest just launched their startup, either. And certainly not the freelancer who quotes you €8,000 for the app using React Native because “it's practically the same as native.”
So I'll say it: cross-platform development is a compromise. Not a solution, not the future, not the smart way to get to market first. A compromise. And like every compromise, it has a price that someone ends up paying.
What “cross-platform” means in practice
Flutter, React Native, .NET MAUI: different implementations of the same principle. Write the code once, ship it on iOS and Android. In theory, maximum efficiency. In practice, a layer of abstraction between your code and the operating system that shows up in ways you don't anticipate until it's too late.
Performance comes first. It's not always critical, and it's not always noticeable to the casual user. But it's there. Animations have that extra millisecond an iOS user notices even if they can't name it. Launch takes a little longer. Memory use is higher. On an iPhone 16 Pro with plenty of RAM, maybe it doesn't matter. On your grandmother's three-year-old phone, it matters a lot.
Second is access to system APIs. Every time Apple ships a new API at WWDC, cross-platform frameworks take months to support it. Sometimes a year. Sometimes never. Want to integrate the Foundation Models framework, the new Liquid Glass animations, next year's watchOS features? Wait. Or write the native code anyway, which is exactly what you were trying to avoid.
The third is subtler: the user experience. Native apps feel like native apps because they respect the operating system's interaction patterns. The swipe-back gesture, the transitions between screens, keyboard behavior, integration with the notification system. Small things that, added up, make the difference between an app that feels like it belongs on an Apple device and one that feels like a website in disguise.
When cross-platform development does make sense
It would be dishonest to say it never makes sense. It makes sense when the app is essentially a form backed by data. When the business logic is simple and the design isn't a differentiator. When budget and time are genuinely limited and advanced system features aren't needed.
An internal warehouse management app for a mid-sized company doesn't need to be native. A booking app with a calendar and a user profile probably doesn't either. Not everything has to be a masterpiece of the Apple ecosystem.
But if your app is your product, if the user experience is your competitive edge, if you want to adopt what Apple ships each year before your competitors do, if you want to publish on the App Store and not have Apple reject it over performance issues in the first few months, then native versus cross-platform isn't a debate anymore. The decision is already made.
Why we teach Swift at AC Academy
We don't teach Swift because we're platform fundamentalists. We teach it because our goal isn't for our students to know how to use a framework. Our goal is for them to understand the operating system well enough to build anything on top of it.
A developer who understands Swift and SwiftUI can pick up React Native in a few weeks if a project calls for it. The reverse isn't always true. Someone who learned mobile development through an abstraction framework has a ceiling that native developers don't.
And there's something else that rarely gets mentioned: the job market for native iOS developers in Spain, and especially at international companies with remote teams, is still one where demand outstrips supply. There aren't enough good Swift developers. That has a direct impact on salaries and on long-term employability.
Cross-platform development isn't the enemy. It's a tool with a specific use case. The problem isn't using it. The problem is using it when it's the wrong tool, and not realizing it until you're carrying two years of technical debt.