Construir HelioPeak: lecciones del desarrollo iOS independiente

Algunos meses de tardes y fines de semana, seis lenguas, tres plataformas, un desarrollador. Es en una frase la historia detrás de HelioPeak. Este artículo trata de cómo esa historia ha sido en la práctica.

Es algo más personal que los otros artículos de esta serie. Intento ser honesto sobre lo que implica un proyecto solo en este tiempo, sin los clichés típicos de "sigue solo tu pasión" o "cuesta menos de lo que piensas". Ambos son generalmente simplificaciones falsas. La realidad es más matizada, más laboriosa, y secretamente más satisfactoria que los relatos heroicos sugieren.

Para quien considere por sí mismo construir algo, espero que este artículo sea informativo. Para quien sea simplemente curioso sobre cómo se construye una app desde cero, espero que sea interesante. Para quien sea usuario HelioPeak: aquí algo del contexto que ayuda a entender por qué la app es como es.

El punto de partida

No soy desarrollador Swift de formación. Mi background es IT, infraestructura, arquitectura de sistemas, no desarrollo mobile. Nunca había publicado una app iOS antes de HelioPeak. Mi experiencia Swift se limitaba a algunas horas de experimentación con SwiftUI en 2024, principalmente por curiosidad.

A pesar de eso, quería hacer una app iOS específica: un cliente PVOutput decente para mí mismo. Las apps existentes no hacían exactamente lo que quería: faltaba el iPad y Mac soporte que quería, las funciones específicas que esperaba (Notes, comparaciones año sobre año, Specific Yield destacado), y mi propia lengua además del inglés. Como tengo suficiente background técnico para no encontrarlas imposibles, decidí una tarde de enero de 2026 hacer una. Lo que se ha vuelto desde entonces.

La asistencia IA

Sin Claude (la herramienta IA que utilizo), este proyecto no habría existido probablemente. No porque la IA hizo todo por mí, sino porque hizo el umbral de aprendizaje suficientemente bajo para mantener tardes donde no tenía energía después de un día de trabajo para leer un tutorial Swift. La IA bajó la altura del salto.

Lo que la IA hace en la práctica: generar boilerplate (todo lo que SwiftUI espera para un nuevo screen, vista, componente), proponer traducciones entre frameworks (cómo cambia un setup UIKit a SwiftUI), proponer consideraciones de arquitectura (¿es mejor estado local o global aquí, debería usar un ObservableObject o un @State, cómo manejo este caso de error?), descifrar mensajes de error.

Lo que la IA no hace: tomar decisiones de arquitectura por mí (debo entender los compromisos), encontrar bugs en mi propio código (debo correr y debuggar), reemplazar la experiencia de tests en aparato real (un simulador miente sobre el rendimiento, los widgets, los permisos), determinar la dirección del producto (la IA puede hacer una pregunta una vez con propuestas posibles, pero la elección queda mía).

Probablemente la IA ha duplicado o triplicado mi productividad. No ha sustituido mi trabajo. Es una distinción importante porque algunos artículos sobre "desarrollo asistido por IA" en 2026 hacen pensar que un no-desarrollador puede llegar a una app live en un fin de semana con prompts. No es así. La parte difícil sigue siendo: comprender el problema, decidir qué hacer, verificar que lo que la IA propone tiene realmente sentido, y debuggar lo que sigue mal. Esa parte no se ha vuelto más fácil.

Lo que he subestimado en la planificación de producción

Algunas cosas que he subestimado severamente al inicio del proyecto, que cada nuevo proyecto indie subestima quizás:

Internacionalización. Seis lenguas desde el principio. Una elección de producto fundamentalmente correcta (lo que tiene una base global más amplia desde el día uno), pero he subestimado enormemente el coste operacional. Cada nueva cadena UI debe pasar por seis traducciones. Cada cambio puede romper una traducción en una lengua si no está atento. Las cadenas en Swift no son interpoladas según la lengua activa, así que un placeholder mal puesto puede causar un crash en español pero funcionar en inglés. La verificación de cada release en todas las lenguas con escenarios de test es agotadora.

El proceso App Store de Apple. Mi primera sumisión ha sido rechazada por un Developer Review que no esperaba (sobre el manejo de tareas en segundo plano y cargas de datos). He necesitado tres iteraciones antes de obtener la primera versión live. Cada release siguiente ha sido más fluido, pero el periodo del primer Submit al primer App Store live ha sido dos semanas más largo de lo planificado.

Compliance privacy. Política de privacidad, App Tracking Transparency, Privacy Nutrition Labels, manifiestos API: todos requisitos que parecen pequeños, pero exigen horas de trabajo y reciben actualizaciones regulares de Apple que rompen los acuerdos antiguos. He gastado más tiempo en formularios de compliance privacy que en escribir la función Notes.

Marketing y descubrimiento. Hacer una buena app es una cosa. Encontrar personas que la quieran usar es otra cosa. He pasado muchas tardes escribiendo posts de foros, contactando con bloggers, respondiendo en reddit, ajustando las descripciones de la App Store, sin que pueda decirse claramente cuál de estas actividades ha hecho realmente algo. Las apps indie viven o mueren más por el boca a oreja y la inclusión en listas accidentales que por el marketing tradicional.

Lo que he subestimado en los detalles técnicos

Algunas lecciones técnicas que solo se han vuelto claras durante el camino:

Probar en aparato real es insustituible. Lo que tiene buen aspecto en el Mac Simulator a veces falla en un iPhone real. El simulador no tiene el throttling térmico del aparato real, no muestra los problemas reales de batería con los widgets que se refrescan, no muestra el comportamiento de red real fuera de la wifi de casa. He cogido bugs durante el viaje al trabajo en su iPhone que jamás habría visto en el desk.

Los widgets son más difíciles de lo que parecen. Los widgets iOS son un proyecto secundario propio con su propio ciclo de vida, sus propios límites de memoria, su propio frame de tiempo, y su propia paradigma de pre-cálculo de datos. Hacerlos sentir live requiere una arquitectura de pre-rendering en la app principal, lo que se vuelve rápidamente más complejo que la pantalla principal misma.

La localización de fechas, números y monedas es un campo de minas. "5.400 kWh" en formato neerlandés/alemán significa 5400; "5,400" en formato inglés/americano significa también 5400; pero "5,400" en formato francés/español significa 5,4. Una sola mala interpretación, y obtiene cifras de producción que tienen un valor de 1.000 veces menos en una lengua. He pasado más tiempo del que quiero confesar debuggando estos errores.

Swift Charts de Apple es brillante pero incompleto. El framework Apple para los gráficos en SwiftUI es elegante para los casos estándar, pero le falta los casos extremos (etiquetas personalizadas en los puntos de datos específicos, tooltips no estándar, ciertos tipos de zoom). He tenido que resolver varios casos con custom overlays sobre SwiftUI Charts, lo que funciona pero es complicado.

Lo que he aprendido sobre el pricing indie

Mi enfoque del pricing de HelioPeak ha cambiado con el tiempo, y los datos me han enseñado algunas cosas.

En el primer lanzamiento en abril de 2026, el IAP estaba en 2,99 €. Era demasiado bajo. He notado en los datos que los usuarios que pagaban se quedaban más activos y más comprometidos, pero el grupo de pago era pequeño porque el precio mismo señalaba "no muy importante". En la versión 2.0 lo he subido a 6,99 €, y para mi sorpresa la tasa de conversión apenas ha cambiado pero los ingresos por usuario se han más que duplicado. Los usuarios existentes con el antiguo precio guardan su unlock; los nuevos usuarios pagan el nuevo precio.

Tres reflexiones de esto:

Demasiado bajo al lanzamiento. Mirando hacia atrás, debería haber empezado más alto y haberlo justificado por la calidad. "2,99 €" suena cheap. "6,99 €" suena serio. La diferencia es psicológica, no económica.

Honesto al relanzamiento. Subir un precio retroactivamente a usuarios existentes es traicionero. Mantenerlo prospectivo (los antiguos usuarios conservan su precio antiguo, los nuevos usuarios pagan el nuevo) es la única manera honesta. Cualquier otra cosa rompe la confianza.

No-subscription compromiso. Sigo creyendo después de algunos meses en mi compromiso original (compra única, sin suscripción para las funciones core). Es un trade-off de modelo de negocio que limita lo agresivamente que puedo crecer, pero respeta a los usuarios sobre la vida útil de 25 años de la instalación solar.

Lo que he aprendido sobre las tasas de conversión: el porcentaje de usuarios gratuitos que convierten a pagantes es bajo (entre 3 y 8 % según mis datos), lo que es típico para una app indie. La mayoría de los usuarios se quedan en el tier gratuito. Y eso está bien. Una app indie no necesita la conversión enmasse, sino una base estable y comprometida de usuarios que valoran la app y pagan ocasionalmente. Eso es lo que HelioPeak parece tener.

Lo que he aprendido sobre los usuarios

Algunas observaciones sobre la base de usuarios HelioPeak que han sorprendido o confirmado mis expectativas:

Son más mayores de lo que pensaba. La edad media de los compradores que he visto a través del feedback en los foros es de unos 50 años, no de 30. Tiene sentido en retrospectiva: los paneles solares son una inversión a largo plazo, y los hogares que tienen paneles tienden hacia personas establecidas con propiedades de vivienda. Los datos demográficos cambian cómo escribo el copy de la app y los artículos: menos jerga, más explicación, más enlaces a información de fondo.

Tienen verdaderas expectativas de calidad. Las opiniones HelioPeak son detalladas, técnicamente competentes y específicas sobre el feedback. La gente de este grupo demográfico no escribe "5 estrellas, buena app", escriben "5 estrellas, especialmente aprecio el iPad layout, pero la función Y podría mejorar de la siguiente forma". Eso pide tomarse en serio, y conduce el roadmap más fuertemente que las opiniones de usuarios más jóvenes con apps menos profundas.

Son orientados a la comunidad. Una parte significativa de la base de usuarios HelioPeak ha llegado vía hilos de foro (Tweakers, foro PVOutput) más que vía marketing tradicional o ASO en la App Store. La gente de la comunidad solar entrega su conocimiento a otros usuarios solares, y un buen pitch en un hilo de foro alimentado activamente trae más usuarios estables que un campaña de Reddit Ads.

Son fieles si lo haces bien. El churn es bajo. Los usuarios que se quedan con la app después de algunos meses se quedan a menudo años. Confirma una experiencia más amplia en el panorama indie: si su app responde a una necesidad y respeta a sus usuarios, el problema no es la retención sino la adquisición.

Las pequeñas lecciones que he encontrado inesperadamente valiosas

Algunas cosas más prácticas que han mejorado mi flujo de trabajo más de lo que esperaba al introducirlas:

Escribir un script de commit. En lugar de hacer git commits manualmente, tengo ahora un script que valida los cambios, hace el commit, sube a GitHub y empuja un dSYM a Sentry para el crash reporting. Las dos horas escribiendo ese script han ahorrado decenas de horas en el último año.

Integrar TelemetryDeck desde el principio. Habría empezado los analytics desde el día uno, no desde una versión posterior. Las primeras semanas produjeron datos que habrían sido valiosos para mantener, y los he perdido porque aún no había encontrado cómo recogerlos sin violar mis propios principios de privacidad. (Finalmente lo he encontrado; véase La cuestión de la privacidad.) Esos datos perdidos están perdidos.

Notas para mí mismo en el código. Pequeños comentarios // HACK: o // TODO: revisar después de release X en el código se han vuelto una memoria de proyecto inestimable. Para un proyecto que está activo durante meses con pausas frecuentes, no soy capaz sin esos rastros de recordar por qué he tomado una decisión específica.

Probar con usuarios reales antes de estar realmente listo. El TestFlight beta abierto que he iniciado a mediados del proyecto ha cogido bugs y dado feedback que nunca habría encontrado en mis propios tests. Los usuarios beta usan la app de manera diferente a yo, y esas diferencias son donde están los bugs.

Lo que queda

En este momento, tengo algunos centenares de usuarios HelioPeak, con buenas opiniones en la App Store, una comunidad activa en Tweakers, y una lista back lo bastante larga de funciones que quiero construir. Los ingresos no son aún suficientes para hacer de esto un trabajo a tiempo completo (espero que sea posible eventualmente), pero hacen que el proyecto se autofinancie y crezca incrementalmente.

Lo que me llevo sobre todo de este proyecto:

Empezar con algo de lo que sienta usted mismo la necesidad. La energía y la motivación para mantenerse durante meses solo vienen si el problema es realmente suyo.

Contar con estimaciones de tiempo realistas. La cosa toma siempre dos a tres veces más de lo que pensaba que tomaría. No es pesimismo, es realismo.

Mantener el ciclo de iteración corto y no preocuparse demasiado por la perfección en la versión 1. Una versión 1 imperfecta que está en el mercado se ajusta vía el feedback. Una versión perfecta que nunca llega al mercado no aprende nada.

Construir con privacidad y calidad en mente desde el inicio. Es más fácil hacerlo bien la primera vez que retrofitar más tarde. Y la confianza de los usuarios, una vez ganada, es difícil de recuperar tras una mala decisión.

Y no tener miedo de ser honesto sobre lo que su app no hace. Cada app tiene límites, y los usuarios respetan más a un desarrollador que es claro sobre sus límites que a uno que pretende algo que no es.

Para terminar

HelioPeak no es una historia de éxito en el sentido financiero (todavía no), pero sí en el sentido personal: he construido algo que quería, lo he publicado en seis lenguas, en tres plataformas, en plazo, y es apreciado por personas reales. Que también valga financialmente en los próximos años, depende de cosas fuera de mi control (la economía solar continua, los usuarios siguen llegando vía boca a oreja). Pero el resultado del aprendizaje y de la satisfacción del oficio existe ya y no me lo quitará nadie.

Para los lectores que consideran construir algo similar por sí mismos, mi consejo final es simple: empiece. La distancia entre "tengo una idea" y "tengo una primera versión" es mucho más larga de lo que piensa, pero la distancia entre "tengo una primera versión" y "tengo algo en lo que la gente tiene confianza" es manejable si la primera distancia ya ha sido recorrida. La parte más difícil es empezar. Todo lo demás es cuestión de mostrarse cada tarde con suficiente energía para hacer una sola cosa más.

Eso, probablemente, es la lección oculta más grande del desarrollo independiente: construir, en sí, ya merece la pena, independientemente de dónde termine al final.

Sven, mayo de 2026