iOS deep linking comes down to two mechanisms: custom URL schemes and Universal Links. They both open your app from a URL, but the similarities stop there. Under the hood, they use completely different OS-level machinery, carry different security properties, and produce noticeably different experiences for users.<\/p>\n\n\n\n
This article walks through exactly how each works, where each falls short, and how to move from one to the other if you're migrating an existing integration. For a comprehensive introduction to Universal Links, see our Universal Links guide<\/a>, and for a detailed look at custom schemes, see the custom URL schemes guide<\/a>.<\/p>\n\n\n\n Custom URL schemes let you register a private URL prefix with iOS. When any link starting with that prefix is tapped anywhere on the device, iOS routes it to your app. No verification required, no server involved.<\/p>\n\n\n\n You register a scheme in your app's With that in place, any link like The scheme is declared entirely client-side. iOS trusts the app's own declaration without any external verification. That simplicity is both the main advantage and the central problem.<\/p>\n\n\n\n Because any app can claim any scheme, there is nothing stopping a malicious app from registering When your app is not installed, tapping a Custom schemes also do not work in web contexts where JavaScript is blocked or in app clips, and they cannot be indexed by search engines in any meaningful way.<\/p>\n\n\n\n Universal Links use standard HTTPS URLs. The key difference is that Apple's infrastructure verifies your ownership of the domain before iOS will route those URLs to your app. This verification happens through a JSON file called the Apple App Site Association (AASA) file.<\/p>\n\n\n\n You host the AASA file at The Universal Links arrive through the If your app is not installed when the link is tapped, iOS falls back to Safari and loads the URL like a normal web page. This means your website can serve an App Store redirect, a web fallback page, or both, with no dead ends.<\/p>\n\n\n\nHow Custom URL Schemes Work<\/h2>\n\n\n\n
Info.plist<\/code> under CFBundleURLTypes<\/code>:<\/p>\n\n\n\n<key>CFBundleURLTypes<\/key>\n<array>\n <dict>\n <key>CFBundleURLSchemes<\/key>\n <array>\n <string>myapp<\/string>\n <\/array>\n <key>CFBundleURLName<\/key>\n <string>com.example.myapp<\/string>\n <\/dict>\n<\/array>\n<\/code><\/pre>\n\n\n\nmyapp:\/\/product\/42<\/code> will open your app. In your AppDelegate<\/code> or SceneDelegate<\/code>, you handle incoming URLs like this:<\/p>\n\n\n\n\/\/ AppDelegate\nfunc application(\n _ app: UIApplication,\n open url: URL,\n options: [UIApplication.OpenURLOptionsKey: Any] = [:]\n) -> Bool {\n guard url.scheme == "myapp" else { return false }\n\n \/\/ Parse the path and route accordingly\n let path = url.host ?? ""\n let components = URLComponents(url: url, resolvingAgainstBaseURL: false)\n\n switch path {\n case "product":\n let productId = components?.queryItems?.first(where: { $0.name == "id" })?.value\n navigateToProduct(id: productId)\n return true\n case "profile":\n let userId = components?.queryItems?.first(where: { $0.name == "userId" })?.value\n navigateToProfile(userId: userId)\n return true\n default:\n return false\n }\n}\n<\/code><\/pre>\n\n\n\nThe Core Problem With Custom Schemes<\/h3>\n\n\n\n
myapp:\/\/<\/code> before your app does (or alongside it). When multiple apps register the same scheme, iOS picks one and the behavior is undefined. This is the URI scheme hijacking problem, and it is not theoretical. It has been exploited in practice against OAuth flows. For a full breakdown of these risks, see our article on deep linking security<\/a>.<\/p>\n\n\n\nmyapp:\/\/<\/code> link produces a dead end. Safari displays an error. There is no fallback to a web page or app store listing unless you build one yourself using JavaScript in a web page, which is fragile and breaks in many contexts (iMessage, Notes, most third-party apps).<\/p>\n\n\n\nHow Universal Links Work<\/h2>\n\n\n\n
The AASA File<\/h3>\n\n\n\n
https:\/\/yourdomain.com\/.well-known\/apple-app-site-association<\/code> (no file extension). Here is a typical structure:<\/p>\n\n\n\n{\n "applinks": {\n "details": [\n {\n "appIDs": ["TEAMID.com.example.myapp"],\n "components": [\n {\n "\/": "\/product\/*",\n "comment": "Match any product detail URL"\n },\n {\n "\/": "\/profile\/*",\n "comment": "Match user profile URLs"\n },\n {\n "\/": "\/invite\/*",\n "comment": "Match invitation links"\n }\n ]\n }\n ]\n }\n}\n<\/code><\/pre>\n\n\n\nappIDs<\/code> field combines your 10-character Apple Team ID with your app's bundle identifier. Apple fetches this file via its own CDN infrastructure at app install time and periodically thereafter. The file must be served over HTTPS with a valid certificate and return a Content-Type<\/code> of application\/json<\/code>.<\/p>\n\n\n\nHandling Universal Links in Swift<\/h3>\n\n\n\n
NSUserActivity<\/code> API, not through the openURL<\/code> delegate method. In a SceneDelegate<\/code>:<\/p>\n\n\n\nfunc scene(\n _ scene: UIScene,\n continue userActivity: NSUserActivity\n) {\n guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,\n let incomingURL = userActivity.webpageURL else {\n return\n }\n\n handleIncomingURL(incomingURL)\n}\n\nprivate func handleIncomingURL(_ url: URL) {\n let components = URLComponents(url: url, resolvingAgainstBaseURL: true)\n let pathComponents = url.pathComponents\n\n guard pathComponents.count >= 2 else { return }\n\n switch pathComponents[1] {\n case "product":\n let productId = components?.queryItems?.first(where: { $0.name == "id" })?.value\n navigateToProduct(id: productId)\n case "profile":\n let userId = pathComponents.count > 2 ? pathComponents[2] : nil\n navigateToProfile(userId: userId)\n case "invite":\n let token = pathComponents.count > 2 ? pathComponents[2] : nil\n handleInvitation(token: token)\n default:\n break\n }\n}\n<\/code><\/pre>\n\n\n\nSide-by-Side Comparison<\/h2>\n\n\n\n