What is a progressive web app?

A progressive web app is a website that browsers treat as an installable app when the right conditions are met. A Web App Manifest tells the browser the site is installable. A Service Worker intercepts network requests and can serve cached responses when the network is unavailable. IndexedDB stores structured application data on the device. The Web Push API delivers push notifications. When a user visits on Android Chrome or a Chromium browser, a prompt appears to add the app to the home screen. On iOS Safari, the user taps Share and selects Add to Home Screen. Once installed, the app runs in its own window without browser UI, loads from cache on repeat visits, and behaves like a native app for most everyday workflows.

PWA vs native app: which should I build?

Build a PWA when you want one codebase across iOS, Android, and desktop, you don't need deep OS integration, and you can accept the platform gaps browsers impose on installed web apps. PWAs install to the home screen, work offline, send push notifications on supported platforms, and ship updates instantly without store review. Build a native app when you need full access to platform APIs that browsers don't expose, when push notifications are mission-critical and iOS limitations are not acceptable, when App Store presence is part of the product's discoverability strategy, or when you need integration with Apple Pay, HealthKit, ARKit, or similar platform-only frameworks. RaftLabs builds both and will tell you in scoping which one actually fits your use case.

Does a PWA work offline?

Yes, if it's designed for it from the start. Offline support in a PWA is built on three things. The Service Worker intercepts network requests and returns cached responses when no network is available. The Cache API stores HTTP responses and static assets. IndexedDB stores structured application data on the device so the app can keep functioning with no connectivity. When the network returns, a sync layer reconciles local changes with the server. We design the conflict resolution logic during discovery because offline sync shapes the data model from the beginning. Adding offline support to an app that was not designed for it is harder than building it in from the start.

Do push notifications work on iOS PWAs?

Yes, with conditions. Apple added Web Push support to iOS Safari in iOS 16.4, released in March 2023. Web Push only works for PWAs the user has added to the home screen; it does not work for the same site accessed as a browser tab. Older iOS versions have no web push support. On Android and desktop browsers, web push works reliably via the Push API with VAPID keys. If your audience skews toward older iOS devices, or if push delivery is mission-critical, we flag this in scoping and discuss fallback channels: SMS, email, or a native iOS app for the iOS audience.

What does progressive web app development cost?

A focused PWA, core workflow, offline support, installable manifest, and push notifications on supported platforms, typically runs $15,000 to $40,000. PWAs that replace a native app or that need complex offline sync with conflict resolution run $40,000 to $80,000. Migration from an existing web app to PWA status, adding the Service Worker, manifest, install prompt, and offline layer to an existing app, usually runs $15,000 to $35,000 depending on how the existing app is structured. We scope every project before pricing and give you a fixed cost.

How long does it take to build a PWA?

A focused PWA with defined scope ships in 8 to 14 weeks. That covers discovery and architecture, design and front-end build, Service Worker and offline layer, push notification system, QA on real devices, and Lighthouse audit to 90+ before launch. Larger builds with complex offline sync, multi-role workflows, or migration from an existing app run 14 to 20 weeks. We give you a timeline before the project starts, not a range we adjust as we go.

Can a PWA be listed in the App Store?

Google Play accepts PWAs packaged via Trusted Web Activity (TWA), which is a Chromium browser wrapper that runs your PWA inside a Play Store-listed app. The experience is identical to a native install. Apple's App Store does not accept PWAs as-is. To distribute via the App Store, you would need a native shell app, at which point the effort overlaps with a native build. If App Store distribution on iOS is a hard requirement, we recommend a native iOS app rather than a workaround. We'll say that during scoping, not after the build is underway.

Progressive Web App Development Company

Progressive Web App Development

A progressive web app installs from the browser, works offline, and sends push notifications, one codebase that covers every platform without a separate iOS or Android team. For many businesses, that is the right call. For others, native wins on hardware access or App Store distribution.
RaftLabs builds both PWAs and native apps. We scope your use case first and tell you which architecture actually fits, including when a PWA would cost you less without giving anything up, and when native is worth the extra build.

See our work

Offline-first architecture using Service Workers, IndexedDB, and background sync so the app keeps working without a network connection
Web Push notifications via the Push API and VAPID keys, with opt-in flows designed to get permission rather than lose it
App shell architecture with code splitting and lazy loading so the installed app opens in under two seconds on repeat visits
Web App Manifest configured for every platform, including maskable icons for Android adaptive launchers and legacy splash images for iOS

Recent outcomes

PWA · Community platform

50K users in 6 months

Built an installable PWA with offline-first architecture and push notifications. 50K users reached in 6 months from a single codebase.

Mobile app · Food & beverage SaaS

3x revenue, 0% order errors

Replaced separate iOS and Android builds with a cross-platform web app. Zero order errors after launch.

Web app · Decision platform

75% faster decisions

Shipped a real-time web app supporting 300+ concurrent users. Teams reached decisions 75% faster.

4.9 / 5 on ClutchSee our work

The problem

Sound familiar?

Paying for separate iOS and Android teams to build the same customer-facing workflow on two codebases?
Mobile site that loads fine in the browser but can't be installed, can't push a notification, and stops working when the network drops?

The short answer

RaftLabs builds progressive web apps for businesses across the US, UK, Europe, Canada, GCC, South Africa, and Southeast Asia. PWAs install from the browser, work offline, and send push notifications from one codebase. Focused builds start at $15,000 and ship in 8 to 14 weeks. 100+ products shipped since 2015.

Key Takeaways

Focused PWA builds start at $15,000 and ship in 8 to 14 weeks from scoped discovery to production.
One codebase covers iOS, Android, and desktop without separate native teams.
Offline-first architecture uses Service Workers, IndexedDB, and background sync so the app works without a network connection.
Web Push notifications are delivered via the Push API with VAPID keys on supported platforms.
The installed app shell loads in under two seconds on repeat visits through code splitting and lazy loading.
RaftLabs has shipped 100+ products since 2015 for businesses in the US, UK, and Australia.

Trusted by

Software delivery, by the numbers

software products shipped: 100+

average time to first production release: 12 weeks

rated by clients on Clutch: 4.9/5

years delivering software for established businesses: 9+

Two native codebases for the same customer workflow is a cost, not a feature

Most businesses building a customer-facing mobile experience default to native iOS and native Android without asking if that's actually required. Two teams, two review cycles, two sets of bugs, two deployments every time you ship a change. For some products, that overhead is justified. For many others, a PWA covers the same ground at a fraction of the cost.

A PWA installs from the browser, works offline, sends push notifications, and loads in under two seconds on a repeat visit. It is not a compromise. It is a different architecture with specific tradeoffs, and those tradeoffs favour the majority of B2B and customer-facing use cases where users are on a phone but don't need the full hardware layer.

According to Google's web.dev case studies, AliExpress saw a 104% increase in conversion rates for new users after rebuilding their mobile experience as a PWA, with time spent per session rising 74% across all browsers. For most customer-facing workflows, the performance gap between a well-built PWA and a native app is negligible — and the cost gap is not.

The one thing that changes the answer: iOS still has gaps in push and background sync. Some hardware APIs aren't exposed to web apps. For products where those gaps are blocking, native wins. We scope your specific requirements before recommending either, so you aren't paying for a build that doesn't fit the problem.

Capabilities

What we build

01
Offline-first architecture
Web apps designed from the data layer up to work without a network connection, not bolted on after the fact. The Service Worker serves cached responses offline and queues outbound requests until connectivity returns, and users see an explicit sync status so they know when their edits have reached the server.
Built with
IndexedDB · Cache API · Service Worker · CRDT sync
02
Push notification systems
Web Push notifications, the standard across Chrome, Edge, Firefox, and home-screen-installed PWAs on iOS. Permission flows are designed around the moment users actually want notifications, with server-side delivery triggered by your business events. We document the iOS caveat in plain language and recommend a fallback channel if push is mission-critical.
Built with
Push API · VAPID keys · iOS Safari 16.4+
03
App shell architecture
App shell architecture separates the static application frame, navigation, and layout from the dynamic data that fills it. The shell is cached on first visit so the app opens in under two seconds regardless of network conditions, with route-level code splitting to keep the initial bundle small. We ship at a Lighthouse performance score of 90+.
Built with
Service Worker · Workbox · Lighthouse
04
PWA installation and onboarding
Web App Manifest configured correctly for every platform: the right display mode, a full icon set, maskable icons for Android launchers, and iOS splash screens. The install prompt surfaces the call-to-action at the right moment rather than immediately on landing, and because the installed PWA on iOS doesn't share cookies with Safari, we handle that in the auth layer so users aren't asked to log in twice.
Built with
Web App Manifest · beforeinstallprompt · Maskable icons
05
Web API hardware access
Modern browsers expose a growing set of hardware APIs that let PWAs do things that used to require a native app: camera and microphone for document scanning and video calls, geolocation for field service routing, and Bluetooth for scanners, printers, and IoT sensors. For any hardware requirement Web APIs can't cover, we tell you up front and recommend a React Native or native build instead.
Built with
MediaDevices API · Geolocation · Web Bluetooth
06
Performance and Core Web Vitals
Performance is not a post-launch task. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1 are built into the architecture from the first sprint. We test on real mid-range Android hardware, not just a MacBook on a fast office connection, because that's what your users are actually on.
Built with
Core Web Vitals · Lighthouse · WebP/AVIF

How we work

From scope to shipped

Every project follows the same four phases. Scope is locked and price is fixed before development starts.

Week 1
01
Discovery and scope
We map the workflow, the offline requirements, and the platform constraints. You leave week 1 with a written scope document and a fixed-price quote. We also tell you here if native wins over PWA for your specific use case.
Weeks 2-3
02
Design and architecture
App shell structure, Service Worker caching strategy, offline sync model, and push notification flows are designed before any production code is written. Decisions made here cost ten times less than the same decisions made in week 8.
Weeks 4-12
03
Build, integrate, and QA
Working PWA at a staging URL by the end of sprint one. Bi-weekly demos. QA runs on real Android and iOS devices in parallel with every sprint. Lighthouse audit to 90+ before launch.
Weeks 12+
04
Launch and post-launch support
Production deployment with monitoring activated on launch day. 8 weeks of post-launch support included in every project.

Why us

Why teams choose RaftLabs

01
Senior engineers build what they scope
The engineers who assess your problem also build the solution. No bait-and-switch, no offshore handoff after the contract is signed. The team you meet in week 1 ships in week 12.
02
Fixed price before development starts
We scope the work, calculate the cost, and lock it in writing before any development starts. A scope change is a change request: priced, agreed, or dropped. It never absorbs into the project and appears on the final invoice.
03
9 years and 100+ products shipped
Clients include Vodafone, T-Mobile, Aldi, Nike, Cisco, and Lockheed Martin. Track record across AI, SaaS, mobile, automation, and enterprise platforms across healthcare, fintech, logistics, and hospitality.
04
Compliance built in from the start
GDPR, HIPAA, SOC 2 - compliance requirements are scoped in week 1, not retrofitted before launch. We have shipped HIPAA-compliant systems for US healthcare clients and GDPR-compliant products for European markets.

Paying for two native apps when one PWA would cover both?

Tell us your app use case, who uses it, and what it needs to do offline. We'll scope the PWA, compare it against native, and give you a fixed cost before you commit to anything.

Talk about your app

Related services