Should Your SaaS Have a Mobile App in 2026?

A property owner opens their phone at 6am, before coffee, to see whether anyone booked the studio overnight. That is a mobile moment. A finance lead reconciling four hundred invoice lines against a bank export is not one, and no amount of responsive CSS will turn it into one.

Most teams ask whether their SaaS should have a mobile app. Wrong question. It skips the only variable that decides the answer: whether your product has a moment that happens away from a desk and resolves in under a minute. Name that moment and you have a case. Reach instead for "our competitor shipped one" and you have a roadmap card that will eat a quarter and finish with four hundred downloads.

Does your SaaS need a mobile app at all?

Your SaaS needs a mobile app only if there is a recurring task your customers must do away from a desk that resolves in under a minute. Everything else is a website that works on a phone.

Run the test properly. Open your analytics, filter to sessions from mobile devices over the last ninety days, and read what those people actually did. Not what they might do. What they did. In most B2B SaaS tools the answer is a depressingly short list: check a status, approve something, read a notification, look up one record before walking into a meeting. Four verbs. If your list looks like that, you do not need an app that mirrors your dashboard. You need four screens.

The inverse failure is more common than teams admit. You rebuild the desktop navigation on a 390-pixel viewport, ship it, and discover that the handful of people who installed it open it for nine seconds a week to check the same one number. That number could have been a push notification.

Where the test comes back clearly yes: field work, scheduling, anything with a physical location attached, anything where the user's hands are busy and their phone is the only computer within reach. Those products are not edge cases. They are just a minority of the SaaS market, and the majority keeps building apps as if it belonged to them.

PWA or native: which one does a SaaS companion need?

A progressive web app covers most companion use cases, with one hard exception: push notifications on iOS, which only work after the user adds the app to their Home Screen. That single constraint decides more of these projects than any performance benchmark.

Web push landed on iOS in 16.4, released March 2023, and it genuinely works. Apple's WebKit team documented it as standard Push API, Notifications API and service workers, so an implementation you already ship on Android ports over with feature detection. The catch sits in the same post. It applies to Home Screen web apps, meaning sites the user added through the Share menu with a manifest that sets display to standalone or fullscreen. A browser tab cannot receive a push on iOS whether or not permission was granted.

So how many of your users will complete a Share-sheet flow that has no install prompt behind it? Apple has an opinion on that. When it announced it would drop Home Screen web apps in the EU ahead of iOS 17.4, the stated reasoning included "the very low user adoption of Home Screen web apps". Apple reversed the removal on 1 March 2024 after a public backlash, so the capability survived. The assessment of adoption was never walked back.

Read that as a cost ladder rather than a feature ladder. Every step to the right buys capability and charges you release velocity.

What does the App Store review tax actually cost?

Shipping to the App Store attaches a review dependency to every release you will ever make, plus a rejection risk that got sharper this year for thin companion apps. It never appears in a build estimate.

Apple's guideline 4.2 has said for years that an app needs to offer something beyond a repackaged website, and that an app which is not particularly useful, unique, or "app-like" does not belong on the store. A companion that renders your existing web dashboard inside a WebView is exactly the shape that rule was written to catch.

Then, on 9 June 2026, Apple rewrote guideline 4.3(b). It now opens with "Don't submit apps that are indistinguishable from what's already widely available," and it carries a clause worth reading twice: "We may remove these apps from the App Store going forward if they are not updated, improved, or do not attract customers." That is no longer only a submission filter. An app you shipped two years ago, that nobody downloads, is now a candidate for delisting.

Google's side is cheaper to enter and slower to start. A personal Play Console account created after 13 November 2023 has to run a closed test with at least twelve testers opted in continuously for fourteen days before it can even apply for production access, and Google takes around seven days to review that application. Twelve real humans, on Android devices, before your first public release. For a two-person team, sourcing them is the actual bottleneck, not the code.

What does a mobile companion cost after launch?

A mobile companion costs you a second release train that runs at a different speed from your web deploys, permanently, and carries its own failure modes. The build is the cheap part.

Two OS versions a year, each with deprecations. Certificate and provisioning renewals that expire on a schedule nobody remembers. A forced minimum-SDK bump when Google raises the target API level. Crash reporting that lives outside your web observability stack, so an incident now has two dashboards.

And the version-skew problem, which is the one that actually hurts. A second client breaks one of the quiet structural advantages of the SaaS delivery model: every customer on the same version, all the time. Your web app is always the latest build. Your mobile users are on whatever they last updated to, which means your API has to stay backwards compatible with a client you cannot force-upgrade.

If your team is React on the web, the honest question is not Flutter against React Native in the abstract, it is how much logic genuinely travels. Business logic and API clients share well between React and React Native through a workspace package. UI does not, and anyone telling you otherwise has not maintained both. Flutter buys you one codebase across mobile and web at the price of maintaining Dart models alongside your TypeScript ones. If you are weighing the low-code route on top of that, the trade-offs between FlutterFlow and hand-written Flutter change the maintenance math again, and the Flutter tooling worth standardising on is a shorter list than the ecosystem suggests.

How this played out on BookBed

BookBed passed the test on the first question, which is why it went to both stores. Property owners check tomorrow's arrivals before they leave the house, and block a date while standing in the doorway of the unit. Both take under a minute. Both happen with no laptop in the room. So BookBed ships as a Flutter app on Firebase, live on the App Store and Google Play, with Cloud Messaging carrying the notifications.

The decision that saved me was not the framework. It was scoping the mobile surface down to the timeline calendar and the booking actions, and leaving everything administrative on web only: Stripe subscription management, email template configuration, widget embed setup. One screen family on mobile. Everything else lives where people have a keyboard.

Actually, "saved" undersells the cost of the part I did not scope away. A product priced at €9 per month for up to twenty units now carries a 99 USD annual Apple Developer Program membership before a single subscriber pays anything. At real scale that is rounding. At ten customers it is a visible slice of revenue. Price it in at the start rather than discovering it at the first renewal notice.

If the answer is yes, build it in this order

1. Instrument before you design. Tag every mobile-web session with the top task completed, and let it run for four weeks. If no single task clears a third of mobile sessions, stop at step one and save the quarter.
2. Ship the progressive web app first. Manifest, service worker, an install prompt on Android, a plain-language explainer for the Share-sheet flow on iOS. This takes days, not months, and it answers the demand question with real users instead of a survey.
3. Measure install intent honestly. Count how many iOS users complete Add to Home Screen without being nagged into it. That number is your realistic native install ceiling, and it is almost always lower than the room expects.
4. Register the store accounts early. Apple enrollment and Google identity verification both take longer than your plan assumes, and the twelve-tester clock cannot start until the Play account exists.
5. Scope version one to four screens. The moment you identified, authentication, one list, one settings page. Nothing else ships in the first release.
6. Wire push notifications before polish. Notifications are the reason the app earns a slot on a home screen. Without them in release one, you have shipped a bookmark with an icon.

If the answer is no

Say so publicly, in your changelog, with the reasoning attached. "We are not building a mobile app, here is the mobile web experience, and here is how to add it to your Home Screen" is a better answer to a sales objection than a roadmap card that never moves. People ask for the app because they want the moment solved. Solve the moment.

Open your analytics tomorrow morning, filter to mobile sessions from the last ninety days, and write down the single most common completed task. One line. If the line stays empty, you have your answer and you just reclaimed a quarter of engineering time. If you can fill it, ask the harder version of the question: is that a screen, or is that a notification?