GymTracker: como publique mi primera app iOS con SwiftUI y CoreData

GymTracker es la primera aplicacion que he disenado, desarrollado y publicado en la App Store como unico responsable del producto. Es una app nativa para iPhone creada con Swift, SwiftUI y CoreData para registrar entrenamientos, seguir la sobrecarga progresiva y consultar la evolucion sin depender de hojas de calculo, notas dispersas o servicios externos.

La respuesta corta sobre el proyecto es esta: GymTracker convierte el cuaderno de gimnasio en una experiencia iOS rapida, privada y offline-first. Permite crear rutinas, registrar peso, repeticiones y RPE, consultar el historial y visualizar metricas como el volumen, el 1RM estimado, el peso corporal y la constancia de entrenamiento.

Resumen del proyecto

Aspecto	Resultado
Problema	Registrar y entender la progresion de fuerza sin friccion
Plataforma	Aplicacion nativa para iPhone
Mi papel	Disenador y desarrollador unico
Stack	Swift, SwiftUI, CoreData y Xcode
Arquitectura	MVVM y persistencia local offline-first
Privacidad	No se recopilan datos
Idiomas	Espanol e ingles
Estado	Publicada gratuitamente en App Store

La ficha publica de App Store identifica a Gorka Hernandez Villalon como desarrollador, muestra una valoracion de 5,0 sobre 5 con tres valoraciones en el momento de publicar este articulo y confirma que la aplicacion no recopila datos.

El problema: registrar datos no siempre ayuda a entenderlos

En un entrenamiento de fuerza es facil apuntar series. Lo dificil es que ese registro resulte util semanas despues. Para aplicar sobrecarga progresiva necesitas responder rapido a preguntas concretas:

• Que peso y repeticiones hice la ultima vez?
• Estoy aumentando volumen o solo acumulando sesiones?
• Como evoluciona mi 1RM estimado?
• Estoy entrenando con constancia?
• Como cambia mi peso corporal junto con el rendimiento?

Muchas aplicaciones resuelven esto anadiendo capas de funciones, cuentas, suscripciones y pantallas. Mi objetivo con GymTracker fue el contrario: reducir la distancia entre terminar una serie y guardar un dato que despues ayude a tomar una decision.

Por eso la interfaz se penso para el contexto real del gimnasio: tema oscuro, botones grandes, registro rapido y acceso directo al historial. La aplicacion no intenta sustituir al entrenador ni prometer resultados automaticos. Su trabajo es conservar informacion util y devolverla de forma clara.

Disenar primero el flujo principal

Antes de pensar en graficas o perfiles, el flujo critico era registrar una serie. Si ese paso resultaba lento, ninguna visualizacion posterior compensaria la friccion.

El nucleo del producto se organiza alrededor de tres acciones:

1. Preparar una rutina personalizada, con los ejercicios y el orden que necesita cada usuario.
2. Registrar una sesion rapidamente, guardando peso, repeticiones y RPE.
3. Consultar el historial y la progresion, para decidir como afrontar el siguiente entrenamiento.

Esta secuencia tambien ayudo a priorizar el desarrollo. Cada nueva funcion tenia que mejorar al menos una de esas acciones. El mapa de calor, por ejemplo, no existe solo como elemento visual: permite entender la constancia de un vistazo. Las graficas de volumen y 1RM estimado convierten registros aislados en una tendencia.

SwiftUI para construir una interfaz nativa

Elegir SwiftUI me permitio desarrollar la interfaz usando componentes declarativos y mantener las vistas conectadas al estado de la aplicacion. Para una app con formularios, listas, historiales, graficas y diferentes estados de entrenamiento, esa relacion entre datos y UI es especialmente importante.

La aplicacion sigue una arquitectura MVVM. Separar vistas, estado de presentacion y modelos evita que las pantallas concentren toda la logica. Esta decision es util cuando una misma informacion aparece en varios lugares: una sesion afecta al historial, a las graficas y al mapa de calor, pero cada vista no deberia tener que reinterpretarla por su cuenta.

SwiftUI tambien encaja bien con otro objetivo del proyecto: que GymTracker se sienta como una app iOS y no como una web encerrada dentro de un telefono. Navegacion, controles y jerarquia visual siguen patrones familiares para el usuario de iPhone.

CoreData y una arquitectura offline-first

GymTracker utiliza CoreData para guardar localmente rutinas, ejercicios, sesiones y metricas. Esta eleccion responde a dos requisitos de producto:

• la app debe funcionar en el gimnasio incluso sin cobertura;
• los datos de entrenamiento no necesitan salir del dispositivo para aportar valor.

En una arquitectura offline-first, la persistencia local no es un fallback: es la fuente principal de verdad. El usuario puede registrar y consultar informacion sin esperar a una API ni crear una cuenta. Esto reduce dependencias, elimina latencia de red y simplifica la experiencia.

La contrapartida es que el modelo de datos importa mucho. Rutinas, ejercicios y registros deben mantener relaciones coherentes para que el historial y las graficas sean fiables. Una serie guardada no es solo una fila: alimenta calculos posteriores y forma parte de la historia de entrenamiento.

Convertir registros en informacion util

Guardar datos era solo la primera mitad del problema. La segunda era presentarlos de forma que ayudaran a interpretar el progreso.

GymTracker incorpora:

• historial completo de entrenamientos;
• graficas automaticas de volumen total;
• evolucion del 1RM estimado;
• perfil con graficas de peso corporal;
• mapa de calor de sesiones realizadas.

Cada visualizacion responde a una escala temporal diferente. El historial sirve para comparar la sesion actual con la anterior. Las graficas muestran tendencias. El mapa de calor resume constancia. Juntas permiten pasar de "hoy he entrenado" a "asi esta evolucionando mi entrenamiento".

Privacidad como decision de arquitectura

La privacidad no se anadio al final como texto legal. Influyo directamente en la arquitectura: GymTracker guarda los datos en el dispositivo y no recopila informacion del usuario. Esta practica aparece declarada publicamente en la ficha de App Store.

No exigir cuenta ni enviar entrenamientos a un servidor tiene varias consecuencias positivas:

• menos pasos antes de empezar a usar la app;
• funcionamiento sin conexion;
• menor superficie de exposicion de datos;
• ausencia de infraestructura remota innecesaria.

Tambien implica aceptar un limite: una arquitectura puramente local no ofrece por defecto sincronizacion entre dispositivos. Para este proyecto preferi priorizar simplicidad, velocidad y privacidad antes que construir una nube sin una necesidad clara.

Llevar una app propia hasta App Store

Publicar GymTracker cambio el proyecto. Dejo de ser una interfaz que funcionaba en mi entorno y paso a ser un producto que otras personas podian instalar, valorar y usar con sus propios datos.

Ese paso obliga a mirar aspectos que en un prototipo pueden quedar escondidos:

• compatibilidad real con dispositivos y versiones de iOS;
• textos y experiencia en espanol e ingles;
• correccion de errores fuera del recorrido ideal;
• descripcion comprensible del producto;
• declaracion de privacidad;
• mantenimiento despues de la primera version.

La version publicada incorporo mejoras de compatibilidad, un perfil con graficas de peso corporal, un mapa de calor de entrenamientos, correcciones y soporte en espanol e ingles. Ese ciclo me enseno que lanzar no es terminar: es empezar a recibir senales reales sobre lo que funciona.

Que hice yo

En GymTracker asumi el proyecto completo como disenador y desarrollador unico:

• definicion del problema y alcance;
• diseno de los flujos principales;
• implementacion de la interfaz con SwiftUI;
• modelado y persistencia con CoreData;
• arquitectura MVVM;
• visualizacion de progreso;
• localizacion al espanol e ingles;
• preparacion y publicacion en App Store.

Para mi, esta amplitud es una de las partes mas valiosas del proyecto. No se trata solo de conocer Swift, sino de tomar decisiones conectadas entre producto, experiencia, datos, privacidad y distribucion.

Lo que aprendi

GymTracker me dejo cuatro aprendizajes principales:

1. La velocidad de la accion principal define el producto. En el gimnasio, registrar una serie tiene que resultar casi inmediato.
2. Los datos necesitan contexto. Un historial es util; una tendencia visual ayuda a decidir.
3. La privacidad puede simplificar el sistema. No recopilar datos elimina infraestructura y reduce friccion cuando el producto no necesita una cuenta.
4. Publicar cambia el nivel de exigencia. Compatibilidad, idiomas, errores y mantenimiento pasan a formar parte del trabajo tecnico.

Resultado

El resultado es una aplicacion iOS publica, gratuita y verificable que resuelve un problema concreto con una arquitectura contenida. GymTracker esta disponible en la App Store, y su ficha ampliada puede consultarse en la seccion de proyectos de mi portfolio.

GymTracker representa el tipo de producto que me interesa construir: software util, enfocado y capaz de explicar con claridad por que existe. Para hablar sobre desarrollo iOS, SwiftUI o un proyecto mobile, puedes escribirme desde la pagina de contacto.