Introduction

Apple deprecated the old openURL(_:) API in iOS 10 in favor of a newer method that provides options and a completion handler. The newer API is better because it gives clearer control and result reporting when opening external URLs, custom schemes, or system destinations. Updating old code is usually simple, but you should also verify URL scheme permissions and fallback behavior.

The Deprecated API

Older code often looked like this:

if let url = URL(string: "https://example.com") {
    UIApplication.shared.openURL(url)
}

This still appears in legacy code bases, but it should be replaced in modern UIKit apps.

The Modern Replacement

Use open(_:options:completionHandler:).

1import UIKit
2
3if let url = URL(string: "https://example.com") {
4    UIApplication.shared.open(url, options: [:]) { success in
5        print("Opened:", success)
6    }
7}

This gives you explicit success or failure feedback and aligns with the supported API surface from iOS 10 onward.

Why the New API Is Better

The newer method adds two important capabilities:

• options dictionary for open behavior
• completion handler for result reporting

That means you can log failures, update UI, or trigger fallback behavior when the target cannot be opened.

Opening Custom URL Schemes

If you need to open another app through a custom scheme:

1if let url = URL(string: "myapp://profile/42") {
2    UIApplication.shared.open(url, options: [:]) { success in
3        if !success {
4            print("Target app not available")
5        }
6    }
7}

This is common for inter-app navigation and deep links.

Check Capability Before Opening

For custom schemes in particular, you may want to check whether the system can handle the URL first.

1if let url = URL(string: "tel://123456789"),
2   UIApplication.shared.canOpenURL(url) {
3    UIApplication.shared.open(url, options: [:], completionHandler: nil)
4}

Be aware that some schemes require configuration in LSApplicationQueriesSchemes when queried with canOpenURL.

Info.plist and Scheme Queries

If canOpenURL always returns false for third-party schemes, the problem may be your app configuration rather than the API call itself. Add allowed schemes to Info.plist where required.

Example:

1<key>LSApplicationQueriesSchemes</key>
2<array>
3    <string>myapp</string>
4</array>

Without this, scheme checks can fail even when the target app is installed.

Scene-Based Apps and Practical Usage

Even in scene-based apps, UIApplication.shared.open remains the standard way to open external URLs. The change from the deprecated API is about method signature and behavior, not about replacing the entire mechanism with something scene-specific.

That means migration is usually a targeted refactor, not a redesign.

Fallback UX Matters

If opening fails, do something useful:

• show an alert
• route to a web fallback
• disable unavailable actions in advance

Example alert pattern:

1func openSupportPage() {
2    guard let url = URL(string: "https://example.com/help") else { return }
3    UIApplication.shared.open(url, options: [:]) { success in
4        if !success {
5            print("Could not open support page")
6        }
7    }
8}

In production apps, replace the print with user-facing recovery logic.

Migration Guidance

When upgrading old code:

1. replace all openURL(_:) calls
2. check for scheme-query requirements
3. add failure handling where useful
4. test on real device for phone, mail, and third-party app flows

This avoids silent regressions in external navigation.

Common Pitfalls

• Replacing the deprecated call but ignoring the completion handler result.
• Using canOpenURL without the required scheme declarations in Info.plist.
• Assuming every valid-looking URL can be opened on the current device.
• Leaving legacy openURL(_:) calls in shared utility code.
• Failing to provide a user-friendly fallback when opening fails.

Summary

• 'openURL(_:) was deprecated in iOS 10 and should be replaced.'
• Use UIApplication.shared.open(_:options:completionHandler:) instead.
• The newer API gives clearer control and better failure handling.
• Custom scheme checks may require Info.plist configuration.
• Test real device flows and add fallback UX for failed opens.