Chrome shortcuts on a phone, and what they leave behind

The instruction to create a Chrome shortcut on a phone sounds like one operation. It is at least three, and the one that gets performed is usually not the one the instructions described. Android and iPhone put the command in different places, one menu produces two different kinds of result, and nothing made on a phone appears on a Mac afterwards. Sorting those apart takes a few minutes and prevents an afternoon of confusion.

The command lives in two different places

On Android, the route runs through the menu. Open the site, tap More to the right of the address bar, then Install and create shortcut, then Create shortcut. On iPhone and iPad, the route runs through sharing. Open the site, tap Share to the right of the address bar, then Add to Home Screen, then edit the details and tap Add.

The wording differs as much as the location. An article that says to look in the share sheet is describing iOS. An article that says to look under More is describing Android. Guides titled for phones in general frequently document one platform and leave the other unmentioned, which is why the step being followed sometimes does not exist.

Both routes end at a dialog where the name can be edited. That name becomes the label under the icon, and the default comes from the page title, which tends to run long. Anything past roughly ten characters gets truncated on a home screen, so shortening it at creation time is faster than living with an ellipsis and guessing later which icon is which.

The order of operations that avoids rework

Load the exact page that should open, not the site root, before starting. Both platforms capture whatever URL is currently loaded. Creating the shortcut from a search results page or a redirect landing page produces an icon that opens the wrong thing, and neither platform offers a way to edit the destination afterwards. The fix is deletion and recreation.

One menu, two different results

The Android menu is named Install and create shortcut because it leads to two outcomes. Choosing Install produces a web app. Choosing Create shortcut produces an icon that opens the site in the browser. They sit one tap apart and look nearly identical afterwards.

Google's help describes web apps as apps for the web that make a website function as an app, accessible from a launcher or home screen, with some of them including extras such as additional storage for offline content, notifications, file system access, and icon badging. A plain shortcut gets none of that, because it is a pointer rather than an installation.

What gets made	Behaviour when tapped	How to identify it
Web app	Opens in its own surface	No browser logo on the icon
Shortcut	Opens in the browser	Chrome logo on the icon

The identification rule comes from the documentation as well. On Android, shortcuts with the Chrome logo open in Chrome. On iPhone, the help notes that if a web app is available the shortcut opens the app, and if a web app is not available the shortcut opens the default browser.

The distinction also decides whether notifications are possible. An installed web app can carry notifications and badges where the site supports them. A plain shortcut cannot, because it is only a route into the browser. For a chat or mail service that difference is the whole point, while for a reference site it changes nothing, so the right choice depends on what the site is used for rather than on which option sounds more complete.

That last clause is the important one. Which result appears is not entirely a matter of choice, because the site has to support being installed. A site that has not published the necessary manifest can only ever become a shortcut. When an icon opens a browser instead of a clean surface, the operation was probably performed correctly and the site simply does not offer the other option.

Nothing made on a phone shows up on the Mac

Signing into Chrome syncs bookmarks, history, passwords, and settings across devices. Home screen icons are not on that list. They are objects belonging to the operating system on that one handset, and they stay there.

What travels between devices is the URL and nothing else. The icon, the shortened name, the position on the third page of the home screen, and the folder it was filed into all stay behind. That also applies to replacing a phone: whether the layout survives depends on the device migration process rather than on browser sync. Arranging thirty icons and then changing handsets means arranging them again.

Sign in state does not carry over either. A site that stays authenticated on the phone will present whatever the Mac's browser profile happens to hold when opened there. Expecting the two devices to mirror each other leads to a fair amount of unnecessary troubleshooting when only one of them shows a login screen.

The practical response is to stop treating the two devices as one setup. A phone is used in short bursts while standing up, so the icons that earn a place there are the ones needed in under ten seconds. A Mac is used for long stretches with many things open at once, so what earns a place there is whatever keeps getting lost among tabs. Those two lists overlap less than expected, and building each one on its own terms produces fewer icons overall.

Removing them, and the day the name changes by itself

Removal also depends on which of the two things got created. On iPhone and iPad, press and hold the shortcut on the home screen and tap Delete Bookmark, a label that reveals what a shortcut actually is. On Android, a web app is removed through the device settings under apps, by opening the entry for it and choosing Uninstall. Dragging the icon off the home screen does not necessarily uninstall the app itself.

Names can also change without being touched. Google's help explains that when an app requests an update to the name shown under its icon, Chrome asks whether to approve it, and that if the update is extreme, such as changing to a name similar to another app, the developer may be attempting a malicious change, in which case the app should be uninstalled. A carefully shortened label can therefore be replaced by a long official name if the request is approved without reading it.

The iPhone documentation adds a related note: removing a shortcut means losing access to additional features, and the website's behaviour may change. Restoring the previous behaviour means visiting the site and adding it again, which also means picking the name a second time.

Approving or declining that request is a real choice rather than a formality, so it pays to read what the new name would be before tapping through it.

The Mac uses the same words for different objects

On a Mac, the desktop version of Chrome carries both commands in the same submenu. Under More, then Cast, save, and share, there is Create shortcut and there is Install page as app. The structure mirrors the phone: one makes a pointer that opens in the browser, the other makes something with its own window.

The constraint is the same as well. Installing as an app depends on the site supporting it, so internal admin panels and older business systems frequently allow only the shortcut. Those are usually the exact sites someone opens twenty times a day and most wants in a window, which is the frustrating part of the built in route.

Ownership differs too. A window created by the browser belongs to the browser profile that created it. Where work and personal accounts are kept in separate profiles, the same site produces different content depending on which profile made the icon, and there is no indication of that on the icon itself.

One difference has no phone equivalent. On a Mac, running two windows of the same site side by side is genuinely useful, because the screen is wide and switching is a keystroke. Two home screen icons for one site just open the same session twice. Carrying a phone organisation strategy onto a Mac therefore produces a Dock full of icons that do less than expected.

Deciding how many icons are worth having

More icons is not the same as faster access, because every addition slows down finding the ones that matter. Three decisions made before creating anything remove most of the later cleanup.

• How many times a day the site actually gets opened, counted from browser history rather than memory
• Which account it should open as, since mixed accounts mean switching on every visit
• What the label should say, since the default is nearly always too long

Counting from history rather than memory is worth insisting on. The sites that come to mind first are the ones that feel significant, while the sites at the top of a day of history are usually the ones opened reflexively between other tasks. Those reflexive visits are where a saved second actually accumulates, and they rarely match the mental list.

The second one causes the most trouble later. Two icons for one site do not produce two sessions if the underlying browser profile is shared, so one account keeps evicting the other. A window that carries its own browser profile avoids that entirely, which is what makes two simultaneous logins possible. The Features page covers what a window can be given, and the Guide walks through building one.

What the preset list says about worthwhile candidates

Tools that turn sites into standalone Mac apps accumulate evidence about which services people separate out in practice. Across 300 or more presets, the concentration is in communication, AI assistants, and work tools. What those share is frequency, not importance: many short visits per day rather than one long session.

Sites opened monthly barely appear, which matches the arithmetic. An icon saves a few seconds per visit, so a site visited twice a month saves nothing worth the clutter. The Supported services list makes it easy to check whether the candidates are already covered, since a preset removes the manual work of choosing a URL and an icon. Cost matters early too, because a one time purchase and a subscription diverge quickly and the free tier decides how much can be tested first, both of which sit on the Pricing page.

What to change first

Pick the single site opened most often and handle one device at a time. On the phone, create the icon and check whether the logo appears on it, which tells you which of the two results you got. On the Mac, check whether the site can be installed at all, and where it cannot, give it a window another way with Kagemusha.