Native app, mobile web, or PWA: choosing for resident services

Reference article · 5 min read

An elected official asks why the agency does not have an app. The question sounds simple, and the honest answer is not. In everyday use, an app means an icon on a phone's home screen, and there are three ways to put one there: a native application distributed through the Apple App Store and Google Play, a responsive website, or a progressive web application, which is an installable website.

The decision turns on how often residents use the service, which device capabilities it genuinely needs, and what the agency can maintain for the life of the system. The tradeoffs below are stated so they can be repeated in a council or board meeting.

The three options, stated plainly

• Responsive website. One codebase, delivered through the browser. No install, no store, no review queue. Changes are live when the agency publishes them.
• Progressive web application. The same website plus a service worker and a manifest, so residents can install it to the home screen, it can cache content for offline use, and it can receive push notifications in most environments.
• Native application. Separate iOS and Android applications, built with platform tools or a cross platform framework and distributed through the stores. Full access to device capabilities, and full exposure to store rules.

What the web can and cannot do

Browser capabilities have moved, and assumptions from a few years ago no longer hold. Specifics change with each browser and operating system release, so confirm current behavior before writing requirements around them.

• Camera. A web page can let a resident take or upload a photo and can read a live camera stream to scan a barcode. It generally cannot capture while the browser is closed.
• Location. Browsers provide location when the page is open and the resident consents. Continuous background location and geofenced alerts remain native territory.
• Push notifications. Web push is supported by the major browsers. On iOS, the resident must first add the site to the home screen. Permission prompts and delivery behavior differ by platform.
• Offline use. A service worker can cache pages and queue a form submitted without a connection. Storage is limited and can be cleared by the operating system, so it is a poor fit for a crew offline all day with large data sets.
• Hardware and background work. Bluetooth peripherals, NFC, background sync, and deep operating system integration favor native.

A workable test: if the service must do something while the resident is not looking at the screen, native is probably required.

The costs that do not appear in the proposal

• Two codebases, indefinitely. Cross platform frameworks reduce duplication but do not eliminate platform specific work, and they add a framework the agency must keep current.
• Store review. Every release waits in a queue, and rejections happen for reasons unrelated to the agency's requirements. Both stores expect government apps to be published by the government entity itself rather than by a contractor.
• Account and key ownership. Developer accounts, certificates, and signing keys are the app's identity. If a vendor holds them, the agency cannot publish an update or change vendors without a difficult recovery. Both stores charge for developer enrollment; confirm current terms with each program.
• Forced maintenance. Operating systems ship annually and stores enforce minimum API targets, so an app needs work every year even when it gains no features. An app that stops being updated eventually stops being distributed.
• Download friction. A resident who needs a service twice a year will not keep an app installed for it. Each use begins with a search, a download, and often a password reset. A link in a utility bill or a text message opens a website immediately.
• Accessibility either way. The Department of Justice rule under Title II of the Americans with Disabilities Act sets a WCAG based technical standard for state and local government web content and mobile applications, with compliance dates phased by entity size. Native apps are covered, not exempt. Confirm current requirements with counsel.

A defensible way to answer the question

Lead with the service, not the format. Most resident services are transactions completed a few times a year: pay a bill, report a pothole, apply for a permit, check a case status. Those belong on a responsive website, with a progressive web application layer where push notifications or offline entry add real value.

Reserve native for a genuine platform requirement. Honest examples include field inspection tools that must work offline all day, transit and parking applications that need background location or Bluetooth beacons, and public safety applications that require background alerting. One more point carries well in public: an app the agency cannot maintain is worse than no app.

What to ask vendors and what to require in the contract

1. Ask for the same feature list priced as a progressive web application. If the vendor cannot name what specifically fails without native code, the requirement is preference rather than necessity.
2. Ask what maintenance costs each year after launch, in a year with no new features.
3. Ask which parts are shared across platforms and which are duplicated.

In the contract, require that developer and store accounts are created in the agency's name with agency administrators, that signing keys and certificates are delivered to the agency, and that source code, build instructions, and deployment configuration belong to the agency. Require an accessibility conformance report for each platform and a defined transition of the published listings at the end of the term. State who owns analytics and push subscriber data, and confirm the records treatment of both with your records officer.

HQT builds resident facing digital services for public agencies across web, progressive web, and native applications.

Frequently asked questions