Making a website feel like a real app

Making a website feel like an app covers a wide range of expectations. For some people it means a window with no tab strip and no address bar. For others it means a Dock icon that answers immediately, notifications that arrive with the browser closed, and a login that never gets mixed up with the other forty tabs. The first version takes a minute on any Mac. The second depends entirely on which route is used, and that is why so many people build a standalone window, look at it, and decide it was not what they wanted.

What "feels like an app" breaks down into

Vague dissatisfaction with a browser tab almost always resolves into four separate things.

• Appearance: no tab strip, no address bar, no bookmarks bar in the way.
• Reach: the site opens from the Dock, from Command Tab, and from Spotlight without going through a browser first.
• Notifications: alerts arrive with the browser closed, and that one site can be silenced without silencing everything.
• Boundary: the login stays put, separate from other tabs, and the same state comes back after a quit and relaunch.

These are not one feature. Appearance and reach come free with every route. Notifications and boundary follow the design of whichever container is used, and that is where the gap between expectation and result almost always sits. Anyone who says the packaged app did not feel like an app is usually describing a failure in the last two.

Deciding which of the four matters most takes about thirty seconds and saves an afternoon of comparing tools. A dashboard that gets glanced at needs appearance and reach and nothing else. A mail client or a chat tool needs all four.

Three routes, and what each one fills in

There are three practical ways to do this on macOS, and they are not exclusive. Mixing them per site is normal.

	Safari Add to Dock	Chrome install	Dedicated site to app tool
Requires macOS Sonoma 14 or later	Yes	No	No
Own notification entry in System Settings	Yes	Follows Chrome	Usually yes
Session separate from the browser	Yes	No	Usually yes
Browser extensions still work	Safari extensions only	Yes	Depends on the engine
Window and link behavior configurable	No	No	Yes
Cost	Free	Free	Free tier or paid

Safari's route lives under File, then Add to Dock, and the result lands in the Applications folder in the home directory. It arrives with a separate cookie store and its own line under System Settings, Notifications.

Chrome's route is Install page as app, found under the three dot menu in Save and share. The similarly named Create Shortcut now produces a bookmark that opens in a normal tab, which is where most confusion about a missing feature comes from. The app runs inside the profile that created it, so extensions keep working and it opens already signed in.

The third route is a dedicated tool, which exists mainly to make the last row of that table non empty. Window behavior, link routing, icons, and per app sessions become settings rather than fixed behavior.

Link handling is what breaks the illusion first

The most common complaint on day two is not about looks. It is about clicking a link inside the app and landing on a completely different site, inside a window with no back button, because the address bar that used to hold one is gone.

Real Mac applications hand external links to the default browser. A packaged site should behave the same way, and the rule is simple: if the destination is inside the domain that was packaged, keep it in the window, and if it is outside, send it to the browser. Whether that rule is configurable is the sharpest practical difference between the routes.

The native routes do not expose it. Recovery there means using the keyboard or a trackpad swipe to go back, which works but has to be learned. The friction scales with how link heavy the site is. A dashboard rarely leaves its own domain. A mail client or a team chat does it constantly, and packaging one of those without link routing produces an app that quietly becomes a bad browser.

Window memory, name, and icon

These three settings take a minute each and decide whether the app is still in the Dock a month later.

Window size and position should be remembered between launches. Opening in the same place at the same size is what makes an app feel settled, because the eye stops searching. A container that forgets reopens small in the corner every time, and resizing it daily is exactly the kind of friction that sends people back to the tab.

Names default to the page title, which often includes an unread count or the name of whatever was open at creation time. That string is unreadable at Dock size and useless in Command Tab. Two words is the right length, and it matters more when two apps from the same service sit next to each other.

Icons matter most of all. A favicon scaled up to Dock size produces a soft square that the eye slides past, and an unrecognizable icon does not get clicked. Replacing one image is a minute of work. Doing it for twenty five apps is an afternoon, which is the point where a preset catalog stops being a convenience. The list on a Supported services page is also a quick way to read what kind of usage a given tool was designed around.

Reach is a setting, not a side effect

The biggest gain in day to day feel is not visual. It is the drop from three actions to one: bring the browser forward, scan the tab strip, click. Packaging removes the middle step by default, but the last part of the gain has to be set up deliberately.

Three things are worth doing right after the app is built. Keep it in the Dock, so it stays reachable after being quit rather than only while running. Give it a name whose first few letters are unique, so Spotlight finds it without a full word being typed. Then check where it lands in Command Tab, because a packaged site takes a place in the same row as native applications, and the tools used most should not be buried at the far end.

Full screen behavior is worth a look as well. As a tab, the site shared one browser window with everything else, and moving it to a second display meant moving the whole browser. As an app it gets its own space in Mission Control, which makes side by side layouts possible. That cuts both ways. Packaging a site that gets opened twice a week adds another candidate to every window switch without adding any value.

The filter that holds up over time is return count rather than open count. A site that is opened once and left running all day gains little from packaging. A site that is returned to from other work, twenty times a day, gains something every time.

Notifications, and opening at login

Alerts arriving with the browser closed is the single biggest perceptual difference between a tab and an app.

Apps created through Safari appear individually under System Settings, Notifications. Mail can be loud while a dashboard stays silent, and all of it is managed in the same place as native applications. Apps created through Chrome inherit the site permission already stored in the browser, so a site that was denied notifications in Chrome stays quiet as an app, and the fix is in browser settings rather than in the app.

The other setting worth turning on for a daily driver is automatic launch.

In various other ways, a web app functions just like other apps. You can also add it as a login item, so that it opens automatically when you log in. Source: support.apple.com

Having the tool already running when the Mac wakes up feels different from opening a tab, even though the underlying page is identical. The limit is startup weight. Two or three login items is reasonable. Ten of them turns every morning into a slow start.

When the site in question is the reader's own

There is a second meaning to this phrase, and it uses none of the same steps. Making a site feel like an app for its visitors is done on the site, not on the visitor's Mac.

That work starts with a manifest, a small file that declares the icon, the start URL, and the display mode. Setting the display mode to standalone is what removes the browser frame for anyone who installs it. Adding a service worker on top of that lets the site show something useful when the network drops, and once both exist, browsers begin offering installation on their own. The reference material at web.dev covers the full model.

The dividing line between the two meanings is ownership. If the site can be edited, this route is available and produces a better result for every visitor. If it belongs to someone else, packaging on the local machine is the only option, and no amount of configuration will add an offline mode the site does not have.

What packaging cannot give

Keeping expectations accurate prevents most disappointment here. A container does not extend what the web page can do. There is no local file access, no hardware access, no custom menu bar interface, and no speed improvement. The same resources load over the same network, rendered by the same browser engine.

Offline behavior follows the site. If it did not work offline in a tab, it will not work offline in an app, and most business tools have no offline support at all.

One more limit surfaces later rather than on day one. Containers tied to an installed browser depend on that browser staying where it was, and a major update can leave an icon broken or an app refusing to launch. With three apps that is a two minute repair. With twenty five it becomes a recurring chore, and how much of it is handled automatically is a real difference between tools rather than a detail.

What packaging solves is a short list: things getting lost, sessions getting mixed, and alerts getting missed. When those three are the actual complaint, the effect is immediate. When the complaint is that the site itself is slow or missing a feature, a window with no tab strip changes nothing.

What to change first

Take the site that gets returned to most often, package it today on whichever route is already installed, and spend the extra minute on a short name, a clear icon, and the correct start URL. If link routing, a shared login, or notification control turns out to be the thing that breaks the feel, that is the moment to compare what a tool like Kagemusha handles differently, and what is listed under Features.