The Same Link, Two Different Outcomes
A friend sends you a restaurant. You tap it and Apple Maps opens with a pin on the right block. Two hours later a colleague emails you the same restaurant, you tap that link, and Safari loads a cramped web map with a banner asking you to install an app. Nothing changed in between, you touched no setting, and the destination is identical.
This is where people conclude something is broken, and where most troubleshooting advice fails them, because it assumes one switch is responsible. There is no such switch. Whether a tap opens an app or a web page depends on a chain: which domain the link actually points at, whether an installed app has claimed that domain, whether you once told the system you prefer the browser for it, whether the tap happened in Safari or in another app’s web view, and whether the link is a real address or a wrapper that resolves only after a server round trip.
Once you can see the chain, the behaviour stops looking random, and it becomes clear why map links fail more often than almost any other link. This post is the mechanics. The settings tour is in our guide to changing the default maps app; the fix is in the hub piece on opening Google Maps links in Apple Maps.
Universal Links: How an App Claims a Web Address
Apple’s mechanism for “this web address should open my app” is Universal Links, and it has three parts.
The app declares its domains. A developer adds an Associated Domains entitlement listing the domains the app wants to handle, written as applinks:example.com, which ships inside the signed app bundle and cannot change without a new version.
The server publishes a matching claim. The domain owner hosts a small JSON file called apple-app-site-association at a well-known path, conventionally https://example.com/.well-known/apple-app-site-association. It names the app by team and bundle identifier and lists the URL path patterns that app may take over, so a site can claim /products/* while leaving /blog/* to the browser.
The OS verifies the pair. Only when the app’s declaration and the site’s published claim agree does iOS or macOS route the link to the app. Neither half is trusted alone, which is the point: an app cannot hijack a domain it does not control, because the owner has to publish the permission from their own HTTPS server.
The details that decide whether it works
The file must be served over HTTPS as plain JSON, directly rather than through a redirect. Since iOS 14 the fetch happens through Apple’s content delivery network rather than device by device, and the result is cached, so a site can fix a broken file while devices keep behaving the old way for a while. Reinstalling or updating an app forces a fresh fetch, which is why “delete and reinstall” sometimes appears to fix link handling by magic. One rule surprises people: tapping a link to the domain you are already on does not launch the app, since Apple treats that as ordinary browsing.
Falling back to the browser is by design
When a claim cannot be verified, the OS shows no error. It quietly opens the URL in the browser, and that is deliberate. A URL is a web address first and an app entry point second, so if the file is missing, malformed, redirected or briefly unreachable, the link still has to resolve to something, and the something that always exists is the web page. That silent fallback is why a broken handoff feels like nothing happened rather than like something went wrong, and why the first assumption should not be “my phone is misconfigured” but “the claim did not verify, or there was never a claim.”
Custom URL Schemes: The Older, Weaker Mechanism
Before Universal Links there were custom URL schemes, which still exist and still cause confusion. A scheme is the part before the colon: an app registers one in its Info.plist and the OS hands it any myapp:// URL.
Schemes are simple, which is their problem. There is no verification of ownership, so any app can register any scheme, including one another app already uses, and Apple does not document which wins. They are also not web links: put myapp://something in a page and, if the app is absent, the tap fails visibly rather than falling back to anything. That is why schemes were superseded once deep links became commercially valuable.
| Custom URL scheme | Universal Link | |
|---|---|---|
| Form | myapp://path |
https://example.com/path |
| Who can claim it | Any app, unverified | Only an app the owner names |
| If the app is absent | Visible failure | Opens the web page |
Apple Maps supports both. It handles the documented maps:// scheme, and it claims maps.apple.com, so http://maps.apple.com/?q=Eiffel+Tower opens Maps on an Apple device and a web page anywhere else. The parameters worth knowing are q for a search string, ll for a latitude and longitude pair, daddr and saddr for destination and start, and dirflg for travel mode, all covered in the guide to Apple Maps URL schemes and sharing locations between apps.
Eight Reasons a Link Lands in the Browser
Every failed handoff comes down to one of these, ordered roughly by how often it is the culprit.
1. No app claims that domain
Apple Maps claims maps.apple.com. It does not claim google.com, maps.google.com, or goo.gl, and it never will, because Google owns those domains and would have to publish an association file naming Apple’s app. Google Maps does claim them, so with that app installed the handoff works. Without it, a Google Maps URL is simply a web page: not a broken link, not a misconfigured phone, but a web page by definition, because no app on your device is permitted to take it. Nothing in Settings can change that, because no setting can make one company’s app claim another’s domain.
2. You told the system to open that domain in the browser
When an app opens from a Universal Link, a breadcrumb appears in the top-right of the status bar showing where you came from. Tap it and you return to Safari, and the OS reads that as a preference: from now on, links to that domain open in the browser. The same happens if you long-press a link and choose Safari over the app, or tap an “open in Safari” banner. The preference is per domain and sticks indefinitely. Reversing it takes one gesture: long-press the link and, if the app is a valid handler, the menu offers “Open in [App name]”. This is the most common self-inflicted cause, and the one people never suspect.
3. The app is not installed, or its claim has not refreshed
Delete an app and links to its domain go to the browser. Reinstall or update it and the OS refetches the association file; until that completes the app can be present while its claim is not yet active. If the file is unreachable at the moment of the fetch, the claim fails and the browser wins. Is It Down checks whether the host is reachable before you hunt for a fault on your own device.
4. You tapped the link inside an in-app browser
Tap a link in a social feed or chat app and you often do not reach Safari at all. You land in a web view inside that app, and an embedded web view is not the system browser: it does not perform the same Universal Link evaluation. Handling becomes the host app’s responsibility, and developers implement it inconsistently or not at all. Some pass links to the system; some intercept everything deliberately, because keeping you in the app is the business model. So the same URL behaves one way from Messages and another from a feed, and neither is a fault on your device. The escape hatch is the same everywhere: open the in-app browser’s share menu and choose Safari.
5. The link is wrapped in a redirect or tracking hop
The OS evaluates the URL it is asked to open, not the URL you eventually land on. A link like https://click.example-mailer.com/r/?u=https%3A%2F%2Fmaps.google.com%2F... has a host of click.example-mailer.com. No app claims that host, so the browser opens, follows the redirect, and by the time the real destination is known you are already on a web page. A server-side redirect does not re-trigger the evaluation; the decision was made once, at the tap, against the wrapper. This is why click tracking reliably breaks app handoff: marketing platforms, enterprise link scanners, analytics wrappers and affiliate redirectors all replace the real host with theirs. Appended tracking parameters cause a subtler version, since extra query components can push a URL outside the path pattern a site claimed.
6. The link is shortened
The same problem in a smaller package: the shortener’s domain is what gets evaluated, and the real destination only exists after a network round trip. Some short-link services are claimed by their parent app, which is why certain short links do open it, but as a class they push the decision past the point where a handoff could happen.
7. Your email client or web app rewrote the link
Webmail interfaces and some mail apps rewrite links before you see them, for click tracking, link proxying, or security scanning, so a message sent with a clean address can arrive carrying a wrapper. That is why the same message can behave differently in two mail clients. Link Gopher pulls every link out of the current page so you can read the real destinations in a list instead of long-pressing one at a time.
8. The navigation is built by JavaScript instead of an href
Universal Link evaluation happens when the system can inspect the target of a user-initiated navigation. If an element has no real href and instead runs a click handler that computes a URL and assigns it to the current location, the OS often has nothing to evaluate at the right moment, so you get a web navigation rather than a handoff. This is common on map surfaces, where results are interactive widgets rather than documents.
How to Diagnose Your Own Case
You can usually identify the cause in under a minute, and the order matters: each step rules out a class of explanation.
- Long-press the link and read the real destination. On iOS the preview shows the URL; on a Mac, hover and read the status bar. You are looking at the host, not the visible text.
- Look for a redirector or tracking parameters. An unfamiliar host, a
?u=or?url=parameter carrying an encoded address, or a click identifier point at causes 5 to 7. - Try the same link from Notes or Messages. Both use standard system link handling, so if it opens the app there but not where you found it, you were in an in-app browser.
- Check for a browser preference on that domain. Long-press the link; if the menu offers to open it in the app, take that option.
- Confirm the app is installed and current. If it was recently reinstalled, give the fetch a moment or restart the device.
- Read the claim yourself, if you are technical. Open
https://<domain>/.well-known/apple-app-site-associationin a browser. A 404, a redirect, or HTML instead of JSON means the claim cannot verify; if you get JSON, check whether the path you are tapping matches a pattern in it. When a page will not load at all, Get Archive pulls up an archived copy.
Work through all six and if the link still opens a web page, you are almost certainly in cause 1, where no configuration will help.
Why Map Links Are an Especially Hard Case
Map links break the usual assumption about what a link even is. On a search results page, a map result is rarely a tidy anchor wrapping text. It is a cluster: a static thumbnail, a place card with a name and address, a directions button, sometimes a knowledge panel repeating the address. Some of those are anchors, some are buttons with click handlers, and some are containers whose destination is assembled from data attributes at the moment you tap. From the browser’s point of view there is no single href to inspect.
The destinations vary as much as the elements. The same place can be a path-style place URL carrying a name and an @lat,long,z coordinate string, a q= search query, a directions URL with origin and destination parameters, an opaque place identifier, or a short link resolving to any of those. Google also serves maps across many domains and regional top-level domains, so anything that recognises one hostname misses most of the world.
Together, those defeat the obvious fix. “Rewrite the href to a maps.apple.com URL” assumes there is an href, that it holds a readable destination, and that the destination is in a translatable shape. On map surfaces, frequently none of the three hold. What is needed is something running inside the page that watches the actual tap and works out a destination from the evidence around the tapped element.
What a Safari Extension Can Do That Link Handling Cannot
That is the gap a content-script extension fills, and why Redirect Map for Safari is an engineering answer rather than a convenience wrapper.
Because it runs in the page, it sees what system link handling never does: the element you tapped, in context. Tap a map link, a thumbnail, an address card or a directions button, and it inspects what is there, parsing addresses and place names, latitude and longitude pairs, q= query parameters, place path segments, short URLs, and @lat,long,z coordinate strings. It recognises Google’s map surfaces across TLDs and subdomains rather than a single hostname. When it has a destination it can stand behind, it hands that to Apple Maps, so the tap ends in the app instead of a web page.
The fallback is where the design is honest about ambiguity. When the extension cannot confidently resolve a destination from the tapped element, it does not guess: it opens the original link first, uses that page to extract a clearer address, then opens Apple Maps once resolution succeeds. Slower, and correct.
The boundary deserves stating plainly. Redirect Map for Safari works in Safari, on links you tap. It changes no system default, does not intercept links arriving from other apps, and does nothing outside Safari. It is not a maps default setting, because on most devices there is no maps default to set.
On permissions, be clear-eyed. The manifest declares a match pattern of *://*/* alongside the activeTab permission, and the setup instructions ask you to allow it on all websites once. That breadth is required by the problem: Google serves maps across many domains and regional TLDs, and an extension scoped to google.com alone would miss most users. The trade-off is real, and you are granting page access. What it does with that access is narrow: the listing states no data collection, and the described behaviour is that it reads the current page’s DOM locally to find map links, stores nothing persistently, and sends no location or personal data off the device. For a framework to judge such requests, our complete guide to Safari extension security and permissions walks through the permission tiers.
Redirect Map for Safari — Send Google Maps links to Apple Maps
DownloadGood companions: Copy on Select for pasting an address by hand, the Safari versus Chrome extensions comparison for why architecture shapes what an extension can do, our roundup of Safari extensions for travel and navigation, the case for switching from Google Maps to Apple Maps, and the best Safari extensions for iPhone and Mac in 2026.
Frequently asked questions
Why does a link open in Safari instead of the app?
Because no installed app has a verified claim on that link’s domain and path, or because you previously told the system you prefer the browser for that domain. Universal Links need the app and the website to agree, and when that cannot be verified the OS quietly opens the web page.
How do I make links open in the app again?
Long-press the link; if an app is a valid handler for that domain, the menu offers to open it in the app, and choosing that restores the preference. If the option is absent, check the app is installed and current, then inspect the link for a wrapper replacing the real host.
Why do links from Instagram or Messages behave differently?
Messages hands links to the system, so normal Universal Link handling applies. Many social apps open links in an embedded web view instead, and a web view does not perform the same handoff unless the host app implements it. Use its share menu to open the page in Safari.
What is an apple-app-site-association file?
It is a small JSON file a website hosts, conventionally at /.well-known/apple-app-site-association, naming which apps may handle which URL paths on that domain. It is the website’s half of the Universal Links handshake, and if it is missing, malformed or unreachable, the claim does not verify.
Do tracking links break app handoff?
Frequently, yes. The system evaluates the URL in the link, so a click-tracking wrapper means the host being checked belongs to the tracking service rather than the brand, and no app claims it. The later server-side redirect does not re-trigger the evaluation.
Why can’t Apple Maps just claim Google Maps URLs?
Because the domain owner has to publish the claim. Apple Maps could declare an interest in Google’s domains, but the handoff would only work if Google hosted an association file naming Apple’s app. That is a property of the design rather than a flaw.
