Turning a website into a Mac app, step by step

The build itself takes about ten minutes and involves no code. What costs time is doing the steps out of order, discovering on day three that the login does not survive a restart, and starting again. This is the sequence that avoids that: choose the site, clean up the browser side, build it one way, test it the same day, then use exactly one of them for a week before making a second.

Decide which site earns an app before touching anything

Two decisions come before any menu item. Which site, and what the app has to do that the tab does not.

The test for the site is narrow. Open it at least three times a day, and losing it mid task has to actually interrupt something. Calendars, internal admin panels, chat, and mail pass. A billing portal opened once a month does not, and neither does anything reached by search rather than by habit. Wrapping a site that gets opened weekly produces a Dock icon that sits there unused, which is the same clutter problem in a new location.

The second decision is what the app has to provide. In practice it comes down to one of four things.

• A window that does not close when the browser window closes.
• Two accounts on the same service, open at once, without switching.
• Notifications that show as a badge on a Dock icon.
• An icon distinct enough to pick out of Command Tab without reading.

Which one is the real requirement determines the route. If the answer is only "a separate window", macOS already includes what is needed. Once two accounts or a custom icon enter the list, the choice moves toward a dedicated builder.

The order of operations

The build is short. The checking and the trial period are what take real time.

Step	What happens	Rough time	Where it goes wrong
1 Choose	One site, one requirement	5 min	Too many candidates
2 Prepare	Sort out logins and accounts	10 min	Second factor not at hand
3 Build	Pick one route and make it	3 min	Menu item is not where the guide says
4 Test	Six checks, same day	15 min	Login gone after a restart
5 Settle	Use one app for a week	7 days	Built and then never opened

Step 4 is the one people skip when in a hurry. Skipping it moves the discovery of every problem several days out, at which point it is much harder to tell whether the cause is the wrapper, the site, or the account.

Step 1. Clean up the browser side first

Preparation changes the outcome more than the build does, because the login a new app inherits depends entirely on the route.

An app made with Safari does not share cookies or settings with Safari, so a fresh login is required immediately after creation. An app made through Chrome carries the session of the profile it was created from, so it usually opens already signed in. A dedicated builder keeps its own storage, which again means signing in once at the start.

So three things belong on the desk before starting. A password manager that is already unlocked. Whatever device produces the second factor. And a decision about which account goes into this app, made now rather than later.

That third item is the one worth deciding early. Running one app and switching accounts inside it reintroduces the exact mistake the app was supposed to prevent, which is sending from the wrong identity. Splitting by purpose and naming each app after its purpose costs one extra build and removes the class of error entirely.

Step 2. Pick one route and build it

There are three routes on macOS. What follows is the entry point for each, not a ranking.

In Safari, open the page, then choose File and Add to Dock from the menu bar. Type a name, click Add, and the app exists. The feature requires macOS Sonoma 14 or later.

The web app is saved to the Applications folder of your home folder, and you can also open it from the Dock or Spotlight. Source: support.apple.com

The location is worth remembering. It is where the app has to be found again on the day it needs deleting.

In Chrome, the item lives in the menu at the top right. Its name and position have moved between versions, appearing as Create Shortcut in some builds and Install as App in others, so a mismatch with a written guide is normal rather than a sign something is broken. When using the shortcut variant, the Open as window checkbox is the part that matters. Without it the result is a bookmark with an icon.

With a dedicated builder, the input is a URL or a preset, and the settings for the icon and for whether links escape to the default browser are decided at build time rather than discovered afterwards.

Step 3. Test six things the same day

Every item below takes under a minute, and every one of them is harder to diagnose a week later.

• Restart the Mac and confirm the login survived.
• Trigger a notification and check whether a badge appears on the Dock icon.
• Click a link inside the app and see whether it opens in the window or jumps to the browser.
• Download a file and note where it lands.
• Print something, and export a PDF.
• Copy, paste, and drag a file in, to confirm the clipboard behaves normally.

The third check matters most for internal tools. An admin panel that links out to external documentation becomes awkward if those links open inside a window with no address bar. The opposite setting, where everything escapes to the browser, breaks flows that were meant to stay inside the app. There is no universally correct answer, which is why the check is a click rather than a setting to read about.

One thing cannot be tested on day one. Sessions designed to expire after a couple of weeks stay silent until they expire. A service that forces reauthentication after fourteen days will look perfect for thirteen. That is the strongest argument for building one app and waiting rather than building eight in an afternoon.

Step 4. Fix the name, the icon, and how it opens

This looks cosmetic and is not. It determines how many seconds per day go into finding the thing.

Names should resolve in Spotlight after two or three characters. Two apps for the same service need purpose in the name, such as Mail Internal and Mail Clients, so that Command Tab stays unambiguous. An icon left as the default favicon is unreadable at Command Tab size, which puts a pause back into every switch.

Launch behavior is a separate decision. Anything opened every single morning belongs in Login Items in System Settings, so it is already running. Chat is usually the opposite case. Leaving it out of Login Items and opening it deliberately keeps it from being the first thing on screen.

Dock position deserves the same treatment. A fixed order, most used on the left, removes the visual search that the whole exercise was meant to eliminate.

Window size belongs in the same pass. Each app remembers its own position and dimensions, so a calendar can live pinned to the left half and a chat window can stay narrow at the right edge, and both return that way after every restart. Setting those once, on the day the app is created, is what turns a wrapped site into something that feels placed rather than something that opens wherever the last window happened to be.

Step 5. Live with one app for a week

The step after building is not building more. It is using the first one for seven days and counting something specific: how many times the same site still got opened in a browser tab.

Close to zero means the site was a good candidate. More than half the time in the browser means the site is reached by links and search rather than by habit, and an icon will not change that. That site belongs back in the browser.

The same count applies to every later addition. Setups that survive tend to settle between three and five apps per person. Past that, the Dock develops the same problem the tab bar had, and time goes back into scanning icons.

Extra checks when the site belongs to work

Wrapping an internal admin panel or a client dashboard adds three checks that personal accounts never need. Skipping them produces an app that works for exactly one person on exactly one Mac.

The first is the authentication method. Corporate systems often sit behind single sign on, a client certificate, or a browser extension that injects credentials. Certificates installed in a browser and extension based authentication may not be reachable from inside a wrapped app. The test is not theoretical: sign in once, all the way through, before deciding the app is usable.

The second is policy. Whether business data may be opened through a third party wrapper is a question for whoever owns information security, not a technical detail. Finding out early whether only built in macOS and browser features are acceptable, or whether outside tools are allowed, prevents rebuilding the whole set later.

The third is reproducibility. One person building something by hand on their own machine does not give a colleague the same result. A single note listing which site was wrapped, by which route, under which name, and with which icon removes the need for every new person to repeat the same investigation. For teams, that note is worth more than any individual setting in it.

There is a fourth item worth watching for services that log people out on a schedule. Sessions built to expire after a fixed period will behave perfectly until the day they do not, and the person who built the app is usually not the one who hits that wall. Writing the expiry behavior into the same note saves a support conversation later.

Where the process stalls

Three failures cover almost everything.

The menu item is missing. In Safari that usually means the Mac is on a release earlier than Sonoma 14. In Chrome it means the item moved in a newer build, so the fix is to read the current menu rather than the older guide.

The app opens to a blank window. This tends to happen with sites that depend on a browser extension, or when cookie restrictions are set aggressively. Rebuilding through a different route is faster than debugging it.

The app needs removing and cannot be found. Safari web apps sit in the Applications folder inside the home folder and go to the Trash from there. Apps from a dedicated builder are removed from that tool's own list.

None of these touch the website itself, which is the reason this is cheap to experiment with. A bad result costs three minutes.

What to change first

Pick the single site opened most often, build it by the cheapest route that meets the one requirement identified in step 1, and run the six checks before the day ends. If the blocker turns out to be a second account, a custom icon, or links leaking into the browser, that is the point where a dedicated builder such as Kagemusha is worth pricing, and the Supported services list is the fastest way to see whether the target site is already covered.