September 16, 2026
September 16, 2026
Most guides on this topic are published by companies that sell website-to-app conversion tools. That shapes what they tell you, and what they leave out. This one is written by a software development team, so it covers the route where you build nothing at all, and the reason a meaningful share of converted apps never reach the store.
Start with the number that governs the whole decision. Apple reviewed roughly 9.1 million app submissions in 2025 and rejected more than 2 million of them. Repackaged websites are one of the named categories in the rejection criteria, and Apple states the rule plainly in its published guidelines.
Here is the short version. There are four routes from website to app: a progressive web app, a WebView wrapper, a hybrid framework rebuild, and a full native rebuild. They differ by a factor of roughly thirty in cost and by a factor of ten in time. The cheapest route carries the highest risk of App Store rejection, and the most common mistake is choosing a route before deciding what the app is actually for.
An app is not a distribution channel. It is a retention channel. People do not discover you through the App Store the way they discover you through search, and installing an app is a much larger commitment than visiting a page.
That distinction determines whether conversion makes sense. An app earns its cost when you have users who return often, and it wastes your money when your traffic is mostly first-time visitors who transact once and leave.
Three signals suggest an app will pay for itself:
Repeat usage. Your analytics show a meaningful cohort returning weekly or more. Order tracking, account dashboards, booking systems, internal tools and staff-facing platforms fit this pattern.
A capability the web cannot deliver. Reliable push notifications, offline operation, camera or barcode scanning, background location, biometric login, or integration with device hardware.
A commercial reason to own the home screen. You are competing for attention against alternatives, and an icon on the device is a durable advantage.
If none of the three applies, the honest answer is that a faster, better mobile website will outperform an app for less money. That is a real option, and our web application development work often ends there rather than in an app store.
A progressive web app is your existing website with a service worker, a manifest file and an offline strategy added. Users add it to the home screen from the browser. There is no app store, no review process and no store fee.
This is the cheapest route by a wide margin because you are enhancing what you already have rather than building a second product. It suits content sites, internal tools and any case where you control the audience and can tell them how to install.
Its weakness is distribution, and on iOS that weakness is serious. There is more detail on that below.
A wrapper is a thin native shell that loads your website inside an embedded browser view. Tools that do this cost from around twenty-five dollars a month upward, and a basic build takes days.
The appeal is obvious. The risk is equally obvious once you read Apple's rules, which the next section covers. A wrapper with nothing else in it is the single most rejected pattern in this category.
Wrappers work when the site is already a genuine web application rather than a brochure, and when you add a real native layer on top: native navigation, push notifications, offline handling, secure storage, and device features that the web version does not have.
Frameworks such as React Native, Flutter and Capacitor let you build a real app from one codebase that ships to both platforms. You reuse your backend, your APIs and your business logic. You rebuild the interface using native components.
This is the default answer for most serious projects in 2026. The gap in performance and platform fidelity between hybrid and native has narrowed to the point where users cannot tell the difference in the large majority of applications.
Capacitor deserves a specific mention because it sits between routes two and three. It can load web content while giving you full access to native APIs and a native shell you control, which makes it a practical migration path when you want to reuse substantial web code without shipping a bare wrapper.
Two separate codebases, Swift for iOS and Kotlin for Android, built against each platform's own frameworks.
You choose this when performance is the product: heavy graphics, real-time media, intensive background processing, or deep integration with platform features that arrive first on native. You also choose it when a regulator or an enterprise client requires it. Otherwise the doubled build and maintenance cost is difficult to justify.
Cost bands reflect market ranges for a mid-complexity product and move with scope, integration count and design ambition.
Apple's App Store Review Guidelines address this directly in section 4.2, Minimum Functionality. The guideline states that 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 doesn't belong on the App Store."
Section 4.2.2 is more specific still. Other than catalogs, apps "shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links."
Read that against a plain wrapper and the conclusion is not ambiguous. A shell that loads your homepage and does nothing else is precisely the pattern the guideline describes.
Reviewers are not rejecting the use of web views. Many large, well-known apps render substantial portions of their interface in web views. They are rejecting apps where the native layer is absent.
An app in this category tends to pass when it has:
The failure mode to avoid is treating this as a checklist to satisfy minimally. Apple's own guidance notes that simply adding a few iOS features is not by itself sufficient. The test applied is whether the experience differs meaningfully from opening the same site in Safari.
Google Play's Spam and Minimum Functionality policy requires apps to provide a basic degree of functionality and a respectful user experience, and it excludes apps that behave in ways inconsistent with a functional experience. Enforcement is generally lighter than Apple's, but it is not absent. Google rejected close to 2 million policy-violating submissions in 2025 and blocked more than 80,000 developer accounts.
Planning for the stricter of the two reviews is the sane approach, because building for Apple's bar and then shipping to Google costs nothing extra.
The direct cost is a resubmission. The real cost is schedule. A rejection cycle typically adds one to three weeks, and it usually arrives after you have announced a launch date. Teams that treat store review as a formality at the end of the project are the ones that get hurt by it.
PWAs are the most misrepresented route in this decision, in both directions. Here is the current state.
Push notifications work, with conditions. Since iOS 16.4, web push is available on iOS, but only for a progressive web app that the user has added to the home screen. A site open in a Safari tab has no access to the push API. If push is the reason you want an app, the user must complete the install step first.
There is no install prompt. iOS does not support the browser event that lets Android show an install banner. The user has to tap the share icon, scroll the share sheet, find "Add to Home Screen" and confirm. Most users do not know this exists. This single limitation is the main reason PWAs underperform on iOS, and no amount of engineering fixes it.
Background sync is not available. The Background Sync API is unsupported on iOS, so a PWA cannot reliably complete deferred work after the user closes it.
Storage limits are tighter than on Chrome, which matters for offline-heavy applications.
iOS 26 improved the default behaviour, with sites added to the home screen now opening as web apps by default.
The practical reading: a PWA is an excellent choice when you can instruct your users to install it, such as staff tools, member portals, logistics applications and B2B platforms with a known user base. It is a weak choice when you need to acquire consumer users at scale on iOS, because the install path loses most of them.
Store fees are trivial. The maintenance line is not, and it is the one most budgets omit. Apple and Google each ship a major OS release annually, and both periodically raise the minimum SDK version required for updates. An app that receives no engineering attention becomes unpublishable within roughly two years.
Before conversion you maintain one surface. After conversion you maintain three: the website, the iOS app and the Android app. Every feature decision is now made three times, every bug is reproduced three times, and every release is coordinated across three pipelines with two of them gated by external review.
This is the strongest practical argument for the hybrid route, and against the native route for most businesses. Shared code is not an aesthetic preference. It is the difference between one team shipping and three teams negotiating.
Two phases are routinely skipped and both cost more later.
API readiness is skipped when a team assumes the website's existing endpoints will serve the app. They usually will not. Web endpoints are often session-based, chatty, and shaped around rendering pages rather than returning data. Mobile clients need token-based authentication, fewer and larger responses, and versioning so that an old app version still works after you deploy. If your backend is not ready for this, our system integration work usually starts here.
Store preparation is skipped because it looks administrative. It is where reviewers form their first impression. Providing a working test account is the most common omission, and an app a reviewer cannot log into is rejected without further examination.
The interface row is the one people argue with. Reusing web navigation on mobile is the most visible sign of a converted site, and it is what reviewers and users both react to. Mobile has its own conventions: bottom tab bars, swipe-back gestures, platform-standard modals, thumb-reachable primary actions. A design that ignores them reads as a website in a frame regardless of the technology underneath.
Testing also changes shape. Device fragmentation, OS version spread, background and foreground transitions, network loss and permission states are all new failure surfaces that a website never had. That is why our quality assurance and testing scope for mobile is broader than for web.
Do not convert when your traffic is dominated by first-time visitors arriving from search. You will spend the build budget acquiring installs that never happen.
Do not convert when the underlying website is slow or unstable. An app makes existing performance problems more visible, not less, because users judge apps against a higher standard than pages.
Do not convert when the real requirement is push notifications and nothing else. Web push on Android and installed-PWA push on iOS may cover the need at a fraction of the cost.
Do not convert when nobody will own the app after launch. An unmaintained app collects one-star reviews and eventually gets removed from the store, which is worse for your brand than never shipping.
Convert when repeat users are asking for it, when a device capability is genuinely required, or when your competitors' apps are taking the habitual usage that used to come to your site.
If you want to work through this decision on your own product rather than in the abstract, our custom software development engagements start with exactly this kind of audit, and the comparison in low-code versus custom software development covers the adjacent build-or-configure question.
How long does it take to convert a website into a mobile app?
A WebView wrapper takes one to three weeks. A progressive web app takes three to six weeks. A hybrid rebuild in React Native, Flutter or Capacitor takes three to six months. A full native rebuild takes five to ten months. Store review adds one to three weeks on top, longer if the first submission is rejected.
How much does it cost to turn a website into an app?
Market ranges run from around S$5,000 for a basic wrapper to S$300,000 or more for a full native rebuild of a complex product. Most businesses converting a functioning web application land between S$45,000 and S$150,000 for a hybrid build. Add 15% to 25% of build cost per year for maintenance.
Will Apple reject an app that is just my website?
Very likely. Apple's guideline 4.2 requires features, content and UI that elevate an app beyond a repackaged website, and section 4.2.2 excludes apps that are primarily web clippings or collections of links. Adding native navigation, push notifications, offline handling and at least one device capability the browser version lacks is what moves an app past that bar.
Can I convert a website to an app without coding?
Yes, using no-code builders or wrapper services, typically for a monthly subscription. The result is suitable for simple content and catalogue use cases. It carries the highest App Store rejection risk and gives you the least control over the outcome, so it fits validation and internal distribution better than a commercial launch.
Do progressive web apps work on iPhone?
Yes, with real limitations. Push notifications work only after the user adds the app to the home screen, iOS provides no automatic install prompt, background sync is unavailable and storage limits are tighter than on Android. PWAs work well when you can instruct users to install; they lose most consumer users on iOS at the install step.
Will my app rank in the App Store the way my site ranks in Google?
No. App store discovery is a separate discipline with its own signals, and it favours downloads, ratings and retention. Assume your app will be found by people who already know you, at least at first.
Should I keep the website after launching the app?
Yes. The website remains your acquisition channel and your only surface reachable by search engines and by users who will not install anything. Apps retain, websites acquire. Retiring the site to push installs consistently reduces total reach.
Do not start with the technology. Start with your analytics. Look at how many users return weekly, what they do when they return, and whether any of it needs a device capability the browser cannot provide. That data selects the route, and it also tells you whether to build at all.
Serdao builds mobile applications across native and cross-platform stacks, and has delivered software and IT services for 18 years from offices in France and Ho Chi Minh City. We are members of CCI France Vietnam and French Tech.
See how we structure delivery on our mobile application development page, or talk to our team about your site. Bring your analytics rather than a feature list. The first useful question is whether an app is the right answer, and that one is answered with data.