Il percorso
In cinque capitoli: idea, design, sviluppo, pubblicazione sugli store e aggiornamenti. L'ultimo non finisce mai, ed è giusto così.
Prima dello schermo c'è la domanda: chi apre l'app, quante volte, per fare cosa. Fissiamo il flusso principale e cosa resta fuori dalla prima versione, perché un'app con tutto dentro non esce mai. Se l'idea va ancora provata, partiamo dalla validazione.
Wireframe, poi un prototipo cliccabile da provare su un telefono vero, poi l'interfaccia definitiva con il suo design system. Rispettiamo le convenzioni di iOS e Android dove l'utente se le aspetta: navigazione, gesti, richieste di permesso. È il lavoro di product design e UX.
Scegliamo la tecnologia in base al prodotto (la tabella più sotto spiega come). Costruiamo app e backend insieme: login, dati, notifiche, acquisti in-app, analytics. Ogni versione passa da test automatici e da una build di prova installata sui telefoni del team.
Account sviluppatore, schede dello store, screenshot, informazioni sulla privacy, build firmate, revisione. Apple e Google controllano l'app prima di pubblicarla: prepararsi alle loro regole fa risparmiare giri di revisione.
Dopo il lancio arrivano i dati veri: crash, recensioni, funzioni che nessuno usa. Rilasciamo aggiornamenti regolari, seguiamo le nuove versioni di iOS e Android e teniamo allineate app e web, che con Capacitor condividono la stessa base.
Tecnologie
Dipende da cosa esiste già e da cosa deve fare l'app. Se hai già una web app o un SaaS, Capacitor è spesso la strada più corta; se l'app vive di hardware e grafica, il nativo.
| Approccio | Come funziona | Quando sceglierlo | Attenzione a |
|---|---|---|---|
| Nativo | Due app separate, in Swift per iOS e in Kotlin per Android, con gli strumenti di Apple e Google | Funzioni di sistema profonde, grafica e prestazioni al limite, realtà aumentata | Due basi di codice da costruire e mantenere |
| React Native | JavaScript o TypeScript, con componenti dell'interfaccia nativi | App con interfaccia nativa e un team che conosce già React | Moduli nativi da scrivere per le funzioni meno comuni |
| Flutter | Linguaggio Dart e un motore grafico proprio, identico su ogni sistema | Interfacce molto personalizzate che devono apparire uguali ovunque | Si condivide poco codice con un sito o una web app esistente |
| Capacitor | La web app gira dentro un guscio nativo, con plugin per notifiche, acquisti e fotocamera | Prodotti che esistono già sul web, come un SaaS: una sola base per web, iOS e Android | Animazioni e gesti complessi vanno curati; alcune funzioni richiedono plugin |
Athleex usa Capacitor: la piattaforma web e le app iOS e Android condividono la stessa base. Lo raccontiamo nel caso studio Athleex.
Store
Con un account sviluppatore per ogni store, una scheda completa e una build firmata che supera la revisione. Il percorso è lo stesso per ogni app; cambiano i dettagli che la fanno respingere.
Apple Developer Program e Google Play Console, intestati alla tua azienda: l'app e le sue recensioni restano tue.
Nome, descrizione, screenshot, categoria, età consigliata e le informazioni su quali dati raccoglie l'app.
Build firmate e test con tester veri: TestFlight su iOS, test interni e chiusi su Google Play, che per alcuni account li richiede prima della pubblicazione.
Apple e Google verificano contenuti, pagamenti, privacy e stabilità. Se respingono, indicano la regola: si corregge e si ripresenta.
Pubblicazione manuale o graduale, poi monitoraggio di crash e recensioni nei primi giorni.
Esperienza diretta
Tre lezioni dall'app iOS di Athleex, tutte arrivate da problemi veri.
Il problema
Apple ha respinto una versione per le regole sugli acquisti in-app (linea guida 3.1.1).
Cosa abbiamo fatto
Abbiamo integrato gli acquisti in-app con StoreKit 2 e la versione è passata. Come si paga dentro l'app va deciso prima della prima revisione.
Il problema
Le notifiche push su iOS non arrivavano, per tre cause indipendenti tra loro: configurazione, permessi, consegna.
Cosa abbiamo fatto
Le abbiamo verificate una per una: sistemarne una non sistema le altre. Ora le push si provano causa per causa.
Il problema
Con iCloud Private Relay il paese dell'utente può risultare diverso da quello reale.
Cosa abbiamo fatto
La valuta mostrata si decide con criterio, non solo dall'indirizzo IP: i prezzi sono una scelta di prodotto, non un dettaglio tecnico.
Dipende soprattutto da quante piattaforme servono, da quante funzioni del telefono (notifiche, pagamenti, fotocamera) e dal backend che c'è dietro. Non pubblichiamo listini: dopo il primo incontro ti diamo una stima su un perimetro scritto. I fattori che pesano sono spiegati in prezzi e tempi.
Se gli utenti ti cercano negli store o servono funzioni profonde del telefono, un'app. Se il prodotto si usa soprattutto al lavoro o al computer, una web app o una PWA costa meno e si aggiorna subito.
Entrambi producono app iOS e Android da una sola base di codice. React Native conviene se il team conosce React o c'è già un prodotto web in React; Flutter se serve un'interfaccia molto personalizzata e identica ovunque. Se il prodotto è già una web app, valutiamo prima Capacitor.
La pubblichiamo noi, sugli account sviluppatore della tua azienda: app, schede e recensioni restano tue. Prepariamo scheda, screenshot e informazioni sulla privacy e seguiamo la revisione fino all'approvazione.
Sì, con gli acquisti in-app di Apple e Google. Su iOS, per sbloccare funzioni o contenuti digitali dentro l'app, Apple li chiede in genere: su Athleex li abbiamo integrati con StoreKit 2 dopo una revisione respinta. È una scelta da fare prima di inviare l'app.
App mobileCome creare un'app: la guida per founder, dall'idea agli storeLeggi 
App mobileQuanto costa creare un'app: cosa fa il prezzo e cosa paghi dopo il lancioLeggi 
App mobileReact Native o Flutter (o Capacitor)? Come scegliere il framework della tua appLeggi 
App mobilePubblicare un'app su App Store e Play Store: passaggi, revisione e cosa abbiamo imparatoLeggi Rispondiamo entro un giorno lavorativo.
Parliamone