La ricetta per una grande app iOS 🍳

Conosci quella sensazione. Apri un’app e funziona — non nel senso che «compila», ma nel senso che «ti capisce». Ogni cosa è al suo posto, niente cigola, e alla fine pensi: «È stato piacevole». E conosci anche il contrario: un pulsante che risponde a fatica, uno scroll a scatti, un popup di autorizzazione che ti salta addosso prima ancora che tu abbia capito a cosa serve l’app. Tra queste due esperienze c’è un mondo. E quasi mai a separarle è una funzionalità magica. È una ricetta.

Pubblico app dai primissimi giorni dell’App Store, dal 2008. Una quarantina di app, centinaia di milioni di download complessivi e una quindicina di WWDC alle spalle. E la domanda che mi fanno più spesso non è cambiata di una virgola: che cosa rende un’app fantastica, e non semplicemente funzionale? Scrivo queste righe a caldo, ancora un po’ frastornato, dopo la WWDC26 ad Apple Park. Al mio ritorno ho tenuto un talk a due voci con Claire. Si intitolava The Recipe to Build a Great iOS App. Ecco la versione lunga, la ricetta completa che non si riesce mai a raccontare tutta sul palco.

Perché una ricetta?

Due persone con le stesse uova non preparano lo stesso piatto. È davvero così semplice. Nello sviluppo iOS, tutti hanno le stesse uova: Swift, SwiftUI e Xcode, gratuiti; centinaia di sessioni WWDC disponibili liberamente; tutorial passo passo; e le Human Interface Guidelines, la bibbia del design Apple, a un clic di distanza. Nessuno ha un ingrediente segreto nascosto in frigorifero. Ciò che distingue una grande app è il modo in cui si assembla tutto questo. E la buona notizia è che si può imparare.

Apple lo dimostra ogni anno. Nel 2026, su oltre due milioni di app, solo 12 hanno ottenuto un Apple Design Award, selezionate fra 36 finaliste in sei categorie. L’asticella è alta. Ma guarda chi la supera: uno studio di due persone nei Paesi Bassi accanto a un team che itera da dieci anni, uno sviluppatore indipendente in India accanto a CD Projekt Red. Il messaggio di Apple è limpido: il design non dipende dal budget, dalla dimensione del team o dal pubblico. Dipende dalla cura.

E la cosa più buffa è che queste app le usi già. Solo che ancora non sai perché funzionano. Ne incontreremo alcune durante la ricetta, non per fare name-dropping, ma perché ognuna illustra un principio meglio di un lungo discorso.

Progettare con intenzione — l’obiettivo prima del codice

Alla WWDC26, Apple ha pubblicato una nuova sessione fondamentale, Principles of great design (sessione 250, diciassette minuti: guardala due volte). Presenta otto principi: Purpose, Agency, Responsibility, Familiarity, Flexibility, Simplicity, Craft, Delight. E Apple insiste su una cosa che i junior non amano sentirsi dire: non esiste una formula. «Sta a te usare le tue conoscenze e il tuo intuito.» Spingere un principio può comprometterne un altro. Saper trovare il giusto equilibrio: ecco il mestiere. Questi otto principi non sono una ricetta da seguire alla lettera: sono gli ingredienti. La cucina la fai tu.

Sul palco Claire ne ha presentati quattro e io gli altri quattro. Qui te li racconto tutti, nell’ordine della ricetta anziché in quello delle slide. Si comincia dalla parte più ingrata, quella che saltiamo sempre: Purpose. La preparazione. In cucina significa predisporre tutto prima di accendere il fuoco. Nel design significa porti l’unica domanda che conta prima di scrivere una riga di codice: quello che sto facendo ha uno scopo vero? Se non è chiaro, non è pronto.

Il primo esempio è grug, Apple Design Award 2026 nella categoria Delight & Fun, creato dallo studio olandese Ocho, due persone: Jip van der Velde e Michel Elings, che lavorano insieme dal 2012. grug è una sola idea: un’affermazione al giorno, in grugniti neolitici. «only walking grug find breakthrough… sitting grug find nothing.» Niente login, niente cloud, niente social. Il suo punto di forza non è ciò che i due hanno avuto il talento di aggiungere: è tutto ciò che hanno avuto il coraggio di non aggiungere. (Hanno persino creato un motore per un font disegnato a mano e una status bar personalizzata: vale la pena leggere il loro Q&A sul sito Apple.) Omettere conta quanto aggiungere. Scegliere cosa creare significa decidere cosa lasciare fuori.

In pratica, come trovi questo scopo? Scrivilo in una frase: [cosa fa] per [chi], in [quale momento della sua vita]. Se nella frase serve una «e», forse stai descrivendo due app, non una. Poi fai la lista di tutto ciò che potresti costruire e taglia tutto quello che non serve a quella frase. Ogni funzionalità rimasta deve «pagarsi l’affitto»: vale il tempo, l’attenzione e la fiducia che richiede? Perché il costo reale di una funzionalità è questo: non le ore di sviluppo, ma tre risorse rare che sottrai all’utente. La trappola da junior è aggiungere una cosa perché la si può fare («vabbè, ci metto due ore»). Ogni aggiunta diluisce lo scopo. Difendere lo scopo significa dire di no, spesso. Prova finale: mostra la frase a tre persone. Se non indovinano cosa fa l’app, lo scopo non è abbastanza incisivo. «Un’agenda visiva per menti neurodivergenti.» «Saggezza quotidiana in grugniti preistorici, senza account.» Se non riesci a formularla, torna in cucina.

Al comando — e con la possibilità di rimediare

Il secondo principio, Agency, significa lasciare che le persone agiscano a modo loro. Un’interfaccia non deve mai ostacolare ciò che qualcuno sta cercando di fare. Lascia che esplori, al proprio ritmo; che salti l’onboarding se vuole; che organizzi l’interfaccia come preferisce. Accompagna, ma non mettere gli utenti sui binari. Più controllo, più coinvolgimento: non è uno slogan, è un meccanismo.

L’esempio è Tiimo, eletta iPhone App of the Year agli App Store Awards 2025 (e già finalista di un Apple Design Award nel 2024). È un planner visivo che restituisce il controllo del tempo alle persone neurodivergenti. Il team è a Copenaghen, l’app è usata da oltre un milione di persone e — dettaglio tutt’altro che secondario — è 100% senza pubblicità, per sempre. Tiimo è stata progettata con le persone interessate, non soltanto per loro. Questo è dare agency: non decidere al posto delle persone.

Il corollario dell’Agency è il perdono. Le persone inviano, modificano e cancellano cose per sbaglio in continuazione. Il tuo compito è rendere reversibili queste azioni. Apple propone una gerarchia chiara per gestire le azioni rischiose, dalla migliore alla peggiore. Prima Undo, come impostazione predefinita: tutto è annullabile, l’utente può provare e poi cambiare idea. Poi Confirm, solo quando annullare è impossibile (una cancellazione definitiva, un invio irreversibile). Interrupt è l’ultima risorsa, per evitare una vera catastrofe. L’errore classico dei principianti è chiedere conferma per tutto: dopo troppi «Sei sicuro?», l’utente preme «Sì» senza leggere, e l’avviso non protegge più nulla. Nel codice si traduce in tre strumenti da conoscere a memoria: un UndoManager, un confirmationDialog e il ruolo .destructive sui pulsanti sensibili. Questa rete di sicurezza non rallenta l’utente: gli dà la fiducia per esplorare l’app e adottarla.

Nell’interesse delle persone — e un’IA responsabile

Il terzo principio, Responsibility, comincia dalla privacy. Apple usa una metafora che adoro: immagina che uno sconosciuto ti fermi per strada e ti dica «Dammi il tuo numero», senza spiegare perché. Non ti fideresti per un secondo. Eppure migliaia di app fanno proprio questo: ti buttano addosso la richiesta di autorizzazione appena le apri, prima che tu abbia capito a cosa serve. Un’interfaccia responsabile aspetta il momento giusto, chiede solo lo stretto necessario e spiega a cosa serve.

L’esempio perfetto è Be My Eyes, premiata agli App Store Awards 2025 nella categoria Cultural Impact. L’app, lanciata nel 2015 da Hans Jørgen Wiberg — che ha cominciato a perdere la vista a 25 anni — mette in contatto persone cieche o ipovedenti con volontari vedenti e, più di recente, con un’IA chiamata Be My AI. Ecco il dettaglio che cambia tutto: l’accesso alla fotocamera viene richiesto solo quando l’utente chiede aiuto visivo, mai all’apertura. Be My AI è stata sviluppata insieme a migliaia di tester ciechi e ipovedenti. L’IA affianca la persona, non la sostituisce. Questo è il modello.

E bisogna parlare di IA, perché nel 2026 è dappertutto. iOS 27 — annunciato a questa WWDC, l’ultimo keynote di Tim Cook come CEO — porta Siri, Apple Intelligence e i Foundation Models on-device in ogni angolo del sistema. Questi modelli girano sul dispositivo, gratuitamente, senza inviare altrove i tuoi dati. È un’opportunità enorme per noi sviluppatori. Ma più aggiungi intelligenza, più aumenta la responsabilità. L’esempio di Apple è volutamente banale, ed è per questo che colpisce: un’app di ricette. L’utente ha dichiarato un’allergia. Il modello, lasciato a sé stesso, gli suggerisce un piatto che contiene proprio l’allergene. Non è un bug estetico: è un pericolo reale. La lezione è che un modello può generare qualcosa di inatteso, falso o pericoloso. Prevedi il peggio e aggiungi protezioni (anteprime, conferme, avvertenze), oppure elimina del tutto la funzionalità se il rischio supera il valore. Le protezioni si progettano fin dall’inizio, non si aggiungono con una patch dopo il rifiuto.

Parlare la lingua della piattaforma — familiarità e flessibilità

Il quarto principio è Familiarity. Il tuo pubblico porta con sé una vita intera di esperienza: il mondo reale e le convenzioni delle altre app che usa. Fai leva su quella familiarità. Il cestino significa eliminare (e recuperare): usarlo per un’altra cosa distrugge immediatamente il riconoscimento. Elementi simili devono comportarsi allo stesso modo. Su Mac si chiude una finestra in alto a sinistra: l’utente non deve pensarci. Per le azioni comuni, non reinventare la ruota: prima i componenti di sistema. La familiarità nel 2026 è Liquid Glass, il materiale presentato alla WWDC25 e ormai presente ovunque in iOS 26. Nel codice si traduce in .glassEffect(), GlassEffectContainer e .buttonStyle(.glass). C’è una trappola che può farti perdere una serata: un antenato con .clipped() o .mask() rompe l’effetto senza alcun warning. Preferisci i componenti di sistema prima di spargere ovunque glass personalizzato. (Le vetrine ufficiali di Apple quest’anno sono Moonlitt e Tide Guide, se vuoi vedere il lavoro fatto bene.)

Poi c’è Flexibility: le persone usano il tuo design in modi unici quanto loro. Apple fa l’esempio della musica: a casa sugli altoparlanti, mentre corri con AirPods e Watch, in macchina a mani libere. Stessa app, tre esperienze. Il modo più concreto di realizzare la flessibilità nel 2026 è uscire dal tuo schermo. Esponi le azioni della tua app al sistema tramite gli App Intents, e all’improvviso l’app vive in Siri, Spotlight, Comandi Rapidi, widget, Centro di Controllo e Apple Intelligence, senza che nessuno la apra. È scoperta e fidelizzazione allo stesso tempo. Per una nuova app, scegli una o due azioni fondamentali («aggiungere un’attività», «avviare un timer»), assegna loro un App Intent e collegale ad Apple Intelligence tramite gli Assistant Schemas. John Geleynse, un veterano, chiamava già questa idea «Connected» ai tempi di iOS 5: l’app deve andare oltre la propria finestra. Nel 2026 questa idea si chiama App Intents.

Gli strumenti giusti — Swift, SwiftUI, Xcode

Abbiamo l’intenzione, l’obiettivo e i principi. Ora servono gli utensili. E qui ti tranquillizzo: per cominciare ne bastano tre, tutti gratuiti. Niente React Native, niente Flutter, niente backend il primo giorno. Prima Swift: un linguaggio sicuro (gli optional e il sistema di tipi rigoroso eliminano intere classi di bug prima ancora che l’app si avvii), accessibile e veloce. Non devi padroneggiare tutto subito; generics, actors e concurrency arriveranno più avanti. Basta saperne quanto serve per iniziare.

Poi SwiftUI: un framework dichiarativo in cui descrivi cosa deve fare l’interfaccia, non come disegnarla. Meno codice e la stessa base per iPhone, iPad, Mac, Watch e Vision Pro. La dimostrazione è Moonlitt, Apple Design Award 2026 per Interaction, realizzata interamente in SwiftUI dallo studio italiano Flipping Hues (tre sviluppatori conosciutisi all’Apple Developer Academy di Napoli). Fasi lunari, pianificazione delle foto, onboarding in pochi tocchi e un’integrazione Liquid Glass che la giuria ha definito «best-in-class». Dettaglio magico del 2025-26: ricompilando con l’SDK di iOS 26, un’app adotta automaticamente Liquid Glass. Non serve riscrivere tutto, ma fai comunque un controllo visivo: «automatico» non significa «perfetto».

Il terzo strumento è Xcode, il laboratorio completo: editor, simulatore, debugger, test e distribuzione. La combinazione di SwiftUI e Previews cambia tutto quando inizi: vedi subito l’effetto di ogni riga, senza ricompilare l’intero progetto. Aggiungi un #Preview a ogni view non banale: diventerà un’abitudine. E soprattutto, non si impara a cucinare leggendo ricette. Apple offre tutorial guidati gratuiti: completa Scrumdinger, l’app d’esempio che copre liste, navigazione, persistenza e accessibilità. Imparerai di più con un’app finita che guardando cento video accelerati.

Le fondamenta — architettura e dati

Un piatto senza struttura crolla. Prima di pensare al craft, prepara basi solide. Un’app è composta da tre cose che dialogano: le view, i dati (la verità) e la navigazione. Organizzarle bene fin dall’inizio ti evita di riscrivere tutto fra tre mesi. La trappola per principianti sono dati che si contraddicono da uno schermo all’altro. La regola SwiftUI: una sola fonte di verità (@State, @Observable, @Bindable) e binding che sincronizzano tutto il resto. Per salvare i dati tra un avvio e l’altro, SwiftData è più che sufficiente per una v1: segue la stessa filosofia di SwiftUI, con più potenza e meno codice di Core Data.

E poi c’è la malattia che vedo ovunque: leggi dieci acronimi di architettura (MVVM, TCA, VIPER… ~~e altri scongiuri ansiogeni~~) e ti paralizzi prima ancora di aver scritto una view. Basta. Mantieni le cose semplici, segui le convenzioni della piattaforma e fai refactoring solo quando il problema si presenta. Ricorda: grug è fatto da due persone senza un blog sull’architettura. Tiimo ha iterato per dieci anni prima di vincere App of the Year. Un’app imperfetta che esiste sarà sempre meglio di un’architettura perfetta mai completata.

Il condimento — ciò che separa il buono dal fantastico

Il piatto è pronto. Ora vengono i dettagli: invisibili uno per uno, ma si sentono tutti insieme. È il principio Craft: «l’attenzione al dettaglio che dice alle persone che tieni davvero alla loro esperienza». Un prodotto fatto di fretta si percepisce come una porta traballante o una camicia che si scuce. Un pulsante lento, uno scroll a scatti, icone disallineate, un layout che si rompe ruotando il dispositivo: tutto sembra fragile e finisci per dubitare della qualità di ogni altra cosa. Il craft, al contrario, ispira fiducia. I suoi «materiali» sono una tipografia nitida su tutti gli schermi, colori che funzionano in modalità chiara e scura, animazioni reattive al tocco e SDK affidabili. Il mio esempio è (Not Boring) Camera, finalista ADA 2026 (Visuals & Graphics): la firma dello studio è l’ossessione per i materiali — interfaccia 3D, luce dinamica, feedback aptico e suono così realistici che ti sembra di avere in mano una macchina fotografica analogica.

Cugina del craft è Simplicity — attenzione a non fraintenderla: semplice non vuol dire minimalista. Nascondere tutto in un unico posto è minimal, non semplice. Semplice significa intuitivo, senza attriti: trovi quello che cerchi senza sforzo. Ci si arriva con la concisione (linguaggio chiaro, meno passaggi) e la chiarezza (una gerarchia forte fatta di ordine, spaziatura e contrasto, così che l’elemento più importante sia il più evidente). A volte semplificare significa persino aggiungere contesto al posto giusto, per esempio il tempo rimanente su un pulsante play/pausa. L’esempio perfetto è Tide Guide, Apple Design Award 2026 (Visuals & Graphics) dello studio statunitense Condor Digital. L’argomento è banalissimo — le maree — ma l’esecuzione è eccezionale: dati orari complessi ridotti a un grafico leggibile a colpo d’occhio, con una palette che segue il colore del cielo durante la giornata. Tema quotidiano, cura maniacale. È tutto qui.

Il condimento include anche l’accessibilità. E qui sarò diretto: non è un lusso, significa raggiungere più utenti e migliorare l’app per tutti. VoiceOver, Dynamic Type, contrasto sufficiente e target touch di almeno 44×44 punti. Be My Eyes e Tiimo ne hanno fatto un pilastro fin dalla progettazione; in ambito televisivo, HBO Max ha persino vinto il titolo App of the Year 2025 su Apple TV dopo aver aggiunto la lingua dei segni americana. Da iOS 26, nella scheda dell’App Store ci sono anche le Accessibility Nutrition Labels: nove funzionalità dichiarabili (VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color, Sufficient Contrast, Reduced Motion, Captions, Audio Descriptions). Oggi sono facoltative, ma diventeranno obbligatorie: portati avanti. Una sola regola d’oro: fai un audit onesto. Tutte le attività comuni dell’app devono poter essere completate con ogni funzione che dichiari. Altrimenti, non dichiararla. La sessione WWDC25 «Evaluate your app for Accessibility Nutrition Labels» spiega il metodo.

E già che parliamo di craft, parliamo di performance, perché a giugno 2026 il messaggio di Apple non lascia dubbi. La stampa ha subito soprannominato iOS 27 una release «Snow Leopard», richiamando il famoso Zero New Features del 2009. Niente fuochi d’artificio, ma Apple ha pubblicato un elenco di oltre quaranta ottimizzazioni concrete: avvio delle app fino al 30% più rapido, foto visibili 70% prima dopo lo scatto, AirDrop 80% più veloce e uno scheduler CPU riscritto, utile a tutti i dispositivi fino a iPhone 11. Per te la traduzione è brutale: un’app che sembra lenta risulterà ancora più penalizzata per contrasto. Animazioni fluide, avvio rapido, niente blocchi durante lo scroll — e prova su dispositivi veri, idealmente un iPhone 11 o 12, non solo sul simulatore dell’ultimo modello. Il craft è anche durata: quando arrivano nuove funzionalità o nuovi dispositivi, evolviti con loro, così le persone si sentono seguite. «Design is never really finished» non è una citazione ~~Pinterest~~, è la realtà di ogni App of the Year.

Impiattare e servire — test e pubblicazione

Non si serve un grande piatto su un piatto sporco. Prima dell’App Store c’è TestFlight: fino a 100 tester interni (membri del team App Store Connect) e 10.000 tester esterni tramite link pubblico o email. La prima build esterna passa una Beta App Review, una coda separata da quella dell’App Store: spesso bastano poche ore, a volte serve più tempo. Feedback, screenshot e crash arrivano direttamente in App Store Connect. E lo ripeto perché quasi nessuno lo fa: prova l’app su dispositivi veri. Il simulatore non riproduce prestazioni, batteria o autorizzazioni reali.

Il secondo aspetto che si sottovaluta: la scheda App Store fa parte dell’app. Icona, screenshot, descrizione, Privacy Nutrition Label e Accessibility Nutrition Label devono rappresentare onestamente ciò che fa l’app. Apple è esplicita: metadati fuorvianti significano rifiuto (Guideline 2.3). Gli screenshot devono mostrare l’app reale, non un’interfaccia finta né un «coming soon». Leggi le App Review Guidelines per tempo, non come ostacolo finale: sono cinque sezioni (Safety, Performance, Business, Design, Legal). Se un giorno aggiungi acquisti in-app, leggi la sezione Business prima di scrivere codice, non dopo. Nel 2026 Apple dice che circa il 90% delle submission viene esaminato entro 24 ore, ma questo vale soprattutto per gli aggiornamenti di app consolidate. Una prima submission spesso richiede da due a cinque giorni (di più a settembre e dicembre, e nelle categorie regolamentate come salute, finanza e bambini). Considera ogni rifiuto un requisito tecnico preciso, mai un giudizio: copia il testo del rifiuto nelle note e correggi punto per punto.

Per fare sul serio serve l’Apple Developer Program, 99 dollari l’anno: TestFlight, App Store Connect, certificati, notifiche push e Sign in with Apple sono inclusi. (Per programmare sul tuo iPhone non devi pagare: basta l’account sviluppatore gratuito, con un certificato di sette giorni rinnovabile. Il programma a pagamento serve solo per il TestFlight esterno e la pubblicazione.) In Xcode archivi la build, la carichi e la invii tramite App Store Connect. Puoi persino attivare un rilascio graduale su sette giorni. E all’improvviso il tuo piatto arriva in 175 storefront nel mondo. Pensa alla localizzazione per tempo: almeno descrizione e screenshot per i mercati a cui punti.

Far arrivare i clienti — e mantenere vivo il piatto

Abbiamo servito un gran piatto. Ma un ristorante che nessuno trova non è un gran ristorante. Ogni settimana centinaia di milioni di persone visitano l’App Store: la visibilità va conquistata. La scoperta combina ASO e marketing, e ogni elemento della scheda influenza i download. Per la ricerca vengono indicizzati 30 caratteri del titolo, 30 del sottotitolo e 100 nel campo parole chiave: 160 caratteri di superficie SEO da scegliere con precisione. Nome e icona fanno la prima impressione; la prima riga della descrizione è la più letta, ma non viene indicizzata: a esserlo è il campo dedicato alle parole chiave. Scegli bene la categoria e non stipare il titolo di keyword, altrimenti rischi il rifiuto (sempre Guideline 2.3).

Tre strumenti che molti ignorano. Le Custom Product Pages: fino a 70 varianti della scheda, ciascuna con screenshot, testo promozionale e URL univoca (?ppid=…) da usare nelle campagne — una pagina per genitori, una per professionisti, una stagionale. Ognuna si misura separatamente e, da iOS 18, può aprirsi direttamente nella schermata giusta. La Product Page Optimization: un test A/B nativo in App Store Connect che mostra a un campione casuale varianti di icona, screenshot o anteprima dell’app, e individua una vincitrice con il 90% di confidenza (misura per almeno due settimane). E la triade campaign links (per attribuire i canali in App Analytics), Apple Ads (posizionamento Today e risultati di ricerca: basta un budget modesto per testare le parole chiave) e Featuring Nominations (un modulo in App Store Connect per proporre l’app alla redazione Apple: racconta la storia umana; Be My Eyes e Tiimo sono ottimi modelli). Inizia con una o due Custom Product Pages legate ai tuoi canali principali: il limite di 70 non è un obiettivo.

Una volta online, comincia il lavoro vero. Un’app non è mai «finita». Ascolta i feedback (TestFlight, recensioni dell’App Store, email al supporto), controlla i crash in Xcode Organizer e pubblica aggiornamenti regolari. Con App Analytics misuri tutto: conversione da scheda a download, retention al giorno 1/7/30, sessioni e rendimento di ogni Custom Product Page. Rispondi alle recensioni, soprattutto alle negative e alle prime: chi ha scritto la recensione riceve una notifica e può aggiornarla. Tiimo ha impiegato dieci anni prima del suo titolo. Be My Eyes itera dal 2015. grug è portata avanti da due persone che iterano dal 2012. Nessuna di queste app è uscita perfetta. Hanno iterato.

L’ingrediente segreto

Aspettavi un ingrediente segreto? C’è sempre. E non è un framework, un’API o una sessione WWDC. È la cura. Care. L’intenzione in ogni fase, dal primo schermo fino al momento in cui trovi il coraggio di chiedere un pagamento. In fondo è Craft e Delight insieme. Delight, l’ottavo principio, è difficile da definire ma lo riconosci subito; non è coriandoli incollati alla fine. È la somma dell’attenzione dedicata al prodotto, il risultato naturale di aver applicato bene gli altri principi. Individua l’emozione che vuoi far provare (rilassatezza, fiducia, entusiasmo), poi rafforzala ovunque. È così che «funziona» diventa «lo adoro».

I miei quattro esempi — grug, Be My Eyes, Tiimo e Moonlitt — non hanno una singola funzione in comune: un aforisma preistorico, un aiuto visivo, un planner e un’app sulle fasi lunari. Ma dietro ognuna ci sono persone a cui è importato davvero. Alla fine conta soltanto quanto la tua app risponde alle esigenze degli esseri umani per cui la stai costruendo. Il resto è tecnica. E la tecnica si impara.

Il miglior consiglio che posso darti sta in due parole: vieni a cucinare. Apri Xcode oggi, scegli un tutorial Apple e crea una piccola app, anche semplice, anche brutta. Un’app descritta in una frase, una beta TestFlight inviata a tre amici, una scheda App Store onesta. Completa tutto il ciclo una volta; punta a questo, non alla perfezione. È ciò che ci ripetiamo a ogni meetup della community ⌘+F e ciò che distingue chi «prima o poi comincerà» da chi pubblica davvero.

E se hai un progetto eccezionale, contattami. Innovare è ciò che mi fa battere il cuore.

Per approfondire

Per il design, tieni a portata di mano le Human Interface Guidelines (gratuite, aggiornate e arricchite alla WWDC26 da una nuova pagina sui Design principles) e la sessione Principles of great design. Per il codice: Swift, SwiftUI, App Intents e i tutorial Apple. Per la distribuzione: TestFlight, le App Review Guidelines e le Custom Product Pages. Per trovare ispirazione, niente batte le pagine degli Apple Design Awards e degli App Store Awards 2025, insieme alle schede delle app citate: è lì che i junior possono osservare il lavoro da vicino. Grazie a Claire per metà di questa ricetta. Ora tocca a te cucinare. 🍳