First Question: Does This Actually Need to Be an App?
We build iOS and Android apps and take them through both stores. We also tell a fair number of UK companies that a responsive web application would serve them better for a fraction of the money. Getting that question right is worth more to you than anything further down this page.
Sometimes the Answer Is No, and We Would Rather Say So
An app is the default request. It is often the wrong one. A store app costs more to build than the equivalent web application, takes two platforms of maintenance instead of one, requires a release cycle you do not control, and depends entirely on persuading someone to install it. For a great many UK small and medium businesses, a fast responsive web application that works properly on a phone does the job, launches sooner and can be changed the same afternoon.
That is not a reason to avoid mobile. Where an app earns its overhead — offline work, hardware access, daily habitual use, push as an operational tool — it earns it comprehensively, and nothing else comes close. The point is only that the decision deserves half an hour of scrutiny rather than being assumed at the start of a project and defended for the rest of it.
What a web application involvesFour Situations, Four Different Recommendations
Read across these and one of them will describe you fairly accurately. It is the same grid we work through on a first call.
When Installed Software Is the Only Thing That Works
Field engineers filling in job sheets in plant rooms with no signal. A logistics operation capturing proof of delivery and customs paperwork at the kerbside. A consumer product people open four times a day. Anything using the camera seriously, Bluetooth, background location, biometrics or the secure element. Anything where push notifications are an operational instruction rather than marketing.
When the Browser Is Quietly the Better Product
Portals customers visit occasionally: a letting agent maintenance form, an insurance renewal, a training booking, an invoice approval. Anything a user reaches from an emailed link. Anything staff use at a desk as well as on a phone. Long forms and document work. Products where you need to ship a change today rather than after store review. Most business-to-business dashboards.
When Two Audiences Want Two Different Things
Common in multi-site retail, healthcare and construction: staff need an app for offline and hardware work, customers or clients need a web portal they can open from an email without installing anything. Build the shared backend once, then the interface each audience needs. We usually sequence these rather than running them together, so the first one funds and informs the second.
When Software Is Not the Constraint
If the difficulty is that nobody knows you exist, an app will not fix it — distribution is harder than development. If an internal process is unclear or contested, software will encode the confusion rather than resolve it. And if the app exists mainly because a competitor has one, the honest advice is to spend the budget on the thing customers are actually complaining about.
Native or Cross-Platform, and What Each Choice Costs You
There is no universally correct answer. There is an answer that fits your feature list, your budget and how long you expect to live with the thing.
Two Native Codebases
Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android. Each platform gets the interface its users expect, new operating system features are available the day they ship, and the awkward areas — background work, Bluetooth, camera pipelines, widgets — behave predictably. The cost is two codebases, so roughly one and a half times the build and two sets of changes for every future feature.
One Shared Codebase
React Native or Flutter, producing genuine apps for both stores from one project. For form-driven products, dashboards, booking flows and most internal tools the result is indistinguishable to users and materially cheaper to maintain, because a change lands on both platforms at once. The cost appears at the edges: deep hardware integration, heavy graphics, or being first to a brand new platform feature.
| Deciding factor | Points towards native | Points towards cross-platform |
|---|---|---|
| Hardware use | Bluetooth peripherals, barcode scanners, background location, complex camera work | Photos, basic location, standard sensors |
| Budget shape | Capital available now and a long horizon | A fixed first-version budget that has to cover both platforms |
| Team after launch | You intend to hire mobile engineers in-house | You want one team and one release process |
| Interface ambition | Platform-specific feel matters commercially, or the animation work is heavy | A consistent brand interface on both platforms is acceptable |
| Platform features | Widgets, Live Activities, App Clips, wearables and other first-party extras | Standard screens, lists, forms, notifications and payments |
We make a recommendation in writing with the reasoning attached, and we are content to be argued out of it. What we will not do is choose a stack because it is the one we prefer working in.
From a Finished Build to a Live Listing
Roughly two to three weeks of elapsed work sits between a build being ready and it being downloadable, and most of it is not writing code. We run it rather than handing you a checklist.
Accounts in Your Company Name
The Apple Developer Program is billed annually; Google Play charges a one-off registration fee. Both go on your card under your legal entity, with us added as team members. Apple organisation enrolment wants a verifiable entity and a D-U-N-S number matching your Companies House record, and verification can take longer than anyone expects, so this starts in week one.
The Listing Itself
Name, subtitle, description, keywords, category, age rating, support URL, privacy policy URL, icon and screenshots at each required device size. Apple also wants working demo credentials if anything sits behind a login. Both stores have rules about what screenshots may imply, and both enforce them.
Privacy Disclosures From the Code
Apple wants privacy labels and a privacy manifest; Google wants a Data Safety declaration. Both ask what you collect, whether it is linked to a person, and what your third-party SDKs do. We complete these by auditing the code and its dependencies, because a declaration that contradicts observable behaviour is a rejection and, under UK GDPR, a transparency problem as well.
Beta, Submit, Release Deliberately
TestFlight and Play closed testing first, with real people on real handsets. Then submission, with the reviewer in mind. Apple review commonly returns within a day or so and Google within a few days, though neither is a promise. Release is phased on Android and can be scheduled or staged on iOS, so a bad build reaches a fraction of users rather than all of them.
Store Billing Rules, Commission, and What They Do to Your Margin
This is the part UK finance directors ask about and the part most agency websites skip. The rules move, so treat this as the shape of the problem rather than a current rate card, and confirm the figures before you build a price list around them.
Digital Goods Go Through the Store
Subscriptions, credits, unlockable features and digital content sold for use inside the app must normally use the store payment system, at the headline commission rate. Both Apple and Google run reduced rates for smaller developers below a revenue threshold and for subscriptions that have been running beyond the first year, which is a meaningful difference for most UK SMEs.
Physical and Real-World, You Bill Direct
Goods shipped to a customer, a table booked, a tenancy paid, a tradesperson hired, a class attended in a building — none of that goes through store billing. You take payment with Stripe or your existing processor and pay ordinary UK card fees. Multi-site retail, hospitality and letting agents almost always sit on this side of the line.
Reader Apps and the Grey Middle
Memberships that also grant physical access, bundles mixing digital and real-world value, and content subscriptions bought elsewhere all sit on a boundary the stores police actively. Getting it wrong means a rejection at best. We settle which side each product sits on during scoping, and where it is genuinely unclear the safe route is to ask the store before building the billing.
What this means for a UK price list
If your revenue is digital and store-billed, model the commission into your pricing before you publish it, not afterwards. A subscription set at a comfortable margin on your own website can be an uncomfortable one through the stores, and raising an in-app price later annoys existing subscribers. Note too that for store-billed digital sales the store generally acts as merchant of record and handles VAT on the consumer sale, paying you net — so what lands in your bank is not what the customer paid. Your accountant will want to know that before the first quarter end rather than during it.
The regulatory picture is also moving. Competition authorities in the UK and Europe have been examining mobile ecosystems and payment rules for several years, and terms have already changed more than once as a result. We build billing so the route money takes is a configuration decision rather than something welded into every screen, which makes reacting to a rule change a small piece of work instead of a rebuild.
What UK Buyers Now Expect From a Mobile Interface
Accessibility on mobile is no longer a specialist concern. It appears in procurement questionnaires, it is the subject of a statutory duty for public bodies, and it is a straightforward source of complaints when ignored.
Where the Obligation Comes From
The public sector accessibility regulations cover mobile applications provided by or for public bodies, with WCAG 2.2 AA as the working standard and a published accessibility statement expected. The Equality Act 2010 sits behind everyone else, requiring reasonable adjustments regardless of sector. If you sell to a council, an NHS trust, a university or a housing association, expect the obligation to be passed down to you in the contract even though the regulations bind the buyer rather than you.
What It Means on a Phone
Respecting the user text size setting so the layout survives large type rather than clipping it. Labels on every control so VoiceOver and TalkBack announce something useful instead of the word button. Touch targets people can hit in a van or with gloves on. Contrast that still works in daylight. Never using colour alone to carry meaning. A visible focus indicator for external keyboards and switch control. Motion that respects the reduce-motion setting.
The economics are the real argument. Almost all of this is free if it is designed in and expensive if it is retrofitted, because fixing contrast, focus order and labelling after the interface is built means reopening every screen. That is why we treat it as a design input on the design and prototyping phase rather than as a test somebody runs the week before launch.
The Obligations That Begin on Launch Day
Publishing an app changes the obligations of running the product. None of this is difficult. All of it is new, and it is the part clients most often have not budgeted for.
Releases Become Events
You cannot fix a typo in production the way you can on the web. Every change queues behind review, and users on old versions persist for months. That pushes you towards feature flags, forced-update mechanisms for genuinely broken releases, and a slower, more deliberate release rhythm.
Two Platform Deadlines a Year
Apple and Google both release a major operating system version annually, each with its own compatibility work, and Google enforces a minimum target API level for apps that stay in the store. Doing nothing is not a stable state: an unmaintained app becomes an unavailable app in a year or two.
Reviews Are Public Support Tickets
A one-star review describing a genuine bug is read by every prospective user until you answer it. Both stores let you reply, and prompting satisfied users for a review at a sensible moment materially changes the average. This needs an owner in your business, not just in ours.
The Numbers Start Arguing Back
Crash-free session rates, funnel drop-off, which features are genuinely used. Usually a fortnight of real data identifies a screen nobody visits and a step where a third of users abandon. That is the roadmap for the next quarter, and it is more reliable than anybody in the room guessing.
The Accounts Become Assets
Your store accounts now hold your listings, your reviews, your signing keys and your revenue. Losing access to a signing key or letting an account lapse is a genuinely serious incident. Keys go into your own secret storage, recovery details go to more than one person at your company, and renewal dates go in a calendar somebody reads.
Support Needs a Rota
Mobile support arrives by email, store review and phone call, often about one specific handset. A retainer covering platform updates, defect fixes and small features keeps this from landing entirely on whoever answers the main line. Maintenance and support sets out how ours works.
Mobile Questions From UK Clients
We sell physical products. Do we still hand Apple and Google a commission?
No. Store commission applies to digital goods and services consumed inside the app: subscriptions, credits, unlocked features, digital content. Physical goods and real-world services booked through an app sit outside it, which is why retailers, restaurants and letting agents can take card payments through Stripe or another processor and pay ordinary card fees instead. The line occasionally gets blurry with memberships and bundles, so we settle which side a given product sits on during scoping rather than after a rejection.
Can a progressive web app be listed in the App Store and Google Play?
Google Play accepts a well-built progressive web app packaged as a Trusted Web Activity fairly readily. Apple is much less forgiving: a listing that is essentially a website in a wrapper, with no meaningful use of the device, is one of the more common rejection outcomes. If a store presence genuinely matters to you, budget for real native behaviour rather than assuming the site can be repackaged cheaply. If it does not, a good progressive web app installed from your own site avoids both stores entirely.
Our engineers and drivers often have no signal. Does that change the answer?
It changes it decisively, and it is the most reliable reason a UK business genuinely needs an installed app. Loft spaces, plant rooms, rural sites, lorry parks and hospital basements all defeat a browser-based tool. An app can hold the job list on the device, capture photos, readings and signatures offline, and sync when a connection returns. That offline sync layer is real engineering and it is where the budget goes, so it should be specified deliberately rather than assumed.
Who is the seller of record for UK VAT on in-app purchases?
For digital goods sold through in-app purchase the stores generally act as the merchant of record and handle the VAT on the sale to the consumer, paying you out net of VAT and commission. When you take payment yourself for physical goods or real-world services, your company is the seller and accounts for UK VAT in the normal way. That distinction changes what your accountant sees in the bank, so it is worth agreeing with them before launch rather than at the first quarter end. We are developers rather than tax advisers, so we build to whatever position your accountant confirms.
We are tendering for a council contract. Does the app have to meet WCAG 2.2 AA?
If the app is provided by or on behalf of a public sector body, the public sector accessibility regulations apply and WCAG 2.2 AA plus a published accessibility statement is the working expectation. Even when you are a private supplier and the regulations do not bind you directly, the tender will usually pass the obligation down through the procurement questionnaire. The practical answer is to design to it from the start, because retrofitting contrast, focus order and screen reader labelling after the interface is built costs far more than doing it in the design phase.
Our previous developer put our apps in their own store account. Can that be fixed?
Usually, though it is more administrative than technical. Both stores support transferring an app between developer accounts, subject to conditions about bundle identifiers, in-app purchases and account standing, and it needs the cooperation of whoever currently holds the account. Where cooperation is not forthcoming the fallback is a fresh listing under your own account, which means losing reviews and rankings and asking users to reinstall. Either way we set new accounts up in your company name, and we will do the transfer legwork as part of a takeover.
Read Next
iOS App Development
Swift, App Review, TestFlight, privacy labels and App Tracking Transparency in UK GDPR terms.
Learn moreAndroid App Development
Kotlin, Compose, Play Console and the rugged budget handsets UK field teams actually carry.
Learn moreMVP Development
Deciding what version one has to prove before the next tranche of funding arrives.
Learn moreTell Us What the App Is Meant to Do
Describe the job and who does it. We will tell you whether it needs to be an app, which platforms to start with, and what it costs in sterling excluding VAT — within two working days.