Mobile app, progressive web app or website? Choosing the right option for SA organisations

When a South Australian small business, not-for-profit or council decides customers or staff need something better on their phones, the first question is usually “should we build an app?” Often the honest answer is “not yet”. A fast, mobile-friendly website or a progressive web app (PWA) can do much of what people expect from an app. It costs less to build and maintain, and nobody has to download anything. Sometimes a native or cross-platform app really is the right tool, especially for field staff, offline work or deep device features. This guide compares the options in plain English so you can brief a developer and compare quotes on a like-for-like basis. It is general guidance; app store rules and browser features change, so check current details before you commit.

The four options at a glance

• Mobile-friendly (responsive) website: one website that adapts to phones, tablets, foldables and desktops. Found through Google, shared by link, updated instantly.
• Progressive web app (PWA): a website with extra capabilities. People can add it to their home screen, it opens full screen like an app, it can keep working with a weak or missing connection, and it can send notifications on supported devices. It is still delivered over the web, with no app store review.
• Cross-platform app: one codebase, built with a framework such as Flutter or React Native, that produces real iOS and Android apps distributed through the App Store and Google Play.
• Native apps: separate apps written for each platform, Swift and SwiftUI for iPhone and iPad and Kotlin for Android, with full access to device features and the most platform-like feel.

Start with who will use it and how often

The most useful question is not about technology. It is how often people will use the thing and what they need it to do.

• Occasional, one-off tasks, such as paying a rate notice, booking a service, reporting a pothole or making an enquiry. Most people will not download an app for something they do a few times a year. A fast website with good forms and payments usually wins. Our guide to online forms and payments covers that side in detail.
• Regular customers or members who come back weekly, such as bookings, loyalty, orders or member portals. A PWA they can add to their home screen often gives an app-like experience without the store overheads. A store app becomes worth it when you need features the web cannot reliably provide.
• Your own staff, such as inspectors, carers, drivers and field crews. Because you can install the app on managed devices, store discovery does not matter, and offline work, camera, barcode scanning and location usually do. A cross-platform or native app, or a well-built PWA on managed devices, is often justified here.

What the web can do now, and where it still falls short

Modern browsers can do far more than many people realise. A well-built website or PWA can:

• Work offline or on a patchy regional connection, using a service worker to cache pages and store drafts on the device until the connection returns.
• Use the camera for photos and document uploads, share location with permission and support sign-in with passkeys, using Face ID, Touch ID or Windows Hello in place of passwords.
• Be added to the home screen on iPhone, iPad and Android and open full screen without browser bars.
• Send web push notifications on Android and desktop, and on iPhone and iPad (iOS and iPadOS 16.4 or later) once the user has added the web app to their home screen and agreed to notifications.

The gaps that still push projects towards a store app are mainly on iPhone: no Bluetooth or NFC access from the web, limited background tasks, and notifications only after the user adds the app to their home screen. Store apps also suit experiences that need sustained background location, heavy offline data, tight integration with device hardware or a presence in the App Store and Google Play because customers expect to find you there.

What a store app adds to the job

An app in the App Store or Google Play brings real benefits, such as an icon on the phone and reliable notifications, but it also brings work that a website does not:

• Developer accounts in your organisation’s name. Apple and Google both verify organisation accounts, usually with a D-U-N-S number, which can take time to arrange. Set them up under your organisation, not a developer’s personal account, for the same reasons covered in our domain, DNS and admin account ownership checklist. Google Play also requires new personal developer accounts to run a closed test with at least 12 testers for 14 days before an app can be published.
• Store review. Every release is reviewed. Apple’s guidelines reject apps that are little more than a repackaged website, so an app needs to offer something the website does not.
• Privacy declarations. Both stores ask you to declare what data the app collects and how it is used: Apple’s privacy details and Google Play’s Data safety section. These must match your privacy policy and what the app actually does. Apps that let people create an account must also let them delete it.
• Yearly upkeep. New iOS and Android versions arrive every year, Google Play requires apps to target a recent Android version, and Apple periodically raises its minimum software development kit (SDK) requirements. An app that is not updated can be hidden from new users or stop working properly, so plan for ongoing maintenance from day one.
• Getting people to install it. A store listing does not bring users by itself. You will still need your website, email and printed material to point people to it.

Cross-platform or native?

If a store app is the right choice, the next decision is how to build it.

• Cross-platform (Flutter or React Native) suits most business and council apps: forms, lists, bookings, photos, maps and offline sync. One codebase means one team and one set of tests, and both frameworks produce real store apps.
• Native (Swift, SwiftUI and Kotlin) suits apps that depend on the newest platform features, heavy background processing, Bluetooth hardware, complex animation or the most platform-like accessibility and feel.
• Mini-apps inside an existing app. If you already have an app, new features such as a calculator, form or chatbot can sometimes run inside it as a secure web view or mini-app, so you can update them without a store release for every change.

Requirements that apply whichever option you choose

• Accessibility. WCAG 2.2 AA is the usual target for websites and is applied to mobile apps too. Test with VoiceOver on iPhone and TalkBack on Android, larger text sizes and both portrait and landscape. Our guide to WCAG 2.2 for SA Government and council websites explains the criteria.
• Privacy and security. Collect only what you need, store personal information in Australian regions where you can, and keep tokens and offline data encrypted on the device. For an app with logins, payments or personal information, a short threat modelling session before build is worth the time.
• Payments. Use your payment provider’s hosted fields or payment sheets so card numbers never touch your systems. Apple and Google have their own rules for digital goods sold inside apps, so check them early if you sell subscriptions or digital content.
• Integration. Most of the value comes from connecting to the systems you already run, such as your CRM, booking system, finance package or council property and rating system, through secure APIs rather than re-keying.
• Testing. Test on the mid-range phones and tablets your users actually have, on slow connections, and with real tasks during user acceptance testing.

A simple way to decide

1. List the top five tasks people need to do on a phone and how often they do them.
2. Mark any task that needs Bluetooth or NFC, sustained background location, large offline data sets or a store listing. If none do, start with a mobile-friendly website or PWA.
3. Check your current website on a phone. If it is slow or awkward, fixing it may deliver more than a new app. Our guide to website speed and Core Web Vitals shows what to look for.
4. Decide who will look after it after launch: updates, store renewals, privacy declarations and support.
5. Write a short brief with the tasks, users, devices, integrations and must-haves, and ask suppliers to quote against it. Our guide to writing a software or website project brief has a template.

If you are weighing an app against an off-the-shelf product, see custom software vs SaaS as well.

How EITSAA can help

EITSAA builds responsive websites, PWAs, cross-platform apps in Flutter and React Native, and native iOS and Android apps, so we can recommend the option that suits your users rather than the one we happen to sell. Every project is quoted to its scope, and many start with a short discovery that confirms which approach fits before any build begins. Get a quote for your app or portal or call 0402 401 584, Monday to Friday, 9am to 5:30pm. See our application development and website design and development services.