Can any website be turned into an app?

For personal use on a Mac, effectively yes, since the routes wrap whatever the browser can display. For distribution the answer depends on the site. Pages that require a desktop layout, browser extensions, or plugins tend to behave badly once packaged, and sites whose terms forbid framing or repackaging rule the approach out entirely.

Does turning a website into an app make it work offline?

Not by itself. Offline behaviour comes from a service worker that the site publishes, not from the container around it. A wrapped site with no service worker shows the same connection error inside the app that it shows in a tab. Building offline access means changing the website, not the wrapper.

How much does it cost to turn a website into a mobile app?

There is no single figure, but the components are predictable: developer program fees for the stores, design and engineering for the native capabilities that justify the app, and ongoing maintenance for engine and policy updates. The wrapping itself is the cheapest part, which is why estimates built around it are usually wrong.

Will Apple reject an app that is just my website in a wrapper?

That is the case the minimum functionality rule in the review guidelines is written for. Apps that are primarily repackaged websites, web clippings, or collections of links are called out explicitly. Adding push notifications, offline content, or hardware features used inside a real flow is what moves an app out of that category.

Is a Progressive Web App good enough instead of a store app?

For many products it is, particularly where the audience arrives through search rather than through a store. Installation happens from the browser, updates ship with the site, and one codebase covers desktop and mobile. The gap is store visibility and the deepest hardware integrations, so the decision usually rests on whether users would ever look in a store for this kind of product.

How to turn a website into an app

The phrase covers two completely different jobs, and most of the confusion around it comes from mixing them. One job is personal. A site gets opened every morning, it lives in a tab that keeps getting lost, and it should have an icon and a window of its own on one particular Mac. The other job is a product decision. A site exists, other people should be able to install it, and someone has to decide between a Progressive Web App, a packaged shell, and a rewrite. The routes do not overlap much, the costs differ by a factor of a hundred, and the first thing to settle is which one is actually on the table.

Which job is this

The test is short. Does the app need to run on a machine that belongs to someone else?

If the answer is no, this is a desktop workflow problem. It is solved in minutes with tools already installed, nothing gets published anywhere, and no code is written. Skip to the next section.

If the answer is yes, this is a distribution problem. It involves stores, review policies, code signing, update mechanisms, and maintenance for as long as the app exists. It is solved in weeks at minimum. The section on shipping covers it.

A third case sits between the two and is worth naming. Internal tools inside a company, where a handful of colleagues all need the same site as an app on their own Macs. That case looks like distribution but is usually solved with the personal route repeated, plus a short written instruction, because nothing has to pass through a store.

The question is worth asking out loud because the two jobs get merged by accident. A request that starts as "the team keeps losing the admin panel in their tabs" turns into a project brief for a mobile app somewhere between the first and second meeting, and the original complaint is never addressed. Writing down the sentence that started the request, and checking whether an app on a store would actually fix that sentence, takes a minute and saves weeks.

The personal route on a Mac, three ways

All three produce a window with its own icon, its own place in Command Tab, and its own line in the Notifications list in System Settings. They differ on where the login lives.

	Safari, Add to Dock	Chrome, Install page as app	Dedicated builder
Requirement	macOS Sonoma 14 or later	Any current Chrome	A separate install
Time to first app	Under a minute	Under a minute	A few minutes
Session	Separate from Safari	Shared with the Chrome profile	Isolated per app
Second account of the same service	Works	Blocked, it follows the profile	Works
Browser extensions inside the app	Safari extensions, per app	Yes, from that profile	Depends on the engine
Custom icon	Yes, in the app's Settings	No, taken from the site	Usually yes
Breaks when	The site changes its URL	The profile is deleted or renamed	The tool stops being updated

Safari's route lives under File then Add to Dock in the menu bar. Apple's support page states plainly what the result is:

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

That is why the first launch shows a signed out page. It is also why two apps built from the same service can hold two different accounts at once, which no amount of tab management achieves.

Chrome's route lives under the three dot menu, in Cast, save, and share, as Install page as app. The similarly named Create shortcut item now produces a launcher that opens the page as an ordinary tab, which is the single most common reason people believe the feature was removed.

A dedicated builder produces a normal application bundle and gives control over the icon, the storage, and how external links are handed off. That control is what makes a set of five or ten wrapped sites manageable rather than a pile of lookalike windows. A list of what a builder covers without configuration is on the Supported services page, and the step order is on the Guide.

Two details decide whether the result gets used after the first week. The first is the icon. Five wrapped sites with five versions of the same favicon are harder to hit in the Dock than five tabs were, so distinct icons are not decoration here. The second is external link handling. Clicking a link to another site from inside a wrapped app should open the default browser rather than navigating the app away from the site it exists for, and tools differ on whether that behaviour can be set.

What the personal route does not give

None of these three make the site work offline. The page is still fetched over the network, and a site that shows an error without a connection will show the same error inside the app.

None of them add native capabilities. There is no access to the file system beyond what the browser engine already permits, no background processing when the app is closed, no menu bar item, no system wide keyboard shortcut. The window is a browser window with the furniture removed.

And none of them are distributable in any meaningful sense. The result exists on one Mac. Copying the bundle to another machine may work, may fail on code signing, and will certainly not update itself. Anyone thinking about handing the result to customers is in the other half of this article.

There is also nothing to maintain, which cuts both ways. A wrapped site follows the website, so a redesign appears immediately with no release and no review. The flip side is that a site which changes its address, or moves behind a new login flow, breaks the app with no warning and no error message that explains what happened. The repair is to build it again, which is why this route stays cheap even when it fails.

Shipping an app to other people

Four routes, in increasing order of cost.

Progressive Web App. The site itself ships a manifest and a service worker, and browsers then offer to install it. Nothing is submitted anywhere, updates happen when the site deploys, and one codebase serves every platform. Offline behaviour and caching are real here rather than simulated. The trade-off is reach into the operating system, which remains limited, and discoverability, since nobody browses a store to find it. The reference material at web.dev is the practical starting point.

Packaged shell for desktop. A framework such as Electron bundles a browser engine with the site so the result installs like any other desktop app. This is how a large number of familiar desktop apps are built. The cost is size, memory, and the responsibility of shipping engine updates when security fixes land.

Hybrid shell for mobile. The same idea on phones. The web content runs inside a native container that exposes camera, contacts, push, and the rest through a bridge. This is the route that reaches the App Store and Google Play with a mostly web codebase.

Native rewrite. No web content at all. Highest cost, best integration, and the only route that removes the browser engine from the equation entirely.

The routes also differ in how a fix reaches users, and that difference outlives the build. A Progressive Web App updates when the site deploys, so a bug fixed on Tuesday morning is fixed for everyone by Tuesday afternoon. A packaged desktop app updates when the user accepts a new build, which means a percentage of the installed base is always running something old. A store app updates when review approves it and the user installs it, which adds a queue of days to every fix and makes hotfixes a planning problem rather than a deployment one. Teams that ship weekly feel that difference more than teams that ship quarterly, and it belongs in the decision rather than in the retrospective.

The store rule that ends most naive plans

The plan people usually arrive with is to wrap the existing site, submit it, and be done. Apple's review guidelines address that directly under minimum functionality:

Your app should include features, content, and UI that elevate it beyond a repackaged website. Source: developer.apple.com

The same section adds that apps should not primarily be web clippings or collections of links. In practice a hybrid app passes review when it does something the mobile site cannot: push notifications tied to account events, offline access to content already downloaded, camera or location used inside a real flow, biometric unlock. A shell around the same pages, with the same navigation, is the version that gets rejected.

That rule is worth reading before any engineering starts, because it changes the estimate. The work is not the wrapping. The work is the two or three native capabilities that justify the app existing at all.

Cost over two years, not on day one

Day one costs are misleading. A wrapped site can be running in an afternoon, which makes the route look cheap. The bill arrives later, in four places.

Engine updates. A bundled browser engine has to be updated when security fixes ship. Skipping that leaves known vulnerabilities inside the product.

Store policy changes. Review rules move, and an app that passed two years ago can fail on resubmission.

Signing and notarisation. Desktop apps outside a store still need a developer certificate and notarisation, and certificates expire.

Two codebases in disguise. The moment native capabilities appear, the app stops being the website and starts being a second product with its own release cycle.

Against that, the personal route has essentially no ongoing cost. The app either keeps working or is rebuilt in a minute. That asymmetry is the strongest argument for making sure the job really requires distribution before treating it as a project. Pricing for the personal route is on the Pricing section, and it sits in a different order of magnitude from the alternative.

A ten minute decision path

Write down who runs the app. If the answer is a specific list of named people using their own Macs, take the personal route and repeat it, and stop there.

If the answer is customers, write down the three things the app will do that the mobile site cannot. If that list is empty, the honest answer is that the site should become a Progressive Web App instead, because the store route has nothing to sell to a reviewer or a user.

If the list has three real items, the choice narrows to a hybrid shell or a native build, and it turns on how much of the interface those three items touch. Touching a little argues for hybrid. Touching everything argues for native.

What to change first

Settle the run on someone else's machine question before opening any tool, because it decides everything downstream. If the honest answer is that this is one Mac and one set of tabs, build the first app today with Safari or with a builder such as Kagemusha, and keep the engineering budget for the case that actually needs it.