Mobile App vs Mobile Website: Which Do You Need?

By Cody Wise, founder of Wise Media, Calgary. Last updated 10 November 2026. Store fees and policy requirements below are quoted from Apple’s and Google’s own published pages as reviewed on this date. Both companies change them, so verify before you budget.

Summary

• Three conditions justify a native app: repeat signed in use, a genuine need for device hardware, and offline operation. One condition is usually not enough. Two is a real conversation. Three means build it.
• Apple’s App Store Review Guidelines say an app “should include features, content, and UI that elevate it beyond a repackaged website”, and guideline 4.2.2 states that other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links.
• Apple lists the Apple Developer Program at $99 annually and Google lists a one time US$25 Play Console registration fee. Those are the smallest numbers in the project and the only ones anyone remembers.
• Google Play personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers who stay opted in for 14 uninterrupted days before applying for production access.
• Apple states App Review typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours, and that over 40% of unresolved issues relate to guideline 2.1, App Completeness.
• A progressive web app covers more than most people assume, but on iOS a web app must be added to the Home Screen before it can request push permission, per Apple’s WebKit team.
• The real cost of an app is not the build. It is two codebases, two store relationships and a mandatory release cadence driven by someone else’s operating system schedule.

Table of contents

• What is the actual difference between a mobile site, a PWA and a native app?
• When does a mobile app actually earn its place?
• When an app is the wrong answer
• What does it cost to keep an app alive?
• How long does it take to get into the stores?
• Can a progressive web app do the job?
• The decision framework
• Common mistakes
• FAQ

What is the actual difference between a mobile site, a PWA and a native app?

Four things get called “an app” in sales conversations and they are not interchangeable. The difference that matters to a buyer is not the technology. It is who controls distribution, what it costs to keep running, and what the software is allowed to do on the device.

Notice what changes in the last column. A website is a relationship between you and your host. An app is a relationship between you, your host, Apple and Google, and the last two can change the rules, require a resubmission, or decline to publish. That is not an argument against apps. It is the actual thing you are buying, and it should be priced and staffed accordingly. If you are weighing this as part of a wider build versus buy question, we covered the general version of that decision in our guide to custom software versus off the shelf, and the delivery side of it sits in our app development work.

When does a mobile app actually earn its place?

Three conditions. Repeat signed in use, hardware dependence, and offline operation. Count how many apply to your actual users doing their actual job. One condition rarely justifies the overhead. Two makes it a genuine decision. Three means stop deliberating.

Condition one: repeat signed in use

The test is frequency plus identity, not traffic. A customer who signs in weekly to check a balance, book a slot, log a job or message a provider benefits from an icon on a home screen and a session that never expires. A customer who visits twice a year to compare prices does not, and will never install anything to do it.

Be honest about the number. Most service businesses in Canada see the same customer somewhere between once and four times a year. That is a website. Property managers, clinics with recurring appointments, trades crews with daily job assignments, and membership businesses with weekly bookings are different, and the pattern is always the same: the same person, signed in, more than monthly.

Condition two: hardware dependence

Does the job require something the browser cannot reach reliably? Background location tracking for a dispatch crew. Continuous Bluetooth connection to a device. Barcode scanning at volume with the screen off. Biometric unlock tied to a stored credential. Background sync that fires while the app is closed. These are real gaps, and they are the most defensible reason to leave the browser.

What is not a gap, despite being sold as one: taking a photo, using the camera for a one off scan, reading the user’s current location with permission, or storing a modest amount of data locally. The web does all of that. If your requirements document lists only those, it is describing a website.

Condition three: offline operation

This one is common in Canada and routinely underrated. A technician in a mechanical room, a crew on a rural site in Alberta, a cleaner in a concrete stairwell, an inspector in a basement. If the work happens where there is no signal and the data must be captured anyway and synced later, you are not having a website conversation. A progressive web app can cache and queue to a point. A native app with a local database and a conflict resolution strategy is the durable answer.

The scorecard

When an app is the wrong answer

Apple has written this down, which saves everyone an argument. The App Store Review Guidelines open guideline 4.2, Minimum Functionality, with this: “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. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted.”

Guideline 4.2.2 is more specific: “Other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.” Apple’s own App Review page lists “Web clippings, content aggregators, or link collections” and “Not enough lasting value” among the common reasons submissions do not pass.

Read that as a procurement filter rather than a policy detail. If the app you have been quoted is your website in a frame with a bottom tab bar, it is the exact thing the guideline describes. You can spend the build budget, pay the developer fees, and still not get listed.

The app builder trap

There is a second rule worth knowing before you sign with a platform that promises an app from your existing site. Guideline 4.2.6 states that apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content, and that such services should not submit apps on behalf of their clients. Apple describes an acceptable alternative for template providers: a single binary hosting all client content in an aggregated or picker model.

So if a vendor tells you they will publish your app under their own developer account, that arrangement is the one the guideline addresses directly. Ask who submits, under which account, and who holds the listing. The answer determines whether you own the distribution channel or rent it, which is the same question as who owns the code when you hire a developer in Canada, applied one layer further out.

Four requests that are websites in disguise

• “We want an app so customers can book.” Booking is a form. A fast mobile booking flow with no install step converts better than an app nobody downloads.
• “Our competitors have one.” Check its reviews and its last update date before you copy it. Abandoned apps are extremely common and they damage a brand more than having no app at all.
• “We want push notifications.” Legitimate, and the strongest of the weak reasons. See the PWA section below, because on iOS this is achievable without the stores under specific conditions.
• “We want to be on the App Store for credibility.” A listing with 40 downloads and a two year old last update is the opposite of credibility.

What does it cost to keep an app alive?

The store fees are trivial and everyone fixates on them. Apple’s developer page lists the Apple Developer Program as a $99 annual membership, and separately mentions the Apple Developer Enterprise Program at $299 per year for private distribution to employees. Google’s documentation states a one time US$25 registration fee for a Play Console account, not recurring. Apple’s page displays only a dollar sign without naming a currency code, so treat it as a figure to confirm at checkout rather than a converted CAD number.

The line nobody puts in the quote

A native app has a floor cost that exists even in a year when you add nothing. Operating systems ship annually. SDKs deprecate. Certificates and signing keys expire. A library you depend on stops being maintained. Each of those forces a release, each release goes through review, and each review can come back with a question. Budget for a maintenance retainer on an app the way you would on a vehicle, not the way you would on a logo.

That is the number to ask any app vendor for before you sign: what does year two cost if we ship no new features? If the answer is zero, the quote is incomplete. We take the same position on websites, where the recurring work is smaller but just as real, and it is why our website maintenance cost breakdown exists as its own page rather than a footnote. For the build side of the numbers, our custom web app cost guide for Canada covers how scope translates into hours.

How long does it take to get into the stores?

Review itself is fast. Getting eligible to be reviewed is the part that surprises people, and on Google Play it can add weeks before a single user sees the app.

Apple: review is usually days, not weeks

Apple states: “App Review works around the clock, typically reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours.” It also notes that if a submission is incomplete, review times may be delayed or the submission may not pass.

The useful detail from the same page is where submissions actually fail. Apple says that on average, over 40% of unresolved issues are related to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information. The listed common issues include crashes and bugs, broken links, placeholder content, incomplete App Review Information, privacy policy issues, unclear data access requests such as missing or vague purpose strings, inaccurate screenshots, substandard user interface, and submission by the incorrect entity.

Almost none of that is about your idea. It is about submission hygiene. A project plan that treats submission as a 30 minute task at the end is the reason first submissions bounce.

Google Play: the 12 tester rule

This is the requirement that derails Canadian small business app timelines most often, because nobody budgets for it. Google’s documentation states that personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers, and that those testers must stay opted in without interruption for 14 days. If a tester opts out and later rejoins, the 14 day clock starts over. Only after meeting those criteria can you apply for production access from the Play Console dashboard.

Google also requires identity verification at account setup, which may require a valid government ID and a credit card in your legal name, and states the registration fee is not refunded if the information is judged invalid. Separately, you must verify access to an Android device using the Play Console mobile app before publishing.

Practical consequence: recruiting and holding 12 real testers for 14 uninterrupted days is a project task with an owner and a deadline, not an afterthought. Start it the week the build enters beta, not the week you want to launch.

Who should own the developer accounts

You, under the business entity, with billing on a company card and the credentials in the company password manager. Not the agency, not the founder’s personal Apple ID, not a contractor. Three reasons, all of which we have watched play out. Apple’s guidelines reference submission by the incorrect entity as a common failure. Transferring a listing between accounts is possible but it is friction you do not want during a dispute. And an account tied to a departed employee’s personal credentials is a hostage situation waiting to happen.

Can a progressive web app do the job?

More often than the app industry likes to admit, and the gap narrowed meaningfully when Apple shipped Web Push for Home Screen web apps. Apple’s WebKit team states that “A web app that has been added to the Home Screen can request permission to receive push notifications”, that the permission request must come from direct user interaction such as tapping a subscribe button, and that the app needs a manifest with its display member set to standalone or fullscreen to become a Home Screen web app.

Two details from the same source matter commercially. You do not need to join the Apple Developer Program to use Web Push on iOS, and Home Screen web apps also get the Badging API for setting and clearing an icon badge count, plus Screen Wake Lock, Screen Orientation and User Activation APIs.

What you get, and what you give up

That last row is the real trade. A PWA that depends on push is depending on a user completing an install gesture that is not advertised anywhere in the operating system. If push is central to your product, you need an in product prompt that teaches the gesture, and you should measure completion of it. If you cannot get that number up, the store install is worth paying for.

The sequence that keeps the decision reversible

Build the mobile web experience properly first, as a PWA, with the manifest, offline caching and push in place. Launch it. Measure three things for a quarter: how many users add it to the home screen, how many enable push, and how many return weekly while signed in. Those three numbers answer the native app question with evidence instead of opinion, and nothing you build is wasted if the answer is yes, because the API layer and the product decisions carry straight over.

The reverse sequence, native first, costs more and tells you less. The same logic applies to the signup flow itself, which we unpacked in our post on what converts a trial signup. Instrument the thing, then decide.

The decision framework

Six steps, in order. Most projects stop at step three with a clear answer, which is the point.

1. Write down the job, in one sentence, from the user’s side. Not “we need an app”. Something like “a crew lead records a completed job on site, often with no signal, and dispatch sees it within the hour”. If you cannot write that sentence, no technology choice will save the project.
2. Score the three conditions. Repeat signed in use, hardware dependence, offline operation. Zero or one means build for the browser. Two means PWA first. Three means native.
3. Check your request against guideline 4.2. If your feature list describes marketing content, a link collection or your website in a frame, Apple’s own wording says it may not be accepted. Redesign the scope or build a website.
4. Price year two with no new features. Store fees, certificate renewals, OS release support, two codebases if fully native. If a vendor cannot give you this number, you do not have a quote.
5. Plan store eligibility as a work stream. Business entity developer accounts, identity verification, and on Google Play the 12 testers held for 14 uninterrupted days. Give it an owner and put it on the critical path.
6. Instrument the browser version first, even if you are confident. Home screen adds, push opt ins, weekly signed in returns. One quarter of real numbers is cheaper than a native build that nobody opens twice.

Common mistakes

• Budgeting the build and not the decade. The build is a one time cost. The store relationship, the OS cadence and the two codebases are permanent.
• Letting a vendor publish under their developer account. Apple’s guideline 4.2.6 speaks directly to template and generation services submitting on behalf of clients. Own the accounts.
• Discovering the 12 tester rule in launch week. It is 14 uninterrupted days after you have recruited 12 testers. That is a calendar problem, not a technical one.
• Treating submission as a formality. Apple reports that over 40% of unresolved issues relate to App Completeness: crashes, placeholder content, incomplete review information.
• Vague purpose strings. Unclear data access requests are on Apple’s own list of common issues. Write the permission explanations as product copy, not as a compliance chore.
• Shipping an app and leaving the mobile site slow. The overwhelming majority of first contacts still arrive through a browser from search or an ad. The app serves the people you already have.
• Counting downloads as success. The number that matters is weekly signed in returns. Downloads measure your marketing, not your product.
• Abandoning it. A listing last updated two years ago, with unanswered one star reviews, actively costs you trust. If you cannot commit to maintaining it, do not publish it.

FAQ

Will Apple reject an app that is just my website?

Apple’s guidelines say an app should include features, content and UI that elevate it beyond a repackaged website, and that if an app is not particularly useful, unique or app like, it does not belong on the App Store. Guideline 4.2.2 states that other than catalogs, apps should not primarily be marketing materials, advertisements, web clippings, content aggregators or a collection of links. Review outcomes are case by case, but a webview wrapper around a brochure site is the scenario those words describe.

How much does it cost to put an app on both stores?

The account fees are small: Apple lists the Apple Developer Program at $99 annually, and Google lists a one time US$25 Play Console registration fee. Those are published rates and should be confirmed at checkout, and Apple’s page does not name a currency code. The meaningful cost is the build plus a permanent maintenance commitment driven by annual operating system releases and SDK deprecations.

Can a PWA send push notifications on an iPhone?

Yes, with a condition. Apple’s WebKit team states that a web app which has been added to the Home Screen can request permission to receive push notifications, that the request must come from direct user interaction, and that the app needs a manifest with display set to standalone or fullscreen. You do not need to join the Apple Developer Program for this. The practical hurdle is getting users to complete Add to Home Screen.

How long does Google Play take to approve a new app?

Review time is not the constraint for a new personal developer account. Google’s documentation requires accounts created after 13 November 2023 to run a closed test with at least 12 testers who remain opted in for 14 uninterrupted days before applying for production access, with the clock restarting if a tester opts out and rejoins. Plan for that window on top of review, and confirm the current requirements for your account type.

Should we build cross platform or fully native?

Cross platform, unless you need earliest access to new operating system features, you are doing something graphically or computationally heavy, or you have in house specialists in both platforms. One codebase is one maintenance stream, and maintenance is where app budgets go. The honest cost of cross platform is a set of platform specific edge cases that still need native knowledge to resolve.

Our competitor has an app. Does that mean we need one?

Check its last update date and read the recent reviews before you treat it as a signal. Abandoned business apps are common, and a stale listing with unanswered complaints is worse for a brand than no listing. If the app is genuinely well maintained and well reviewed, that is worth understanding. If it was built once and left, you are looking at a cost your competitor regrets.

Who should own the Apple and Google developer accounts?

Your business entity, with company billing and credentials in the company password manager. Apple’s own list of common submission issues includes submission by the incorrect entity. An account held by an agency, a contractor or a departed employee’s personal ID is a dependency you will eventually have to unwind, usually at the least convenient moment.

What if we only want an app for internal staff?

Then the public stores may be the wrong channel entirely. Apple mentions the Apple Developer Enterprise Program at $299 per year for private distribution to employees, and a PWA is often the simplest answer for an internal tool because you control distribution with a link and a bookmark. Internal tools are also the case where offline operation most often decides it.

The short version

Score the three conditions honestly. Repeat signed in use, hardware dependence, offline operation. If you score zero or one, build a fast mobile website and spend the difference on getting people to it. If you score two, build the progressive web app, instrument it, and let a quarter of real numbers make the native decision for you. If you score three, build native, own the developer accounts under your business, and put store eligibility on the critical path from day one.

The expensive mistake is not choosing wrong. It is choosing before anyone has written down, in one sentence, what the user is actually trying to do.

Get a straight answer on your case

We build mobile web experiences and native apps for Canadian operators, and we will tell you when you do not need the second one. If you are weighing an app against a better mobile site, send us the details through our intake form and we will score it against the framework above and come back with a scope and a year two number.

Sources

• Apple, App Store Review Guidelines, guideline 4.2 Minimum Functionality
• Apple, App Review, review times and common issues
• Apple Developer Program, membership and pricing
• Google Play Console Help, registration fee and identity verification
• Google Play Console Help, app testing requirements for personal developer accounts
• WebKit, Web Push for Web Apps on iOS and iPadOS