Lanzamiento de LiftCrew AI: nuestro recorrido creando una aplicación iOS de fitness con IA

El encargo: entrenamiento grupal en gimnasio, personalizado con IA

La mayoría de las aplicaciones de fitness se optimiza para un solo usuario. LiftCrew partió de una premisa distinta: las personas entrenan mejor en grupo, pero un grupo de amigos rara vez comparte el mismo nivel de fuerza. Nuestro cofundador imaginó a un grupo de cuatro personas haciendo el mismo ejercicio, en la misma serie y al mismo tiempo, cada una con el peso adecuado en la barra para su cuerpo. Esa idea, aparentemente sencilla, se convirtió en el principio central del producto: mismo ejercicio, peso individualizado.

Para desarrollarlo hizo falta una coordinación estrecha entre un modelo de IA que entiende la planificación del entrenamiento, una capa en tiempo real que mantiene sincronizado a un grupo distribuido y una experiencia iOS lo bastante nativa como para pasar desapercibida durante una serie pesada.

Por qué React Native + Expo para iOS (y por qué sigue siendo suficientemente nativo)

Elegimos React Native 0.81 sobre la nueva arquitectura (Fabric + TurboModules) y Expo SDK 54 con expo-router 6 para la navegación basada en archivos. Esta tecnología nos permitió compartir una sola base de código entre iOS y Android y utilizar módulos nativos de iOS donde la experiencia importa: el módulo nativo expo-apple-authentication para Iniciar sesión con Apple, StoreKit 2 nativo mediante react-native-purchases (RevenueCat), la galería de iOS mediante expo-image-picker , y Reanimated 4.3 para animaciones a 60 fps en el hilo de la interfaz.

El resultado es una aplicación que supera sin problemas la revisión de Apple (ID de App Store Connect 6762237223, equipo C23ARGS845), respeta las directrices de interfaz humana de Apple y recibe actualizaciones OTA del paquete JavaScript mediante EAS, sin renunciar a lo que los usuarios de iOS realmente perciben.

La IA: Claude como entrenador

El entrenador de IA genera un plan para cada sesión cuando un grupo inicia un entrenamiento. El modelo recibe la composición del grupo, los valores de referencia de 1RM de cada miembro, el historial reciente de sesiones, el equipamiento de su gimnasio y el objetivo del entrenamiento del día. Devuelve un plan JSON estructurado con ejercicios, esquemas de series y repeticiones, y una prescripción de peso por miembro.

Utilizamos por defecto Claude Haiku 4.5 por su velocidad y costo, con escalamiento a Claude Sonnet 4 para planificaciones más complejas y para visión (análisis de fotos de comidas). Lo fundamental es que la clave de API nunca sale del servidor: cada llamada a la IA pasa por un proxy sin servidor de Vercel en /api/generate-workout , autenticado con el JWT de Supabase del usuario. El paquete de la aplicación no contiene ningún secreto: la única clave de Anthropic reside en las variables de entorno de Vercel.

Además, añadimos una caché de respuestas de 1 hora en el cliente (para que volver a abrir el mismo plan no consuma tokens), sustitución de ejercicios durante la sesión (el modelo recalcula el peso del ejercicio sustituto según la intensidad relativa) y un límite deliberadamente breve de reintentos para que una red inestable nunca impida entrenar.

Sincronización del grupo en tiempo real sin un backend a medida

Las sesiones grupales son el corazón social de la aplicación. Cuatro personas en tres gimnasios distintos deben sentir que entrenan juntas: cuando alguien completa una serie, todos lo ven; cuando termina el descanso, todos avanzan; cuando alguien bate un récord personal, todo el grupo recibe confeti.

En lugar de crear un servicio propio en tiempo real, recurrimos a las transmisiones de Supabase Realtime por WebSocket. Cada serie completada, avance de ejercicio y cambio de estado de un miembro envía un pequeño evento a un canal de la sesión. El almacén local de Zustand lo aplica de forma optimista y recurre a AsyncStorage si la red se cae a mitad de una serie: el levantamiento es sagrado y la sincronización se realiza en la medida de lo posible.

La detección de récords personales se ejecuta en el cliente mediante la fórmula de Epley frente al 1RM almacenado de cada usuario. Al terminar una sesión, el mayor 1RM estimado por levantamiento se guarda en el perfil y se publica en la actividad del grupo. Los récords empatados muestran a todos los ganadores, porque la interacción social importa más que la clasificación.

Registro de comidas por foto con la visión de Claude

La nutrición iba a ser originalmente una pantalla de búsqueda manual de alimentos. La descartamos después del primer prototipo: nadie quiere escribir «pechuga de pollo, 142 g» después de un día de piernas. En su lugar, el usuario toma una foto de su plato y la capacidad visual de Claude Sonnet devuelve calorías y macronutrientes en un JSON estructurado que se incorpora directamente a los totales diarios.

Detrás hay una calculadora de metabolismo basal y gasto energético diario BMR/TDEE de Mifflin-St Jeor que establece los objetivos del usuario, anillos de progreso diario que se animan al registrar comidas y un historial móvil de 5 días guardado en una columna JSONB del perfil de Supabase del usuario. Cerrar sesión y reinstalar no hace perder los datos: resultó ser una de nuestras decisiones de mayor impacto.

Retos grupales: convertir los entrenamientos en una temporada

Los retos grupales hacen que los amigos sigan participando. La aplicación admite cuatro modos de puntuación: volumen (kg totales levantados), sesiones (cantidad de entrenamientos completados), récords personales (número de récords personales) y rachas (días consecutivos de entrenamiento). Al cerrar una sesión, los retos en los que se participa suman automáticamente los resultados y la clasificación se actualiza para todo el grupo.

El motor de puntuación reside íntegramente en funciones de Supabase y Postgres: no existe un servicio de retos separado. Las políticas RLS garantizan que un usuario solo vea retos de los grupos a los que pertenece. Es una lección de siempre: cuando tu capa de datos es buena, no necesitas muchos servicios.

Las partes difíciles: pagos, pruebas y revisión de Apple

Utilizamos RevenueCat con StoreKit 2 nativo en iOS y Google Play Billing en Android. El permiso de acceso se controla con un único indicador pro ; los productos son liftcrew_pro_monthly_v2 (CA$4.99/mes) y liftcrew_pro_yearly_v4 (CA$39.99/año). La prueba gratuita de 15 días se controla desde el servidor en la tabla subscriptions vinculada a auth.users.created_at —porque los relojes de prueba en el cliente son una invitación abierta a manipular la fecha y abusar de las reinstalaciones.

Un webhook de RevenueCat en /api/revenuecat-webhook replica cada evento de suscripción en Supabase, de modo que un usuario cuya suscripción haya vencido pierde el acceso en el siguiente inicio aunque su caché de recibos esté desactualizada. La pantalla de suscripción se cierra automáticamente en cuanto cambia el permiso de acceso.

La revisión de Apple reveló un requisito importante que no habíamos previsto: la directriz 1.2 exige que el contenido generado por usuarios permita denunciar y bloquear a otros usuarios. Añadimos la tabla user_reports , una lista de bloqueos en las solicitudes de conexión y una RPC delete_own_account para que los usuarios puedan eliminar su cuenta por completo. La aplicación superó la revisión en el siguiente envío.

La arquitectura, en un párrafo

React Native 0.81 + Expo 54 en el cliente. Zustand para el estado, guardado en AsyncStorage y sincronizado con columnas JSONB de Supabase para que la aplicación conserve los datos tras una reinstalación. Supabase Postgres con RLS en nueve tablas para usuarios, sesiones, ejercicios, conexiones grupales, gimnasios, retos, tokens push, suscripciones y denuncias. Supabase Realtime para sesiones grupales en vivo. Funciones sin servidor de Vercel para el proxy de IA, el webhook de RevenueCat, el envío de notificaciones push y un agente de soporte de Gmail a Linear. Claude para IA. RevenueCat para pagos. EAS Build para compilar iOS/Android en la nube. Bebas Neue y DM Sans como tipografías, verde lima #d4ff5a sobre #0d0d0f para el aspecto visual.

Qué repetiríamos y qué no

• Repetiríamos: claves de IA en el servidor detrás de un proxy autenticado con JWT. Innegociable.
• Repetiríamos: columnas JSONB para estructuras cambiantes de estado del usuario (ajustes, comidas, planes). Permitieron avanzar más rápido que las migraciones de esquemas.
• Repetiríamos: RevenueCat. La combinación de webhook + StoreKit 2 se amortizó la primera vez que tuvimos que conciliar un reembolso.
• No repetiríamos: lanzar sin contemplar el cumplimiento de Apple 1.2 desde el primer día. Sabíamos que necesitaríamos denunciar/bloquear; debimos incluirlo en la primera compilación.
• No repetiríamos: un reloj de prueba en el cliente, ni siquiera como solución provisional. Trasládalo primero al servidor.

¿Quieres esto para tu aplicación iOS?

LiftCrew AI es una de las varias aplicaciones iOS que SEYSO SERVICES INC ha diseñado y lanzado. Si tienes una idea —con IA, de fitness, productividad o B2B— y buscas un socio capaz de llevarla desde un boceto hasta una ficha activa en la App Store, nos encantará conversar. Swift nativo, SwiftUI, React Native, Expo, integración de IA, optimización para la App Store y los requisitos continuos de cumplimiento de Apple: a eso nos dedicamos.