App development for iOS, Android and the web

Native, cross-platform or PWA: how to choose

Start from what the app has to do, not from what is fashionable. Native means writing separately for iOS and Android using each platform toolchain. You get the best performance, immediate access to new operating system features, and interfaces that feel exactly right on each platform. You also write and maintain two codebases.

Cross-platform frameworks such as Flutter and React Native let one codebase produce both apps. For the majority of business apps, which are lists, forms, accounts, bookings, messaging and dashboards, the performance difference is not something users notice. The saving on build and maintenance is substantial. The cost is occasional friction at the edges, where a platform feature needs native code written anyway.

A progressive web app is a website that installs to the home screen, works offline and can send notifications on supported platforms. It skips the app stores entirely, which means no review process, no store commission and instant updates. It cannot reach the deepest hardware features, and discovery works through search rather than store browsing.

• Native: heavy graphics, real-time camera or sensor work, platform-specific feel, or a long-lived product with a dedicated team
• Cross-platform: most business and service apps, where speed to market and one maintenance stream matter more than the last few percent of performance
• PWA: content, booking, ordering and account tools where store presence adds nothing and update speed matters
• Hybrid: a cross-platform shell with native modules for the two or three features that genuinely need them

What actually drives the cost of an app

Screen count is the number people ask about, and it is rarely the main driver. The expensive parts are usually invisible from the outside: accounts and authentication, payments, syncing data between device and server, offline behaviour, push notifications, and anything that has to stay correct when two people edit the same thing.

Back-end work is the most commonly underestimated line. An app that shows data has to get that data from somewhere, and building or integrating that server side is often comparable in effort to the app itself. If the data lives in an existing system, integration quality decides how much of that effort you avoid.

Then there is everything after the code. Testing across a spread of real devices and operating system versions. Store assets, listings and submission. Analytics and crash reporting. And the ongoing cost of keeping the app working as the platforms change underneath it. A quote that ignores those is not a cheaper app, it is an incomplete one.

• User accounts, roles and password recovery
• Payments, subscriptions and store billing rules
• Offline support and data synchronisation
• Push notifications and the server that triggers them
• Device and operating system version testing
• Store submission, review handling and post-launch updates

App store review, and how to avoid failing it

Both stores review submissions against published guidelines, and Apple reviews more strictly than Google. Rejections are normal and usually fixable, but they cost days each time, which is why the guidelines belong in the build plan rather than in a panic at the end.

The rejections we see most often are predictable. Apps that are effectively a wrapper around a website with nothing added. Sign-in requirements on features that do not need an account. Digital goods sold outside the store billing system. Missing or inaccurate privacy declarations about what data is collected. Placeholder content or broken links left in a build. Requesting a permission without explaining why it is needed.

Design for review from day one. Provide a working test account with the submission. Write the privacy declarations honestly against what the app actually collects, including anything third-party SDKs collect. Make sure every feature described in the listing exists and works in the submitted build.

• Give reviewers working credentials and any codes needed to see the whole app
• Declare data collection accurately, including data collected by SDKs you added
• Ask for permissions at the moment they are used, with a plain reason
• Sell digital goods through the store billing system unless you are certain an exemption applies

Scoping a first version that ships

The biggest risk to an app project is not technical, it is scope. Teams list every feature they can imagine, the build stretches, the budget goes on things nobody uses, and the app launches late into a market that has moved. A first version should do one job properly for one group of users.

The way to find that job is to write down the single action the app exists to make easier, then ask of every proposed feature whether removing it stops that action working. If it does not, it is version two. This is uncomfortable in planning and obviously right six months later.

A tight first version also gives you something more valuable than features: real usage. Once people are using the app you learn which parts they actually touch, which is almost never the list you would have guessed. Building version two from that evidence is far cheaper than building it from assumptions.

• Name the one action the app must make easier
• Cut any feature that the core action works without
• Ship with analytics and crash reporting from the first release
• Plan the second release from usage, not from the original wish list

Why maintenance is not optional

Mobile platforms move on a schedule you do not control. Apple and Google release major operating system versions every year, deprecate APIs, change permission behaviour and periodically raise the minimum build requirements for apps that want to stay in the store. An app left untouched will eventually stop working, and before that it will start looking wrong on new devices.

Security adds a second clock. Third-party libraries in the app get patched, and shipping an old version means shipping known problems to your users devices. Unlike a website, you cannot fix that centrally. Every user has to receive an update, which means you need a release habit rather than a release event.

A realistic maintenance plan covers platform version compatibility, dependency and security updates, crash monitoring with actual triage, store listing upkeep, and a small budget for the fixes that only surface once real people use the thing. Businesses that skip this usually pay for it as an unplanned rebuild.

Getting found: app stores are search engines too

Most app discovery happens through search inside the stores, so listing quality decides how much of your marketing effort turns into installs. The title and subtitle carry the most weight, the keyword field on the App Store is separate from the description, and on Google Play the description text itself is indexed. Those are different systems and the same copy will not serve both well.

Screenshots do the converting. Most people decide from the first two, so those should show what the app does with a caption explaining the benefit, not a bare interface capture. A short preview video helps when the value is hard to show in a still image.

Ratings and reviews affect both ranking and conversion, so ask for ratings at a sensible moment, after the user has had a good experience rather than on first open. Reply to reviews, especially the critical ones. A visible pattern of fixing what people complain about is persuasive to the next reader.

• Title and subtitle carry the most search weight, so use them for terms, not slogans
• First two screenshots decide most installs, so caption the benefit
• Request ratings after a positive moment, never on first launch
• Reply to reviews, because future readers see the replies

Does your business need an app at all?

This is the question we ask before quoting, and sometimes the honest answer is no. Apps earn their place when people use them repeatedly, when the experience needs something a browser cannot do, or when notifications and offline access genuinely change the value. A brochure app, a one-off transaction, or content people read occasionally are all better served by a fast, well-built website.

The reason to be strict is the install barrier. Persuading someone to install an app, grant permissions and remember it exists is far harder than persuading them to open a link. If the use is occasional, most people will never get past that barrier, and the app will show good download numbers with poor active use.

Where the case is genuine but unproven, a progressive web app is often the sensible first step. It tests demand without the store overhead, and if usage proves the case, the work done on the back end carries over to a native or cross-platform build.