In the iOS ecosystem, developers often need to guide users directly to a specific screen inside an app—whether they’ve tapped a link in an email or clicked an ad. There are two main approaches to achieve this deep linking: Custom URL Schemes and Universal Links. Both let you open your app at a designated location, but each works differently, comes with its own trade-offs, and serves distinct use cases. Below, we explore how to configure each method, compare their strengths and weaknesses, and explain why Universal Links represent the future of deep linking on iOS.
Custom URL Schemes: Simplicity and Risks
A Custom URL Scheme is literally a custom prefix—like myapp://—that you register in Xcode. To set it up, you add a URL Type under Signing & Capabilities, specify your scheme (for example, myapp), and then implement this delegate method in your AppDelegate:
This approach is extremely straightforward—no server support required, just a few lines of setup in Xcode and code. However, that very simplicity introduces risks. Because schemes aren’t vetted by Apple or tied to your website, two different apps can mistakenly claim the same prefix, and iOS might launch the wrong app. There’s also no automatic fallback: if the user hasn’t installed your app, clicking the link does nothing, unless you build your own logic to redirect them to the App Store. Custom URL Schemes work well for internal integrations between your own apps or for quick prototypes, but they’re not ideal as the primary deep-linking mechanism in production.
Universal Links: Reliability and Seamless Experience
Universal Links use standard HTTPS URLs (for example, https://example.com/path) and require no additional user prompts—just a secure association between your website and app. When a user taps a Universal Link, iOS performs a lightweight TLS handshake to fetch your site’s apple-app-site-association (AASA) file, verifies that the file lists your app’s Team ID and bundle identifier, and checks whether the tapped path matches one of the allowed patterns. If everything lines up, the system launches your app and hands off the URL via NSUserActivityTypeBrowsingWeb, including any query parameters and metadata (such as the originating network or Handoff context). If the app isn’t installed—or if the URL doesn’t match any pattern—iOS falls back to opening the same link in Safari, preserving the user’s context without dead ends.
Behind the scenes, the AASA file can list multiple apps (useful if you maintain both free and paid editions) and multiple domains, each with its own set of paths. Wildcards (*) and exact matches work together: for example, /products/* captures all product pages, while /promo?code=* lets you accept any code parameter. Note that Universal Links don’t support URL fragments (the #section part) and cannot listen on custom ports—everything must be plain https://domain.com.
Because iOS aggressively caches the AASA file (sometimes up to 24 hours), you’ll want to use device resets or alternate bundle IDs during testing. And since any TLS misconfiguration (expired certificate, missing intermediate, self-signed cert) causes iOS to ignore the file, keeping your HTTPS setup rock-solid is crucial. Apple’s Validator tools and Console.app logs are your best friends here: they’ll flag JSON syntax errors, header issues, or mismatches between the app entitlements and the AASA contents.
Universal Links also power modern features like App Clips—where a lightweight portion of your app can launch instantly from a web banner—and Smart App Banners in Safari, giving users a one-tap route to install or open your app. In short, once the initial setup is done (adding the Associated Domains entitlement in Xcode and hosting a correct AASA file), Universal Links deliver a truly seamless, secure, and future-proof deep-linking experience.
This JSON maps your Team ID and bundle identifier to the URL paths your app handles. When a user taps a link, iOS fetches and validates this file; if there’s a match, it launches your app and delivers the URL via NSUserActivityTypeBrowsingWeb. Otherwise, the link opens in Safari. Despite the extra setup, Universal Links guarantee a web fallback when the app isn’t installed and enforce a secure, Apple-verified association between site and app. The only real downside is that iOS may cache the site association, causing changes to propagate with some delay, and that a valid SSL certificate is mandatory—self-signed certificates won’t work.
A Side-by-Side Comparison
Custom URL Schemes win on ease of setup and lack of server requirements, but they suffer from potential naming collisions, no fallback behavior, and minimal security. Universal Links require server and app configuration, but they deliver a seamless user experience—tapping a link always goes somewhere useful—and provide Apple-backed validation and HTTPS security.
Custom URL Scheme | Universal Links | |
Setup complexity | Xcode only | Xcode + server configuration |
Fallback when not installed | None | Opens in Safari |
Collision risk | High (unvetted schemes) | None (Apple-verified domains) |
Security | Low | High (HTTPS + AASA validation) |
Caching | Immediate | May delay (up to 24h) |
Context info | Only URL | NSUserActivity with metadata |
Choosing the Right Tool
Use Custom URL Schemes for private, internal communications between your own apps or when you need a lightweight callback mechanism (for instance, during an OAuth flow) without a backend in place. For any public-facing deep links—marketing campaigns, email newsletters, social media posts—opt for Universal Links. They ensure that users who haven’t yet installed your app still land on an accessible web page, while installed-app users enjoy a native, in-app experience.
Why Universal Links Are the Future
Apple’s ecosystem is increasingly centered on HTTPS-based links. App Clips, Smart App Banners in Safari, and other modern features all rely on Universal Links. As a result, Custom URL Schemes are gradually relegated to legacy status, used only where backward compatibility or very specific scenarios demand them.
Practical Advice for Developers
When starting a new project, set up Universal Links from day one: configure Associated Domains in Xcode and host the apple-app-site-association file properly. Keep a Custom URL Scheme on hand as a backup for internal tools or rapid prototyping, but do not lean on it for public links. Test your association file with online validators, and monitor device logs through Console.app on macOS to catch caching or certificate issues early.
Conclusion
Both Custom URL Schemes and Universal Links serve the goal of deep linking, but Universal Links offer a more robust, secure, and user-friendly solution. For public integrations and future-facing features, they are the clear choice. Custom schemes can remain in your toolkit for niche or internal use, but the industry—and Apple itself—has made its preference clear: HTTPS-based Universal Links are the modern standard for iOS deep linking.
WhatsApp
Call me