canOpenURL est déprécié : ce qu'il faut appeler à la place

Apple a mis à la retraite en trois phrases une méthode livrée depuis iOS 3.0 : « canOpenURL: est déprécié. Tentez d’ouvrir l’URL et gérez l’échec éventuel plutôt que de la valider au préalable. Utiliser des liens universels plutôt que des schémas d’URL personnalisés supprime entièrement le besoin de cette validation. »¹

L’entrée porte le radar 179874781 et figure sous UIKit, Deprecations, juste en dessous de l’obligation de cycle de vie par scène qui empêche les applications de se lancer.¹ L’entrée voisine nomme une conséquence. Celle de canOpenURL n’en nomme aucune.

Chacune des trois phrases est une consigne distincte, et seule la deuxième répond à la question que se pose réellement un développeur : qu’est-ce que j’écris à la place ? La réponse d’Apple change la forme de l’appel, pas seulement son nom.

TL;DR

• Apple a déprécié canOpenURL(_:) en 27.0 sur iOS, iPadOS, Mac Catalyst, tvOS et visionOS, avec le message « Préférez tenter d’ouvrir les URL et gérer les échecs éventuels ».² Aucune version de suppression, aucune conséquence à l’exécution.
• Le changement qui mord est un chiffre, et il se cache dans la discussion de la méthode dépréciée plutôt que dans une note de version : « Les applications liées à partir d’iOS 27 sont limitées à un maximum de 25 entrées dans la clé LSApplicationQueriesSchemes », contre 50 auparavant.² Le déclencheur, c’est le SDK avec lequel vous liez votre application.
• Le remplacement mécanique, c’est open(_:options:completionHandler:) et son booléen, qui n’exige aucune entrée dans la liste d’autorisation : « la méthode open(_:options:completionHandler:) n’est pas soumise à l’exigence LSApplicationQueriesSchemes ».²
• Un usage perd son remplaçant : canOpenURL répond avant que vous n’affichiez quoi que ce soit, alors que la tentative répond par ses conséquences, puisqu’une réussite met une autre application au premier plan.² Ce qui survit, c’est universalLinksOnly, une option d’open présente depuis iOS 10 et qu’Apple n’a pas dépréciée : elle « n’ouvre l’URL que s’il s’agit d’un lien universel valide et qu’une application installée est capable de l’ouvrir ».³
• SwiftUI n’a jamais livré la méthode, et le booléen de sa closure de complétion signifie déjà « peut ouvrir » et non « a ouvert ».⁴¹⁵ Sur sept de mes applications publiées et 463 fichiers Swift maison, canOpenURL et LSApplicationQueriesSchemes apparaissent zéro fois chacun.⁶

La dépréciation sans conséquence, et le chiffre qui en a une

Apple a écrit une dépréciation, pas une suppression. La page du symbole porte deprecatedAt 27.0 sur les cinq plateformes où UIApplication existe, et le résumé, la discussion, le contrat de valeur de retour et la déclaration restent tous en place.² Aucune page d’Apple ne nomme la version où la méthode cessera de fonctionner, et le précédent le plus proche pointe dans l’autre sens : openURL(_:), dépréciée en iOS 10.0, a toujours sa page, dont la note indique désormais « Appeler cette méthode n’a aucun effet ».⁷ Dix ans de dépréciation ont produit une méthode inerte plutôt qu’absente : c’est un précédent, pas un calendrier.

L’annonce est par ailleurs plus étroite que la dépréciation. La note de version se trouve sur une page qu’Apple intitule « iOS & iPadOS 27 Beta 4 Release Notes » et n’apparaît nulle part ailleurs, alors que les métadonnées du symbole déprécient tout autant la méthode sur tvOS et visionOS, et que ni la page des nouveautés UIKit de juin 2026 ni les notes de version de Xcode 27 n’en soufflent mot.¹²⁸⁹ La page du symbole est ici la moitié durable du dossier.

Ce qui fait du chiffre enfoui la véritable information. Dans la discussion de la méthode dépréciée elle-même, dans le même encadré qui impose la déclaration à l’origine : « Les applications liées à partir d’iOS 15 sont limitées à un maximum de 50 entrées dans la clé LSApplicationQueriesSchemes. Les applications liées à partir d’iOS 27 sont limitées à un maximum de 25 entrées dans la clé LSApplicationQueriesSchemes. »²

La liste d’autorisation survit à la dépréciation de la seule méthode qu’elle sert, et le plafond est divisé par deux pour les applications liées au nouveau SDK. Apple énonce le plafond et s’arrête là. Rien ne dit ce qui se passe au-delà de la 25e entrée, et lire ensemble les deux moitiés de l’encadré donne une réponse probable, pas une réponse documentée : les schémas non déclarés renvoient toujours false, donc une application qui en déclare 40 et qu’on relie au nouveau SDK traitera vraisemblablement 15 d’entre eux comme absents. Apple ne dit jamais lesquels, ni même que la troncature suit l’ordre du tableau. Considérez le mécanisme comme une déduction et le risque comme réel, car un false a exactement la même allure, que ce soit l’application ou la déclaration qui manque.

Le paragraphe suivant de la même discussion porte une seconde limite, et les deux sont des alternatives plutôt qu’un cumul. Apple les indexe sur le SDK avec lequel vous avez lié votre application : « Si vous liez votre application avec une version antérieure d’iOS mais qu’elle s’exécute sous iOS 9.0 ou ultérieur, vous pouvez appeler cette méthode jusqu’à 50 fois. Une fois cette limite atteinte, les appels suivants renvoient toujours false. Si l’utilisateur réinstalle ou met à jour l’application, iOS réinitialise la limite. »² Lisez la condition. Ce budget appartient aux applications liées avec une version antérieure à iOS 9, ce que plus personne ne peut publier aujourd’hui. Toutes les applications actuelles relèvent de l’autre branche, le plafond de déclaration, celui-là même qu’Apple a ramené de 50 entrées à 25. Les deux s’épuisent dans le même false silencieux, et les deux ne sont documentés qu’à l’intérieur de la méthode qu’Apple vient de déprécier.

La lecture « vie privée » relève elle aussi de la déduction. canOpenURL était le moyen standard de détecter quelles applications une personne avait installées, un signal d’appareil plutôt qu’une vérification de lien, et la définition qu’Apple donne du fingerprinting couvre les API « détournées pour accéder à des signaux de l’appareil afin de tenter d’identifier l’appareil ou l’utilisateur ».¹⁰ Apple n’établit jamais le lien : la méthode ne figure sur aucune liste d’API à motif obligatoire, et la note de version, le message de dépréciation et la page du symbole donnent tous une justification purement mécanique.¹²¹⁰ Un plafond de requêtes divisé par deux colle au récit de la vie privée, et Apple ne l’a pas écrit.

Ce que canOpenURL promettait vraiment

Un true était une garantie sur l’appel suivant, pas une description de l’URL : « Lorsque cette méthode renvoie true, iOS garantit que les appels suivants à la méthode open(_:options:completionHandler:) avec la même URL lanceront avec succès une application capable de traiter cette URL. »² Un false était ambigu par construction, avec deux causes et aucun moyen de savoir laquelle s’était déclenchée : « false si l’appareil n’a pas d’application installée enregistrée pour traiter le schéma de l’URL, ou si vous n’avez pas déclaré le schéma de l’URL dans votre fichier Info.plist ».²

Trois choses auxquelles elle n’a jamais répondu, et qu’on lui prête volontiers : « La valeur de retour n’indique ni la validité de l’URL, ni l’existence de la ressource spécifiée, ni, dans le cas d’un lien universel, si l’appareil dispose d’une application installée enregistrée pour répondre à ce lien universel. »² La troisième proposition compte pour la migration recommandée par Apple, et elle revient plus bas.

La propriété qui rendait la méthode structurellement utile est justement celle que rien ne remplace. canOpenURL porte le mot-clé nonisolated dans sa déclaration, et Apple l’écrit sans détour : « vous pouvez appeler cette méthode en toute sécurité depuis un thread autre que le thread principal ».² Un booléen synchrone disponible hors du main actor peut conditionner une décision de mise en page avant tout rendu.

Tenter et gérer : la forme qui change

La consigne de remplacement d’Apple tient en une proposition, et l’avant/après paraît 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()
}

L’entrée Info.plist disparaît, et Apple le dit directement : « Contrairement à cette méthode, la méthode open(_:options:completionHandler:) n’est pas soumise à l’exigence LSApplicationQueriesSchemes. Si une application est disponible pour traiter l’URL, le système la lancera, même si vous n’avez pas déclaré le schéma. »² Une base de code qui migre entièrement supprime la clé, et avec elle le problème des 25 entrées.

Deux différences survivent à la réécriture, et toutes deux sont structurelles.

La première tient à l’isolation et au moment de l’appel. La déclaration d’UIApplication s’écrit @MainActor class UIApplication, donc open s’exécute sur le main actor, et son résumé appelle un chat un chat : « Tente d’ouvrir de façon asynchrone la ressource à l’URL spécifiée. »¹¹¹² Le booléen synchrone, appelable hors du thread principal, disparaît : toute logique de validation préalable installée dans une couche de modèle, une file d’attente en arrière-plan ou un utilitaire non isolé doit déménager ou devenir async.

La seconde, c’est qu’on ne peut plus poser la question discrètement. Quand la tentative réussit, une autre application passe au premier plan : « iOS lance cette application et lui transmet l’URL. (Lancer l’application amène l’autre application au premier plan.) »¹² La réponse arrive comme effet de bord de l’action. Apple ne documente rien de visible pour le cas d’échec, seulement que « le gestionnaire de complétion est appelé avec le paramètre success à false », mais tous les usages qui avaient besoin de la réponse avant l’action la perdent : n’afficher une ligne « ouvrir dans une autre application » que si l’application est présente, trier une feuille de partage selon ce qui est installé, ou choisir une cible par défaut parmi plusieurs concurrentes.¹²

La documentation d’Apple elle-même n’a pas suivi. La page d’open(_:options:completionHandler:) continue d’indiquer : « Pour déterminer si une application capable de traiter l’URL est installée, appelez la méthode canOpenURL(_:) avant celle-ci. »¹² La page du remplaçant recommande la méthode dépréciée.

La vérification de présence qui survit

Un chemin documenté répond à la question de canOpenURL en tentant l’ouverture, sans rien montrer à l’utilisateur quand la réponse est non. UIApplication.OpenExternalURLOptionsKey.universalLinksOnly existe depuis iOS 10, Apple ne l’a pas dépréciée, et son comportement est exactement une vérification de présence : « la méthode n’ouvre l’URL que s’il s’agit d’un lien universel valide et qu’une application installée est capable de l’ouvrir ».³

// 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
}

La branche false est ce qui a de la valeur. Aucun navigateur lancé, aucune application au premier plan, et l’appelant a appris ce que canOpenURL lui disait autrefois. Le compromis se cache dans le nom de l’option : sans elle, une tentative en https réussit dès qu’un navigateur peut la prendre en charge, puisque « si aucune application n’est disponible pour traiter un lien universel, iOS l’achemine vers le navigateur par défaut de la personne, ce qui permet au site associé de répondre ».² L’option achète un booléen porteur de sens en supprimant le repli qui rend les liens universels agréables. Apple documente la valeur comme « un objet NSNumber contenant une valeur booléenne », ce qu’un true Swift satisfait via le pont Objective-C.³

Le prix est architectural, et c’est la troisième phrase d’Apple. Les liens universels exigent une association bidirectionnelle : « Lorsque quelqu’un installe votre application, le système vérifie un fichier stocké sur votre serveur web pour confirmer que votre site autorise votre application à ouvrir des URL en son nom. Vous seul pouvez stocker ce fichier sur votre serveur, ce qui sécurise l’association entre votre site et votre application. »¹³ Un fichier serveur que vous contrôlez, c’est précisément ce qu’un schéma personnalisé n’a jamais exigé, et c’est pourquoi la migration fonctionne pour votre propre famille d’applications et ne donne rien face à un tiers qui ne publie que theirapp://. Deux surprises documentées s’invitent au passage : votre application qui ouvre son propre lien universel n’est pas redirigée vers elle-même, et un appui sur un lien du même domaine pendant que vous naviguez sur votre site dans Safari reste dans Safari.¹³

C’est là que retombe la troisième proposition évoquée plus haut : canOpenURL ne répondait pas non plus à la question de la présence pour un lien universel.² Migrer supprime la détection de présence plutôt que de la porter, car une simple tentative en https réussit déjà, que ce soit l’application ou seulement le site qui ait répondu. Un usage qui ne fonctionnait que parce que les schémas personnalisés laissaient fuiter l’état d’installation s’en va avec les schémas, et la note de version d’Apple présente cette perte comme la raison même de migrer.

SwiftUI n’a jamais eu cette méthode

Du côté SwiftUI, c’est court et la nouvelle est bonne. EnvironmentValues.openURL, OpenURLAction et Link sont tous disponibles depuis iOS 14.0 sans dépréciation, et aucun des trois n’expose de vérification de validité.⁴⁵¹⁴

Ce que SwiftUI livre à la place, c’est tenter puis gérer, avec la sémantique qu’Apple veut désormais partout, et la documentation du paramètre de complétion dit que le booléen répond à l’ancienne question : « Une closure que la méthode appelle après avoir déterminé si elle peut ouvrir l’URL, mais possiblement avant de l’avoir entièrement ouverte. La closure prend une valeur booléenne qui indique si la méthode peut ouvrir l’URL. »¹⁵ Peut ouvrir, pas a ouvert. L’exemple d’Apple lui-même l’affiche :

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

Link n’expose aucun booléen et s’en remet à l’environnement, où le comportement par défaut met déjà en œuvre le scénario des liens universels : « l’action par défaut ouvre un Universal Link dans l’application associée si possible, sinon dans le navigateur web par défaut de l’utilisateur ».⁵ Une OpenURLAction personnalisée renvoyant .handled, .discarded ou .systemAction intercepte chaque Link et chaque lien markdown d’un Text qui lit l’action dans cet environnement.⁵

Une lacune compte avant de planifier une migration entièrement SwiftUI. OpenURLAction n’a pas de dictionnaire d’options. Ses signatures d’appel sont callAsFunction(_:), callAsFunction(_:completion:) et, ajoutée en iOS 26, callAsFunction(_:prefersInApp:), et aucune des trois n’accepte universalLinksOnly.¹⁵¹⁸ Une vérification de présence sans effet de bord passe toujours par un appel à UIApplication.shared.open.

Sept applications, 463 fichiers, zéro appel

J’ai audité mon propre portfolio avant d’écrire sur celui des autres, en m’attendant à une liste de migration. Il n’y a rien à migrer.⁶

Le zéro a survécu à trois passes d’élargissement du périmètre, jusqu’à chaque paquet Swift vendorisé et chaque type de fichier dans chaque dépôt.⁶ Aucun schéma interrogé n’est déclaré non plus dans les 192 fichiers .plist, .pbxproj, .entitlements et .xcconfig, ce qui se comprend : une application sans appel à canOpenURL n’a aucune raison d’en déclarer un.

La raison est banale et probablement répandue. Sur les 23 sites d’appel, neuf ouvrent un document juridique, quatre renvoient vers le produit web de l’application, deux ouvrent census.gov depuis une alerte pour qu’un utilisateur trouve son élu, deux ouvrent l’URL d’une offre d’emploi renvoyée par une API, deux sont des exports file: réservés à macOS, et un est UIApplication.openSettingsURLString derrière une alerte « Accès Santé requis ». Aucun de ces 20 appels n’interroge une autre application, puisque chaque destination est soit une URL https, à laquelle Safari répond toujours, soit une URL système. Les trois restants concentrent tout le comportement intéressant.

Le seul endroit qui valide avant d’ouvrir ne fait pas ce que vise la dépréciation : le flux de facturation de ResumeGeni envoie un POST vers /api/me/portal, puis vérifie url.scheme == "https" sur l’URL renvoyée par le serveur, au cas où un serveur compromis ou bogué transmettrait à l’application une URL file: ou à schéma personnalisé.⁶ La note d’Apple vise la validation de l’existence d’une application cible et ne dit rien de la confiance accordée à une entrée distante : supprimer ce garde-fou serait une régression de sécurité, pas une migration.

Les deux autres sont les transferts macOS de Banana List, et l’un d’eux abrite la seule véritable vérification de présence du portfolio. L’application demande NSWorkspace.shared.urlForApplication(withBundleIdentifier: "com.anthropic.claudefordesktop") != nil avant de confier une extension .mcpb embarquée à Launch Services, un bouton voisin ouvrant claude.com/download pour ceux à qui l’application manque encore. Le commentaire du code en donne le motif : sans cette vérification, macOS affiche sa propre boîte de dialogue « no application set to open the document ».⁶ Autre plateforme, et la donnée la plus utile de l’audit, parce qu’elle attrape sur le terrain le mode d’échec du tenter-puis-gérer. Une tentative ratée n’est pas toujours silencieuse, et quand le système parle à votre place, l’utilisateur lit une erreur système au lieu de votre repli.

Aucun dépôt ne déclare applinks:, donc aucune application ici ne prend en charge les liens universels, et le correctif architectural d’Apple reste à payer de mon côté aussi.⁶ Un schéma personnalisé coûte une entrée Info.plist ; un lien universel coûte un fichier sur un serveur web, un entitlement et un domaine que vous contrôlez.

Ce qui indique où se trouve le vrai travail : pas dans le code des applications maison, mais dans les feuilles de partage qui se réordonnent selon les applications installées, les sélecteurs « ouvrir dans », et les SDK d’attribution, qu’un dépôt propre n’exclut nullement.

L’audit lui-même est plus facile ici qu’ailleurs dans le cycle 27. Contrairement aux clés d’écran de lancement, qui proviennent des réglages de build et déjouent complètement une recherche textuelle, LSApplicationQueriesSchemes n’a pas d’équivalent INFOPLIST_KEY_ dans la référence des réglages de build d’Apple : un grep est donc le bon premier réflexe, et les schémas présents dans ce tableau vous disent quelle dépendance veut la réponse.¹⁶

FAQ

canOpenURL cesse-t-elle de fonctionner sous iOS 27 ?

Non, et Apple n’a pas dit quand ce serait le cas. Le symbole porte deprecatedAt 27.0, et tout le reste de la page, y compris le contrat de valeur de retour, la garantie sur l’appel open suivant, le plafond de déclaration et le budget d’appels hérité, reste documenté.² Aucune version de suppression n’apparaît dans la note de version, sur la page du symbole ni dans les notes de version de Xcode 27.¹²⁹ Anticipez un avertissement et un lent délitement plutôt qu’une rupture.

Qu’est-ce que j’écris à la place si j’ai besoin de savoir si l’application est installée ?

Tout dépend de qui contrôle la cible. Si c’est vous, publiez un lien universel et passez universalLinksOnly à open : Apple documente cette option comme n’ouvrant l’URL que lorsqu’il s’agit d’un lien universel valide avec une application installée pour le prendre en charge, si bien qu’un false signifie que rien ne s’est ouvert et que rien n’a basculé.³ Le coût est un fichier d’association bidirectionnelle sur votre serveur web.¹³ Si un tiers ne publie qu’un schéma personnalisé, il n’existe aucun remplaçant : canOpenURL répond toujours, exige toujours sa déclaration Info.plist, et le plafond de cette déclaration tombe à 25 entrées pour les applications liées à partir d’iOS 27.² Le code SwiftUI n’a rien à changer sur ce point, puisque openURL et Link n’ont jamais proposé cette vérification.⁴¹⁴

Ai-je encore besoin de LSApplicationQueriesSchemes ?

Uniquement pour canOpenURL. La documentation Launch Services d’Apple définit la clé entièrement à travers la méthode dépréciée : elle « spécifie les schémas d’URL que vous voulez que l’application puisse utiliser avec la méthode canOpenURL: de la classe UIApplication ».¹⁷ La clé n’a aucune page dans la référence moderne Information Property List d’Apple, et la discussion de la méthode dépréciée renvoie pour cela vers l’archive héritée.²¹⁷ Le remplaçant n’a besoin de rien, puisqu’Apple exempte purement et simplement open de l’exigence de déclaration.² Terminez la migration et le tableau disparaît ; gardez un seul appel et vous gardez le tableau, l’exigence de déclaration et le plafond réduit.

L’App Store rejettera-t-il un build comportant plus de 25 entrées ?

Aucune page d’Apple ne le dit. Le plafond apparaît à un seul endroit, la discussion de canOpenURL(_:), et Apple le formule comme une limite sur ce que contient la clé, pas comme une règle de soumission.² Rien dans les notes de version d’iOS 27, la page des nouveautés UIKit ou les notes de version de Xcode 27 n’y attache de conséquence lors de l’examen, et le symptôme documenté pour un schéma que le système considère comme non déclaré est un simple false à l’exécution.¹²⁸⁹ Les App Store Review Guidelines ne contiennent aucune occurrence de LSApplicationQueriesSchemes, de canOpenURL ni du chiffre de 25 entrées, alors que c’est là qu’une règle de soumission figurerait si elle existait.¹⁹ L’échec à anticiper est donc une mauvaise réponse dans votre propre code, pas un build rejeté.

À retenir

Pour les développeurs iOS : - Remplacez if canOpenURL(url) { open(url) } par let opened = await open(url) avec un repli sur !opened, puis supprimez l’entrée LSApplicationQueriesSchemes correspondante une fois qu’il ne reste plus aucun appel.² - Conservez toute vérification de schéma appliquée à une URL provenant d’un serveur. La note d’Apple vise la validation de présence d’une application, pas les entrées distantes, et les deux se ressemblent trait pour trait dans un grep.

Pour les équipes qui livrent des liens profonds entre applications d’une même famille ou des SDK : - Optez pour universalLinksOnly plutôt que canOpenURL quand vous avez besoin d’une réponse de présence, et prévoyez le fichier d’association de domaines que cela exige.³¹³ C’est la seule vérification documentée qui ne laisse rien de visible pour l’utilisateur quand l’application est absente. - Comptez les entrées de votre tableau LSApplicationQueriesSchemes avant de lier votre application avec le SDK d’iOS 27. Tout ce qui dépasse 25 entrées sort du plafond documenté, et le symptôme d’Apple pour un schéma non déclaré est un simple false, qui se lit exactement comme une application non installée.²

Pour les responsables de publication : - N’inscrivez pas cette dépréciation comme bloquant de publication. Sans date de suppression ni conséquence à l’exécution, elle passe derrière la clé d’écran de lancement qui coûte un rejet, l’obligation de scène qui empêche le lancement, et la macro @State qui casse la compilation. - Traitez le plafond de 25 entrées comme le seul point doté d’un vrai déclencheur, car il dépend du SDK avec lequel vous liez votre application, pas de l’OS qu’exécutent vos utilisateurs.²

Le cycle 27 continue d’arriver avec des poids différents, et lire ce poids, c’est bien employer le cycle : la clé d’écran de lancement bloque une soumission, l’obligation de scène empêche une application de se lancer, la macro @State casse la compilation, On Demand Resources déclenche un compte à rebours de migration, et canOpenURL se contente d’avertir. Fabriquer de l’urgence autour d’un avertissement gaspille un cycle. La ligne à surveiller se trouve dans un paragraphe de discussion plutôt que dans une note de version, et c’est un chiffre. Le sommaire complet est la série Écosystème Apple.

Références