Publicar Enolisa en iOS: rigor de App Store, QA y trabajo con IA
Cómo convertí la publicación de Enolisa en iOS en un proceso de producto, documentación, QA y trazabilidad, usando IA para ordenar contexto, revisar criterios y preparar una entrega más sólida.
Publicar en iOS no es solo subir una app
La publicación de Enolisa en iOS fue una fase distinta dentro del proyecto.
Android había sido el primer gran hito público: validar que la app podía salir al mercado, que el producto tenía una base real y que el usuario podía empezar a registrar, organizar y entender mejor sus vinos.
iOS añadió otra capa: no bastaba con que la aplicación funcionara. Había que explicar mejor el producto, ordenar la información, revisar la experiencia desde la mirada de plataforma y preparar cada entrega con una disciplina más parecida a la de un sistema operativo que a la de una simple publicación móvil.
Apple tiene una forma muy concreta de mirar una app. No revisa solo pantallas. Revisa permisos, privacidad, compras, cuenta de usuario, claridad de uso, consistencia visual, comunicaciones, textos, acceso a funcionalidades y relación entre lo que se promete y lo que realmente se entrega.
Ese nivel de exigencia puede vivirse como fricción o como una oportunidad. Yo decidí tratarlo como una oportunidad para madurar Enolisa como producto.
El reto real: convertir una revisión en sistema
Cuando una app llega a App Store, el trabajo no termina en compilar una versión. Empieza otra parte igual de importante: demostrar que el producto es comprensible, coherente y trazable.
En el caso de Enolisa, había varias capas que debían convivir bien:
- una app móvil construida en Flutter;
- una experiencia pensada para registrar vinos, catas y recuerdos personales;
- una base de privacidad y control del usuario;
- funcionalidades premium y compras dentro de la app;
- una evolución futura hacia recomendaciones, maridajes y capacidades inteligentes;
- documentación suficiente para que una revisión externa entienda el propósito del producto.
El punto clave no era publicar “como fuera”. El punto clave era publicar con criterio.
Para mí, esa diferencia es importante. Una cosa es tener una app técnicamente funcional. Otra es tener un producto preparado para pasar por una plataforma exigente, con una narrativa clara, decisiones defendibles y documentación capaz de sostener cada versión.
Ahí es donde la IA empezó a tener un papel muy útil.
IA como capa de orden, no como sustituto de criterio
En esta fase no utilicé la IA para “hacer la publicación”. La utilicé para ordenar el trabajo.
El proceso generó muchos documentos: checklists, notas por versión, textos para App Store, explicaciones orientadas a revisión, resúmenes de cambios y matrices internas para contrastar requisitos.
Lo importante no era producir más texto. Lo importante era producir mejor contexto.
La IA ayudó en tareas muy concretas:
- convertir criterios amplios de plataforma en listas revisables;
- contrastar cambios de producto contra expectativas de privacidad, compra y experiencia;
- preparar documentos orientados a terceros, escritos con claridad y sin ruido técnico innecesario;
- resumir diferencias entre versiones sin perder la trazabilidad;
- revisar si una entrega se estaba explicando desde el punto de vista del usuario y no solo desde el punto de vista del desarrollador.
Pero el criterio seguía siendo humano.
La IA puede ayudar a ordenar una revisión, detectar incoherencias de documentación o proponer una estructura de entrega. Lo que no puede hacer por sí sola es decidir qué experiencia quieres construir, qué compromisos de producto son aceptables o qué nivel de claridad necesita una plataforma para confiar en tu app.
Ese es el trabajo que me interesa cada vez más: usar agentes y modelos como una capa operativa, pero manteniendo el control sobre producto, arquitectura, QA y comunicación.
Documentar para reducir ambigüedad
Una de las lecciones más claras de la publicación en iOS fue que documentar no es burocracia cuando el producto tiene varias capas.
Enolisa no es solo una pantalla para guardar vinos. Es un producto con identidad, cuenta de usuario, privacidad, monetización, evolución funcional y una visión de largo plazo alrededor del conocimiento del vino.
Si todo eso no se explica bien, la revisión externa tiene que deducir demasiado. Y cuando una plataforma tiene que deducir, el proceso se vuelve menos predecible.
Por eso empecé a trabajar con documentos específicos por versión. No eran documentos internos para enseñar la arquitectura completa. Eran documentos de lectura externa: qué cambia, qué valor aporta al usuario, cómo se navega por la app, qué partes son gratuitas, qué partes pertenecen a una experiencia premium y cómo se mantiene la coherencia con las políticas de plataforma.
Esta separación me parece clave.
La documentación interna sirve para construir. La documentación orientada a revisión sirve para explicar. Y un producto serio necesita ambas.
De la checklist al flujo de release
La parte más valiosa del proceso fue transformar una publicación puntual en un flujo repetible.
En vez de trabajar cada entrega como una excepción, fui consolidando una forma de operar:
- revisar la versión anterior publicada;
- identificar qué había cambiado realmente;
- preparar una explicación clara de producto;
- contrastar permisos, privacidad, compras y experiencia;
- revisar textos públicos y material de App Store;
- dejar trazabilidad suficiente para entender por qué se enviaba esa versión.
Este tipo de flujo reduce improvisación. También fuerza a pensar mejor.
Cuando tienes que explicar una funcionalidad a una plataforma, descubres si realmente la funcionalidad está bien colocada dentro del producto. Cuando tienes que describir una compra dentro de la app, descubres si el valor está suficientemente claro para el usuario. Cuando tienes que justificar un permiso o una pantalla de acceso, descubres si la experiencia es tan limpia como pensabas.
Esa es una de las razones por las que considero la publicación en iOS una fase de madurez, no solo una fase administrativa.
El rigor de Apple como espejo de producto
Apple no obliga solo a cumplir reglas. También obliga a tomar decisiones con más precisión.
En una app como Enolisa, donde hay experiencia personal, datos del usuario, funcionalidades premium y una capa de inteligencia futura, esa precisión es útil.
Me obligó a revisar cómo se explicaban las capacidades de la app. Me obligó a separar mejor lo que el usuario podía hacer en cada contexto. Me obligó a pensar en privacidad no como un bloque legal, sino como parte del diseño. Y me obligó a mantener una relación más clara entre producto, documentación y release.
Ese aprendizaje tiene valor más allá de iOS.
Una vez incorporas esa disciplina, también mejora Android, mejora la web, mejora la comunicación del producto y mejora la forma en la que preparas nuevas funcionalidades.
Lo que empieza como una necesidad de publicación acaba convirtiéndose en una forma de trabajar.
Qué dice esto de cómo construyo Enolisa
Para mí, este proceso resume bastante bien el tipo de perfil técnico que estoy construyendo alrededor de Enolisa.
No se trata solo de programar una app. Tampoco se trata solo de tener ideas de producto.
Se trata de operar el ciclo completo:
- entender el modelo de negocio;
- diseñar una experiencia móvil coherente;
- implementar sobre una arquitectura real;
- preparar compras, privacidad y plataforma;
- documentar para terceros;
- validar con criterios de QA;
- usar IA para ganar profundidad y velocidad sin perder control.
Esa combinación es cada vez más importante.
En el trabajo tecnológico que ya está llegando, una persona con criterio puede producir mucho más si sabe apoyarse en agentes, documentación viva, specs iterativas y herramientas de IA. Pero esa capacidad solo tiene valor si está conectada con responsabilidad de producto.
La publicación de Enolisa en iOS fue un buen ejemplo. No fue una tarea aislada de distribución. Fue una prueba de método: cómo convertir una exigencia de plataforma en un proceso de aprendizaje, cómo usar IA para ordenar complejidad y cómo mantener una app preparada para crecer sin perder claridad.
Cierre
Publicar en App Store me hizo ver Enolisa desde fuera.
No como el creador que conoce cada decisión interna, sino como lo vería una plataforma, un usuario nuevo o una persona que evalúa si el producto está bien explicado.
Esa distancia es incómoda a veces, pero muy valiosa. Obliga a limpiar, ordenar, justificar y comunicar.
Y ese es exactamente el tipo de trabajo que quiero reflejar en este blog: no solo construir funcionalidades, sino construir producto con criterio, documentación, QA e IA aplicada de forma práctica.
Lecturas relacionadas
Este artículo forma parte de la serie pública sobre cómo estoy construyendo Enolisa como producto tecnológico end-to-end.