App Development
Progressive web apps, no store required
A progressive web app installs from the browser, works offline and can send notifications, with no app store between you and your users. For many products it delivers the app experience at a fraction of the cost.
Who it is for: Businesses that want an installable app without store fees, review queues or a separate codebase, and products whose users start from the web anyway.
Everything in this service
- Installable PWA with home-screen icon and full-screen mode
- Offline support for the features that need it
- Push notifications where the platform allows
- Speed engineered in, because a PWA lives on web performance
- Analytics on installs, engagement and return visits
What to expect
- An installable app without store fees or review delays
- Updates that reach every user instantly
- One codebase serving web and app users
How progressive web apps actually works
Installability: what it means and what it changes
A progressive web app is a website that meets a set of technical requirements which let a browser offer it as something installable. Once installed it gets an icon on the home screen, opens in its own window without browser controls, and appears in the device app switcher. To the user it looks and behaves like an app, because for practical purposes it is one.
Three things make that possible. A manifest file declaring the name, icons, colours and how the app should be displayed. A secure connection, which is required. And a service worker, a script that sits between the app and the network and can decide what to serve from a stored copy rather than fetching.
The behavioural change matters more than the technical detail. An installed app is opened deliberately from the home screen rather than found through a browser, which changes it from something someone visits into something someone returns to. Prompting for install is a judgement: asking on the first visit tends to be dismissed, whereas asking after someone has used the thing a few times and found it useful lands far better. And on iOS there is no automatic install prompt at all, so the app has to explain the steps itself, which means designing that explanation rather than assuming the platform will handle it.
- Manifest, a secure connection and a service worker are the requirements
- Provide the full range of icon sizes, a poor icon undermines the whole effect
- Prompt for install after value has been demonstrated, not on arrival
- On iOS, guide the user through the manual install steps
- Test the installed window, controls hidden by the browser become your job
Offline behaviour: what is realistic and what is not
Offline support is the most misunderstood part of a PWA. It does not mean the whole product works without a connection. It means you decide what still works, and design the rest to fail gracefully.
A service worker can store files and responses and serve them when the network is unavailable or slow. That reliably covers the application shell, so the app opens instantly rather than showing a browser error, plus previously viewed content, reference material that changes rarely, and forms that can be filled offline and sent when a connection returns. What it does not cover is anything requiring live data: current prices, live availability, another person messages, a payment. Pretending otherwise produces something worse than an honest offline message, because the user acts on stale information.
The best default is not a binary online or offline state but graceful degradation, because the common real condition is a slow or unreliable connection rather than no connection at all. Serve the stored copy immediately so something appears, fetch fresh data in the background, and update when it arrives. Show clearly when content is from a stored copy and when it was last updated. Queue actions taken offline and confirm when they have actually been sent, since an action that appears to have worked and silently did not is the most damaging failure available. And test on a genuinely poor connection, not just with the network switched off, because the intermittent case is harder and far more common.
- Decide explicitly which features work offline, do not promise everything
- Cache the shell so the app always opens, then refresh data behind it
- Label stored content and show when it was last updated
- Queue offline actions and confirm clearly when they are really sent
- Test on a slow flaky connection, not only fully offline
When a PWA beats a store app
A PWA is the better choice more often than the industry admits, mainly because the alternatives carry costs that are easy to overlook.
It wins when your users find you through search or a link. There is no install step between discovery and use, and the person can start immediately and install later if they want to return. It wins when the product is content, service booking, ordering, account access or internal tools, since those are things a web application already does well. It wins when you need to release frequently, because updates reach everyone on next open with no submission, no review and no waiting for users to update. It wins when you already have a web product and cannot fund a separate app team. And it wins when store commission on digital sales would take a meaningful share of your revenue.
It loses when the product needs deep hardware access, sustained high performance, or platform capabilities the web does not expose. It also loses when your customers simply expect to find you in the store, which is a real commercial factor rather than a technical one and should be weighed as such. A reasonable way to decide: if the app is a way to access a service you already run on the web, a PWA is usually the efficient answer. If the app is the product itself and depends on the device, it usually is not.
- No install friction between finding you and using you
- Updates reach everyone immediately, with no review queue
- One codebase serving web and app users, which halves maintenance
- No store commission on what you sell through it
- Loses where deep hardware access or store presence genuinely matter
Platform limitations, especially on iOS
Being straightforward about limits is the only responsible way to sell a PWA, because the gaps are real and they are not evenly distributed between platforms.
Android support is strong. Installation is prompted by the browser, notifications work, and a wide range of device capabilities is available to web applications. iOS support has improved considerably and is still narrower. Installation is manual through the browser share menu, with no automatic prompt, so users must be told how. Notification support arrived later and requires the app to be installed to the home screen first, which is a meaningful conversion step. Background activity is more restricted. Storage limits are tighter, and stored data can be cleared after a period of not using the app, which matters for anything relying on offline data. Some hardware features available to native apps are not exposed to web applications at all.
Across both platforms, the general gaps are similar: deep hardware integration, background processing, some contact and calendar access, and system-level features like widgets. The practical response is to map your feature list against these limits before committing any budget, and to test on an actual iPhone rather than trusting a support table, since behaviour differs by version. Where a limit blocks something essential, say so early. Discovering it after the build is the expensive path, and it is entirely avoidable.
- iOS install is manual, so the app must explain the steps itself
- iOS notifications require the app to be installed first
- iOS storage is tighter and can be cleared after disuse
- Deep hardware access, background work and widgets remain native territory
- Check the feature list against the limits before any budget is spent
The discoverability advantage nobody counts
A PWA has one structural advantage over a store app that rarely appears in the comparison: it is on the web, so it can be found, linked and shared like any web page.
That means search engines can index it, so people looking for what you do can arrive directly on the relevant screen. It means every link works, whether from an email, a message, a social post or another site. It means a link can point at a specific item rather than at a store listing, and the person lands exactly there rather than downloading an app and searching for what they were sent. A store app, by contrast, is a closed destination: its content is generally not indexed by web search, and every route in goes through an install.
The gap is largest at the top of the relationship. A store app requires commitment before any value is delivered, and a large share of people who intend to install one never complete it. A PWA delivers the value first and asks for commitment afterwards, which reverses the order in a way that suits products people discover rather than products people already know they want. The counterweight is store presence, which some audiences expect and which carries its own discovery for well-known categories. Both can be had if it matters: a PWA can be packaged and listed in the stores, so the web version remains the discoverable front door while a listing exists for people who look there first.
- Content is indexable and reachable through search
- Every link works and can point at a specific screen
- Value is delivered before any commitment is asked for
- Sharing needs no install step for the recipient
- A PWA can also be packaged for the stores if listing matters
Building a PWA that feels like an app rather than a site
The technical requirements make a PWA installable. They do not make it feel like an app. That comes from engineering and design choices, and skipping them produces a website in a window, which users recognise instantly.
Speed is the largest factor. An installed app is expected to open immediately, so the shell should render from a stored copy without waiting for the network, and interactions should respond at once. Anything that takes time needs immediate visual acknowledgement, since a delay with no feedback reads as a broken tap. Movement between screens should be instant with content filling in behind, rather than a full page load with a blank moment in between.
Then the details. Design for the installed window, where there is no browser back control, which means your own way back must always be present and obvious. Use platform-appropriate gestures where they are expected. Respect system settings for text size, dark mode and reduced motion. Handle the on-screen keyboard properly so it does not cover the field being typed into. Make touch targets generous. Manage scroll position so returning to a list puts the user where they were rather than at the top. And define the offline and error states properly, because an installed app showing a browser error page is the clearest possible signal that it is not really an app.
- Render the shell instantly from cache, then fill in data
- Give immediate feedback on every tap, even for slow actions
- Always provide your own way back, the browser control is gone
- Respect text size, dark mode and reduced motion settings
- Design real offline and error screens, never fall back to a browser error
A clear path, step by step
- 01
Check the fit
We confirm a PWA can deliver your feature list, including the iOS limits, before you commit.
- 02
Build app-grade
Fast loads, smooth interactions and offline handling, engineered like an app, not a site.
- 03
Make it installable
Manifest, service worker and install prompts configured and tested per platform.
- 04
Measure and improve
Install and engagement data guides what gets built next.
Why choose us for this
We are upfront about platform limits, especially on iOS
Web performance is our home ground, and a PWA is all web performance
One build serves your site and your app users
Common questions
What can a PWA not do?
Deep hardware access and some background features remain limited, and iOS supports fewer PWA capabilities than Android, notifications being the common gap. We map your feature list against these limits before you spend anything.
Can a PWA still go in the app stores?
Yes. A PWA can be packaged and listed on Google Play and, within Apple’s rules, the App Store. You get store presence while keeping one codebase.
Explore related work
Want this for your business?
Book a free visibility call and I will tell you honestly whether I can help.
How this is delivered
One person leads every project. Where a job genuinely needs a specialist, I bring in people I have worked with before and manage them, so you get one point of contact and one invoice rather than three suppliers blaming each other.
- You talk to the person responsible for the work, not an account manager
- Specialists are briefed and managed by me, and their work is checked before it reaches you
- One contract, one invoice, one place to chase