Servicios de desarrollo de apps iOS para marcas

Los proyectos iOS nuevos arrancan con Swift 6 y concurrencia estricta activada, con iOS 17 como mínimo de despliegue e iOS 18 como SDK de compilación. Eso cubre aproximadamente el 92 % de los iPhone activos en EE. UU. y la UE en el momento de redactar esto. Para apps B2B que deben funcionar en flotas de dispositivos heredados, bajamos el mínimo a iOS 16 y aislamos la concurrencia de Swift 6 con importaciones @preconcurrency. SwiftUI es la capa de interfaz por defecto, con interoperabilidad con UIKit donde SwiftUI todavía no llega (pipelines de captura de cámara, PDFKit avanzado, entrada de teclado personalizada).

Tratamos las Directrices de revisión de la App Store 2.x, 3.x, 4.x y 5.x como una lista de comprobación previa obligatoria antes de cada envío. Estos son los patrones de rechazo más comunes que eliminamos: Directriz 4.0 (metadatos incompletos, falta de cuenta de demostración), Directriz 2.1 (fallo en el build de TestFlight con la configuración regional del revisor), Directriz 3.1.1 (bienes digitales enrutados por Stripe en lugar de compras dentro de la app), Directriz 5.1.1 (faltan cadenas de propósito en Info.plist para cámara, fotos, contactos o movimiento) y Directriz 5.1.2 (eliminación de cuenta que no se puede hacer desde la app, obligatoria desde junio de 2022). También rellenamos con precisión las etiquetas de privacidad de la App Store y las mantenemos sincronizadas con el comportamiento real de los SDK.

App Tracking Transparency (ATT) es obligatorio desde iOS 14.5 para cualquier seguimiento entre apps o sitios mediante IDFA. Condicionamos el acceso al IDFA a ATTrackingManager.requestTrackingAuthorization, mostramos el mensaje previo solo cuando aporta valor real al producto y diseñamos la app para que funcione por completo si el usuario lo rechaza (las tasas de aceptación en EE. UU. son del 25–38 %). Para el cumplimiento del Reglamento de Mercados Digitales (DMA) de la UE, admitimos marketplaces de apps alternativos, motores de navegador de terceros mediante BrowserEngineKit en iOS 17.4+ en la UE y las APIs de pago NFC/contactless reservadas a contratistas cuando el caso de negocio lo requiere.

Por defecto, SwiftUI primero, con el framework Observation (iOS 17+) en lugar de ObservableObject y puentes UIViewRepresentable donde UIKit todavía va por delante: celdas de tabla de alto FPS con diseño personalizado, interfaz de cámara con AVFoundation, PencilKit y overlays de MapKit a gran escala. Usamos Swift Concurrency (async/await, actors, tareas estructuradas) en lugar de Combine en el código nuevo; los pipelines de Combine existentes se mantienen y se enlazan con puentes. La navegación usa NavigationStack con un NavigationPath de tipado seguro. The Composable Architecture (TCA) está disponible para los equipos que lo deseen, pero por defecto usamos SwiftUI + Observation sin añadidos en los proyectos nuevos.

Alineados con el RGPD desde el diseño: base jurídica documentada por categoría de datos, flujos de consentimiento en la app separados de ATT, exportación granular de datos y eliminación de cuenta (también un requisito de la App Store desde 2022) y DPA con cada SDK de terceros. Para los clientes de la UE alojamos la infraestructura del backend en eu-central-1 o eu-west-3, ciframos en reposo con AWS KMS o GCP CMEK y mantenemos los datos personales (PII) fuera de los informes de fallos (con el enmascaramiento de PII de Sentry/Firebase Crashlytics activado). Para la CCPA incorporamos el tratamiento de la señal No vender/No compartir y una pantalla de privacidad específica de la CCPA para los usuarios de California detectados por región (no por geolocalización IP, que no es fiable en iOS).

Los proyectos iOS son de alcance cerrado y escalonados según la complejidad del producto, con precio total y presupuestados en USD. Un MVP parte de $3,500 (4–8 semanas) para la primera app operativa con el flujo principal y la publicación en la App Store; una app de producción, de $5,800, con varias funciones, integración con el backend, persistencia offline y analítica; un producto completo, de $9,200, con varios módulos, roles, integraciones externas, CI/CD y QA en dispositivos; y una app compleja, de $11,500, con pagos, sincronización offline-first, SDK nativos, escala y pruebas A/B. La cifra exacta depende de cuántas plataformas de Apple se publiquen, de la complejidad de la integración y de StoreKit y del alcance del cumplimiento. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de que se escriba una sola línea de código. No hay cargos ocultos ni sobrecostes por herramientas. Las cuotas del Apple Developer Program y de las APIs de terceros se facturan en sus propias cuentas.

Prevenimos los rechazos en lugar de repararlos. Antes de cada envío realizamos una comprobación previa estructurada frente a las cinco categorías de rechazo más comunes: Directriz 4.0 (metadatos incompletos o falta de cuenta de demostración), Directriz 2.1 (fallo en un build con la configuración regional o los ajustes de accesibilidad del revisor activados), Directriz 3.1.1 (bienes digitales o suscripciones que eluden las compras dentro de la app, normalmente un pago con Stripe olvidado en un paywall), Directriz 5.1.1 (faltan cadenas de propósito en Info.plist para cada permiso que usa la app) y Directriz 5.1.2 (eliminación de cuenta no disponible desde la app). Las etiquetas de privacidad de la App Store se rellenan a partir de una auditoría en vivo de la lista real de SDK, no de una plantilla, y se mantienen sincronizadas a medida que cambian las dependencias. Para ATT condicionamos el acceso al IDFA a ATTrackingManager.requestTrackingAuthorization, mostramos el mensaje previo personalizado solo cuando aporta valor real al producto (las tasas de aceptación en EE. UU. se sitúan en el 25–38 %, así que un mensaje innecesario le cuesta más de lo que le devuelve) y diseñamos cada función posterior para degradarse con elegancia cuando el usuario lo rechaza. Nuestra tasa de aprobación a la primera en la App Store supera el 90 % en los proyectos que hemos enviado.

SwiftUI primero, con el framework Observation (iOS 17+), es nuestra opción por defecto en todos los proyectos nuevos que arrancan en 2026. La macro Observation sustituyó a ObservableObject y eliminó gran parte de los re-renderizados innecesarios. Usamos NavigationStack con un NavigationPath de tipado seguro para el enrutamiento de enlaces profundos, SwiftData para la persistencia local (respaldada por Core Data en objetivos anteriores) y Swift Concurrency (async/await, actors, tareas estructuradas) en todo el código; no escribimos código Combine nuevo. UIKit sigue presente en un conjunto concreto de casos en los que SwiftUI todavía se queda corto: pipelines de captura de cámara con AVFoundation, celdas de tabla de alto FPS con diseño totalmente personalizado (Collection View Compositional Layout supera a LazyVGrid con conjuntos de datos muy grandes), capas de anotación con PencilKit y overlays de MapKit con miles de anotaciones. Los enlazamos con UIViewRepresentable y UIViewControllerRepresentable para que el grafo de navegación de SwiftUI permanezca intacto. Para los proyectos que lo necesitan, está disponible The Composable Architecture (TCA); en caso contrario, usamos SwiftUI + Observation sin añadidos, que es más ligero y más fácil de incorporar al equipo.

StoreKit 2 (introducido en iOS 15 y hoy el estándar de producción) sustituye al StoreKit 1, cargado de callbacks, por una API async/await y un modelo de transacciones del lado del servidor que simplifica enormemente la validación de recibos. Implementamos el flujo de compra completo: obtención de productos con Product.products(for:), compra con product.purchase(), listener de transacciones como secuencia asíncrona en ejecución desde el arranque de la app y un endpoint de verificación en el servidor que llama a la App Store Server API (el nuevo endpoint REST que sustituye al antiguo verifyReceipt). El estado de la suscripción se gobierna con Transaction.currentEntitlements en lugar de analizar recibos locales. Los códigos de oferta, las ofertas promocionales, las ofertas de recuperación (win-back, iOS 18) y el uso compartido en familia se gestionan donde el producto lo requiere. Para las apps que necesitan una vía de pago web junto a las compras dentro de la app (algo habitual en herramientas SaaS que también tienen un nivel web), implementamos con cuidado el entitlement de enlace a sitio web externo conforme con la DMA de la UE para evitar un rechazo por la Directriz 3.1.1. La analítica de suscripciones (conversión, de prueba a pago, churn) se instrumenta desde el primer día con RevenueCat o un backend propio, y no se estima a partir de las cifras agregadas de App Store Connect.

Sí. Planteamos las apps complementarias para Apple Watch, las apps nativas para iPad y las experiencias para Apple Vision Pro como líneas de trabajo distintas dentro del mismo proyecto. Las apps de Apple Watch funcionan en watchOS con SwiftUI y complicaciones de WidgetKit; se comunican con el iPhone mediante WatchConnectivity y ejecutan su propia lógica independiente en escenarios de entrenamiento, salud y notificaciones en los que el reloj debe funcionar sin el teléfono. Las apps de iPad reciben un diseño adaptable como es debido, no un diseño de iPhone estirado, con el sistema de size classes de SwiftUI, NavigationSplitView para diseños de varias columnas, compatibilidad con Stage Manager y entrada con Apple Pencil mediante PencilKit cuando procede. Las apps de Apple Vision Pro en visionOS usan el mismo código SwiftUI con extensiones de espacios volumétricos e inmersivos. Cada plataforma de Apple adicional se delimita de forma explícita en el descubrimiento: añade trabajo de diseño y QA y la dimensionamos con honestidad, en lugar de meterla en un precio cerrado que luego se desvía. Probamos en dispositivos reales de toda la matriz de dispositivos objetivo, no solo en el Simulator.

Las etiquetas de privacidad de la App Store (la «etiqueta nutricional» visible en la página del producto) deben reflejar con exactitud cada categoría de datos que su app y cada SDK incluido recopilan, vinculan a la identidad y usan para el seguimiento. Empezamos con una auditoría automatizada de SDK mediante un análisis de privacy manifests (Apple exige archivos PrivacyInfo.xcprivacy para las APIs de motivo obligatorio desde iOS 17) para enumerar las prácticas de datos declaradas por cada biblioteca de terceros. Después asignamos la lista de SDK a las categorías de privacidad de la App Store (datos usados para rastrearle, datos vinculados a usted, datos no vinculados a usted) y rellenamos las etiquetas conforme a ese mapa, no a una plantilla. Trampas habituales que evitamos: los SDK de analítica (Firebase, Amplitude, Mixpanel) declaran datos vinculados a la identidad si se envía un ID de usuario; las herramientas de informes de fallos (Sentry, Crashlytics) declaran datos de rendimiento; los SDK publicitarios declaran datos de seguimiento. Si se selecciona una categoría de etiqueta, debe existir la cadena de propósito correspondiente en Info.plist y el permiso en tiempo de ejecución debe solicitarse antes del acceso. Para los clientes de la UE, la base jurídica del RGPD se documenta por categoría de datos y la plataforma de gestión del consentimiento se conecta de modo que ATT y el consentimiento del RGPD sean dos mensajes distintos y secuenciados, y no una única pantalla que no satisface ninguno de los dos.