Da un’idea in SwiftUI all’App Store in poche settimane

C’è un ritardo tipico dei progetti iOS: una funzionalità che doveva essere pubblicata «in poche settimane» è ancora in sviluppo tre mesi dopo, perché il perimetro continuava ad ampliarsi e il processo di invio si è rivelato più articolato del previsto. In realtà, pubblicare rapidamente un’app SwiftUI non dipende dalla velocità di sviluppo: occorre decidere presto cosa l’app non farà e restare fedeli alla decisione quando arriva la tentazione di aggiungere un’altra funzionalità.

Abbiamo pubblicato diverse app SwiftUI in tempi brevi. Il processo è ripetibile, ma richiede disciplina sul perimetro, una conoscenza chiara del processo di invio di Apple e la disponibilità a pubblicare qualcosa di valido anche se non ancora completo. Ecco come funziona nella pratica.

Il perimetro si decide prima del primo commit

Il lavoro più importante in un ciclo rapido di rilascio iOS avviene prima di scrivere codice. La domanda non è «cosa deve fare questa app», ma «qual è l’unico problema che la prima versione risolve per l’utente». Ogni funzionalità non direttamente collegata a quel problema va nella seconda versione.

È più difficile di quanto sembri, perché quando si progetta da zero quasi tutto sembra rilevante. Le notifiche sembrano importanti. Le funzionalità social sembrano importanti. Le dashboard dettagliate per l’analisi dei dati sembrano importanti. In realtà, però, gli utenti non possono valutare queste funzionalità prima di aver usato quella principale e averne riconosciuto il valore. Un’app che fa bene una cosa e viene pubblicata in quattro settimane produce riscontri più utili di un’app che fa sei cose discretamente e viene pubblicata in quattro mesi.

Lo strumento pratico è un elenco a due colonne, scritto prima di iniziare lo sviluppo: cosa rientra nell’MVP e cosa viene esplicitamente rimandato. L’elenco delle funzionalità rimandate non è un backlog: serve a imporre una scelta. Ogni funzionalità aggiunta a un progetto in corso va valutata per capire se debba finire in quell’elenco anziché nello sprint attuale. Per la maggior parte, la risposta è sì.

Le prime due settimane: solo le schermate essenziali

Un’app SwiftUI con uno scopo unico e chiaro richiede in genere da tre a cinque schermate: un percorso introduttivo, una o due schermate per le interazioni principali e una schermata delle impostazioni o dell’account. Nelle prime due settimane queste schermate devono essere complete sul piano funzionale: svolgere il proprio compito, con dati reali e nell’ordine corretto. Non devono ancora essere rifinite. Le animazioni possono essere quelle predefinite di sistema, così come la tipografia. Per gli errori bastano semplici avvisi testuali.

Le decisioni architetturali che contano in questa fase sono quelle difficili da cambiare in seguito: il modello di navigazione (NavigationStack, TabView o un coordinatore personalizzato), l’approccio alla gestione dello stato (usare @Observable del framework Observation oppure mantenere ObservableObject) e la strategia di persistenza dei dati (SwiftData, Core Data, UserDefaults per uno stato semplice). Prendere queste decisioni in modo esplicito e tempestivo, anziché lasciare che si accumulino spontaneamente, evita di ritrovarsi alla terza settimana con metà app che usa un modello di navigazione e metà che ne usa un altro.

Per le app che integrano un backend Supabase, il flusso di autenticazione merita particolare attenzione in questa fase. Le linee guida di App Review di Apple distinguono due requisiti: le app che consentono di creare account devono permettere agli utenti di eliminarli dall’interno dell’app (linea guida 5.1.1(v)), mentre le app che usano un accesso di terze parti o social, come Google Sign-In, per l’account principale devono offrire anche un’opzione di accesso equivalente incentrata sulla privacy, che nella pratica è solitamente Accedi con Apple (linea guida 4.8). Se l’app usa soltanto un proprio sistema di autenticazione con email e password tramite Supabase, Accedi con Apple non è obbligatorio, ma il flusso di eliminazione dell’account deve rientrare nell’MVP: non perché gli utenti lo useranno il primo giorno, ma perché App Review rifiuterà l’app in sua assenza. Se aggiungi un accesso social, pianifica contemporaneamente l’opzione di accesso equivalente.

Terza e quarta settimana: rifinitura e TestFlight

Nella terza settimana l’app comincia ad assomigliare a un prodotto vero. È il momento di gestire gli stati di caricamento (non solo «mostrare un indicatore», ma «mostrare un indicatore che renda comprensibile l’attesa»), gli stati senza dati (cosa mostra l’app quando non ci sono ancora dati) e gli stati di errore (cosa succede quando una chiamata di rete fallisce). Non sono semplici rifiniture: costituiscono l’esperienza dei nuovi utenti, che iniziano senza dati e occasionalmente hanno problemi di rete.

La distribuzione tramite TestFlight dovrebbe iniziare nella terza settimana, non nella quarta. La prima build caricata presenterà infatti problemi imprevisti. App Store Connect convalida il binario prima di renderlo disponibile per i test e rileva problemi che la compilazione locale di Xcode non evidenzia: autorizzazioni mancanti, combinazioni errate dei profili di provisioning, chiavi Info.plist obbligatorie ma assenti. Scoprirli nella terza settimana lascia il tempo di correggerli prima dell’invio definitivo. Scoprirli la sera prima del lancio, no.

In questa fase, i riscontri di TestFlight sono più utili per individuare percorsi di navigazione poco chiari e comandi difficili da riconoscere che per raccogliere richieste di funzionalità. Chiedi ai tester: «Hai provato a fare qualcosa senza riuscire a capire come?» anziché «Quali funzionalità vorresti?». La seconda domanda produrrà un elenco che allungherebbe i tempi di mesi.

Il processo di invio all’App Store

Il processo di invio all’App Store prevede più passaggi di quanto si aspettino gli sviluppatori alla prima pubblicazione, e ognuno può bloccare il rilascio. Affrontarli in anticipo, anziché iniziare solo quando il codice è completo, evita che l’ultima settimana diventi una corsa contro il tempo.

Le schermate sono obbligatorie prima dell’invio e devono rispettare una delle dimensioni in pixel accettate per ciascuna dimensione del display. A ottobre 2026, App Store Connect richiede schermate iPhone per la categoria di display da 6,9 pollici (per esempio, iPhone 16 Pro Max), oppure per quella da 6,5 pollici (per esempio, iPhone 14 Plus) se non fornisci quelle da 6,9 pollici, oltre a schermate iPad da 13 pollici (per esempio, iPad Pro (M4) o iPad Pro da 12,9 pollici (6ª generazione)) se l’app funziona su iPad. Generarle nel Simulatore è semplice, ma richiede tempo se lo lasci all’ultimo giorno. Una semplice configurazione di Fastlane snapshot può automatizzare il processo.

La sezione relativa alla privacy dell’app in App Store Connect richiede di dichiarare ogni tipo di dato raccolto dall’app, il suo utilizzo e se sia collegato all’identità dell’utente. Non sono metadati facoltativi: l’invio non riesce se la sezione è incompleta. Se l’app usa Supabase con autenticazione, raccoglie almeno indirizzi email e identificativi degli utenti, entrambi da dichiarare. SDK di terze parti e strumenti di analisi ampliano l’elenco. Mappare accuratamente la raccolta dei dati prima dell’invio evita di dover aggiornare queste informazioni dopo il lancio.

Apple dichiara di esaminare in genere il 50% degli invii in meno di 24 ore e il 90% in meno di 48 ore; è possibile richiedere una revisione accelerata in circostanze eccezionali, come la correzione di un bug critico o un lancio legato a un evento. La verifica viene svolta da una persona che confronta l’app con le linee guida di Apple. Le cause più comuni di rifiuto al primo invio sono funzionalità dell’account mancanti (eliminazione dell’account dall’interno dell’app oppure un’opzione di accesso equivalente accanto all’accesso social), credenziali di un account dimostrativo non fornite per le app con accesso e arresti anomali in casi limite incontrati dai revisori ma non dai tester.

Cosa eliminare e come farlo

La parte più difficile di un ciclo di rilascio rapido è far percepire le rinunce come scelte intenzionali, non come il risultato della fretta. Gli utenti distinguono un’app volutamente semplice da un’app incompiuta. La differenza sta soprattutto nella completezza di ciò che c’è — ogni schermata presente deve essere completa — più che nel numero di schermate.

Rinunce pratiche che raramente penalizzano una prima versione: notifiche push (complesse da configurare correttamente, e gli utenti devono fidarsi dell’app prima di apprezzarle), funzionalità social (seguire altri utenti, condividere, classifiche: utili su larga scala, fonte di distrazione al lancio), impostazioni avanzate di personalizzazione (la maggior parte degli utenti non cambia mai quelle predefinite) e qualsiasi funzionalità che richieda un’infrastruttura backend significativa di cui l’MVP non ha già bisogno.

Rinunce pratiche che invece penalizzano la prima versione: gestione degli errori (un’app che si arresta per un timeout di rete compromette duraturamente l’esperienza degli utenti), stati di caricamento (un’app che si blocca senza riscontri visivi sembra guasta) e funzioni essenziali di gestione dell’account (gli utenti devono poter reimpostare la password ed eliminare il proprio account anche nell’MVP).

Dopo il lancio: le prime due settimane contano di più

Le prime due settimane dopo il lancio sono il periodo in cui le valutazioni sull’App Store sono più vulnerabili. Una serie iniziale di recensioni a una stella, causata da un arresto anomalo non emerso nei test, danneggia in misura sproporzionata la valutazione dell’app nel lungo periodo. Nella prima settimana occorre controllare ogni giorno Instruments e l’organizzatore degli arresti anomali di Xcode. Una versione correttiva per gli arresti critici dovrebbe essere inviata entro 24 ore dalla loro individuazione: App Review offre un percorso accelerato per queste correzioni.

Conviene resistere per almeno due settimane alla tentazione di pubblicare subito dopo il lancio le funzionalità rimandate. Capire come gli utenti interagiscono davvero con l’esperienza principale, prima di aggiungere complessità, vale più che dimostrare di procedere rapidamente. Le funzionalità della seconda versione saranno progettate meglio dopo due settimane di osservazione dell’uso reale che se fossero state sviluppate in parallelo al lancio.

Approfondimenti correlati

• Risolvere i rifiuti delle icone sull’App Store — I requisiti sRGB, canale alfa e TrueColor che bloccano l’invio nell’ultimo passaggio.
• Creare un’app di preparazione agli esami con migliaia di domande — L’architettura necessaria quando l’MVP deve evolvere in un prodotto completo.
• Concorrenza in Swift 6: guida pratica alla migrazione — Quando affrontare gli avvisi di concorrenza di Swift 6 durante un ciclo rapido di rilascio e quando rimandarli.