Sviluppare un'app iOS nativa

Riassunto

Come piccolo progetto parallelo, infilato tra il mio lavoro di tutti i giorni, ho lavorato a qualcosa di personale: un'app nativa per iOS che traccia gli allenamenti. Volevo rendere inutile il mio smartwatch e usare il telefono per tracciare gli allenamenti. Quanto può essere difficile raccogliere dati dettagliati dai sensori con le API native di Swift?

Testo completo

Contesto

Se segui il mio blog, non ti sorprenderà: adoro andare in bici e da poco ho cominciato anche a correre. Ho parecchia esperienza nel tracciare i miei allenamenti, con Garmin, Strava, Omata, Wahoo, Biostrap, Whoop e varie app e sensori. Trovo utili i dati su salute e fitness per conoscere le tue prestazioni fisiche e per avere una specie di responsabilità verso te stesso (per esempio, ti motiva a continuare gli allenamenti).

Il nerd che è in me ama i grandi insiemi di dati, i tanti tipi di sensori disponibili sono una festa per la mia curiosità, ma questo è in conflitto con il mio desiderio di minimalismo e di semplicità. Ti servono davvero tutti i dati degli allenamenti? Non basta forse ascoltare il proprio corpo? Non lo so, ma apprezzo la capacità di uno smartwatch di tracciare gli allenamenti nei dettagli, (quasi) senza fatica. Mi piace come l'Apple Watch si possa usare per tracciare gli allenamenti, oltre alle sue qualità di moderno orologio da lavoro e sostituto del telefono. Capisco che la maggior parte delle persone indossi lo smartwatch e basta, ma a me piacciono anche i vecchi orologi meccanici come un Rolex, un Tudor, un Grand Seiko, o perfino qualcosa fatto su misura. Anche se li apprezzo entrambi, quando devo scegliere tra smartwatch e orologi meccanici tendo verso gli orologi meccanici.

L'idea per l'app: Gran Fondo

E se esistesse un'app per smartphone che raccoglie tutti i dati dell'allenamento che vuoi, senza fastidi e senza confusione? Me la immaginavo così:

• Semplice: deve "togliersi di mezzo", essere pensata per "funzionare e basta", senza bisogno di trafficare con impostazioni e opzioni infinite. Premi "start" e inizi l'allenamento.
• Flessibile: usa l'app in modi diversi: monta o indossa il telefono in vista per i dati in tempo reale, oppure mettilo in tasca e lascialo lavorare in background.
• Potente: collegati con sensori di frequenza cardiaca, cadenza, potenza e velocità via Bluetooth; supporta più sensori, ideale se usi bici diverse.
• Amica di Apple Health: salva tutti i dati in Apple Health con il massimo dettaglio, compresi i percorsi degli allenamenti e le singole misure di potenza, cadenza e velocità. Così puoi analizzare le registrazioni in qualsiasi app che supporti Apple Health, come Strava, WHOOP, HealthFit e molte altre.
• Onesta: niente pubblicità né vendita di dati. Niente account né registrazione. I tuoi dati devono restare privati, al sicuro e sul tuo dispositivo.

Nessuna delle app di sport e fitness per smartphone che esistono soddisfa tutti questi punti. La maggior parte è inutilmente complessa o è in qualche modo pensata per portare via i tuoi dati a vantaggio di chi ha fatto l'app o della sua piattaforma. Potevo fare di meglio?

Costruire l'app

Sapendo perché e cosa volevo, ho deciso come costruire l'app.

Nativa contro ibrida/web

Per la maggior parte del lavoro che faccio preferisco tecnologie web aperte e libere (nel senso di libertà), come HTML, JavaScript e CSS, oppure software server rilasciato con una licenza di software libero, come la GPL. Per questo caso d'uso avevo bisogno di un'efficienza energetica estrema e di integrarmi a fondo con il sistema operativo dello smartphone. Il modo migliore per farlo su un iPhone è abbracciare fino in fondo il kit di sviluppo software di Apple: fare l'app in modo nativo in Swift con SwiftUI e seguire il più possibile la documentazione tecnica e le linee guida di design.

Programmare con l'aiuto dell'IA

Anche se ho le mie riserve, ultimamente programmare con l'IA attira tutta l'attenzione. Qualcuno sostiene perfino che tecnologie come Copilot o ChatGPT renderanno inutili i programmatori. Io con l'IA ci so fare: l'ho usata per generare codice, insegno alla gente come usarla, ma non l'avevo mai usata per costruire un'app iOS completa. Ho pensato che fosse l'occasione perfetta per vedere quanto sia adatta l'IA a qualcosa di più complesso di un semplice frammento di script. Scopriamo quanto sono obsoleto come programmatore in questa moderna era dell'IA...

GPS e sensori Bluetooth Low Energy

Dopo aver configurato il mio ambiente Xcode, ho chiesto a ChatGPT di OpenAI di darmi del codice per leggere i dati di posizione GPS e di generare le classi Swift necessarie per rilevare e collegarsi ai sensori Bluetooth. Ragazzi, sono finito nella proverbiale tana del coniglio!

Il punto della programmazione assistita dall'IA è che SÌ funziona, ma solo IN PARTE. Ti dà pezzi che funzionano, ma non si incastrano perfettamente e non per forza lavorano insieme. Vedere il codice che genera è come sentire gli echi di una grande canzone: riconosci che somiglia a qualcosa, ma non è proprio la stessa cosa che sentire la band suonare dal vivo, figuriamoci cantarla tu!

Ho preso i pezzi dell'IA e mi sono messo a leggere da solo la documentazione rilevante, e questo si è rivelato molto più efficace, perché mi ha permesso di capire davvero cosa dovesse fare il meccanismo. L'IA mi ha aiutato a trovare le cose da imparare. Tracciare i dati di posizione GPS è stato sorprendentemente facile con CoreLocation di Apple. Collegare il sensore Bluetooth all'app si è rivelato molto più difficile, perché richiede molti passaggi distinti:

• Rilevare i dispositivi Bluetooth: cercare nella zona circostante i dispositivi disponibili che stanno trasmettendo
• Collegarsi a un dispositivo Bluetooth: stabilire e mantenere una connessione tra l'app e il dispositivo
• Scoprire le caratteristiche del dispositivo Bluetooth: un dispositivo Bluetooth semplice non esiste, devi fare tu la "scoperta" delle capacità e delle funzioni del dispositivo; molti dispositivi trasmettono più segnali diversi, sia per i dati dei sensori sia per i meccanismi di controllo e per i parametri operativi, come il livello della batteria.
• Sottoscrivere le caratteristiche: alla fine ci si abbona a un flusso di dati sintonizzando le radio Bluetooth su una certa caratteristica Bluetooth.
• Decodificare i dati: dato che è fatto per risparmiare energia, ricevi pochissimi dati in bit grezzi; i pacchetti di dati devi decodificarli tu; la parte difficile è che ogni sensore, di qualsiasi produttore, codifica i dati a modo suo.

Prendiamo un sensore "semplice" come un sensore di cadenza da mettere sul pedale della bici, che si può usare per ricavare i giri al minuto durante un'uscita in bici. Quanto può essere difficile? Pensavo che la specifica ufficiale del Bluetooth mi avrebbe dato tutti i dettagli necessari... MACCHÉ! Un semplice sensore di cadenza è sorprendentemente complesso:

• Profilo Bluetooth combinato per velocità e cadenza del ciclismo: qualsiasi sensore di cadenza si identifica sempre come sensore di velocità e di cadenza, e le sue capacità vanno scoperte "al volo".
• Pacchetti di dati non uniformi: il contenuto dei dati dipende dalle capacità attuali del sensore (per esempio, se ha rilevato qualcosa), e il pacchetto va interpretato bit per bit, controllando i possibili flag che indicano cosa rappresenta il bit successivo.
• Dati non banali: non aspettarti un valore chiaro per la "cadenza", il sensore ti dà un conteggio cumulativo dei giri e un timestamp rudimentale dell'ultimo cambiamento rilevato; devi usare questi valori per calcolare la metrica che cerchi di misurare.

L'IA mi ha dato del codice di esempio, ma non funzionava con il mio sensore. Con un'app di debug per Bluetooth, Bluefy, sono riuscito a capire meglio i dati che il sensore trasmetteva. Sul blog ufficiale del Bluetooth ho trovato un pezzo di codice Java che mi ha dato qualche indizio su come interpretare i dati dei sensori. Ho adattato quel codice a vari profili di sensore diversi e l'ho tradotto in Swift. Così ho ottenuto un primo prototipo funzionante.

Design UI/UX

Uno dei motivi principali per cui mi piace l'app Allenamento dell'Apple Watch è che la sua interfaccia utente (UI) è pensata per offrire un'esperienza d'uso (UX) piacevole. L'app sull'orologio ha pulsanti piuttosto grandi che premi per avviare una registrazione, e più o meno basta. L'app ha poche opzioni, il suo design ha un'impronta decisa ma è molto ponderato. È un contrasto netto con dispositivi come Garmin, che offrono un mare di opzioni di personalizzazione. Il trucco è trovare il giusto equilibrio tra flessibilità nei casi d'uso e un'impostazione predefinita che funzioni bene.

Con un sistema di fissaggio come QuadLock puoi attaccare saldamente lo smartphone al manubrio della bici. Così l'iPhone può sostituire il tuo Garmin come ciclocomputer. Gli iPhone moderni hanno un display sempre attivo che può mostrare informazioni in modo efficiente dal punto di vista energetico, a patto di usare il kit di sviluppo software di Apple, che include varie ottimizzazioni. Dopo moltissimi chilometri con il mio ciclocomputer Garmin, ho scelto una vista con campi dati in tempo reale per velocità, potenza e frequenza cardiaca. Quello che mi piace dei Garmin Edge più avanzati è che possono tracciare un grafico. Così tieni gli occhi sulla strada quando conta e dai un'occhiata ai dati storici un po' più tardi.

Per massimizzare l'efficienza energetica ho deciso di usare le librerie di Apple per i grafici: Swift Charts. Un problema che ho incontrato durante lo sviluppo è che le misure dei sensori arrivano a intervalli e in momenti diversi. Serve una specie di meccanismo di sincronizzazione per avere punti dati con timestamp comuni, così da poter confrontare e mettere in relazione i valori. Ho progettato questo meccanismo per sincronizzare anche gli aggiornamenti dell'interfaccia: tutti i grafici e i punti dati si aggiornano in un unico refresh, ottimizzando CPU e prestazioni grafiche (e quindi la batteria). Come extra ho aggiunto il supporto per diversi intervalli di tempo, così i grafici possono mostrare i dati dell'ultimo minuto, di 5 minuti, di 15 minuti, dell'ultima ora o dell'intero allenamento.

L'app mostra automaticamente i grafici disponibili in base ai sensori collegati, e non servono configurazioni diverse se hai più di una bici. Se tocchi un grafico, si ingrandisce o si riduce. Se tocchi l'intervallo dei dati (per esempio "ultimi 5 minuti"), puoi passare da uno all'altro. L'app ricorda la tua configurazione e ti prepara in automatico per l'allenamento successivo. Siccome tutti i punti da toccare e i pulsanti sono piuttosto grandi, funzionano bene anche con le mani sudate o con i guanti.

Da tasca: ottimizzare per l'uso in background e il consumo di energia

Un altro modo in cui immaginavo di usare l'app era dalla tasca, come app in background. Così si può raccogliere i dati in modo discreto: avvii l'app e metti via il telefono. Mi piace l'idea di avere un "set di dati completo" per tutte le mie uscite in bici e le mie corse, senza dover avere l'app al centro dell'attenzione sempre. Molti allenamenti di corsa e uscite in bici non sono così interessanti.

Di default il sistema operativo iOS di Apple limita rigorosamente le possibilità delle app di girare in background. Questo massimizza la durata della batteria e la privacy dell'utente. Se segui le linee guida di Apple e chiedi correttamente all'utente i permessi necessari, puoi in effetti progettare la tua app perché funzioni alla perfezione in background. Ho davvero imparato ad apprezzare gli sforzi di Apple per ottimizzare tutto lo stack, che permettono alla tua app di essere più efficiente dal punto di vista energetico. In poche parole, "non chiamateci, vi chiamiamo noi" è ciò che fa il sistema operativo: prende il controllo di quando la tua app fa le sue cose, e così può sincronizzare, combinare ed elaborare a lotti attività diverse sui core disponibili (a basso consumo) dei chip Apple Silicon.

Durante uno dei miei test con una versione prototipo dell'app sono riuscito a raccogliere oltre 127 mila (!!) punti dati in un'uscita in bici di 8 ore su una sola carica della batteria dell'iPhone, con lo schermo acceso tutto il tempo. Se giochi secondo le regole di Apple, hai davvero il potere (per così dire). Sviluppare questa app mi ha portato lontano, ah!

I veri artisti consegnano

La strada per l'inferno è lastricata di buone intenzioni, dicono... Per questo mi piace portare a termine i miei progetti. Per un'app significa pubblicarla sull'App Store. Prepararla al vaglio di Apple e farla approvare dai revisori dell'App Store è un traguardo in più. È importante, perché ti fa riflettere sull'onboarding (dei nuovi utenti) e sul modello di guadagno.

Onboarding

Una sfida particolare quando si costruisce un'app è guidare chi non la conosce a usarla. Una buona interfaccia utente può aiutare, ma data la profonda integrazione dell'app con Apple Health, i dati di posizione e i sensori Bluetooth, serve anche chiedere gentilmente i permessi.

Devi progettare il processo in modo che non fallisca quando le persone rifiutano certi permessi. Apple è molto severa su questo: le persone hanno il diritto di rifiutare. Tocca a te far funzionare l'app con permessi parziali o senza. È una sfida in più.

Modello di guadagno per finanziare lo sviluppo

Non posso sopravvalutare l'importanza del software libero, nel senso di libertà, ma non posso nemmeno ignorare che ho una famiglia da mantenere. E soprattutto, trovare persone disposte a pagare per il tuo prodotto può servire da convalida in più della tua idea. Sii aperto e onesto sul tuo modello di guadagno e ti aiuterà a finanziare il tuo progetto; non dipendere da investitori o venture capital, fai da solo il tuo sviluppo!

Non devi pagare per provare l'app. La schermata di pagamento compare solo quando le persone usano davvero l'app (e si può sempre chiudere). Perché non provarla tu stesso? Puoi trovare l'app qui.

Futuro

Usa per primo ciò che costruisci, dicono: continuerò a sviluppare l'app usandola io stesso. Non mi aspetto che questo progetto sia un guadagno (economico) rapido, ma se è utile in pratica a me, è probabile che possa essere utile anche a qualcun altro.

Una cosa che mi piace di questo progetto è che richiede poca fatica per andare avanti, perché mi piace allenarmi. Il debug delle nuove versioni di questa app spesso significa uscire a correre o in bici. Chi l'ha detto che lo sviluppo software è un lavoro sedentario?!

Conclusione

Tante persone hanno "grandi idee", poche si danno da fare per realizzarle. È questo che distingue chi fa dagli altri. Mi piace fare le cose, perché il processo ti obbliga a entrare davvero nella materia. Impari moltissimo e accumuli un'esperienza che gli altri non avranno. Accidenti, costruiscitela da solo, falla tua!