canOpenURL Is Deprecated: What to Call Instead

Apple retired a method that has shipped since iOS 3.0 in three sentences: “canOpenURL: is deprecated. Attempt to open the URL and handle any failure instead of validating it first. Using universal links instead of custom URL schemes removes the need for this validation entirely.”¹

The entry carries radar 179874781 and sits under UIKit, Deprecations, directly beneath the scene life cycle mandate that stops apps from launching.¹ The neighboring entry names a consequence. The canOpenURL entry names none.

Each of the three sentences is a separate instruction, and only the second answers the question a developer actually has: what do I write instead? Apple’s answer changes the shape of the call, not just the name.

TL;DR

• Apple deprecated canOpenURL(_:) at 27.0 on iOS, iPadOS, Mac Catalyst, tvOS, and visionOS, with the message “Prefer attempting to open URLs and handling any failures.”² No removal version, no runtime consequence.
• The change with teeth is a number, and it sits in the deprecated method’s own discussion rather than in any release note: “Apps linked on or after iOS 27 are limited to a maximum of 25 entries in the LSApplicationQueriesSchemes key,” down from 50.² The trigger is the SDK you link against.
• The mechanical swap is open(_:options:completionHandler:) and its Boolean, which needs no allowlist entry: “the open(_:options:completionHandler:) method isn’t constrained by the LSApplicationQueriesSchemes requirement.”²
• One pattern loses its replacement, because canOpenURL answers before you draw anything while attempting answers by consequence: a success puts another app in the foreground.² What survives is universalLinksOnly, an open option since iOS 10 that Apple has not deprecated: it “opens the URL only if the URL is a valid universal link and there is an installed app capable of opening that URL.”³
• SwiftUI never shipped the method, and its completion Boolean already means “can open” rather than “did open.”⁴¹⁵ Across seven of my shipping apps and 463 first-party Swift files, canOpenURL and LSApplicationQueriesSchemes each appear zero times.⁶

The deprecation with no consequence, and the number that has one

Apple wrote a deprecation, not a removal. The symbol page carries deprecatedAt 27.0 on all five platforms where UIApplication exists, and the abstract, discussion, return-value contract, and declaration all remain in place.² No Apple page names a version in which the method stops working, and the nearest precedent points the other way: openURL(_:), deprecated at iOS 10.0, still has a page, and its note now reads “Calling this method has no effect.”⁷ A decade of deprecation produced a method that is inert rather than absent, which is precedent rather than a schedule.

The announcement is also narrower than the deprecation. The release note lives on a page Apple titles “iOS & iPadOS 27 Beta 4 Release Notes” and appears nowhere else, while the symbol metadata deprecates the method on tvOS and visionOS all the same, and neither Apple’s UIKit updates page for June 2026 nor the Xcode 27 release notes mention it at all.¹²⁸⁹ The symbol page is the durable half of the record here.

Which makes the buried number the real story. Inside the deprecated method’s own discussion, in the same aside that requires the declaration in the first place: “Apps linked on or after iOS 15 are limited to a maximum of 50 entries in the LSApplicationQueriesSchemes key. Apps linked on or after iOS 27 are limited to a maximum of 25 entries in the LSApplicationQueriesSchemes key.”²

The allowlist outlives the deprecation of the only method it serves, and the ceiling halves for apps linked against the new SDK. Apple states the ceiling and stops there. Nothing says what happens past entry 25, and reading the aside’s two halves together gives a likely answer rather than a documented one: undeclared schemes always return false, so an app declaring 40 schemes that relinks probably starts treating 15 of them as absent. Apple never says which 15, or that truncation follows array order at all. Treat the mechanism as inference and the risk as real, because a false looks identical whether the app is missing or the declaration is.

The next paragraph of the same discussion carries a second limit, and the two are alternatives rather than additions. Apple keys them to the SDK you linked against: “If you link your app against an earlier version of iOS but it is running in iOS 9.0 or later, you can call this method up to 50 times. After reaching that limit, subsequent calls always return false. If the user reinstalls or upgrades the app, iOS resets the limit.”² Read the condition. That budget belongs to apps linked before iOS 9, which is nothing you can ship today. Every current app lives under the other branch, the declaration ceiling, which is the one Apple cut from 50 entries to 25. Both spend down to the same silent false, and both are documented only inside the method Apple just deprecated.

The privacy reading is inference too. canOpenURL was the standard way to detect which apps a person had installed, a device signal rather than a link check, and Apple’s own definition of fingerprinting covers APIs “misused to access device signals to try to identify the device or user.”¹⁰ Apple never connects the two: the method appears on no required reason API list, and the release note, deprecation message, and symbol page all give a purely mechanical rationale.¹²¹⁰ A halved query ceiling fits the privacy story, and Apple has not written it down.

What canOpenURL actually promised

A true was a guarantee about the next call, not a description of the URL: “When this method returns true, iOS guarantees subsequent calls to the open(_:options:completionHandler:) method with the same URL will successfully launch an app that can handle the URL.”² A false was ambiguous by design, with two causes and no way to tell which fired: “false if the device doesn’t have an installed app registered to handle the URL’s scheme, or if you haven’t declared the URL’s scheme in your Info.plist file.”²

Three things it never answered are easy to assume it did: “The return value doesn’t indicate the validity of the URL, whether the specified resource exists, or, in the case of a universal link, whether the device has an installed app registered to respond to the universal link.”² The third clause matters for the migration Apple recommends, and it returns below.

The property that made the method structurally useful is the one nothing replaces. canOpenURL carries the nonisolated keyword in its declaration, and Apple states plainly that “you can call this method safely on a thread that isn’t the main thread.”² A synchronous Boolean available off the main actor can gate a layout decision before anything renders.

Attempt and handle: the shape that changes

Apple’s replacement instruction is one clause long, and the before-and-after looks trivial.

// Before: validate, then open. Requires an Info.plist declaration.
let url = URL(string: "someapp://profile/42")!
if UIApplication.shared.canOpenURL(url) {
    UIApplication.shared.open(url)
} else {
    presentWebFallback()
}

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>someapp</string>
</array>

// After: attempt, then handle. No declaration needed.
let url = URL(string: "someapp://profile/42")!
let opened = await UIApplication.shared.open(url)
if !opened {
    presentWebFallback()
}

The Info.plist entry disappears, and Apple says so directly: “Unlike this method, the open(_:options:completionHandler:) method isn’t constrained by the LSApplicationQueriesSchemes requirement. If an app is available to handle the URL, the system will launch it, even if you haven’t declared the scheme.”² A codebase that migrates fully deletes the key, and with it the 25-entry problem.

Two differences survive the rewrite, and both are structural.

The first is isolation and timing. UIApplication’s declaration reads @MainActor class UIApplication, so open runs on the main actor, and its abstract calls it what it is: “Attempts to asynchronously open the resource at the specified URL.”¹¹¹² The synchronous, off-main-thread Boolean is gone, so validate-then-open logic sitting in a model layer, a background queue, or a non-isolated helper has to move or become async.

The second is that you can no longer ask privately. When the attempt succeeds, another app is in the foreground: “iOS launches that app and passes the URL to it. (Launching the app brings the other app to the foreground.)”¹² The answer arrives as a side effect of acting on it. Apple documents nothing visible for the failing case, only that “the completion handler is called with the success parameter set to false,” but every pattern that needed the answer ahead of the action loses it: showing an open-in-another-app row only when the app is there, ordering a share sheet by what is installed, or picking a default among competing targets.¹²

Apple’s own documentation has not caught up either. The open(_:options:completionHandler:) page still instructs: “To determine whether an app is installed that is capable of handling the URL, call the canOpenURL(_:) method before calling this one.”¹² The replacement’s page recommends the deprecated method.

The presence check that survives

One documented path answers canOpenURL’s question by attempting, with nothing user-visible when the answer is no. UIApplication.OpenExternalURLOptionsKey.universalLinksOnly has existed since iOS 10, Apple has not deprecated it, and the behavior is exactly a presence check: “the method opens the URL only if the URL is a valid universal link and there is an installed app capable of opening that URL.”³

// Presence check with no side effect when the app is absent.
let url = URL(string: "https://myphotoapp.example.com/albums?albumname=vacation")!
let installed = await UIApplication.shared.open(
    url,
    options: [.universalLinksOnly: true]
)
if !installed {
    presentWebFallback()   // nothing opened, nothing switched
}

The false branch is the valuable part. No browser launched, no app came forward, and the caller learned what canOpenURL used to tell it. The tradeoff hides in the option name: without it, an https attempt succeeds whenever a browser can take it, since “if no app is available to handle a universal link, iOS routes it to the person’s default browser, allowing the associated website to respond.”² The option buys a meaningful Boolean by suppressing the fallback that makes universal links pleasant. Apple types the value as “an NSNumber object containing a Boolean value,” which a Swift true satisfies through Objective-C bridging.³

The price is architectural, and it is Apple’s third sentence. Universal links need a two-way association: “When someone installs your app, the system checks a file stored on your web server to verify that your website allows your app to open URLs on its behalf. Only you can store this file on your server, securing the association of your website and your app.”¹³ A server file you control is exactly what a custom scheme never required, which is why the migration works for your own app family and does nothing for a third party who publishes only theirapp://. Two documented surprises ride along: your app opening your own universal link does not route into your app, and a same-domain tap while browsing your site in Safari stays in Safari.¹³

Which is where the third clause from earlier lands: canOpenURL never answered the presence question for a universal link either.² Migrating removes presence detection rather than porting it, because a plain https attempt already succeeds whether the app answered or only the website did. A pattern that worked only because custom schemes leaked installation state leaves with the schemes, and Apple’s release note frames the loss as the reason to migrate.

SwiftUI never had the method

The SwiftUI side is short, and the news is good. EnvironmentValues.openURL, OpenURLAction, and Link all carry availability from iOS 14.0 with no deprecation, and none of the three exposes a validity check.⁴⁵¹⁴

What SwiftUI ships instead is attempt-and-handle with the semantics Apple now wants everywhere, and the completion parameter documentation says the Boolean answers the old question: “A closure the method calls after determining if it can open the URL, but possibly before fully opening the URL. The closure takes a Boolean value that indicates whether the method can open the URL.”¹⁵ Can open, not did open. Apple’s own example prints on it:

openURL(url) { accepted in
    print(accepted ? "Success" : "Failure")
}

Link exposes no Boolean at all and defers to the environment, where the default already implements the universal-link story: “the default action opens a Universal Link in the associated app if possible, or in the user’s default web browser if not.”⁵ A custom OpenURLAction returning .handled, .discarded, or .systemAction intercepts every Link and every markdown link in a Text that reads the action from that environment.⁵

One gap matters before planning a SwiftUI-only migration. OpenURLAction has no options dictionary. Its call signatures are callAsFunction(_:), callAsFunction(_:completion:), and the iOS 26 addition callAsFunction(_:prefersInApp:), and none of the three accepts universalLinksOnly.¹⁵¹⁸ A side-effect-free presence check still means calling UIApplication.shared.open.

Seven apps, 463 files, zero calls

I audited my own portfolio before writing about anyone else’s, expecting a migration list. There is nothing to migrate.⁶

The zero survived three passes of widening scope, out to every vendored Swift package and every file type in every repository.⁶ Nothing declares a queried scheme in 192 .plist, .pbxproj, .entitlements, and .xcconfig files either, which follows: an app with no canOpenURL call has no reason to declare one.

The reason is mundane and probably common. Of the 23 call sites, nine open a legal document, four hand off to the app’s own web product, two open census.gov from an alert so a user can find their representative, two open a job posting URL that arrives from an API, two are macOS-only file: exports, and one is UIApplication.openSettingsURLString behind a “Health Access Required” alert. None of those 20 queries another app, because every destination is either https, which Safari always answers, or a system URL. The remaining three carry all the interesting behavior.

The one place that validates before opening is not doing what the deprecation is about: ResumeGeni’s billing flow POSTs to /api/me/portal, then checks url.scheme == "https" on the URL the server returns, in case a compromised or buggy server hands the app a file: or custom-scheme URL.⁶ Apple’s note targets validating whether a target app exists and says nothing about trusting remote input, so deleting that guard would be a security regression, not a migration.

The other two are Banana List’s macOS handoffs, and one of them holds the only genuine presence check in the portfolio. The app asks NSWorkspace.shared.urlForApplication(withBundleIdentifier: "com.anthropic.claudefordesktop") != nil before handing a bundled .mcpb extension to Launch Services, with a nearby button opening claude.com/download for people who need the app first. The code comment names the motive: without the check, macOS shows its own “no application set to open the document” dialog.⁶ Different platform, and the most useful data point in the audit, because it catches the attempt-and-handle failure mode in the wild. A failed attempt is not always silent, and when the system speaks for you the user reads a system error instead of your fallback.

No repository declares applinks:, so no app here supports universal links, and Apple’s architectural fix is unpaid on my side too.⁶ A custom scheme costs an Info.plist entry; a universal link costs a file on a web server, an entitlement, and a domain you control.

Which points at where the real work sits: not first-party app code, but share sheets that reorder by installed app, “open in” pickers, and attribution SDKs, none of which a clean repository rules out.

The audit itself is easier here than elsewhere in the 27 cycle. Unlike the launch screen keys, which arrive from build settings and defeat a text search entirely, LSApplicationQueriesSchemes has no INFOPLIST_KEY_ equivalent in Apple’s build settings reference, so a grep is the right first move, and whose schemes appear in that array tells you which dependency wants the answer.¹⁶

FAQ

Does canOpenURL stop working in iOS 27?

No, and Apple has not said when it will. The symbol carries deprecatedAt 27.0, and every other part of the page, including the return-value contract, the guarantee about the following open call, the declaration ceiling, and the legacy call budget, remains documented.² No removal version appears in the release note, on the symbol page, or in the Xcode 27 release notes.¹²⁹ Plan for a warning and slow decay rather than a break.

What do I write instead, if I need to know whether the app is installed?

It depends on whether you control the target. If you do, publish a universal link and pass universalLinksOnly to open, which Apple documents as opening the URL only when it is a valid universal link with an installed app to take it, so a false means nothing opened and nothing switched.³ The cost is a two-way association file on your web server.¹³ If a third party publishes only a custom scheme, no replacement exists: canOpenURL still answers, still needs its Info.plist declaration, and the ceiling on that declaration halves to 25 entries for apps linked on or after iOS 27.² SwiftUI code needs no change on this front, because openURL and Link never offered the check.⁴¹⁴

Do I still need LSApplicationQueriesSchemes?

Only for canOpenURL. Apple’s Launch Services documentation defines the key entirely in terms of the deprecated method: it “specifies the URL schemes you want the app to be able to use with the canOpenURL: method of the UIApplication class.”¹⁷ The key has no page in Apple’s modern Information Property List reference at all, and the deprecated method’s discussion links to the legacy archive for it.²¹⁷ The replacement needs nothing, because Apple exempts open from the declaration requirement outright.² Finish migrating and the array goes away; keep one call and you keep the array, the declaration requirement, and the smaller ceiling.

Will the App Store reject a build with more than 25 entries?

No Apple page says so. The ceiling appears in one place, the discussion of canOpenURL(_:), and Apple phrases it as a limit on what the key holds rather than as a submission rule.² Nothing in the iOS 27 release notes, the UIKit updates page, or the Xcode 27 release notes attaches a review consequence to it, and the documented symptom for a scheme the system treats as undeclared is a plain false at runtime.¹²⁸⁹ The App Store Review Guidelines carry no occurrence of LSApplicationQueriesSchemes, canOpenURL, or the 25-entry figure, which is where a submission rule would live if one existed.¹⁹ So the failure to plan for is a wrong answer in your own code rather than a rejected build.

Key Takeaways

For iOS developers: - Replace if canOpenURL(url) { open(url) } with let opened = await open(url) and a fallback on !opened, then delete the matching LSApplicationQueriesSchemes entry once no call remains.² - Keep any scheme check you run on a URL that arrives from a server. Apple’s note targets app-presence validation, not remote input, and the two look identical in a grep.

For teams shipping app-family deep links or SDKs: - Reach for universalLinksOnly rather than canOpenURL when you need a presence answer, and budget the associated-domains file it requires.³¹³ It is the only documented check that leaves nothing user-visible when the app is missing. - Count your LSApplicationQueriesSchemes array before linking against the iOS 27 SDK. Anything past 25 entries lands outside the documented ceiling, and Apple’s symptom for an undeclared scheme is a plain false, which reads exactly like an app that is not installed.²

For release managers: - Do not schedule the deprecation as a release blocker. No removal date and no runtime consequence puts it behind the launch screen key that costs a rejection, the scene mandate that stops launches, and the @State macro that stops a build. - Treat the 25-entry ceiling as the one item with a real trigger, because it keys off the SDK you link against rather than the OS your users run.²

The 27 cycle keeps arriving in different weights, and reading the weight is how you spend the cycle well: the launch screen key blocks a submission, the scene mandate stops an app from launching, the @State macro stops a build, On Demand Resources starts a migration clock, and canOpenURL only warns. Manufacturing urgency around the warning wastes a cycle. The line worth watching sits in a discussion paragraph instead of a release note, and it is a number. The full series hub is the Apple Ecosystem Series.

References