Most people ask their developer the wrong question. They ask "will I get an app". The better question is "what did I actually buy". Those are not the same thing, and the gap between them is where a lot of money quietly goes missing.
Here is the uncomfortable bit. Two apps can look identical on the phone. One is a proper native build. The other is your website in a costume. On the App Store icon grid you cannot tell them apart. On the invoice, often, you cannot either.
At WebAi.Scot we build native. We also think the wrapper trick is fine, sometimes, sold honestly. The problem is not the technology. The problem is the pitch.
Three things, all called "an app"
There are broadly three ways to put software on a phone. They are not the same, and honest developers do not pretend they are.
Tier one: the webview wrapper. Tools like Capacitor, Cordova and Ionic take your website and run it inside an embedded browser window with no address bar. The "app" is a web page in a native shell. Think of a food van parked inside a shopping centre. It looks like a shop unit. It is still a van.
Tier two: the cross-platform framework. React Native and Flutter are a genuinely different animal, and it would be dishonest to lump them in with wrappers. Flutter compiles Dart code ahead of time to native ARM machine code and draws its own screen with a rendering engine called Impeller. React Native runs real native controls driven by JavaScript. These are not web pages in a costume. They are a serious middle path.
Tier three: true native. Swift and SwiftUI for Apple. Kotlin and Jetpack Compose for Android. Two codebases, each speaking the phone's own language with nothing in between. This is what we do.
Why the difference shows up in real life
A wrapper leans on a browser engine to draw everything. That has a cost your customers feel. Native apps start faster, use less memory and scroll more smoothly, because the compiled code is built for the exact device it runs on.
Battery is the honest tell. A 2023 study presented at IEEE MobileSoft compared popular Android apps with their web counterparts and found the native versions used significantly less energy, CPU and memory.
Offline is the next one. A native app stores data on the device and keeps working in a tunnel or a lift. A pure webview leans on the website loading, so a weak signal often means a weak app.
Then there is the hardware. Camera, sensors, notifications, home-screen widgets, an Apple Watch face, Apple Pay and Google Pay. Native reaches all of it directly. Wrappers reach some of it through plugins, and some things simply do not work. Apple Pay and Google Pay inside a webview are a known headache, and developers report them failing where the same code works in a real browser.
The bit the sales pitch skips
New iPhone and Android features arrive every year. Apple previews its new APIs in June and ships them to users with the autumn OS release, and a native app can adopt them on day one. Cross-platform and wrapper apps wait for the framework or a plugin to catch up, which can be months, or never.
There is also a quieter risk you are rarely told about. When you build on someone else's framework, you are betting on their roadmap. Meta's React Native and Google's Flutter are well backed, and Kotlin has JetBrains and Google behind it. Others were not so lucky. Microsoft ended support for all Xamarin SDKs on 1 May 2024. Adobe announced in August 2020 it was ending PhoneGap, shut PhoneGap Build on 1 October 2020 and ended its investment in Apache Cordova with it. Every plugin in a wrapper is a small dependency that can break when the OS updates, and some are maintained by one person in their spare time.
Accessibility deserves a mention too, because in the UK it is not optional for many organisations. Native apps plug straight into VoiceOver on Apple and TalkBack on Android. Per the WebAIM Screen Reader User Survey, 91.3% of respondents use a screen reader on a mobile device, with VoiceOver the primary mobile reader at 70.6% and TalkBack at around 34.9%. Content inside a webview can lose accessibility signals along the way, which quietly shuts those people out.
The rules the stores actually enforce
This is not just our opinion. The store owners agree, in writing.
Apple's App Store Review Guidelines, in the version updated 8 June 2026, say the quiet part out loud. Guideline 4.2 states your app "should include features, content, and UI that elevate it beyond a repackaged website". Guideline 4.2.2 adds that, other than catalogs, apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links".
A lazy wrapper can be rejected on those words alone. Apple also polices payments under Guideline 3.1.1: digital features unlocked inside an app, "subscriptions, in-game currencies, game levels, access to premium content", must use its in-app purchase system, though the rules have loosened in the US and EU since 2025.
Google says much the same. Its policy states apps "should provide a stable, responsive, and engaging user experience", and its spam rules bar apps "whose primary purpose is to drive affiliate traffic to a website or provide a webview of a website without permission from the website owner or administrator". Google announced this tightened Spam and Minimum Functionality policy on 17 July 2024, and has been clearing low-effort apps out of the Play Store since.
So the wrapper you were sold as "a native app" can, at the extreme, be refused a place on the very stores it was meant for.
The famous U-turn, told fairly
The go-to example is Airbnb. In 2016 it bet big on React Native. In June 2018 it announced it was sunsetting the technology and going back to native.
Its own engineers were honest about why. In the words of Airbnb engineer Gabriel Peal, "large amounts of bridging infrastructure were required to enable product engineers to work effectively. As a result, we wound up supporting code on three platforms instead of two." They also hit walls with complex gestures and long scrolling lists. Worth noting for balance: Airbnb later added a caveat to the top of the series, saying "If these articles are exclusively cited as a reason not to use React Native, please do more research of your own before making a decision".
And the other direction exists. Shopify spent five years moving all its apps to React Native and published a retrospective in January 2025. Its engineering leaders report reaching about 86% shared code between iOS and Android, up from roughly 5% at the start. Balance matters. Cross-platform is a real engineering choice, not a con.
When a wrapper is the right call
Here is where we part company with the native purists. Sometimes a wrapper is exactly right.
If you have a tight budget, a simple content or catalogue app, an internal tool for your own staff or you need to be in the stores next month to test an idea, a wrapper can be the sensible, cheaper answer. Speed to market is a real business advantage.
The sin is not the wrapper. The sin is charging native money for it and calling it something it is not.
The better questions to ask
You do not need to become a developer. You need three questions for whoever you hire.
Ask: is this native, cross-platform or a webview wrapper, in plain words. Ask: which of my features need the camera, notifications, offline use or Apple Pay, and does this approach do them properly. Ask: who owns the code, and what happens when Apple and Google update in the autumn.
A straight answer tells you a lot. So does a squirming one.
We build. We teach. You own. If the app matters to your business for the next five years, buy the thing that lasts. If it is a quick experiment, buy the cheap thing on purpose, with your eyes open. Either way, know what you are paying for.