Most companies asking for a mobile app are describing a website they want to feel better on a phone. That is a real problem, and it is rarely a native app problem. Native earns its place when a requirement genuinely exceeds the browser: background work, hardware access, offline-first operation, or the store as a sales channel. Everything else is fashion, and native charges rent forever.
What actually forces a native app?
The list is shorter than most roadmaps assume. Four requirements survive scrutiny.
Work that continues when nobody is looking at the screen. If the product has to report a driver's position while the app is closed and the screen is off, or keep recording a workout in a pocket, you are asking the operating system for a capability it gates behind explicit background permissions. That is a native conversation. It is also the one to verify against the platform's own documentation before committing, because this is exactly the class of claim that ages badly.
Push you can actually rely on. This is where most of the confusion lives, so be precise about it. Web push does exist on iPhone. WebKit shipped it for Home Screen web apps in iOS and iPadOS 16.4, announced on February 16, 2023, and the requirement was explicit: a web app that has been added to the Home Screen can request permission, and the request has to come from direct user interaction. Apple later loosened the install step itself. In the Safari 26.0 release notes published September 15, 2025, WebKit stated that "there are now zero requirements for 'installability' in Safari," and that on iOS 26 and iPadOS 26, every website added to the Home Screen opens as a web app by default.
Read those two facts together and the business question sharpens. Web push on iPhone is not blocked. It is gated behind the user choosing to add your site to their Home Screen. If push is a convenience, that gate is fine. If push is the product, meaning the delivery ETA, the shift alert, the price trigger, then you have put a conversion funnel you do not control in front of your core feature. That is a legitimate reason to go native.
Hardware and sensors past the shallow end. Camera capture and basic geolocation are ordinary web features. Sustained sensor access, tight Bluetooth pairing, or platform payment and wallet integration is where the browser stops being the cheap option.
Offline as an operating condition, not a nicety. A service worker caching your pages so a tunnel does not break the session is normal web work. A field technician who works a full shift with no signal, writes records the whole time, and reconciles conflicts on reconnect is a different engineering problem, and the honest version of it is usually native.
What a responsive web app already does
Almost everything else. A well-built responsive web app or PWA handles the phone layout, installs to the Home Screen, works offline for reads, sends push on both major platforms subject to the install gate above, and ships to every user the moment you deploy. No review queue, no version fragmentation, no two codebases. The reason this keeps getting underrated is that "app" has become a synonym for "good mobile experience," and those are not the same purchase.
What does shipping native actually cost after launch?
The build is the part everyone budgets. The tax afterward is the part that surprises people.
Review is cheap at the median and expensive in the tail. Apple's App Review page states that "on average, 90% of submissions are reviewed in less than 24 hours." That number is genuinely good, and it is also the wrong number to plan against. The cost is not the average wait. It is that the one-line fix you could push to the web in twenty minutes now enters a queue you do not own, on a day you do not choose, and the 10 percent that is not fast is disproportionately the submission that matters.
The platform bills you annually whether or not you shipped a feature. Apple's Upcoming Requirements page is explicit: since April 28, 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26, or watchOS 26. Apple runs this on a schedule, roughly every April. That is recurring engineering work that produces zero new customer value and cannot be deferred, because the alternative is losing the ability to ship updates at all.
Two codebases, or one codebase and a framework bet. Cross-platform tools like Flutter and React Native make this survivable rather than free. You still carry an OS version support matrix, two sets of store rules, two release trains, and a dependency on a framework's own upgrade cadence.
None of that argues against native. It argues that native is a subscription, not a purchase, and the requirement had better be worth the rent.
Does the app store count as a reason to go native?
Sometimes, and the App Store Review Guidelines answer the question themselves. Guideline 4.2 on Minimum Functionality reads: "Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store." Guideline 4.2.2 adds that "other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."
That is the whole argument in Apple's own words. If your only reason to build an app is distribution, and the app is your website in a shell, the rule that rejects you is the same rule that answers your question. Store distribution is a real channel when the app does something app-like. It is not a way to acquire customers for a brochure.
When we chose native, and why
Local Living Project is a Flutter app, and the reasons were requirements, not preference. It is a marketplace for local vendors including farmers, food producers, restaurants, bakers, and artisans, with card payments through Stripe and EBT checkout through a Forage-oriented architecture. It carries vendor onboarding, inventory, fulfillment, earnings, admin review, notifications, accessibility controls, and multilingual settings, and a later milestone adds server-controlled last-mile delivery.
Payment rails and last-mile fulfillment on a phone, in the customer's hand, at the moment of purchase, is a genuine mobile requirement. Notice also what stayed off the device: the delivery workflow is deliberately server-controlled, so routing, status, and fulfillment rules are managed centrally instead of hard-coded into a client that needs a store review to change. That is the pattern worth stealing. Put as little as possible behind the release queue.
A sequence that works
- Write down the requirement in plain language, not the artifact. "Drivers must be trackable while the app is closed" is a requirement. "We need an app" is not.
- Test each requirement against the browser, using the platform's current documentation rather than a blog post or your memory of one. This surface moves.
- If nothing survives, build the responsive web app and stop. This is the common outcome.
- If something survives, ask whether it needs the whole product to be native or only one workflow. Often it is one.
- If you ship native, keep every rule you can on the server, so a policy change is a deploy and not a resubmission.
- Budget the yearly SDK upgrade before you start, not the April you get blocked. The decision is not about ambition or how modern the company looks. It is about whether a specific requirement exceeds a specific browser, and whether that requirement is worth paying rent on for as long as the product exists. Commerce Beacon makes this call the same way it approaches SaaS platform development generally: start with the operating constraint, choose the smallest system that satisfies it, and refuse to buy capability you cannot name a reason for. It is the same lens as deciding between custom software and more SaaS tools, and the same reasoning that put Local Living Project on Flutter while keeping its delivery logic on the server.
Common questions
Can a web app send push notifications on an iPhone?
Yes, with one condition. WebKit added Web Push for Home Screen web apps in iOS and iPadOS 16.4, and the permission request must follow direct user interaction. The user has to add your site to their Home Screen first. As of the Safari 26.0 release notes, iOS 26 removed the old installability requirements and opens any added site as a web app by default, which lowers that bar but does not remove it.
Is a PWA just a cheaper version of a real app?
No. It is a different distribution model. A PWA ships instantly, updates without a review queue, and runs one codebase. It trades away background execution, deep hardware access, and store placement. If you do not need those three things, the trade is in your favor.