canOpenURL quedó obsoleto: qué llamar en su lugar

Apple retiró en tres oraciones un método que venía incluido desde iOS 3.0: “canOpenURL: quedó obsoleto. Intenta abrir la URL y maneja cualquier fallo en lugar de validarla primero. Usar universal links en vez de esquemas de URL personalizados elimina por completo la necesidad de esa validación”.¹

La entrada lleva el radar 179874781 y aparece bajo UIKit, Deprecations, justo debajo del mandato del ciclo de vida basado en escenas que impide que las apps se lancen.¹ La entrada vecina nombra una consecuencia. La de canOpenURL no nombra ninguna.

Cada una de las tres oraciones es una instrucción distinta, y solo la segunda responde a la pregunta que de verdad se hace quien desarrolla: ¿qué escribo en su lugar? La respuesta de Apple cambia la forma de la llamada, no solamente el nombre.

TL;DR

• Apple declaró obsoleto canOpenURL(_:) en la versión 27.0 de iOS, iPadOS, Mac Catalyst, tvOS y visionOS, con el mensaje “Prefiere intentar abrir las URL y manejar cualquier fallo”.² Sin versión de eliminación, sin consecuencia en tiempo de ejecución.
• El cambio que de verdad muerde es un número, y vive en la discusión del propio método obsoleto en lugar de en alguna nota de la versión: “Las apps enlazadas en iOS 27 o posterior están limitadas a un máximo de 25 entradas en la clave LSApplicationQueriesSchemes”, frente a las 50 anteriores.² El disparador es el SDK contra el que enlazas.
• El reemplazo mecánico es open(_:options:completionHandler:) y su booleano, que no necesita entrada en la lista de esquemas permitidos: “el método open(_:options:completionHandler:) no está sujeto al requisito de LSApplicationQueriesSchemes”.²
• Un patrón se queda sin reemplazo, porque canOpenURL responde antes de que dibujes nada mientras que intentar responde por consecuencia: un éxito pone otra app en primer plano.² Lo que sobrevive es universalLinksOnly, una opción de open disponible desde iOS 10 que Apple no ha declarado obsoleta: “abre la URL solo si la URL es un universal link válido y hay una app instalada capaz de abrirla”.³
• SwiftUI nunca incluyó el método, y su booleano de finalización ya significa “puede abrir” y no “abrió”.⁴¹⁵ En siete de mis apps publicadas y 463 archivos Swift propios, canOpenURL y LSApplicationQueriesSchemes aparecen cero veces cada uno.⁶

La obsolescencia sin consecuencia, y el número que sí la tiene

Apple escribió una obsolescencia, no una eliminación. La página del símbolo lleva deprecatedAt 27.0 en las cinco plataformas donde existe UIApplication, y el resumen, la discusión, el contrato del valor de retorno y la declaración siguen todos en su sitio.² Ninguna página de Apple nombra una versión en la que el método deje de funcionar, y el precedente más cercano apunta en la dirección contraria: openURL(_:), obsoleto desde iOS 10.0, todavía tiene página, y su nota dice hoy “Llamar a este método no tiene efecto”.⁷ Una década de obsolescencia produjo un método inerte antes que ausente, lo cual es precedente y no calendario.

El anuncio también es más estrecho que la obsolescencia. La nota de la versión vive en una página que Apple titula “iOS & iPadOS 27 Beta 4 Release Notes” y no aparece en ningún otro lugar, mientras que los metadatos del símbolo declaran el método obsoleto igualmente en tvOS y visionOS, y ni la página de novedades de UIKit de junio de 2026 ni las notas de la versión de Xcode 27 lo mencionan en absoluto.¹²⁸⁹ La página del símbolo es aquí la mitad duradera del registro.

Lo cual convierte al número enterrado en la verdadera historia. Dentro de la discusión del propio método obsoleto, en el mismo inciso que exige la declaración en primer lugar: “Las apps enlazadas en iOS 15 o posterior están limitadas a un máximo de 50 entradas en la clave LSApplicationQueriesSchemes. Las apps enlazadas en iOS 27 o posterior están limitadas a un máximo de 25 entradas en la clave LSApplicationQueriesSchemes”.²

La lista de esquemas permitidos sobrevive a la obsolescencia del único método al que sirve, y el tope se reduce a la mitad para las apps enlazadas contra el nuevo SDK. Apple enuncia el tope y ahí se detiene. Nada dice qué ocurre pasada la entrada 25, y leer juntas las dos mitades del inciso da una respuesta probable antes que documentada: los esquemas no declarados siempre devuelven false, así que una app que declara 40 esquemas y vuelve a enlazar probablemente empiece a tratar 15 de ellos como ausentes. Apple nunca dice cuáles 15, ni que el truncamiento siga el orden del array. Trata el mecanismo como inferencia y el riesgo como real, porque un false se ve idéntico tanto si falta la app como si falta la declaración.

El párrafo siguiente de esa misma discusión trae un segundo límite, y los dos son alternativas antes que sumandos. Apple los ata al SDK contra el que enlazaste: “Si enlazas tu app contra una versión anterior de iOS pero se ejecuta en iOS 9.0 o posterior, puedes llamar a este método hasta 50 veces. Al alcanzar ese límite, las llamadas siguientes siempre devuelven false. Si el usuario reinstala o actualiza la app, iOS reinicia el límite”.² Lee la condición. Ese presupuesto pertenece a las apps enlazadas antes de iOS 9, algo que hoy no puedes publicar. Toda app actual vive bajo la otra rama, el tope de la declaración, que es el que Apple recortó de 50 entradas a 25. Ambos se agotan hasta el mismo false silencioso, y ambos están documentados únicamente dentro del método que Apple acaba de declarar obsoleto.

La lectura en clave de privacidad también es inferencia. canOpenURL era la forma estándar de detectar qué apps tenía instaladas una persona, una señal del dispositivo antes que una comprobación de enlaces, y la propia definición de fingerprinting de Apple cubre las API que “se usan indebidamente para acceder a señales del dispositivo e intentar identificar el dispositivo o al usuario”.¹⁰ Apple nunca conecta ambas cosas: el método no aparece en ninguna lista de API de motivo obligatorio, y la nota de la versión, el mensaje de obsolescencia y la página del símbolo dan todos una justificación puramente mecánica.¹²¹⁰ Un tope de consultas reducido a la mitad encaja con la historia de privacidad, y Apple no la ha puesto por escrito.

Qué prometía realmente canOpenURL

Un true era una garantía sobre la llamada siguiente, no una descripción de la URL: “Cuando este método devuelve true, iOS garantiza que las llamadas posteriores al método open(_:options:completionHandler:) con la misma URL lanzarán correctamente una app capaz de manejarla”.² Un false era ambiguo por diseño, con dos causas y sin manera de saber cuál se disparó: “false si el dispositivo no tiene instalada una app registrada para manejar el esquema de la URL, o si no has declarado el esquema de la URL en tu archivo Info.plist”.²

Hay tres cosas que nunca respondió y que es fácil suponer que sí: “El valor de retorno no indica la validez de la URL, si el recurso especificado existe ni, en el caso de un universal link, si el dispositivo tiene instalada una app registrada para responder a ese universal link”.² La tercera cláusula importa para la migración que Apple recomienda, y vuelve más abajo.

La propiedad que hacía al método estructuralmente útil es la que nada reemplaza. canOpenURL lleva la palabra clave nonisolated en su declaración, y Apple afirma sin rodeos que “puedes llamar a este método con seguridad desde un hilo distinto al principal”.² Un booleano síncrono disponible fuera del actor principal puede condicionar una decisión de disposición antes de que se renderice nada.

Intentar y manejar: la forma que cambia

La instrucción de reemplazo de Apple ocupa una sola cláusula, y la comparación entre el antes y el después parece 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()
}

La entrada del Info.plist desaparece, y Apple lo dice directamente: “A diferencia de este método, el método open(_:options:completionHandler:) no está sujeto al requisito de LSApplicationQueriesSchemes. Si hay una app disponible para manejar la URL, el sistema la lanzará, aunque no hayas declarado el esquema”.² Un código base que migre por completo borra la clave, y con ella el problema de las 25 entradas.

Dos diferencias sobreviven a la reescritura, y ambas son estructurales.

La primera es el aislamiento y el momento de la llamada. La declaración de UIApplication dice @MainActor class UIApplication, así que open se ejecuta en el actor principal, y su resumen lo llama por su nombre: “Intenta abrir de forma asíncrona el recurso en la URL especificada”.¹¹¹² El booleano síncrono y ejecutable fuera del hilo principal ya no está, de modo que la lógica de validar-y-luego-abrir que viva en una capa de modelo, en una cola en segundo plano o en una función auxiliar no aislada tiene que mudarse o volverse async.

La segunda es que ya no puedes preguntar en privado. Cuando el intento tiene éxito, otra app queda en primer plano: “iOS lanza esa app y le pasa la URL. (Lanzar la app trae la otra app al primer plano)”.¹² La respuesta llega como efecto colateral de actuar sobre ella. Apple no documenta nada visible para el caso fallido, solo que “se llama al manejador de finalización con el parámetro de éxito establecido en false”, pero todo patrón que necesitaba la respuesta antes de la acción la pierde: mostrar una fila de “abrir en otra app” solo cuando esa app está, ordenar una hoja para compartir según lo que hay instalado o elegir un valor por defecto entre destinos que compiten.¹²

La propia documentación de Apple tampoco se ha puesto al día. La página de open(_:options:completionHandler:) sigue indicando: “Para determinar si hay instalada una app capaz de manejar la URL, llama al método canOpenURL(_:) antes que a este”.¹² La página del reemplazo recomienda el método obsoleto.

La comprobación de presencia que sobrevive

Hay una vía documentada que responde a la pregunta de canOpenURL intentando, sin nada visible para el usuario cuando la respuesta es no. UIApplication.OpenExternalURLOptionsKey.universalLinksOnly existe desde iOS 10, Apple no la ha declarado obsoleta y su comportamiento es exactamente una comprobación de presencia: “el método abre la URL solo si la URL es un universal link válido y hay una app instalada capaz de abrirla”.³

// 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 rama del false es la parte valiosa. No se lanzó ningún navegador, ninguna app pasó al frente, y quien llama se enteró de lo que canOpenURL solía decirle. La contrapartida se esconde en el nombre de la opción: sin ella, un intento sobre https tiene éxito siempre que un navegador pueda encargarse, ya que “si no hay ninguna app disponible para manejar un universal link, iOS lo enruta al navegador predeterminado de la persona, permitiendo que el sitio web asociado responda”.² La opción compra un booleano con significado a costa de suprimir el respaldo que hace agradables a los universal links. Apple define el valor como “un objeto NSNumber que contiene un valor booleano”, algo que un true de Swift satisface mediante el puente con Objective-C.³

El precio es arquitectónico, y es la tercera oración de Apple. Los universal links necesitan una asociación en ambos sentidos: “Cuando alguien instala tu app, el sistema comprueba un archivo almacenado en tu servidor web para verificar que tu sitio web permite a tu app abrir URL en su nombre. Solo tú puedes almacenar ese archivo en tu servidor, lo que asegura la asociación entre tu sitio web y tu app”.¹³ Un archivo en un servidor bajo tu control es exactamente lo que un esquema personalizado nunca exigió, y por eso la migración funciona para tu propia familia de apps y no hace nada por un tercero que solo publica theirapp://. Vienen de la mano dos sorpresas documentadas: tu app abriendo tu propio universal link no se enruta hacia tu app, y un toque sobre el mismo dominio mientras navegas por tu sitio en Safari se queda en Safari.¹³

Y ahí es donde aterriza la tercera cláusula de antes: canOpenURL tampoco respondía nunca la pregunta de presencia para un universal link.² Migrar elimina la detección de presencia en lugar de portarla, porque un intento plano sobre https ya tiene éxito tanto si respondió la app como si respondió solo el sitio web. Un patrón que funcionaba únicamente porque los esquemas personalizados filtraban el estado de instalación se va junto con los esquemas, y la nota de la versión de Apple presenta esa pérdida como la razón para migrar.

SwiftUI nunca tuvo el método

El lado de SwiftUI es corto, y la noticia es buena. EnvironmentValues.openURL, OpenURLAction y Link llevan disponibilidad desde iOS 14.0 sin obsolescencia, y ninguno de los tres expone una comprobación de validez.⁴⁵¹⁴

Lo que SwiftUI ofrece en su lugar es intentar-y-manejar con la semántica que Apple quiere ahora en todas partes, y la documentación del parámetro de finalización dice que el booleano responde a la vieja pregunta: “Un closure al que el método llama tras determinar si puede abrir la URL, pero posiblemente antes de abrirla del todo. El closure recibe un valor booleano que indica si el método puede abrir la URL”.¹⁵ Puede abrir, no abrió. El propio ejemplo de Apple lo imprime:

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

Link no expone ningún booleano y delega en el entorno, donde la acción por defecto ya implementa la historia de los universal links: “la acción por defecto abre un Universal Link en la app asociada si es posible, o en el navegador web predeterminado del usuario si no lo es”.⁵ Una OpenURLAction personalizada que devuelva .handled, .discarded o .systemAction intercepta cada Link y cada enlace en markdown dentro de un Text que lea la acción desde ese entorno.⁵

Hay un hueco que importa antes de planificar una migración solo con SwiftUI. OpenURLAction no tiene diccionario de opciones. Sus firmas de llamada son callAsFunction(_:), callAsFunction(_:completion:) y la incorporación de iOS 26 callAsFunction(_:prefersInApp:), y ninguna de las tres acepta universalLinksOnly.¹⁵¹⁸ Una comprobación de presencia sin efectos colaterales sigue implicando llamar a UIApplication.shared.open.

Siete apps, 463 archivos, cero llamadas

Audité mi propio portafolio antes de escribir sobre el de nadie más, esperando una lista de migración. No hay nada que migrar.⁶

El cero sobrevivió a tres pasadas que fueron ampliando el alcance, hasta cada paquete Swift incorporado y cada tipo de archivo en cada repositorio.⁶ Tampoco hay nada que declare un esquema consultado en 192 archivos .plist, .pbxproj, .entitlements y .xcconfig, lo cual es coherente: una app sin ninguna llamada a canOpenURL no tiene motivo para declarar ninguno.

La razón es mundana y probablemente común. De los 23 puntos de llamada, nueve abren un documento legal, cuatro derivan al producto web de la propia app, dos abren census.gov desde una alerta para que el usuario encuentre a su representante, dos abren la URL de una oferta de trabajo que llega desde una API, dos son exportaciones file: exclusivas de macOS, y uno es UIApplication.openSettingsURLString detrás de una alerta de “se requiere acceso a Salud”. Ninguno de esos 20 consulta por otra app, porque cada destino es o bien https, al que Safari siempre responde, o bien una URL del sistema. Los tres restantes concentran todo el comportamiento interesante.

El único lugar que valida antes de abrir no está haciendo aquello de lo que trata la obsolescencia: el flujo de facturación de ResumeGeni hace POST a /api/me/portal y luego comprueba url.scheme == "https" sobre la URL que devuelve el servidor, por si un servidor comprometido o con errores le entrega a la app una URL file: o de esquema personalizado.⁶ La nota de Apple apunta a validar si existe una app de destino y no dice nada sobre confiar en entradas remotas, así que borrar esa protección sería una regresión de seguridad, no una migración.

Los otros dos son las derivaciones de macOS de Banana List, y uno de ellos guarda la única comprobación de presencia genuina del portafolio. La app pregunta NSWorkspace.shared.urlForApplication(withBundleIdentifier: "com.anthropic.claudefordesktop") != nil antes de entregar una extensión .mcpb incluida a Launch Services, con un botón cercano que abre claude.com/download para quien primero necesite la app. El comentario del código nombra el motivo: sin la comprobación, macOS muestra su propio diálogo de “no hay ninguna aplicación configurada para abrir el documento”.⁶ Otra plataforma, y el dato más útil de la auditoría, porque captura en la práctica el modo de fallo de intentar-y-manejar. Un intento fallido no siempre es silencioso, y cuando el sistema habla por ti el usuario lee un error del sistema en vez de tu respaldo.

Ningún repositorio declara applinks:, así que ninguna app de aquí admite universal links, y la solución arquitectónica de Apple también está sin pagar de mi lado.⁶ Un esquema personalizado cuesta una entrada en el Info.plist; un universal link cuesta un archivo en un servidor web, un entitlement y un dominio bajo tu control.

Lo cual señala dónde está el trabajo de verdad: no en el código de las apps propias, sino en las hojas para compartir que se reordenan según la app instalada, en los selectores de “abrir en” y en los SDK de atribución, nada de lo cual queda descartado por un repositorio limpio.

La auditoría en sí es más fácil aquí que en otros puntos del ciclo 27. A diferencia de las claves de la pantalla de lanzamiento, que llegan desde los ajustes de compilación y derrotan por completo a una búsqueda de texto, LSApplicationQueriesSchemes no tiene equivalente con INFOPLIST_KEY_ en la referencia de ajustes de compilación de Apple, así que un grep es el primer movimiento correcto, y saber de quién son los esquemas que aparecen en ese array te dice qué dependencia quiere la respuesta.¹⁶

Preguntas frecuentes

¿canOpenURL deja de funcionar en iOS 27?

No, y Apple no ha dicho cuándo lo hará. El símbolo lleva deprecatedAt 27.0, y todo el resto de la página, incluidos el contrato del valor de retorno, la garantía sobre la llamada siguiente a open, el tope de la declaración y el presupuesto heredado de llamadas, sigue documentado.² No aparece ninguna versión de eliminación en la nota de la versión, en la página del símbolo ni en las notas de la versión de Xcode 27.¹²⁹ Planifica pensando en una advertencia y un deterioro lento, no en una ruptura.

¿Qué escribo en su lugar si necesito saber si la app está instalada?

Depende de si controlas el destino. Si lo controlas, publica un universal link y pasa universalLinksOnly a open, que Apple documenta como abrir la URL solo cuando es un universal link válido con una app instalada que pueda recogerlo, de modo que un false significa que no se abrió nada y no cambió nada.³ El costo es un archivo de asociación en ambos sentidos en tu servidor web.¹³ Si un tercero solo publica un esquema personalizado, no existe reemplazo: canOpenURL sigue respondiendo, sigue necesitando su declaración en el Info.plist, y el tope de esa declaración se reduce a la mitad, hasta 25 entradas, para las apps enlazadas en iOS 27 o posterior.² El código en SwiftUI no necesita ningún cambio en este frente, porque openURL y Link nunca ofrecieron la comprobación.⁴¹⁴

¿Sigo necesitando LSApplicationQueriesSchemes?

Solo para canOpenURL. La documentación de Launch Services de Apple define la clave enteramente en términos del método obsoleto: “especifica los esquemas de URL que quieres que la app pueda usar con el método canOpenURL: de la clase UIApplication”.¹⁷ La clave no tiene página alguna en la referencia moderna de Information Property List de Apple, y la discusión del método obsoleto enlaza al archivo histórico para encontrarla.²¹⁷ El reemplazo no necesita nada, porque Apple exime a open del requisito de declaración sin más.² Termina de migrar y el array desaparece; conserva una sola llamada y conservas el array, el requisito de declaración y el tope más pequeño.

¿La App Store rechazará una compilación con más de 25 entradas?

Ninguna página de Apple lo dice. El tope aparece en un solo lugar, la discusión de canOpenURL(_:), y Apple lo formula como un límite sobre lo que contiene la clave antes que como una regla de envío.² Nada en las notas de la versión de iOS 27, en la página de novedades de UIKit ni en las notas de la versión de Xcode 27 le atribuye una consecuencia de revisión, y el síntoma documentado para un esquema que el sistema trata como no declarado es un false sencillo en tiempo de ejecución.¹²⁸⁹ Las App Store Review Guidelines no contienen ninguna aparición de LSApplicationQueriesSchemes, canOpenURL ni de la cifra de 25 entradas, que es donde viviría una regla de envío si existiera.¹⁹ Así que el fallo para el que hay que prepararse es una respuesta equivocada en tu propio código antes que una compilación rechazada.

Conclusiones clave

Para quienes desarrollan en iOS: - Reemplaza if canOpenURL(url) { open(url) } por let opened = await open(url) con un respaldo sobre !opened, y borra la entrada correspondiente de LSApplicationQueriesSchemes cuando no quede ninguna llamada.² - Conserva cualquier comprobación de esquema que hagas sobre una URL que llegue desde un servidor. La nota de Apple apunta a validar la presencia de una app, no la entrada remota, y ambas cosas se ven idénticas en un grep.

Para equipos que publican deep links entre apps de una misma familia o SDK: - Recurre a universalLinksOnly en vez de a canOpenURL cuando necesites una respuesta de presencia, y presupuesta el archivo de dominios asociados que exige.³¹³ Es la única comprobación documentada que no deja nada visible para el usuario cuando la app falta. - Cuenta las entradas de tu array LSApplicationQueriesSchemes antes de enlazar contra el SDK de iOS 27. Todo lo que pase de 25 entradas cae fuera del tope documentado, y el síntoma de Apple para un esquema no declarado es un false sencillo, que se lee exactamente igual que una app que no está instalada.²

Para quienes gestionan versiones: - No programes esta obsolescencia como bloqueante de una versión. Sin fecha de eliminación y sin consecuencia en tiempo de ejecución, queda por detrás de la clave de la pantalla de lanzamiento que cuesta un rechazo, del mandato de escenas que impide el lanzamiento y de la macro @State que rompe la compilación. - Trata el tope de 25 entradas como el único punto con un disparador real, porque depende del SDK contra el que enlazas y no del sistema operativo que ejecutan tus usuarios.²

El ciclo 27 va llegando con pesos distintos, y leer el peso es la manera de gastar bien el ciclo: la clave de la pantalla de lanzamiento bloquea un envío, el mandato de escenas impide que una app se lance, la macro @State rompe una compilación, On Demand Resources pone en marcha un reloj de migración, y canOpenURL solo advierte. Fabricar urgencia alrededor de la advertencia desperdicia un ciclo. La línea que vale la pena vigilar está en un párrafo de discusión y no en una nota de la versión, y es un número. El índice completo de la serie es la Serie del ecosistema Apple.

Referencias