Experiencia · Aplicaciones móviles
Construimos aplicaciones nativas iOS en Swift, con sensores y HealthKit, y aplicaciones con un solo código para iOS, Android y web cuando el proyecto no requiere sensores. El núcleo de lógica se prueba aparte de la pantalla.
Ya construidoSunt trei implementări proprii, nu una. Un depozit cu cinci ținte de aplicație (patru iOS și una macOS) definite în `project.yml`, ale cărui teste de logică le-am rulat azi: 160 din 160 trec. O a doua aplicație iOS, în alt proiect, cu 40 de fișiere Swift și HealthKit. Și o a treia direcție, cu un singur cod pentru iOS, Android și web, a cărei variantă web răspunde astăzi. Rezerva care schimbă răspunsul la întrebarea pe care o pune orice cumpărător înainte de toate: niciuna dintre aplicațiile noastre nu este publicată în App Store sau Google Play. Motivul e unul singur și are nume — `DEVELOPMENT_TEAM` este gol în configurația de proiect, adică lipsește identificatorul de echipă din Apple Developer Program. Mașina are o identitate de semnare validă, suficientă pentru instalare pe dispozitiv propriu, insuficientă pentru distribuție în magazin. E o problemă de cont, nu de cod, dar rămâne o problemă și o scriem aici, nu la subsol.
Una aplicación móvil tiene dos partes que se rompen de forma diferente. La parte que lee los sensores y calcula algo — un ángulo, una puntuación, un estado — y la parte que dibuja pantallas. Las mantenemos separadas, y no por motivos estéticos: en nuestro repositorio principal de iOS, los archivos del núcleo no importan la interfaz, así que pueden compilarse directamente con `swiftc` en Mac y ejecutarse como un programa normal, sin simulador y sin teléfono. La suite tiene 160 comprobaciones agrupadas en 16 etapas; la ejecutamos hoy y pasa íntegramente. Esa es la razón por la que podemos decir qué hace exactamente un algoritmo, en lugar de decir que "funciona bien".
En iOS trabajamos en Swift 6, con objetivo mínimo iOS 17. Ese mismo repositorio define cinco aplicaciones como objetivos separados: cuatro para iPhone y una para macOS, y la de macOS reutiliza quince archivos del núcleo de iOS, sin copiar. Los sensores se leen en la fuente: la interfaz de Apple para los sensores de los auriculares expone la orientación de la cabeza, y la aplicación compara el ángulo actual con una posición que el usuario calibra al inicio de la sesión. Los umbrales no son «ajustes internos»: por debajo de 7° está recto, entre 7° y 13° está deslizándose, por encima de 13° sostenido durante tres segundos activa la alerta, y el suavizado usa una media exponencial con el coeficiente 0,15. Los cuatro valores están en cuatro líneas consecutivas de código y pueden mostrarse.
Cuando el proyecto no necesita sensores, no recomendamos nativo. La tercera dirección del portafolio es un solo código que se compila para iPhone, Android y navegador — React Native con Expo — y la versión web está publicada y responde hoy. La diferencia práctica para el cliente: un cuestionario, una calculadora o un panel de control no justifican dos equipos y dos repositorios; una aplicación que escucha un sensor a veinte muestras por segundo, sí.
Lo que aún no podemos. Ninguna de nuestras aplicaciones está en App Store ni en Google Play. No porque no compile — compila, se instala en el simulador y pasa las pruebas — sino porque en la configuración del proyecto el identificador de equipo de Apple está vacío, es decir, no existe una inscripción en el Apple Developer Program vinculada a estos builds. En Mac existe una identidad de firma válida, de tipo desarrollo, que basta para la instalación en el propio dispositivo y no basta para la tienda. Para un proyecto de cliente, la cuenta de desarrollador se abre a nombre de la empresa del cliente y queda suya — esa es la conversación que hay que tener al inicio, no al final.
Qué incluye
En iOS usamos directamente las interfaces de Apple: `CMHeadphoneMotionManager` para la orientación de la cabeza en los auriculares, con delegado para conexión y desconexión, y verificación explícita del estado de autorización antes de iniciar el flujo. Si el sensor no está disponible, el estado pasa a `waiting`, no a un error silencioso.
Los archivos de análisis, calibración, historial y políticas son Swift simple. Se compilan con `swiftc` junto con el archivo de pruebas y se ejecutan como binario de línea de comandos. El resultado de hoy: 160 verificaciones, 16 etapas de 10, todas pasadas. Una prueba que corre en dos segundos en Mac se ejecuta con cada cambio; una que requiere simulador, no.
SwiftUI para ambos. El objetivo de macOS del mismo repositorio incluye quince archivos del núcleo de iOS como fuentes compartidas, no como archivos copiados, así que una corrección en el algoritmo llega simultáneamente a ambas aplicaciones.
Expo sobre React Native, con `react-native-web` para la versión de navegador, fuentes cargadas desde el paquete e iconos de aplicación separados para Android, incluida la variante monocroma que exige el sistema. La misma aplicación funciona en el teléfono y en la página, desde un solo repositorio.
No “leemos HealthKit”, sino una tabla en el código: once tipos de datos (ángulos posturales, movimiento bruto de los auriculares, pulso y variabilidad, sueño, marcha, exposición al audio, sesiones guiadas y otros) y cinco regímenes posibles (solo local, lectura desde HealthKit, escritura de entrenamiento, escritura de sesión de relajación, escritura de recorrido). Cada tipo recibe explícitamente uno de los regímenes. La segunda aplicación iOS del portafolio, de un proyecto privado, usa el mismo enfoque en 40 archivos Swift.
Cuatro objetivos tienen `PrivacyInfo.xcprivacy` incluido como recurso de compilación, no añadido a toda prisa tras el primer rechazo. Las descripciones de uso para movimiento, cámara, micrófono, HealthKit y notificaciones están escritas en rumano, en la configuración del proyecto, no generadas automáticamente.
La búsqueda de `URLSession` en las fuentes del objetivo iOS devuelve cero resultados. El historial se escribe en el dispositivo, mediante `FileManager` y `UserDefaults`, con opción de borrar el archivo. El único código de red del repositorio está en una función de la aplicación de macOS, en un archivo separado. Cuando una aplicación no necesita servidor, no se lo ponemos.
El onboarding tiene 24 pasos con identificadores únicos y ordenados, y algunos pasos requieren una confirmación explícita (los límites del sensor, el funcionamiento en primer plano, la confidencialidad, la preparación) sin la cual el botón de continuar sigue bloqueado. El estado se codifica y se reanuda. Diez de las 160 pruebas verifican exactamente eso.
Verificamos qué cuenta de desarrollador existe, a nombre de qué empresa, quién la administra y qué falta para que el build pueda firmarse para la tienda. Es una lista corta y aburrida, pero es la diferencia entre una aplicación que funciona en nuestro teléfono y una que llega a los usuarios.
Qué aspecto tiene
La pregunta no es de gusto, sino de hardware: ¿la aplicación necesita movimiento, salud, Bluetooth, cámara en tiempo real, segundo plano? Si sí, nativo. Si se trata de formularios, cálculos, listas y un panel de control, un solo código para iOS, Android y web hace el mismo trabajo con la mitad de mantenimiento. Entregamos la decisión por escrito, con el motivo.
El algoritmo, los umbrales, los estados y la persistencia. Las pruebas se compilan directamente en Mac y se ejecutan en unos segundos. Entregamos la suite y su resultado, no una promesa de calidad.
SwiftUI en iOS y macOS, o React Native cuando hemos elegido el código compartido. Verificamos el recorrido de inicio, los permisos y el comportamiento cuando el sensor falta o se desconecta en mitad de la sesión —el caso que suele fallar en la práctica.
Identificador de paquete, versión, iconos, archivo de privacidad, descripciones de permisos, identificador de equipo de Apple Developer Program. Aquí se bloquean los proyectos que no discutieron la cuenta al principio, incluidos los nuestros, que es exactamente el motivo por el que ponemos este paso por escrito.
Los datos
Las preguntas que hace cualquiera que tenga un delegado de protección de datos — hechas aquí antes de que las haga él.
Un caso
La situación
Un proyecto propio, no de un cliente: un cronómetro de concentración que observa cuánto se ha inclinado la cabeza respecto a una posición calibrada por el usuario al inicio de la sesión. Necesitábamos un caso en el que las afirmaciones sobre el algoritmo pudieran mostrarse, no describirse.
Qué construimos
Separamos el núcleo de la interfaz y escribimos los umbrales en código, no en la documentación: por debajo de 7° recto, entre 7° y 13° deslizamiento, por encima de 13° mantenido tres segundos activa la alerta háptica, con suavizado exponencial al coeficiente 0,15. Los datos vienen de la interfaz de Apple para los sensores de los auriculares, con tratamiento explícito de la desconexión. El onboarding tiene 24 pasos, de los cuales cuatro piden confirmar los límites antes de dejar al usuario seguir adelante. Construimos a partir del mismo núcleo también una variante de macOS.
Qué salió
La suite de lógica se compila con `swiftc` y se ejecuta en Mac en unos segundos: 160 verificaciones en 16 etapas, todas superadas en la última ejecución. La aplicación se instala y se inicia en el simulador. Cualquier afirmación del párrafo anterior puede verificarse abriendo cuatro líneas de código.
Qué no dice el caso
No está en App Store. La configuración del proyecto tiene el identificador de equipo de Apple vacío, así que el build no puede firmarse para distribución — una falta de inscripción en el programa de Apple, no una falta de funcionalidad. Y todavía una limitación, del producto y no del código: mide la inclinación de la cabeza, no la salud de la columna, y funciona con los auriculares que exponen sensores de movimiento mediante la interfaz de Apple.
Preguntas
No. Ninguna de nuestras aplicaciones está en App Store ni en Google Play, y es correcto preguntar eso primero. Lo que podemos mostrar: cinco destinos de aplicación definidos en el mismo proyecto, de los cuales cuatro para iPhone y uno para macOS, que compilan y se instalan en el simulador, más la suite de lógica de 160 verificaciones, ejecutada a petición delante de ti. El bloqueo para la publicación es `DEVELOPMENT_TEAM` vacío en la configuración del proyecto, es decir, la falta de un identificador del Apple Developer Program. En Mac hay una identidad de firma válida, de tipo desarrollo — suficiente para instalar en el propio dispositivo, no para la tienda.
De nada, si pides una prueba de publicación — no tenemos una y no la inventamos. Lo que sí puedes verificar es el resto de la cadena: código que compila, pruebas que pasan, archivos de privacidad presentes, permisos declarados, iconos y versiones configurados. El paso que falta es una inscripción de pago en un programa de Apple, hecha a nombre de la empresa que posee la aplicación. En un proyecto de cliente, esa cuenta es del cliente y se abre al principio, justamente para que no sea ese el paso que sorprenda a alguien al final.
Depende de los sensores. Si la aplicación lee movimiento, salud, Bluetooth o cámara en tiempo real, nativa: esas interfaces son de la plataforma y cualquier capa intermedia añade retraso y nuevas formas de fallar. Si la aplicación es, en esencia, formularios, cálculos y pantallas de resultados, un solo código cubre iOS, Android y navegador desde un repositorio. Tenemos ambas variantes en el portafolio y las elegimos con un argumento escrito, no por defecto.
Con código común, sí: el mismo proyecto Expo genera builds para Android, con el icono adaptativo y la variante monocroma que exige el sistema, ya configuradas. Android nativo, en Kotlin, no lo tenemos en el portafolio; si un proyecto lo requiere, lo decimos antes, no después de firmar.
Porque el núcleo no depende de la pantalla. Los archivos de análisis se compilan por separado, con el compilador Swift, y se ejecutan como programa en Mac. La suite actual tiene 160 comprobaciones en 16 etapas y se ejecuta en unos segundos. Lo que no se puede comprobar así — cómo se siente una vibración, cómo se ve una pantalla en un teléfono concreto, cómo se comportan los auriculares cuando salen de una oreja — se prueba en el dispositivo, y se dice cuál es cuál.
Solo si los apruebas, tipo por tipo, en la pantalla de Apple, y solo los declarados. En el código, la política es explícita para cada tipo de dato: unos se quedan solo en el teléfono, otros se leen desde HealthKit, otros se pueden escribir de vuelta como entrenamiento o como sesión de relajación. No se hace diagnóstico, y los datos no llegan a nosotros.
Se quedan en el teléfono. En la aplicación iOS de referencia de nuestro portafolio no existe ninguna llamada de red: la búsqueda de `URLSession` en los fuentes de ese target devuelve cero resultados. El historial se escribe en un archivo local y se puede borrar desde la aplicación. Cuando un proyecto necesita servidor, lo construimos, pero no lo ponemos por reflejo.
Empieza con una verificación de compatibilidad, no con una oferta: qué versión de plataforma apunta, qué dependencias tiene y cuáles de ellas siguen mantenidas, si el build se reproduce en una máquina limpia, quién posee la cuenta de desarrollador y las claves. Hay proyectos en los que la respuesta honesta es que reescribir el núcleo cuesta menos que mantenerlo.
En macOS, sí, y desde el mismo núcleo: en nuestro repositorio principal, el target de macOS reutiliza quince archivos de lógica de la aplicación de iPhone, como fuentes compartidos. Windows no está en el portafolio.
10 de ellas son código y archivos de nuestros repositorios. No publicamos su nombre ni la línea: juntos, en una sola página, describirían con demasiada precisión cómo están construidos sistemas que no son solo nuestros. Los repasamos contigo, en el repositorio, a petición — la verificación sigue siendo posible, solo que se hace en una conversación.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.