Web Development
Progressive Web Apps
The option most businesses should evaluate before committing to native. Cheaper, faster to ship, and adequate for a large share of what people ask apps for.
A progressive web app is a website that can be installed, works offline and sends push notifications. The Nexclick builds them where those capabilities are enough, because a PWA avoids app store review, install friction and the cost of maintaining two native codebases.
Is this you?
What usually prompts the call
- You have been quoted for iOS and Android apps and the number was startling.
- Your users need offline access on unreliable connections — field staff, warehouses, sites.
- You want push notifications without maintaining two native codebases.
- App store review keeps delaying releases you need out quickly.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Establish whether native is actually needed
- What device capabilities the requirement genuinely uses. A large share of app briefs describe something a PWA does at a fraction of the cost.
- Offline strategy
- What is cached, what is queued while offline, and how conflicts resolve when connectivity returns. This is the substance of a PWA rather than the manifest file.
- Installability
- Manifest, icons and install prompts so it appears as an app on the home screen and launches without browser furniture.
- Push notifications
- Supported across Android and, since 2023, on iOS for installed web apps — with the platform caveats stated honestly rather than glossed over.
- Performance as a requirement
- A PWA that loads slowly is judged as a bad website rather than as an app. Performance budgets are part of the build, not an optimisation afterwards.
- Background sync
- Actions taken offline queued and submitted when connectivity returns, with the user told what has and has not sent.
- Honest platform limitations
- A written list of what a PWA cannot do on iOS in particular, so nobody discovers a gap after launch.
Comparison
PWA versus native — what you actually gain and lose
This decision is usually made on assumption. Here is what each genuinely gives you, so it can be made on the requirement rather than on which sounds more substantial.
| Progressive web app | Native apps | |
|---|---|---|
| Build cost | One codebase | Two, or one cross-platform with compromises |
| App store review | None | Every release, with delays |
| Install friction | A prompt — no store visit | Store search, download, install |
| Updates | Immediate for everyone | Users must update; many do not |
| Offline | Yes, with a service worker | Yes |
| Push notifications | Yes on Android; yes on iOS once installed | Yes, more reliably |
| Camera and location | Yes | Yes, with deeper capability |
| Bluetooth, NFC, background location | Limited or unavailable | Yes |
| App store discovery | None | Real, though heavily contested |
| Perceived legitimacy | Lower with some audiences | Higher |
| Heavy graphics or processing | Limited | Yes |
| Best for | Content, forms, dashboards, field tools | Device-integrated, graphics-heavy, store-discovered |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1
Assess against native
Which capabilities the requirement genuinely needs, and whether any of them rules out a PWA. An honest gate.
- 02Week 1–3
Design for offline
Caching strategy, queueing and conflict resolution designed before building, since retrofitting offline is close to a rewrite.
- 03Week 3–10
Build
Application with service worker, manifest and background sync, tested on real devices with the network genuinely disabled.
- 04Week 10–12
Test and launch
Cross-platform testing including iOS install behaviour, then launch with monitoring.
What you get
Reporting and ownership
- A written comparison against native before building, including when native is the right answer.
- An offline strategy documented — what is cached, what is queued, how conflicts resolve.
- Testing on real devices with the network genuinely disabled, not simulated.
- A written list of iOS platform limitations, so nobody discovers a gap after launch.
- No app store dependency — you release when you decide to.
Tools and platforms
- Next.js or a comparable framework
- Service workers / Workbox
- Web Push (VAPID)
- IndexedDB
- Lighthouse PWA audits
- Real device testing
Timeline
How long this actually takes
Ten to twelve weeks, which is considerably less than two native apps and comparable to one. The saving is not only the build: there is no store review, no release approval delay, no two codebases diverging, and updates reach everyone immediately. Where native genuinely wins is deep device integration — Bluetooth peripherals, background location, health data, heavy graphics — and app store discovery if that is genuinely how your users will find you. We will say which side of that line you fall on before quoting.
Pricing model
Fixed-price project
Fixed price against a specification. Typically well under the cost of native apps for both platforms, with no ongoing store or release overhead.
Questions
Progressive Web Apps questions
Can a PWA send push notifications on iPhone?
Yes, since iOS 16.4, provided the user has added it to their home screen. That was the main historic argument against PWAs on iOS and it no longer holds. Delivery is still less reliable than native, and the requirement to install first is a genuine constraint.
What can a PWA not do?
Deep device integration — Bluetooth peripherals, NFC, background location tracking, health data — and heavy graphics work. It also has no app store presence. If none of those matter to your requirement, the case for native is weaker than it appears.
Will users know how to install it?
Not without prompting, and that is the real friction. An in-app prompt explaining the benefit works reasonably on Android and needs more explanation on iOS, where the install route is less obvious. It is a design and communication problem rather than a technical one.
Does a PWA work genuinely offline?
Yes, with a service worker caching what is needed and queueing actions taken while disconnected. The design work is deciding what to cache and how to resolve conflicts when connectivity returns — that is the substance, not the manifest file.
Is a PWA worse for SEO?
No — better, if built correctly, because it is a website. Server-rendered or statically generated pages are fully crawlable, unlike a native app which is invisible to search entirely. This is a genuine and often overlooked advantage.
Could we start with a PWA and go native later?
Yes, and it is a sensible sequence. Ship the PWA, validate that people want the thing, and build native only if the constraints genuinely bite. Going the other way — building native first and discovering a PWA would have done — is the expensive order.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.