Deep linking in iOS Swift - Deep Dive

Overview - Deep linking

What is it?

Deep linking is a way to open a specific part of a mobile app directly from a link, instead of just launching the app's home screen. It works like a shortcut that takes users exactly where they want to go inside the app. This helps users save time and improves their experience by avoiding extra taps.

Why it matters

Without deep linking, users would have to open the app and manually find the content they want, which can be slow and frustrating. Deep linking makes navigation faster and smoother, increasing user engagement and satisfaction. It also helps marketing campaigns by linking ads or emails directly to app content.

Where it fits

Before learning deep linking, you should understand basic app navigation and how apps launch on iOS. After mastering deep linking, you can explore universal links, app indexing, and advanced user experience optimizations.

Mental Model

Core Idea

Deep linking is like a GPS coordinate for your app, guiding users straight to the exact screen or content they want.

Think of it like...

Imagine your app is a big shopping mall. Normally, when someone enters, they start at the main entrance (home screen). Deep linking is like giving them a special map that takes them directly to the store they want, skipping the rest of the mall.

App Launch Flow
┌───────────────┐
│ User clicks   │
│ a link        │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ OS checks link│
│ type          │
└──────┬────────┘
       │
       ▼
┌───────────────┐       ┌───────────────┐
│ If deep link  │──────▶│ Open specific │
│ recognized   │       │ screen/content│
└───────────────┘       └───────────────┘
       │
       ▼
┌───────────────┐
│ Else open app │
│ home screen   │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a deep link

Concept: Introduce the basic idea of deep linking as a special link that opens a specific part of an app.

A deep link is a URL that points to a specific screen or content inside a mobile app. For example, instead of just opening the app's home page, a deep link can open a product page or a user profile directly. On iOS, these links often start with a custom scheme like "myapp://".

Result

Users clicking a deep link go straight to the intended screen inside the app.

Understanding deep links as special URLs helps you see how apps can be more user-friendly by skipping unnecessary steps.

2

Foundation

How iOS handles app links

Concept: Explain how iOS recognizes and routes links to apps using URL schemes and universal links.

iOS uses two main ways to open apps from links: custom URL schemes and universal links. Custom URL schemes are like "myapp://page1" and only work if the app is installed. Universal links use regular web URLs and can open the app or fallback to a website if the app is missing.

Result

iOS decides whether to open the app or a website based on the link type and app setup.

Knowing the difference between URL schemes and universal links is key to choosing the right deep linking method.

3

Intermediate

Setting up URL schemes in Swift

🤔Before reading on: do you think URL schemes require changes in the app code, the project settings, or both? Commit to your answer.

Concept: Teach how to register and handle custom URL schemes in an iOS app using Swift.

To use URL schemes, you add a scheme name in your app's Info.plist under "URL Types". Then, implement the AppDelegate method "application(_:open:options:)" to catch incoming URLs and navigate to the right screen. Example: func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool { if url.scheme == "myapp" { // parse url.path and open screen return true } return false }

Result

The app can open specific screens when launched via a URL with the registered scheme.

Understanding how to register and handle URL schemes lets you control app navigation from outside sources.

4

Intermediate

Using Universal Links for better UX

🤔Before reading on: do you think universal links require server setup, app setup, or both? Commit to your answer.

Concept: Introduce universal links as a modern, secure way to deep link using standard web URLs.

Universal links use regular HTTPS URLs that open your app if installed, or fallback to your website if not. To set them up, you host an "apple-app-site-association" file on your website that lists allowed paths. Then, you enable associated domains in your app's capabilities with your domain. iOS then automatically routes matching links to your app.

Result

Users clicking universal links get a seamless experience whether or not the app is installed.

Universal links improve user experience by combining web and app navigation smoothly.

5

Intermediate

Parsing deep link data in Swift

Concept: Show how to extract information from the deep link URL to decide what screen to show.

When your app receives a deep link URL, you parse its components like path and query parameters. For example, a URL like "myapp://product/123?ref=ad" tells you to open the product screen with ID 123. Use URLComponents in Swift to safely extract this data: let components = URLComponents(url: url, resolvingAgainstBaseURL: false) let productId = components?.path.split(separator: "/").last let ref = components?.queryItems?.first(where: { $0.name == "ref" })?.value

Result

Your app can open the correct screen with the right data based on the deep link.

Parsing URLs carefully ensures your app responds correctly to different deep link requests.

6

Advanced

Handling deep links when app is closed

🤔Before reading on: do you think deep links open the app instantly or require special handling if the app is not running? Commit to your answer.

Concept: Explain how iOS launches the app and passes deep link data even if the app was not running before.

When a deep link is tapped and the app is closed, iOS launches the app and calls the same AppDelegate methods with the URL. You must handle navigation after app launch, often by storing the URL and navigating once the UI is ready. This avoids crashes or missed navigation if the app's UI isn't ready immediately.

Result

Deep links work reliably whether the app is running or closed.

Knowing app lifecycle and timing helps you handle deep links smoothly in all states.

7

Expert

Security and privacy in deep linking

🤔Before reading on: do you think any app can handle any deep link URL, or are there protections? Commit to your answer.

Concept: Discuss security risks and best practices to prevent malicious deep links or data leaks.

Deep links can be exploited if apps blindly trust incoming URLs. Use validation to check URLs and parameters. Universal links require domain verification to prevent other apps from hijacking links. Avoid exposing sensitive data in URLs. Also, consider user privacy when handling referral or tracking parameters.

Result

Your app safely handles deep links without exposing users to risks.

Understanding security prevents vulnerabilities and protects user trust in your app.

Under the Hood

When a user taps a deep link, iOS checks if the link matches any registered URL schemes or universal link domains. For URL schemes, iOS looks up the app that registered the scheme and launches it, passing the URL to the app delegate. For universal links, iOS verifies the domain association via the apple-app-site-association file and routes the link to the app if installed, or opens Safari otherwise. The app then parses the URL to decide navigation.

Why designed this way?

Deep linking was designed to improve user experience by reducing navigation friction. Custom URL schemes came first but had security and fallback limitations. Universal links were introduced to use standard web URLs, improve security via domain verification, and provide seamless fallback to websites. This design balances flexibility, security, and user convenience.

User taps link
   │
   ▼
┌───────────────┐
│ iOS checks    │
│ URL scheme or │
│ universal link│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Match found?  │
├───────────────┤
│ Yes           │
│   │           │
│   ▼           │
│ Launch app    │
│ Pass URL      │
└───────────────┘
       │
       ▼
┌───────────────┐
│ App parses URL│
│ Navigates UI  │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do universal links require the app to be installed to open the link? Commit yes or no.

Common Belief: Universal links only work if the app is installed; otherwise, they fail.

Reality: Universal links open the app if installed, but if not, they open the website fallback URL automatically.

Why it matters: Believing universal links fail without the app leads to poor fallback planning and broken user experience.

Quick: Can any app claim any URL scheme and intercept links? Commit yes or no.

Common Belief: Any app can register any URL scheme, so deep links are insecure.

Reality: While URL schemes can conflict, iOS uses the first app installed with that scheme. Universal links solve this by verifying domain ownership, making them more secure.

Why it matters: Ignoring this can cause link hijacking or unexpected app launches, harming user trust.

Quick: Does handling deep links require the app to be running? Commit yes or no.

Common Belief: The app must be running to handle deep links properly.

Reality: iOS launches the app if needed and passes the deep link URL during startup, so the app can handle links even when closed.

Why it matters: Thinking otherwise leads to missing deep link handling in cold start scenarios.

Quick: Are deep links only useful for marketing campaigns? Commit yes or no.

Common Belief: Deep links are mainly for marketing and promotions.

Reality: Deep links improve all user navigation, including notifications, onboarding, and internal app flows.

Why it matters: Limiting deep links to marketing misses opportunities to enhance overall app usability.

Expert Zone

1

Universal links require precise JSON formatting in the apple-app-site-association file; even minor errors cause silent failures.

2

Handling deep links in SwiftUI apps requires bridging AppDelegate methods or using new scene delegate APIs carefully.

3

Deep link URLs should be designed to be idempotent and safe to open multiple times without side effects.

When NOT to use

Avoid deep linking for highly sensitive actions like payments without additional authentication. Instead, use in-app navigation triggered by secure user actions. Also, for apps without web presence, custom URL schemes may suffice but lack fallback options.

Production Patterns

In production, apps combine universal links with analytics to track link sources. They also implement deferred deep linking to handle users installing the app after clicking a link. Apps often centralize deep link parsing logic to maintain consistency and ease updates.

Connections

Web URLs and HTTP

Deep linking builds on the concept of URLs to navigate content, extending it from web browsers to apps.

Understanding how URLs work on the web helps grasp how deep links use similar patterns to navigate inside apps.

App lifecycle management

Deep linking interacts closely with app launch and state restoration processes.

Knowing app lifecycle events helps handle deep links correctly whether the app is running, backgrounded, or closed.

Security and authentication

Deep linking must consider security to prevent unauthorized access or data leaks.

Security principles guide safe deep link design, ensuring user data and app integrity are protected.

Common Pitfalls

#1 Ignoring fallback behavior for deep links when the app is not installed.

Wrong approach:

Using only custom URL schemes without a website fallback, e.g., "myapp://product/123" with no web URL.

Correct approach:

Implement universal links with a website fallback URL, e.g., "https://example.com/product/123", and configure apple-app-site-association.

Root cause:

Not understanding that custom URL schemes fail silently if the app is missing, causing broken links.

#2 Parsing deep link URLs without validation, leading to crashes or wrong navigation.

Wrong approach:

Force unwrapping URL components without checks:
let productId = url.pathComponents[1]! // unsafe

Correct approach:

Safely unwrap and validate components:
if url.pathComponents.count > 1 {
let productId = url.pathComponents[1]
}

Root cause:

Assuming URLs always have expected format without handling errors.

#3 Handling deep links only in AppDelegate without considering SwiftUI or SceneDelegate apps.

Wrong approach:

Implementing only application(_:open:options:) in AppDelegate for deep links in a SwiftUI app.

Correct approach:

Use onOpenURL modifier in SwiftUI or handle scene(_:openURLContexts:) in SceneDelegate for proper deep link support.

Root cause:

Not adapting deep link handling to modern app lifecycle APIs.

Key Takeaways

Deep linking lets users open specific app screens directly from links, improving navigation and user experience.

iOS supports deep linking via custom URL schemes and universal links, each with different setup and fallback behaviors.

Properly parsing and validating deep link URLs ensures your app navigates correctly and safely.

Handling deep links requires understanding app lifecycle to support cold starts and background states.

Security and fallback planning are essential to avoid broken links and protect user data.

Practice

1. What is the main purpose of deep linking in an iOS app?

easy

A. To increase app storage capacity

B. To improve app startup speed

C. To open a specific screen or content inside the app from a link

D. To change the app's icon dynamically

Solution

1. Step 1: Understand deep linking concept

   Deep linking allows users to open a specific part of an app directly from a link, not just launch the app.

2. Step 2: Compare options

   Options A, B, and D are unrelated to deep linking's purpose.

3. Final Answer:

   To open a specific screen or content inside the app from a link -> Option C

4. Quick Check:

   Deep linking = open specific app content [OK]

Hint: Deep linking = direct app content access from links [OK]

Common Mistakes:

• Confusing deep linking with app performance improvements
• Thinking deep linking changes app appearance
• Mixing deep linking with app storage features

2. Which method in AppDelegate handles opening your app via a custom URL scheme?

easy

A. application(_:didFinishLaunchingWithOptions:)

B. application(_:open:options:)

C. applicationDidBecomeActive(_:)

D. applicationWillTerminate(_:)

Solution

1. Step 1: Identify URL handling method

   The method application(_:open:options:) is called when the app is opened via a URL scheme.

2. Step 2: Exclude other lifecycle methods

   Other methods handle app launch, active state, or termination, not URL opening.

3. Final Answer:

   application(_:open:options:) -> Option B

4. Quick Check:

   Custom URL open method = application(_:open:options:) [OK]

Hint: URL open handling uses application(_:open:options:) [OK]

Common Mistakes:

• Choosing didFinishLaunchingWithOptions for URL handling
• Confusing app lifecycle methods with URL handling
• Ignoring the options parameter in the method

3. Given this code snippet in AppDelegate, what will happen when the app opens with URL scheme myapp://profile?id=123?

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
  if url.scheme == "myapp" && url.host == "profile" {
    print("Open profile with id: \(url.query ?? "none")")
    return true
  }
  return false
}

medium

A. Returns false without printing anything

B. Prints 'Open profile with id: none' and returns false

C. Crashes because url.query is nil

D. Prints 'Open profile with id: id=123' and returns true

Solution

1. Step 1: Check URL scheme and host

   The URL scheme is "myapp" and host is "profile", so the if condition is true.

2. Step 2: Evaluate url.query value

   The query part is "id=123", so url.query is "id=123" and prints correctly.

3. Final Answer:

   Prints 'Open profile with id: id=123' and returns true -> Option D

4. Quick Check:

   URL matches scheme and host, query printed [OK]

Hint: Check url.scheme and url.host before using url.query [OK]

Common Mistakes:

• Assuming url.query is nil and causes crash
• Ignoring url.host check
• Returning false despite matching URL

4. Identify the error in this AppDelegate method for handling deep links:

func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any]) -> Bool {
  if url.scheme = "myapp" {
    // handle URL
    return true
  }
  return false
}

medium

A. Using single equals (=) instead of double equals (==) in the if condition

B. Missing return statement inside the if block

C. Incorrect method signature missing default value for options

D. URL scheme comparison should use url.host instead

Solution

1. Step 1: Check the if condition syntax

   The condition uses single equals (=) which is assignment, not comparison.

2. Step 2: Understand correct comparison operator

   In Swift, equality check uses double equals (==), so this is a syntax error.

3. Final Answer:

   Using single equals (=) instead of double equals (==) in the if condition -> Option A

4. Quick Check:

   Comparison needs '==' not '=' [OK]

Hint: Use '==' for comparison, '=' is assignment [OK]

Common Mistakes:

• Confusing assignment (=) with equality (==)
• Ignoring method signature correctness
• Mixing url.scheme and url.host in condition

5. You want to support universal links in your iOS app. Which of the following is NOT required for universal links to work correctly?

hard

A. Implementing application(_:open:options:) to handle the link

B. Hosting an apple-app-site-association file on your website

C. Adding associated domains capability in your app's entitlements

D. Configuring your website's HTTPS server with a valid certificate

Solution

1. Step 1: Understand universal links requirements

   Universal links require a hosted apple-app-site-association file, entitlements setup, and HTTPS with valid certificate.

2. Step 2: Identify handling method difference

   Universal links use NSUserActivity, not application(_:open:options:), which is for custom URL schemes.

3. Final Answer:

   Implementing application(_:open:options:) to handle the link -> Option A

4. Quick Check:

   Universal links use NSUserActivity, not open URL method [OK]

Hint: Universal links use NSUserActivity, not open URL method [OK]

Common Mistakes:

• Thinking application(_:open:options:) handles universal links
• Ignoring HTTPS requirement for universal links
• Skipping apple-app-site-association file setup