Native app or PWA: what does your business need?
Meypi Developers · Updated on
Choosing a native app or PWA starts with what the person using it must be able to do. An installable web app can fit a journey that works in the browser; a mobile app is worth investigating when that journey cannot meet a requirement. At Meypi Developers, a software studio in the Barcelona metropolitan area, we suggest deciding with a task list and a test of the hardest requirement.
1. What you are comparing
A website opens through a link. A PWA is an installable web app that can be added to a device and opened from its icon. A native app is built for a platform; a cross-platform project shares part of its development across platforms. These names describe the solution, but they do not establish whether it meets your business needs.
PWA installation varies by browser and operating system. MDN’s installation guide sets out those differences. An icon on a phone does not, by itself, demonstrate offline use or support for a particular feature.
2. A starting point for the decision
| Your need | First option to investigate | Test it must pass |
|---|---|---|
| Publish information and receive enquiries | Mobile-friendly website | Open a link, read and contact the business without installing anything. |
| Book or check an account regularly | Installable web app or mobile app, depending on requirements | Complete the task on the devices your audience uses. |
| Work without a connection | Either option if it implements the journey | Save offline and reconnect without losing or duplicating work. |
| Use a particular phone feature | Compare that exact feature in both options | Try it with permission granted, refused and withdrawn. |
| Be available through app stores | App project with distribution defined | Agree who owns the accounts and what will be published. |
This table is Meypi’s proposed decision framework, not a rule that makes one technology the winner. If several options pass the tests, compare their development and maintenance costs.
3. Write requirements as tasks
- Who signs in: an occasional customer, a member returning each week or a team working throughout the day.
- What they must finish: book an appointment, read a document, record a visit or pay.
- What happens offline: what can be read or saved, and when confirmation appears.
- Which notifications matter: what they are for and what happens if permission is refused or a message is missed.
- Which devices are used: phones, computers, versions and usual browsers.
- What connects to it: which program owns the record and who handles an interrupted connection.
For example, “record a visit in an area without coverage and send it once when the connection returns” gives you a testable requirement. “Make it like an app” does not yet say what to check. This is an illustrative requirement, not a client project.
4. Installation, notifications and offline work are separate decisions
Offline use requires decisions about what is stored and how it is synchronised. MDN describes offline and background operation. Test the complete journey, including what people see when something has not yet been sent.
For iPhone and iPad, WebKit documents web notifications for apps added to the Home Screen from iOS and iPadOS 16.4, with permission requested following a user action.WebKit’s Web Push conditions. Set the target devices and permission journey before quoting for notifications.
5. Two journeys to test the decision
Our mobile app development page illustrates a class notification and an offline test. Here we use them to prepare requirements; they are not presented as two clients or fresh compatibility tests.
- A class notification.: A member allows notifications, receives one and opens the right class. Ask to test what happens when permission is refused and how they check the activity another way. A notification entry in a feature list does not resolve those steps.
- A test on the metro.: A learner answers offline, closes the app and recovers their work. When the connection returns, check the saved progress and that a retry does not duplicate it. The choice remains subject to this test on the agreed devices.
6. Ask for a test of the requirement that could change the choice
Before building every screen, choose the requirement that might rule out an option. Prepare a small journey: sign in, finish the task, check the record and recover from a failure. Base the decision on that result as well as the feature list.
- Repeat the task on the agreed phones and browsers.
- Try a weak connection and reopen the application.
- Check what happens when permission is refused and how to continue.
- Verify the result in the program that keeps the record.
- Record what works, what is missing and what would require another option.
7. What to compare in a quote
Compare the same first version with the same acceptance checks. Separate design, features, integrations, distribution, maintenance and incident support. An installable web app does not deliver a fixed saving over a mobile app: it depends on what must be built and maintained.
Our app development cost guide explains the factors in a quote. For the stages of a project, read how an app is developed.
8. What to bring to a project discussion
Bring three essential tasks, the devices your audience uses and the programs that need to connect. If there is an existing website or app, add what should be kept and what is failing today. This helps define the first version and decide what needs a practical trial.
To discuss the work, see our mobile app development service or tell us what your business needs.
Keep reading
- Mobile app development
Commissioning an app for your customers or team.
- App development cost
What affects development and maintenance costs.
- Custom web design
When the customer journey starts with your business website.
Tell us what you need
What you want to build, by when and with what budget.