Mobile app, progressive web app or responsive website: what should you build first?

A mobile app is not automatically a better mobile experience.

If customers use a service twice a year, arrive from search and need to complete one straightforward task, asking them to find, install and keep an app may introduce friction without creating meaningful value. If field staff complete the same workflow every hour in unreliable connectivity and need camera, location, background processing and managed-device controls, a responsive public website may be the wrong tool.

A progressive web app sits between those examples, but it is not simply a budget native app. It is a web application that can use capabilities such as a web app manifest, service workers, installation and offline behaviour, subject to the relevant browser and operating-system support.

The correct question is not “Which technology is best?” It is:

Which surface lets the intended users complete the job with the least friction, while giving the organisation a supportable, secure and commercially credible operating model?

That decision should account for reach, frequency, offline use, device capabilities, distribution, accessibility, security, data, team capability and the cost of operating more than one product surface.

The short answer

Start with a responsive website or web application when broad reach, search discovery, link sharing and immediate access matter more than installation or deep device integration.

Consider a progressive web app when the service can remain web-based but benefits from installation, selected offline behaviour, faster repeat access or supported web capabilities.

Consider a native or cross-platform mobile app when frequent use, app-store distribution, deep device capability, background behaviour, managed deployment or platform-specific experience creates enough value to justify separate release and support obligations.

Use more than one surface only when each has a defined role. Do not build an app merely to reproduce the marketing website inside a wrapper.

Understand what the three options actually are

Responsive website or web application

Responsive web design adapts layout and interaction to different screens and device capabilities. Google’s responsive design guidance describes it as a strategy that responds to users’ needs and their devices by changing the layout to suit the device being used.

The term includes more than public content pages. A responsive web application can support accounts, transactions, portals, dashboards and sophisticated workflows through the browser. It is reached by URL, can be linked and indexed where public, and can update centrally without an app-store release.

Responsive does not guarantee usable. Tiny targets, desktop-first forms, inaccessible navigation and excessive assets can still create a poor mobile experience.

Progressive web app

A PWA uses web technologies while providing selected app-like capabilities. A web app manifest describes how the application should appear when installed. A service worker can intercept requests and support caching, offline experiences, background events and push behaviour where supported. See the current web.dev service-worker guidance.

PWA capability is progressive: the experience can enhance according to the browser and device. That makes resilience possible and also means capability is not identical everywhere. Product requirements should be checked against current support rather than a generic list of what “PWAs can do”.

Native or cross-platform mobile app

A mobile app is installed as an application package and distributed through an app store, enterprise system or other permitted channel. Native development uses platform-specific technologies. Cross-platform frameworks can share substantial code while still producing installed apps.

An app can access deeper device and operating-system capability, but it introduces platform releases, store requirements, signing, review, compatibility testing, analytics, support and update management. Apple reviews apps and updates under its current App Review Guidelines, while Google Play provides its own release and quality guidance. These are ongoing operating dependencies, not launch paperwork alone.

Start with the job, not the channel

Describe the mobile job in observable terms:

Who performs it?
What triggers it?
How frequently does it occur?
Where is the user physically?
What information or hardware is required?
What can interrupt the journey?
What happens if connectivity disappears?
Does the user already have a relationship and account?
What outcome must occur in another system?
Who supports exceptions?

“Customers need an app” is not a job. “Technicians need to retrieve assigned work, capture photos and signatures, and complete a job in areas with intermittent coverage” is.

Different jobs in the same organisation may require different surfaces. Public product research can stay on the responsive website while authenticated, high-frequency workforce tasks use an app. The decision does not have to force the entire digital estate into one technology.

Compare reach and installation friction

A responsive web journey has the broadest immediate reach. A user can arrive from search, email, advertising, a QR code or another website and begin without installation. This is powerful for acquisition, occasional tasks, public information and unknown audiences.

An installed app adds a funnel:

Discover the app.
Trust that it is worth installing.
Visit the store or approved channel.
Download and grant relevant permissions.
Open, onboard and authenticate.
Keep it updated and retained.

That friction can be justified for repeat value. It is harder to justify for a task that users complete infrequently.

A PWA can reduce some friction by allowing eligible users to add a web experience to the home screen, but installation prompts and behaviour vary. Treat installation as an enhancement, not the only route to the service.

Use frequency and relationship as a strong first filter

Low-frequency, high-discovery journeys

Public information, campaign response, first enquiry, one-off application, location search and occasional self-service usually favour the web. Users may not yet trust the brand enough to install anything.

Repeat customer journeys

Order tracking, account management, loyalty, booking and repeat purchase can fit a responsive web app, PWA or mobile app. Decide according to frequency, notifications, offline need and depth of interaction.

High-frequency operational journeys

Workforce, field, delivery, inspection, clinical or equipment workflows may justify an installed app when device integration, background processing, offline data and managed deployment are central.

Frequency alone is not enough. A banking transaction may be infrequent for some users but security, trust, notifications and service breadth can justify an app. Use the complete framework.

Define offline as specific behaviours

“Must work offline” is not a requirement until the team defines what works.

Options include:

Display a clear offline page.
Open previously viewed content.
Read previously synchronised records.
Create a draft locally.
Capture photos or signatures.
Submit an action to a queue.
Resolve conflicts when connectivity returns.
Continue authentication for a defined period.
Receive or process background events.

Web service workers can support cached resources and offline experiences. The web.dev offline-data guidance explains that a robust offline experience requires deliberate storage management, persistence and limits. This is application architecture, not a switch labelled offline.

Native apps can provide deeper and more predictable local integration, but they still need synchronisation, conflict, security and storage design. Offline data increases privacy and device-loss considerations regardless of technology.

Test each required device capability

Create a capability register rather than assuming “native can” and “web cannot”.

For each capability, record:

Required behaviour.
Supported devices and operating systems.
Browser or app constraints.
Permission and consent experience.
Accessibility implications.
Offline behaviour.
Security and privacy risk.
Fallback if unavailable.
Test evidence.

Capabilities might include camera, barcode scanning, location, Bluetooth, file access, biometrics, contacts, calendar, push notifications, background sync and digital wallet integration.

Web capabilities continue to evolve. Apple supports web push for Home Screen web apps from iOS and iPadOS 16.4, according to its web push documentation. That does not mean web push behaves identically to native notifications in every context. Verify the exact platforms and user journey required at the time of implementation.

Treat notifications as a service, not a feature tick

Push notifications can create value when they communicate meaningful, timely events: an order is ready, a booking changed, a task was assigned or action is required.

They also create governance obligations:

Permission timing and explanation.
Notification preferences and quiet periods.
Sensitive content on locked screens.
Deep links to the correct authenticated state.
Duplicate suppression across email, SMS, web and app.
Delivery monitoring and fallback.
Opt-out and account closure.
Ownership of message content.

If the use case is occasional promotional broadcasting, an app may not be justified. Consider email, SMS, browser notifications or authenticated web messaging according to consent, customer preference and value.

Compare distribution and discovery models

Web distribution

URLs support search, sharing, campaigns and direct deep links. Public pages can contribute to the organisation’s broader search presence. Updates are centrally deployed.

App-store distribution

Stores can create discovery, trust and managed update pathways, but the organisation must maintain listings, screenshots, declarations, policy compliance, review and release timing. Some changes require store review. The operating team needs capacity for both iOS and Android obligations where both are supported.

Enterprise or managed distribution

Workforce apps can be deployed through device-management arrangements. This can reduce public discovery concerns but adds organisational identity, device policy, version support and help-desk dependencies.

PWA distribution

A PWA is primarily reached through the web and can be installed where supported. Some ecosystems also allow packaged distribution, but that should not be assumed to provide identical store treatment or capability.

Select the channel through which the intended user will realistically discover and trust the product.

Do not assume one codebase means one product

A responsive website naturally uses one web delivery surface across supported browsers. A PWA adds service-worker, manifest, caching, installation and capability concerns. A cross-platform app can share code, but platform-specific integrations, permissions, store metadata, accessibility, QA and release handling remain.

The true operating cost includes:

Product management and roadmap.
UX and content for each surface.
Development and platform-specific work.
Browser, device and operating-system testing.
Store and policy management.
Analytics and crash monitoring.
Security, privacy and accessibility assurance.
Customer support and knowledge material.
Release, rollback and deprecation.
API and backend operation.

If the organisation already struggles to maintain one website, adding two app binaries may multiply the underlying governance problem.

Build shared services before duplicating interfaces

Where more than one surface is justified, separate common capabilities from presentation:

Identity and account service.
API and integration layer.
Product, content and customer data.
Permissions and consent.
Notification orchestration.
Analytics event definitions.
Audit, monitoring and support.
Design foundations and content language.

This does not require an elaborate microservices programme. It does require clear ownership and contracts between the surfaces and backend systems.

Avoid building business rules independently in the website, iOS app and Android app. Divergence creates inconsistent eligibility, pricing, status and support outcomes.

Use an eight-dimension decision scorecard

Score the options only after defining the requirements. Use evidence rather than weighting criteria to force a preferred technology.

Dimension	Responsive web	PWA	Mobile app
Immediate reach	Strong	Strong	Installation required
Search and link discovery	Strong	Strong before installation	Limited to store and deep-link model
Repeat access	Good	Strong when installed	Strong
Offline capability	Designed, generally limited	Designed through service worker and storage	Deepest potential
Device integration	Browser-dependent	Enhanced but variable	Deepest and most predictable
Store presence	No	Possible in some forms	Core distribution route
Release overhead	Central web release	Web release plus PWA QA	Platform and store release lifecycle
Best fit	Broad or occasional access	Repeat web-based tasks	Frequent, integrated or managed-device tasks

The table is directional. The actual result depends on current browser support, chosen frameworks, product requirements and user devices.

Accessibility applies to every option

Native does not mean accessible, and responsive does not mean usable.

Test navigation, focus, target sizes, orientation, text resizing, contrast, gestures, error handling, authentication, notifications, motion, screen readers and external keyboards according to the surface. W3C says mobile accessibility is covered by existing standards and provides guidance for applying WCAG 2.2 to mobile applications across native apps, mobile web apps and hybrid apps.

Specify accessibility responsibility, conformance, representative device coverage, manual testing and defect acceptance before development.

Consider security and privacy in the surface decision

Map:

Personal and sensitive information handled.
Data stored on device.
Authentication and session requirements.
Permission use and revocation.
Rooted or compromised-device policy where relevant.
API authorisation.
Logging without leaking sensitive data.
App or browser update dependencies.
Account recovery and device replacement.
Data deletion and decommissioning.

An app does not secure a weak API. A PWA does not remove responsibility for cached data. A responsive site does not avoid account and integration risk. Security architecture follows the service and threat model.

A practical build-first decision sequence

1. Establish the responsive baseline

For most organisations, the public website should provide a high-quality mobile experience even if an app exists. It supports discovery, trust, help, legal content and users who cannot or will not install the app.

2. Identify repeat jobs with distinct mobile value

Use research and operational evidence. Do not turn the entire website sitemap into an app backlog.

3. Validate device and offline requirements

Prototype or technically validate uncertain capabilities on representative devices.

4. Define shared backend and identity needs

Avoid surface-specific data silos.

5. Select the smallest credible production surface

That may be a responsive web application, a PWA enhancement, a native app for one workflow or a staged combination.

6. Fund the lifecycle

Approve support, updates, monitoring, store administration, analytics and continuous improvement, not only initial build.

When paid Discovery should come first

Discovery is warranted when the decision depends on unresolved:

User groups and task frequency.
Offline and synchronisation behaviour.
Device capabilities and platform support.
Identity, roles and sensitive data.
Backend systems and APIs.
Store, enterprise or public distribution.
Accessibility and compliance.
Product ownership, support and lifecycle cost.
Relationship with the existing website and content.

The output should be a recommendation, release scope, validated capability position, architecture, operating model and investment pathway. Discovery may recommend improving the responsive website first rather than building an app.

Frequently asked questions

Is a PWA cheaper than a mobile app?

It can be when the required experience fits web capabilities and one web delivery model. Cost depends on offline behaviour, device features, backend systems, testing, security and support. PWA is a technology approach, not a guaranteed budget tier.

Can a PWA send push notifications on iPhone?

Apple supports web push for Home Screen web apps on supported iOS and iPadOS versions. The user journey and capability differ from native apps, so verify current platform support and requirements before relying on it.

Will users install our app?

Installation depends on repeat value, trust, discovery and relevance. Validate the user job and expected frequency rather than assuming customers want an icon.

Can a responsive website work offline?

Selected web content and actions can use service workers, caching and local storage, but offline behaviour must be deliberately designed. Define exactly what the user can read, create, submit and synchronise.

Does an app improve search visibility?

A public responsive website remains the primary searchable and linkable surface for most content. App-store listings create a separate discovery channel but do not replace a crawlable web content strategy.

Should we build iOS and Android at the same time?

Only if the audience evidence, commercial case and support model justify both. Device distribution, capability and risk may support a staged release, but shared backend and product decisions should anticipate the approved pathway.

Is cross-platform development the same as one build?

No. It can share code, but platform integrations, permissions, quality assurance, accessibility, store requirements and releases still require platform-specific work.

Do we still need a website if we build an app?

Usually yes. The website supports discovery, public information, help, trust, accessibility, legal content and users who have not installed the app.

How Emote can help

Emote helps organisations define digital journeys across responsive websites, web applications, portals and connected platform experiences. The team can assess how audience, task, content, identity, data and integration requirements shape the right delivery surface rather than beginning with an app label.

The guide to choosing the right website pathway is a useful companion when the delivery surface is still undecided.

Comparing a responsive site, PWA or app? Book a meeting with Emote to discuss the user job and technical constraints.