Why We Chose PWA Over a Native App

Early on, we had the same conversation every product team has at some point: our users are out in the field, on their phones, standing in supermarket receiving bays. Should we build a native app?

We looked at the tradeoffs carefully. In the end, the answer was no. This is why.

The update problem

The deciding factor for us was update distribution.

With a native app, the user keeps whatever version they last installed until they update it. If we fix a bug today, that fix does not reach every driver today. It reaches them when they notice the update, open the store, and install it, which might be later that week, or much later, or not at all.

For a logistics product, that matters more than it might for a consumer app. The driver's record is not just a convenience feature. It is the source of truth for what was delivered, what was returned, and what paperwork needs to follow. If there is a bug in that flow, we need the fix in the driver's hands immediately.

With a PWA, the next time they open the app, they are on the current version. No store approval cycle. No waiting for the user to do maintenance. No gap between shipping a fix and having it in the field.

The other tradeoffs

There are genuine advantages to native apps. They can reach deeper device capabilities, and on some interactions they feel a little more polished.

But the tradeoff on our side was hard to ignore: separate iOS and Android builds, store review delays, more maintenance overhead, and a slower path from bug fix to real user.

For what wallmarkets actually needs to do - log deliveries, confirm completions, process returns, surface dashboards - the web platform is fast enough. We do not depend on device features that would force us into a native build. And the experience is consistent enough across iPhone and Android that the operational benefit of one current codebase outweighed the cosmetic benefit of separate apps.

What we did not want to fake

One trap in mobile product decisions is pretending the installed experience matters only at launch. It does not. It matters in the moment of use.

A driver at a receiving bay does not care whether the software was shipped through an app store or the web. They care whether it opens fast, whether the right delivery is there, whether the data is current, and whether they can finish the job without friction.

We did not want to build a native shell just to perform "app-ness" while still fighting slower update distribution underneath it. That would have optimized for the demo, not for the workflow.

What field use confirmed

The obvious concern with a web-based tool is friction. A driver standing at a receiving bay does not want to type a URL or fight with browser tabs. They want to tap once and land in the right place.

That is what the installed PWA gives them. It lives on the home screen. There is no URL bar. No browser chrome. To the person using it in the middle of a working day, the difference between a native app and an installed PWA is close to invisible.

What is not invisible is the update model. When we ship a fix, they get it on the next open. That matters more than an extra layer of native polish.

Offline is useful, but only in the right places

Another reason people reach for native is the assumption that offline support will automatically be better.

Offline support is not a checkbox. It is a product decision about what can safely happen without the server.

For wallmarkets, we are comfortable caching the app shell, previously visited pages, and data that is safe to read later. We are much more cautious about pretending a delivery completion or a return submission can always be handled offline with no operational consequences. In logistics software, fake confidence is worse than an honest limitation.

So we chose the more defensible path: make the installed experience fast, resilient, and useful in poor connectivity, while being explicit about which actions still need a live connection.

One release train matters more than two app stores

There is also a smaller-team reality here that is worth saying plainly.

Every additional platform is not just more code. It is more release coordination, more QA surface area, more build maintenance, and more room for one platform to drift behind the other.

With one codebase, one release train, and one installable experience, the product team can spend more of its time improving the workflow itself instead of managing distribution mechanics.

For an engineering-first company, that matters. We would rather invest effort in cleaner delivery flows, better return handling, faster dashboards, and more reliable field behavior than in maintaining separate native shells that do not solve the hardest part of the product.

How to install

iPhone: Safari -> share icon -> "Add to Home Screen."

Android: Chrome -> three-dot menu -> "Add to Home Screen" or "Install App."

Desktop: Chrome or Edge shows an install icon in the address bar on the right side. Opens in its own window, no browser chrome.

Once installed, wallmarkets behaves like any other app on the device: one tap from the home screen, full screen, immediate access. The help article on PWA installation walks through the setup on each platform.