The Short Answer
Most UK businesses commissioning their first app are asking the wrong question first. "Native or cross-platform?" is an engineering decision that a competent developer can make for you in an afternoon once they know three things: what the app has to do with the device, who has to maintain it afterwards, and where it will be distributed.
The questions worth deciding before you brief anyone are these. Does this need to be an app at all, or is it a website that people should be able to save to their home screen? What happens on the phone itself — camera, Bluetooth, offline working, background location, health data — because heavy device work pulls you towards native and light device work makes the argument for it very weak. And who owns it in two years, because the stack you pick decides who you can hire to keep it alive.
Then there is the part almost no comparison article covers: four obligations, three of which arrived in 2025, that decide whether you can distribute at all. They have caught UK businesses who had a finished app and no route to the store.
The Comparison
| Native (Swift and Kotlin) | Cross-platform (React Native, Flutter, Kotlin Multiplatform) | Web app or PWA | |
|---|---|---|---|
| Best when | Deep device work, demanding graphics, or a long-lived product with a dedicated team | Two platforms, similar behaviour on each, one team maintaining both | Nobody actually needs it on a home screen and search visibility matters |
| Device access | Everything, the day the platform ships it | Most things, sometimes waiting on a bridge or plugin | Limited, and varies by browser |
| Two platforms means | Two codebases and usually two skill sets | Substantially shared code, with a native layer where it matters | One codebase |
| Who can maintain it | iOS and Android specialists | Often your existing web team, for the React Native route | Your existing web team |
| Store distribution | Yes | Yes | No, which removes a whole category of obligation |
| Weakest at | Cost of carrying two of everything | The last ten per cent, where platform differences resurface | Anything the browser will not let it touch |
| Common mistake | Choosing it for prestige rather than need | Assuming shared code means no platform knowledge is required | Building one when the requirement was genuinely native |
What Actually Decides It
Device work is the real dividing line. An app that scans, streams, works offline for hours, talks to hardware over Bluetooth, or handles health or payment data at the OS level is doing work the platform vendors design their own tools around. Go native and stop arguing. An app that is mostly screens, forms, lists and an API behind them is not doing that work, and building it twice is difficult to justify.
Who maintains it matters more than launch day. The framework decision is often made by whoever builds the first version and lived with by whoever inherits it. React Native renders native components while running your logic in a JavaScript runtime, which is why teams with web experience take to it. Flutter, from Google, brings its own rendering engine and uses Dart, which gives very consistent visuals across platforms at the cost of a language your web team probably does not write. Kotlin Multiplatform takes a different position again: rather than an all-or-nothing choice it lets you share the parts that make sense — typically the business logic — and keep genuinely native interfaces. JetBrains reports in its own Developer Ecosystem Survey that Kotlin Multiplatform adoption roughly doubled between 2024 and 2025; that is the vendor's own research and worth weighing as such, but the direction is consistent with what we see in briefs.
Shared code is not free. Cross-platform frameworks commonly share most of a codebase, but the remainder is where platform differences live, and it is the part that consumes the time nobody budgeted. Any agency telling you a cross-platform build costs half of two native builds is quoting the easy portion.
Be honest about whether it is an app. A meaningful share of the app briefs we receive describe something that would work better as a responsive web application with a saved home screen shortcut, and would then be findable in search, updatable without review, and free of everything in the next section. Sometimes the honest answer is that you want an app icon on a customer's phone for commercial reasons, which is legitimate — but it should be a decision, not an assumption.
Four Obligations That Decide Whether You Can Ship
This is the section that costs people money when it is skipped. None of it is legal advice and your own advisers should confirm how each applies to you.
Trader status, if you distribute in the EU. Articles 30 and 31 of the EU Digital Services Act require app marketplaces to verify and display trader contact details, and Apple's developer documentation confirms that from 17 February 2025 apps without a verified trader status were removed from the App Store in the EU until it was provided. The practical consequence surprises people: the address, phone number and email address you supply are published on your App Store product page in the EU. If you are a sole trader working from home, decide early what address you are willing to have shown, because it is not optional and it is not private.
Accessibility, if you sell to EU consumers. The European Accessibility Act took effect on 28 June 2025 and covers mobile applications, applying the same accessibility requirements as the Web Accessibility Directive. Microenterprises providing services — broadly, fewer than ten people — are exempted, but that exemption is narrower than most founders assume and does not cover products. From that date customers can complain to national authorities or courts. Retrofitting accessibility into a finished app is dramatically more expensive than building it in, which is the entire argument for raising it in week one rather than at launch.
The Online Safety Act, if users can see each other. If your app lets users post, share or interact with one another, it is likely a Part 3 user-to-user service under the UK Online Safety Act. Ofcom's compliance timeline required in-scope services to complete a children's access assessment, with services allowing pornography needing highly effective age assurance from July 2025, and Ofcom has an explicit Small but Risky Services Taskforce for platforms with small user bases and high potential for harm — so being small is not a shelter. A comments feature, user profiles or in-app messaging can move an otherwise simple app into scope. Decide whether you need those features before you build them.
UK GDPR, from the first user. An app that collects personal data needs a lawful basis, a privacy notice that covers what the app actually does, and a retention rule. The ICO updated its guidance on AI and data protection in April 2026 to reflect the Data (Use and Access) Act, and is revising its automated decision-making guidance under the same Act, so if your app makes decisions about people this is live ground rather than settled.
Together these are the reason we ask about distribution and features before stack. The compliance surface, not the framework, is what most often changes a project's shape.
What to Ask an App Development Company
- •Which of the four obligations above apply to us, and how do you know? A supplier who has shipped UK apps recently will answer immediately. One who has not will tell you it is your lawyer's problem.
- •Who maintains this in two years, and can we hire for it? Ask for the honest hiring picture for the stack in the UK, not just their own availability.
- •What is genuinely shared and what is not? For any cross-platform proposal, ask which parts will still need platform-specific work.
- •What happens to the accounts? The Apple and Google developer accounts should be in your company's name, not the agency's. If they are in the agency's name you cannot leave.
- •Show me a release you did not enjoy. Store review rejections, a platform version bump, an urgent fix. How a supplier handles those matters more than the demo.
How We Approach It
BigBerri builds mobile apps for UK businesses from Manchester. We start from what the app has to do on the device and where it will be distributed, and only then recommend a stack — sometimes that recommendation is that you do not need an app. Every project is quoted as a fixed price after a free discovery call rather than a day rate, the developer accounts are set up in your name, and the code is yours on completion and full payment.
Scope detail is on /services/mobile-app-development. If you are weighing an app against a first product release more broadly, /blog/mvp-development-uk-startups-2025 covers how to scope something that answers one question rather than everything, and /blog/how-much-does-it-cost-to-build-an-app-uk covers what actually drives the size of an app project. For sector context, /industries/ecommerce sets out how we work with online retailers and /industries/clinics covers booking-led businesses where an app is often the wrong answer and a better booking flow is the right one.
Next Step
If you are not yet sure whether you need native, cross-platform, or no app at all, that is exactly what a discovery call is for. Book a free one at /contact, message us on WhatsApp, or call — and we will tell you plainly if the honest answer is a website.
Frequently Asked Questions
Is cross-platform cheaper than building two native apps?
Usually, but not by half, and anyone promising half is quoting the easy part. Cross-platform frameworks share a large majority of a codebase, and the remainder is exactly where platform differences live — permissions, background behaviour, store review quirks, the last ten per cent of the interface. That remainder consumes the time nobody budgeted. The stronger argument for cross-platform is usually maintenance rather than build: one team, one codebase, one release process afterwards.
Do we actually need an app, or would a website do?
A good share of the briefs we receive describe something that works better as a responsive web application people can save to their home screen. That route is findable in search, updates without waiting for a review queue, and sits outside app store distribution obligations entirely. Native is the right answer when the app does real work on the device — offline for long periods, Bluetooth hardware, heavy media, OS-level payment or health data. If your requirement is screens, forms and an API behind them, we will say so on the call.
Will our address really be published if we sell in the EU?
Yes, if you distribute in the EU App Store as a trader. Articles 30 and 31 of the EU Digital Services Act require marketplaces to verify and display trader contact details, and Apple's developer documentation confirms that from 17 February 2025 apps without verified trader status were removed from the EU App Store until it was supplied. The address, phone number and email you provide appear on your product page. Sole traders working from home should decide what address they are willing to show before starting, because it is not optional.
Does accessibility apply to us if we are a small UK company?
It depends on where you sell and how small you are. The European Accessibility Act took effect on 28 June 2025 and covers mobile applications for businesses placing products or services on the EU market, applying the same requirements as the Web Accessibility Directive. Microenterprises providing services are exempted, but that exemption is narrower than founders tend to assume. Separately, UK equality law expects reasonable adjustments regardless. The practical point is commercial rather than legal: retrofitting accessibility into a finished app costs far more than designing it in, so it belongs in week one.
Who owns the developer accounts and the code?
You should, and you should confirm it in writing with any supplier before signing. We set up the Apple and Google developer accounts in your company name rather than ours, and the code is yours on completion and full payment. If an agency holds those accounts, leaving them means rebuilding your store presence and losing your reviews and ranking history, which is a far more expensive form of lock-in than the code itself.