Costruire HelioPeak: lezioni dallo sviluppo iOS indipendente

Alcuni mesi di serate e weekend, sei lingue, tre piattaforme, uno sviluppatore. È in una frase la storia dietro HelioPeak. Questo articolo tratta di come quella storia è stata nella pratica.

È un po' più personale degli altri articoli di questa serie. Cerco di essere onesto su cosa implica un progetto da solo in questo tempo, senza i clichés tipici di "segui solo la tua passione" o "costa meno di quanto pensi". Entrambi sono generalmente semplificazioni false. La realtà è più sfumata, più laboriosa, e segretamente più soddisfacente di quanto i racconti eroici suggeriscano.

Per chi consideri di costruire da solo qualcosa, spero che questo articolo sia informativo. Per chi sia semplicemente curioso su come si costruisce un'app da zero, spero che sia interessante. Per chi sia utente HelioPeak: ecco qualcosa del contesto che aiuta a capire perché l'app è com'è.

Il punto di partenza

Non sono sviluppatore Swift di formazione. Il mio background è IT, infrastruttura, architettura di sistemi, non sviluppo mobile. Non avevo mai pubblicato un'app iOS prima di HelioPeak. La mia esperienza Swift si limitava a poche ore di sperimentazione con SwiftUI nel 2024, principalmente per curiosità.

Nonostante questo, volevo fare un'app iOS specifica: un client PVOutput decente per me stesso. Le app esistenti non facevano esattamente quello che volevo: mancava il supporto iPad e Mac che volevo, le funzioni specifiche che mi aspettavo (Notes, confronti anno su anno, Specific Yield in evidenza), e la mia lingua oltre all'inglese. Poiché ho abbastanza background tecnico da non trovarle impossibili, ho deciso un pomeriggio di gennaio 2026 di farne una. Quello che è diventato da allora.

L'assistenza IA

Senza Claude (lo strumento IA che utilizzo), questo progetto probabilmente non sarebbe esistito. Non perché l'IA ha fatto tutto per me, ma perché ha reso la soglia di apprendimento abbastanza bassa per sostenere serate in cui non avevo energia dopo una giornata di lavoro per leggere un tutorial Swift. L'IA ha abbassato l'altezza del salto.

Cosa fa l'IA nella pratica: generare boilerplate (tutto quello che SwiftUI si aspetta per una nuova schermata, vista, componente), proporre traduzioni tra framework (come cambia un setup UIKit a SwiftUI), proporre considerazioni di architettura (è meglio stato locale o globale qui, dovrei usare un ObservableObject o un @State, come gestisco questo caso di errore?), decifrare messaggi di errore.

Cosa l'IA non fa: prendere decisioni di architettura per me (devo capire i compromessi), trovare bug nel mio proprio codice (devo girare e debuggare), sostituire l'esperienza di test su dispositivo reale (un simulatore mente sulle prestazioni, sui widget, sui permessi), determinare la direzione del prodotto (l'IA può fare una domanda una volta con proposte possibili, ma la scelta resta mia).

Probabilmente l'IA ha raddoppiato o triplicato la mia produttività. Non ha sostituito il mio lavoro. È una distinzione importante perché alcuni articoli su "sviluppo assistito da IA" nel 2026 fanno pensare che un non-sviluppatore possa arrivare a un'app live in un weekend con prompt. Non è così. La parte difficile resta: capire il problema, decidere cosa fare, verificare che quello che l'IA propone abbia davvero senso, e debuggare quello che continua a non funzionare. Quella parte non è diventata più facile.

Cosa ho sottovalutato nella pianificazione di produzione

Alcune cose che ho gravemente sottovalutato all'inizio del progetto, che ogni nuovo progetto indie forse sottovaluta:

Internazionalizzazione. Sei lingue dall'inizio. Una scelta di prodotto fondamentalmente giusta (il che ha una base globale più ampia dal giorno uno), ma ho enormemente sottovalutato il costo operativo. Ogni nuova stringa UI deve passare attraverso sei traduzioni. Ogni modifica può rompere una traduzione in una lingua se non si è attenti. Le stringhe in Swift non sono interpolate secondo la lingua attiva, quindi un placeholder mal posizionato può causare un crash in italiano ma funzionare in inglese. La verifica di ogni release in tutte le lingue con scenari di test è estenuante.

Il processo App Store di Apple. La mia prima sottomissione è stata rifiutata da una Developer Review che non mi aspettavo (sulla gestione di task in background e caricamenti di dati). Ho avuto bisogno di tre iterazioni prima di ottenere la prima versione live. Ogni release successiva è stata più fluida, ma il periodo dal primo Submit al primo App Store live è stato due settimane più lungo di quanto pianificato.

Compliance privacy. Politica privacy, App Tracking Transparency, Privacy Nutrition Labels, manifesti API: tutti requisiti che sembrano piccoli, ma esigono ore di lavoro e ricevono aggiornamenti regolari di Apple che rompono gli accordi vecchi. Ho speso più tempo in moduli di compliance privacy che a scrivere la funzione Notes.

Marketing e scoperta. Fare una buona app è una cosa. Trovare persone che la vogliano usare è un'altra cosa. Ho passato molte serate scrivendo post di forum, contattando blogger, rispondendo su reddit, regolando le descrizioni dell'App Store, senza che si possa dire chiaramente quale di queste attività abbia veramente fatto qualcosa. Le app indie vivono o muoiono più per il passaparola e l'inclusione in liste accidentali che per il marketing tradizionale.

Cosa ho sottovalutato nei dettagli tecnici

Alcune lezioni tecniche che sono diventate chiare solo durante il cammino:

Testare su dispositivo reale è insostituibile. Quello che ha buon aspetto sul Mac Simulator a volte fallisce su un iPhone reale. Il simulatore non ha il throttling termico del dispositivo reale, non mostra i problemi reali di batteria con i widget che si rinfrescano, non mostra il comportamento di rete reale fuori dal wifi di casa. Ho preso bug durante il viaggio al lavoro sul suo iPhone che non avrei mai visto al desk.

I widget sono più difficili di quanto sembrino. I widget iOS sono un progetto secondario proprio con il proprio ciclo di vita, i propri limiti di memoria, il proprio frame di tempo, e il proprio paradigma di pre-calcolo di dati. Renderli sentiti live richiede un'architettura di pre-rendering nell'app principale, il che diventa rapidamente più complesso della schermata principale stessa.

La localizzazione di date, numeri e valute è un campo minato. "5.400 kWh" in formato olandese/tedesco significa 5400; "5,400" in formato inglese/americano significa anche 5400; ma "5,400" in formato francese/italiano significa 5,4. Una sola cattiva interpretazione, e ottiene cifre di produzione che hanno un valore 1.000 volte inferiore in una lingua. Ho passato più tempo di quanto voglio confessare a debuggare questi errori.

Swift Charts di Apple è brillante ma incompleto. Il framework Apple per i grafici in SwiftUI è elegante per i casi standard, ma gli mancano i casi estremi (etichette personalizzate sui punti di dati specifici, tooltip non standard, certi tipi di zoom). Ho dovuto risolvere diversi casi con custom overlay sopra SwiftUI Charts, il che funziona ma è complicato.

Cosa ho imparato sul pricing indie

Il mio approccio al pricing di HelioPeak è cambiato nel tempo, e i dati mi hanno insegnato alcune cose.

Al primo lancio in aprile 2026, l'IAP era a 2,99 €. Era troppo basso. Ho notato nei dati che gli utenti che pagavano restavano più attivi e più impegnati, ma il gruppo di pagamento era piccolo perché il prezzo stesso segnalava "non molto importante". Nella versione 2.0 l'ho alzato a 6,99 €, e con mia sorpresa il tasso di conversione è cambiato appena ma i ricavi per utente sono più che raddoppiati. Gli utenti esistenti con il vecchio prezzo mantengono il loro unlock; i nuovi utenti pagano il nuovo prezzo.

Tre riflessioni da questo:

Troppo basso al lancio. Guardando indietro, avrei dovuto cominciare più alto e giustificarlo con la qualità. "2,99 €" suona cheap. "6,99 €" suona serio. La differenza è psicologica, non economica.

Onesto al rilancio. Alzare un prezzo retroattivamente a utenti esistenti è infido. Mantenerlo prospettico (i vecchi utenti conservano il loro vecchio prezzo, i nuovi utenti pagano il nuovo) è l'unico modo onesto. Qualsiasi altra cosa rompe la fiducia.

Compromesso no-subscription. Continuo a credere dopo alcuni mesi nel mio compromesso originale (acquisto unico, nessun abbonamento per le funzioni core). È un trade-off di modello di business che limita quanto aggressivamente posso crescere, ma rispetta gli utenti sulla vita utile di 25 anni dell'impianto solare.

Cosa ho imparato sui tassi di conversione: la percentuale di utenti gratuiti che convertono a paganti è bassa (tra il 3 e l'8% secondo i miei dati), il che è tipico per un'app indie. La maggior parte degli utenti resta nel tier gratuito. E va bene così. Un'app indie non ha bisogno della conversione di massa, ma di una base stabile e impegnata di utenti che valorizzano l'app e pagano occasionalmente. Quello è quello che HelioPeak sembra avere.

Cosa ho imparato sugli utenti

Alcune osservazioni sulla base di utenti HelioPeak che hanno sorpreso o confermato le mie aspettative:

Sono più anziani di quanto pensassi. L'età media dei compratori che ho visto attraverso il feedback nei forum è di circa 50 anni, non di 30. Ha senso in retrospettiva: i pannelli solari sono un investimento a lungo termine, e le famiglie che hanno pannelli tendono verso persone stabilite con proprietà di abitazione. I dati demografici cambiano come scrivo il copy dell'app e gli articoli: meno gergo, più spiegazione, più collegamenti a informazioni di sfondo.

Hanno vere aspettative di qualità. Le recensioni HelioPeak sono dettagliate, tecnicamente competenti e specifiche sul feedback. Le persone di questo gruppo demografico non scrivono "5 stelle, buona app", scrivono "5 stelle, apprezzo specialmente il layout iPad, ma la funzione Y potrebbe migliorare nel seguente modo". Questo chiede di prenderli sul serio, e guida la roadmap più fortemente delle recensioni di utenti più giovani con app meno profonde.

Sono orientati alla comunità. Una parte significativa della base di utenti HelioPeak è arrivata tramite thread di forum (Tweakers, forum PVOutput) piuttosto che tramite marketing tradizionale o ASO sull'App Store. Le persone della comunità solare passano la loro conoscenza ad altri utenti solari, e un buon pitch in un thread di forum alimentato attivamente porta più utenti stabili di una campagna di Reddit Ads.

Sono fedeli se lo fa bene. Il churn è basso. Gli utenti che restano con l'app dopo alcuni mesi restano spesso anni. Conferma un'esperienza più ampia nel panorama indie: se la sua app risponde a un bisogno e rispetta i suoi utenti, il problema non è la retention ma l'acquisizione.

Le piccole lezioni che ho trovato inaspettatamente preziose

Alcune cose più pratiche che hanno migliorato il mio flusso di lavoro più di quanto mi aspettassi introducendole:

Scrivere uno script di commit. Invece di fare git commit manualmente, ho ora uno script che valida i cambiamenti, fa il commit, carica su GitHub e spinge un dSYM a Sentry per il crash reporting. Le due ore scrivendo quello script hanno risparmiato decine di ore nell'ultimo anno.

Integrare TelemetryDeck dall'inizio. Avrei iniziato le analytics dal giorno uno, non da una versione successiva. Le prime settimane hanno prodotto dati che sarebbero stati preziosi da mantenere, e li ho persi perché non avevo ancora trovato come raccoglierli senza violare i miei principi privacy. (Alla fine l'ho trovato; vedi La questione della privacy.) Quei dati persi sono persi.

Note a me stesso nel codice. Piccoli commenti // HACK: o // TODO: rivedere dopo release X nel codice sono diventati una memoria di progetto inestimabile. Per un progetto che è attivo per mesi con pause frequenti, non sono capace senza quelle tracce di ricordare perché ho preso una decisione specifica.

Testare con utenti reali prima di essere veramente pronto. Il TestFlight beta aperto che ho iniziato a metà progetto ha preso bug e dato feedback che non avrei mai trovato nei miei test. Gli utenti beta usano l'app in modo diverso da me, e quelle differenze sono dove sono i bug.

Cosa resta

In questo momento, ho alcune centinaia di utenti HelioPeak, con buone recensioni sull'App Store, una comunità attiva su Tweakers, e una lista back abbastanza lunga di funzioni che voglio costruire. I ricavi non sono ancora sufficienti per fare di questo un lavoro a tempo pieno (spero che sia possibile eventualmente), ma fanno sì che il progetto si autofinanzi e cresca incrementalmente.

Cosa porto via soprattutto da questo progetto:

Iniziare con qualcosa di cui senta lei stesso il bisogno. L'energia e la motivazione per mantenersi per mesi vengono solo se il problema è veramente suo.

Contare con stime di tempo realistiche. La cosa prende sempre due-tre volte di più di quanto pensavo che avrebbe preso. Non è pessimismo, è realismo.

Mantenere il ciclo di iterazione corto e non preoccuparsi troppo della perfezione nella versione 1. Una versione 1 imperfetta che è sul mercato si aggiusta tramite il feedback. Una versione perfetta che non arriva mai sul mercato non impara nulla.

Costruire con privacy e qualità in mente dall'inizio. È più facile farlo bene la prima volta che retrofittare dopo. E la fiducia degli utenti, una volta guadagnata, è difficile da recuperare dopo una cattiva decisione.

E non avere paura di essere onesto su cosa la sua app non fa. Ogni app ha limiti, e gli utenti rispettano più uno sviluppatore che è chiaro sui suoi limiti di uno che pretende qualcosa che non è.

Per concludere

HelioPeak non è una storia di successo nel senso finanziario (non ancora), ma sì nel senso personale: ho costruito qualcosa che volevo, l'ho pubblicato in sei lingue, in tre piattaforme, in tempo, ed è apprezzato da persone reali. Che valga anche finanziariamente nei prossimi anni, dipende da cose fuori dal mio controllo (l'economia solare continua, gli utenti continuano ad arrivare tramite passaparola). Ma il risultato dell'apprendimento e della soddisfazione del mestiere esiste già e nessuno me lo toglierà.

Per i lettori che considerano di costruire qualcosa di simile da soli, il mio consiglio finale è semplice: cominci. La distanza tra "ho un'idea" e "ho una prima versione" è molto più lunga di quanto pensi, ma la distanza tra "ho una prima versione" e "ho qualcosa in cui le persone hanno fiducia" è gestibile se la prima distanza è già stata percorsa. La parte più difficile è cominciare. Tutto il resto è questione di mostrarsi ogni sera con abbastanza energia per fare una sola cosa in più.

Quello, probabilmente, è la lezione nascosta più grande dello sviluppo indipendente: costruire, in sé, vale già la pena, indipendentemente da dove finisca alla fine.