La casilla de redes sociales de la App Store y lo que cuesta

Dos campos booleanos de la API de App Store Connect cargan con todo el peso de un requisito de envío que arranca en septiembre: socialMedia y socialMediaAgeRestricted.¹ El segundo cuesta un entitlement, la adopción de una API y una bifurcación de comportamiento dentro de tu app.

Apple anunció el requisito el 8 de junio de 2026: “Starting September 2026, you’ll be required to indicate whether your app or game includes social media capabilities in order to submit new versions or updates to the App Store, or for notarization for distribution on alternative app marketplaces.”² El 9 de julio Apple publicó el cambio en el cuestionario y añadió una frase que decide cómo conviene invertir las semanas previas: “You can review and answer these questions starting today.”³

En resumen

• La declaración ya está disponible en App Store Connect y se vuelve obligatoria en septiembre de 2026, así que el margen entre lo disponible y lo exigido es tuyo para dedicarlo a una decisión en vez de a una fecha límite.²³
• Apple sí define qué son las “social media capabilities”, en cuatro lugares, y tres de ellos no coinciden entre sí. En junio lo acota a feeds “that visibly spreads content to many users”; en julio elimina la cláusula por completo.²³⁴
• La API de App Store Connect expone la respuesta como dos booleanos escribibles y mantiene userGeneratedContent y messagingAndChat como preguntas aparte, con umbrales de clasificación aparte. Las redes sociales son un eje nuevo, no un cambio de nombre.¹⁴
• Quedar fuera de la categoría de Redes sociales para menores de 13 años exige tres condiciones, no una. El anuncio de Apple menciona la API Declared Age Range; la Ayuda de App Store Connect añade que los menores de 13 años no deben tener acceso alguno y que “Only age-appropriate UGC is delivered.”²⁴
• La API Declared Age Range existe en iOS, iPadOS, Mac Catalyst y macOS, y en ningún otro lugar.⁵ Una app de tvOS, visionOS o watchOS igual responde la pregunta en septiembre, y la vía documentada para acogerse a la excepción no existe en su plataforma.

El único cambio de este ciclo disparado por un calendario

Todos los demás cambios disruptivos que he cubierto en este ciclo esperan a que te muevas primero. El requisito de pantalla de inicio se activa al compilar contra el SDK de iOS 27.0. La macro @State se activa al abrir el proyecto en Xcode 27. La obsolescencia de On Demand Resources dispara una advertencia del compilador que puedes ignorar indefinidamente. Si no tocas tu toolchain, ninguno te alcanza.

La declaración de redes sociales te alcanza igual, porque Apple la ató a un mes y a un acto que ibas a realizar de todas formas. Una corrección de una sola línea viaja por el mismo canal de envío que un lanzamiento de funciones, y en septiembre ese canal hace la pregunta.

El alcance es estrecho y conviene leerlo con exactitud. El requisito cubre “new versions or updates to the App Store” y “notarization for distribution on alternative app marketplaces.”² En julio se repite el par como “new apps or updates to the App Store” y “apps for notarization for alternative distribution.”³ Ninguno de los dos anuncios menciona una versión del SDK, un deployment target ni una plataforma. Las apps ya publicadas siguen vendiéndose. La puerta está en la entrada del próximo envío.

Lo que te cuesta la respuesta es quedar en una categoría que los padres pueden limitar. Time Allowances llega este otoño junto con Ask to Browse, Schedules y un Tiempo de uso rediseñado, y da a los padres “more flexible ways to manage the time their kids spend in apps across categories, including Entertainment, Games, and Social Media”, con orientación adaptada a la edad como punto de partida.¹⁶ La ubicación en Entretenimiento y Juegos sigue tu categoría de App Store Connect. La ubicación en Redes sociales depende únicamente de la respuesta del cuestionario, “regardless of the category selected in App Store Connect.”² Un juego de puzles con un feed cae en la categoría que un padre limita primero, diga lo que diga la ficha del producto.

Apple define el término, y las definiciones se desplazan

El modo típico de fallar ante una pregunta de política es adivinar el sentido de una palabra sin definir. Apple publicó una definición, lo que reduce la adivinanza, y la publicó cuatro veces con contornos distintos.

Junio la plantea de forma inclusiva: “This includes the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method that visibly spreads content to many users.”²

Julio la plantea como definición, y más corta: “A social media capability is defined as the ability to redistribute, amplify, or interact with user-generated content through a social feed or similar discovery method.”³ El matiz sobre difundir contenido de forma visible entre muchos usuarios desapareció.

La Ayuda de App Store Connect trae la versión más larga, conserva el matiz y agrega ejemplos: “Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users. May include: users reposting, liking, commenting, reacting, or making user-generated content more visible through a social feed, community, search, or other sharing and discovery tools.”⁴

Tres de las cuatro exigen difusión amplia y visible. Una no, y para una app que roza el límite esa diferencia decide la respuesta. Yo trataría la página de Ayuda como la que manda, porque el cuestionario enlaza a ella y los anuncios envejecen; leerlo así es una inferencia mía, no una instrucción de Apple. El “May include” también importa: Apple enumera ejemplos en vez de cerrar el conjunto, así que una función que no se parece a ninguno de los cinco verbos listados igual puede quedar dentro.

Lo que afila el límite es la compañía que rodea al descriptor. Apple define User-Generated Content por separado, como “the broad distribution of content created by users as a component of the app’s intended user experience”, y Messaging and Chat otra vez por separado, como usuarios que “can directly communicate with one another through features within the app.”⁴ La API de App Store Connect conserva la división al pie de la letra, con userGeneratedContent, messagingAndChat y socialMedia como tres booleanos independientes.¹

Las clasificaciones divergen con la misma nitidez. El contenido generado por usuarios y la mensajería aparecen en la definición de 4+ de Apple. Las redes sociales aparecen por primera vez en 13+.⁴ Una app puede alojar contenido de usuarios, permitir que la gente se escriba y aun así obtener una clasificación 4+; agrega un feed que amplifique ese mismo contenido hacia desconocidos y el umbral salta nueve años. Ambos descriptores de redes sociales viven solo en el esquema de clasificación de OS 26 en adelante, y la tabla de Apple para versiones anteriores del OS no incluye ninguna entrada de redes sociales en ninguna clasificación.⁴

El campo ya se puede responder hoy

Tres artefactos de Apple confirman que el cambio del cuestionario ya está publicado, que es el punto práctico de todo este artículo.

El anuncio del 9 de julio dice que el cuestionario “now includes questions about your app’s social media capabilities” e invita a responder de inmediato.³ La API de App Store Connect documenta socialMedia como “A Boolean value that indicates whether the app includes social media features” y socialMediaAgeRestricted como “A Boolean value that indicates whether the app’s social media features are age restricted.”¹ La especificación OpenAPI publicada por Apple los trae a ambos como booleanos escribibles y anulables.¹ Están junto a ageAssurance, agregado en la revisión anterior del cuestionario, cuya definición nombra la “declared age range API” como mecanismo válido.⁴¹⁵ Adoptar la excepción te deja, por tanto, dentro de esa definición también, lo que a mi juicio es una segunda pregunta que conviene revisar, no una que convenga dejar quieta.

Quien automatice envíos debería aprenderse la estructura ahora: lee la declaración con GET /v1/appInfos/{id}/ageRatingDeclaration, escríbela con PATCH /v1/ageRatingDeclarations/{id} y pasa cualquiera de los dos booleanos al parámetro fields[ageRatingDeclarations].¹ Un pipeline que arma a mano los payloads de clasificación por edad sigue pasando hasta el día en que deja de pasar.

Una consecuencia salió a la luz solo en julio: “Apps with these capabilities will display a new Social Media content descriptor on their App Store product page.”³ Responder que sí cambia tu ficha, no solo una categoría de controles parentales.

Así que abre el cuestionario esta semana y lee la clasificación que calcula App Store Connect. Hacerlo no compromete nada hasta que envíes, y convierte una fecha límite en una decisión que ya tomaste.

La excepción tiene tres condiciones, no una

El anuncio de Apple presenta la vía para menores de 13 años como si fuera una sola llamada a la API: “If you indicate that your app or game includes social media capabilities but they are disabled for anyone under 13, it won’t be included in the Time Allowance category for Social Media for users under 13… You’ll also need to use the Declared Age Range API (at a minimum) to check users’ age ranges.”²

La Ayuda de App Store Connect enuncia ese mismo descriptor como tres requisitos: “Users under 13 don’t have access to social media capabilities. At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features. Only age-appropriate UGC is delivered.”⁴

La tercera frase es la que nadie cita. “Only age-appropriate UGC is delivered” es una obligación de moderación sin API asociada, sin umbral publicado y sin prueba que puedas ejecutar. Apple no define ni qué es apropiado para la edad ni cuál es el mecanismo de entrega. Un equipo que adopta la verificación de edad y entrega el mismo feed sin filtrar a alguien de 12 años ha cumplido una condición de tres, según el propio texto de la página de Ayuda.

Fíjate también en lo que la excepción no te consigue. La propia frase de Apple continúa diciendo que una app así “will remain in the Social Media category for users 13 and above.”² La exención cubre solo a los menores de 13 años, así que alguien de 14 sigue topándose con el límite que un padre haya puesto a Redes sociales.

Las tablas de clasificación arrastran una tensión que no pude resolver. El anuncio de Apple dice que la opción restringida deja que tus “overall responses in the age rating questionnaire” determinen la clasificación, lo que “may result in a rating lower than 13+.”² Sin embargo, la tabla global de Apple lista tanto “Social media” como “Social media disabled for users under 13” bajo Capabilities en 13+, y las tablas regionales las colocan juntas en 16+ en Australia, A16 en Brasil, 15+ en Corea y 16+ en Vietnam.⁴ Leído como se lee cualquier otra fila, donde un descriptor fija un piso, la opción restringida también parece fijar un piso de 13+. Apple no reconcilia nada, y no voy a adivinar qué documento implementa la calculadora. Selecciona la opción en el cuestionario en vivo, lee la clasificación calculada y confía en la calculadora por encima de ambos textos.

Seguir la casilla hacia dentro de la app

Supongamos que te acoges a la excepción. Activas la capacidad Declared Age Range en el target dentro de Xcode, lo que agrega el entitlement com.apple.developer.declared-age-range: “A Boolean value indicating whether your app may request a person’s age range.”⁶ Después llamas a la API con los umbrales que te importan, que en SwiftUI llega como una acción del entorno:⁵

Apple le impone a esa acción una regla de ubicación: úsala “in response to user interactions”, y el propio ejemplo de Apple pone la llamada detrás de un botón.⁵ La solicitud puede presentar una hoja del sistema, así que dispararla desde .task o onAppear le lanza un aviso de permiso a alguien que todavía no pidió nada. Cuélgala mejor del toque que entra a la superficie restringida.

import SwiftUI
import DeclaredAgeRange

@available(iOS 26.0, *)
struct SocialFeedGate: View {
    @Environment(\.requestAgeRange) private var requestAgeRange
    @State private var feedEnabled = false
    @State private var checking = false

    var body: some View {
        if feedEnabled {
            FeedView()
        } else {
            Button("Open community feed") {
                checking = true
                Task {
                    feedEnabled = await resolveGate()
                    checking = false
                }
            }
            .disabled(checking)
        }
    }

    private func resolveGate() async -> Bool {
        guard let response = try? await requestAgeRange(ageGates: 13) else {
            return false          // AgeRangeService.Error: your default, not Apple's
        }
        guard case let .sharing(ageRange) = response else {
            return false          // .declinedSharing
        }
        guard let lowerBound = ageRange.lowerBound else {
            return false          // nil lower bound means below your lowest gate
        }
        return lowerBound >= 13
    }
}

Cuatro detalles de ese listado deciden si el filtro aguanta.

Tienes como máximo tres umbrales. Ambas sobrecargas se detienen en tres: la acción de SwiftUI es callAsFunction(ageGates threshold1: Int, _ threshold2: Int? = nil, _ threshold3: Int? = nil), y el método de UIKit solo añade el anclaje de presentación.⁷ Cuatro tramos es el techo. Si necesitas 13 por la regla de Apple y 16 por la ley australiana, ya gastaste tres de cuatro antes de diseñar nada.

Un límite inferior nil es la respuesta, no un error. AgeRange.lowerBound y upperBound son ambos Int?, y Apple enuncia el caso nil sin rodeos: “When this value is nil, the person’s age range is below your lowest specified age, indicating they are under your minimum age requirement.”⁸ El código que desempaqueta con optimismo invierte el filtro justo sobre la población a la que debería proteger.

Rechazar es una rama real, y Apple no dice qué hacer con ella. AgeRangeService.Response trae .sharing(range:) y .declinedSharing.⁹ En algunas regiones reguladas “the system automatically provides the person’s age range” y las personas “can’t decline sharing”; en regiones no reguladas, “If the person declines, you receive a declinedSharing response.”¹⁰ Un rechazo es indistinguible de un adulto que valora su privacidad: trátalo como menor de 13 y bloqueas a personas adultas; trátalo como adulto y abres la puerta que prometiste cerrar. Apple te deja el valor por defecto a ti. Yo denegaría por defecto y lo diría en la interfaz.

Tus umbrales son orientativos. El sistema puede devolver rangos de edad que anulan los umbrales que especificas “based on the person’s location and applicable regulations”, y cuando la normativa local exige umbrales concretos, el rango de edad devuelto “reflects regulatory requirements” en vez de ceñirse a los límites que fijaste.⁷ El código que da por hecho que los límites devueltos coinciden con los solicitados se rompe primero en las jurisdicciones más estrictas.

Hay otro comportamiento que pertenece al diseño, y espero que genere tickets de soporte. Apple guarda la respuesta en caché: “When a person’s age crosses into a new range (for example, when they turn 13), the API continues returning the previous range until the anniversary of their original declaration.”¹⁰ Alguien que cumple 13 un lunes puede seguir leyéndose como menor de 13 durante meses. El remedio es una ruta de Configuración que el usuario recorre solo, bajo su nombre, luego Información personal y luego Rango de edad para apps.¹⁰ Cualquier app que filtre por 13 necesita esa instrucción en su propia UI, porque nadie la encuentra de otro modo.

Dos detalles menores importan en la etapa de diseño. isEligibleForAgeFeatures informa si la persona está en una región que exige verificación de edad, y en macOS “returns false because the system doesn’t require Age Assurance for the person or device”, así que una app de Mac llama directamente a requestAgeRange.¹¹ Y AgeRangeDeclaration, que informa cómo se estableció la edad, ya cambió: seis casos granulares en 26.2 que nombraban pago, documento de identidad y otros métodos para la persona y su tutor, colapsados en un único caso confirmed en 26.5.¹² Si preguntas qué método verificó a un usuario, la API actual ya no lo dice.

Y luego está el piso de plataformas, que declaran los metadatos de disponibilidad y ninguna fuente en prosa. Declared Age Range publica iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 y macOS 26.0, y nada más: sin fila de tvOS, sin fila de visionOS, sin fila de watchOS.⁵ Time Allowances llega a las mismas familias, “iOS 27, iPadOS 27, and macOS 27, or later”, mientras que el requisito de declaración no lleva ningún calificador de plataforma.²³ Una app de tvOS o visionOS con un feed social responde en septiembre y no puede cumplir el mínimo documentado de la excepción, porque la API que esta nombra no existe allí. Leer el desajuste como un hueco y no como una exención intencional es una inferencia mía; Apple no ha publicado nada en ninguna dirección.

Qué declaran ocho apps mías

Hice la revisión antes de escribir sobre el código ajeno: ocho proyectos de Xcode, 491 archivos Swift.¹³ Ninguno contiene CKShare, UICloudSharingController, una base de datos de CloudKit compartida o pública, GameKit ni ningún símbolo de Declared Age Range. Ninguna app del conjunto mueve contenido de una persona a otra. Cuatro proyectos no tienen superficie marcada de ningún tipo. Los otros cuatro tienen superficies ante las que una persona cuidadosa podría dudar, y son de tres clases que vale la pena razonar en voz alta.

Get Bananas tiene una lista de compras compartida, y “compartida” es más estrecho de lo que suena. La app escribe un documento JSON en un contenedor de ubicuidad de iCloud y lo lee de vuelta en iPhone, Apple Watch y Mac, con com.apple.developer.icloud-services en CloudDocuments y sin ningún uso de CloudKit sharing en el proyecto.¹³ La lista se comparte entre los dispositivos de una misma persona, no entre personas, así que no hay redistribución y no hay un segundo usuario al que difundir. La respuesta cambia el día en que agregue CKShare para colaboración doméstica, y aun entonces cambia a contenido generado por usuarios y no a redes sociales, porque una lista de compras para dos no tiene feed ni superficie de descubrimiento. La línea que hay que vigilar está más lejos: listas compartidas más una galería pública de plantillas más “me gusta” es un feed con pasos adicionales.

Tres apps muestran una hoja para compartir, y una hoja para compartir no es una función social. Get Bananas, Water y la app de iOS de ResumeGeni envuelven cada una UIActivityViewController para entregar el contenido del propio usuario a la app que elija.¹³ El contenido se va a Mensajes o Mail y nunca vuelve a una superficie que controle mi app, y la definición de Apple gira sobre la redistribución “through a social feed or similar discovery method”, que una hoja para compartir del sistema no es.⁴ El razonamiento cubre una porción grande de la App Store: exportar no es publicar.

Watch Connectivity parece mensajería y no lo es. Get Bananas y Reps usan WCSession, que mueve datos entre un teléfono y un reloj emparejados con la misma persona, mientras que el descriptor Messaging and Chat de Apple exige que “Users can directly communicate with one another.”⁴¹³ El mismo usuario está en ambos extremos.

El resultado nulo se generaliza, y esa es la parte que vale la pena tomar prestada. Cada app del conjunto guarda contenido para quien lo creó y se lo muestra de vuelta a esa misma persona. El cuestionario pregunta otra cosa muy distinta: ¿tu app toma el contenido de una persona y lo pone frente a otras a través de algo que lo difunde? Las apps de seguimiento, los temporizadores y las herramientas de estudio responden que no por arquitectura, no por lectura de políticas. Las apps que sí tienen que pensarlo son las que tienen alguna superficie donde los usuarios ven el trabajo de los demás.

Los deployment targets son el otro número que conviene revisar primero. Seis de los siete proyectos con target de iOS están en iOS 26.0 o posterior; Ace Citizenship todavía declara 17.0 y 17.5 en algunos de sus targets.¹³ Cualquier cosa por debajo de 26.0 no puede llamar a la API en absoluto, lo que elimina la excepción y deja la declaración simple como única respuesta exacta.

El hueco de plataformas aparece en la misma revisión, y más extendido que el de versiones. Cuatro de los ocho proyectos declaran xros xrsimulator en SUPPORTED_PLATFORMS: Reps, Return, Water y Yawara. Reps añade appletvos appletvsimulator y publica un target aparte de watchos watchsimulator; Return y Banana List también llevan targets de watchOS.¹³ Declared Age Range publica disponibilidad para iOS 26.0, iPadOS 26.0, Mac Catalyst 26.0 y macOS 26.0, y ninguna fila para tvOS, visionOS o watchOS.⁵ Todos esos targets están sujetos a la declaración de septiembre, y en cualquiera de ellos una respuesta afirmativa deja la excepción fuera de alcance, porque la API de la que depende no se publica ahí.

Una advertencia de método, ya que la primera vez me equivoqué en esto. XROS_DEPLOYMENT_TARGET aparece en proyectos que no tienen ningún destino visionOS, porque Xcode escribe el ajuste en las configuraciones de todos modos. ResumeGeni lleva XROS_DEPLOYMENT_TARGET = 26.2 y compila únicamente iphoneos iphonesimulator.¹³ Lee SUPPORTED_PLATFORMS, no las claves de deployment target, o contarás plataformas en las que tu app no se publica.

Dónde la respuesta deja de ser técnica

Apple añade a la documentación de Declared Age Range una advertencia que conviene leer dos veces: “Data from the Declared Age Range API is based on information declared by an end user, or their parent or guardian”, y “You are solely responsible for ensuring compliance with associated laws or regulations that may apply to your app.”¹⁴

Esa frase traza el límite donde se detiene este artículo. El cuestionario de Apple produce una clasificación y una categoría de Time Allowance, y ningún cumplimiento normativo. La ley australiana exige desde el 10 de diciembre de 2025 que ciertas plataformas de redes sociales impidan que los menores de 16 años tengan una cuenta, y la orientación de Apple sobre esa ley nombra la API Declared Age Range como una herramienta entre cinco.¹⁵ Cuestionario y ley se solapan sin encajar: uno pregunta por los 13, la otra por los 16, y tienes tres umbrales para cubrir ambos.

Saber si tu app es una plataforma de redes sociales bajo una ley determinada es una pregunta para un abogado de esa jurisdicción. Saber si tiene funciones de redes sociales bajo el cuestionario de Apple es cosa tuya, y puedes responderla hoy mismo contra la definición publicada por Apple.

Preguntas frecuentes

¿La pregunta sobre redes sociales ya está activa en App Store Connect?

Sí. El anuncio de Apple del 9 de julio de 2026 indica que el cuestionario “now includes questions about your app’s social media capabilities” y que “You can review and answer these questions starting today.”³ La API de App Store Connect lo confirma de forma independiente, documentando socialMedia y socialMediaAgeRestricted como atributos del recurso AgeRatingDeclaration, ambos escribibles mediante PATCH /v1/ageRatingDeclarations/{id}.¹ Responder ahora no compromete nada: las respuestas quedan fijadas al enviar, y septiembre de 2026 es cuando enviar sin ellas deja de funcionar.²

¿Apple define qué son las “social media capabilities”?

Sí, en cuatro lugares y con dos alcances distintos. La Ayuda de App Store Connect da la versión más completa, que exige “Redistribution, amplification, or interaction with user-generated content through a social feed or similar discovery method that visibly spreads content to many users”, y después enumera como ejemplos repostear, dar me gusta, comentar, reaccionar y aumentar la visibilidad.⁴ Junio incluye esa misma cláusula de alcance; julio la elimina.²³ Como los ejemplos son ilustrativos y no exhaustivos, la clasificación de tu propia app sigue siendo tuya, y yo me guiaría por la página de Ayuda.

Mi app tiene contenido generado por usuarios. ¿Eso la convierte automáticamente en red social?

No. Apple las mantiene como preguntas distintas, con definiciones distintas y consecuencias distintas en la clasificación. User-Generated Content cubre “the broad distribution of content created by users as a component of the app’s intended user experience” y aparece en la definición de 4+ de Apple.⁴ Las redes sociales exigen redistribución, amplificación o interacción a través de un feed o una superficie de descubrimiento comparable, y aparecen por primera vez en 13+.⁴ La API refleja la división con booleanos independientes userGeneratedContent y socialMedia.¹ Una app donde la gente crea contenido que solo ella ve no es ninguna de las dos cosas.

¿Qué me obliga a construir en realidad la opción para menores de 13 años?

Tres cosas, y solo la segunda es una API. La Ayuda de App Store Connect exige que los menores de 13 años no tengan acceso a funciones de redes sociales, que “At a minimum, the Declared Age Range API is called to check users’ age ranges before enabling social media features”, y que “Only age-appropriate UGC is delivered.”⁴ Es decir: agregas el entitlement com.apple.developer.declared-age-range, llamas a requestAgeRange con 13 entre tus umbrales antes de que aparezca cualquier superficie social, ramificas según la respuesta incluyendo el caso de rechazo que Apple deja sin definir, y además mantienes apropiado para la edad el contenido que entregas a menores.⁵⁶ La API te limita a tres umbrales y guarda en caché el rango de una persona hasta el aniversario de su declaración, así que quien cumpla 13 seguirá leyéndose como más joven hasta que actualice Configuración.⁷¹⁰

Puntos clave

Para desarrolladores de iOS: - Responde el cuestionario esta semana en vez de en septiembre. El campo está activo, las respuestas solo quedan fijadas al enviar, y leer la clasificación calculada resuelve la cuestión del 13+ que ninguno de los dos anuncios aclara del todo.³⁴ - Si te acoges a la excepción para menores de 13 años, presupuesta tres condiciones en vez de una llamada a la API, y escribe la rama de rechazo de forma deliberada. .declinedSharing es idéntico a un adulto celoso de su privacidad, y Apple no publica ninguna guía sobre hacia qué lado inclinarse.⁴⁹

Para equipos en tvOS, visionOS o watchOS: - Revisa la disponibilidad antes de planificar. Declared Age Range publica filas de iOS, iPadOS, Mac Catalyst y macOS y ninguna más, así que el mínimo documentado de la excepción no está disponible en tu plataforma mientras que la declaración de septiembre sí se aplica a tu envío.²⁵ - El mismo hueco atrapa a cualquier target por debajo de iOS 26.0 por otra razón: sin API no hay excepción, y la declaración simple queda como única respuesta exacta.⁵

Para responsables de lanzamiento: - Trata la fecha como el disparador, a diferencia del resto de este ciclo. La clave de la pantalla de inicio y la macro @State se disparan con un SDK y un toolchain que tú controlas; septiembre se dispara con un envío que ibas a hacer igual.² - Haz pasar la respuesta por quien sea dueño de la ficha del producto. Declarar funciones de redes sociales agrega un descriptor de contenido Social Media a tu ficha de la App Store, una consecuencia que Apple reveló solo en julio.³

El ciclo 27 sigue ordenando sus cambios según lo que los dispara: un ajuste de compilación, un toolchain, una advertencia del compilador y ahora un calendario. Para la obsolescencia de este mismo ciclo con los dientes más flojos y la migración más grande detrás, consulta On Demand Resources y lo que cuesta Background Assets. El índice completo de la serie es la Serie sobre el ecosistema de Apple.

Referencias