Sviluppo App Mobile Android e iOS

Quando un'app mobile risolve davvero un problema (e quando non serve)

Sviluppare un'app mobile non è una decisione tecnologica: è una decisione di business. Prima di chiedersi "quanto costa" o "quale tecnologia usare", la domanda giusta è se questa app risolve davvero un problema operativo concreto, che oggi sta facendo perdere all'azienda tempo, clienti o margine. Lavoriamo con PMI in tutta Italia da quando il mobile è diventato indispensabile per i servizi, e raccontiamo onestamente — senza vendere a tutti i costi — quando un'app fa la differenza e quando la risposta migliore è "non serve".

Un'app mobile ha senso quando l'azienda ha un'esigenza operativa specifica che si risolve meglio fuori dal browser. Scenari tipici dove l'investimento si ripaga: operatività sul campo, con tecnici, agenti, ispettori che devono compilare report, scansionare codici, geolocalizzare interventi e sincronizzarsi offline — è ciò che fa la nostra app ParkCheck per gli operatori comunali nei parchi gioco, anche senza connessione di rete; servizi consumer ricorrenti, dove l'utente accede più volte al giorno e l'app riduce il friction rispetto a "apri browser, cerca sito, fai login"; funzionalità native come notifiche push, geolocalizzazione continua, fotocamera, biometria, integrazione con calendario o contatti del telefono.

Ci sono però casi dove un'app è la risposta sbagliata, e una web app responsive o una PWA (Progressive Web App) fa lo stesso lavoro con costi e attriti minori: quando il servizio viene usato 1-2 volte all'anno, quando il pubblico è B2B che lavora prevalentemente da desktop, quando il valore è informativo e statico, quando il budget è limitato e una soluzione alternativa coprirebbe il 90% dei casi reali. La nostra regola è semplice: se valutiamo il progetto e l'app non è la soluzione migliore, lo diciamo prima di firmare. Vendere un'app a chi non ne ha bisogno crea un cliente insoddisfatto, che è il peggior risultato possibile per tutti.

Le tre strade tecnologiche: native, cross-platform o PWA

Lo sviluppo di un'app oggi passa da tre approcci principali. Non esiste un vincitore assoluto: c'è la scelta giusta per ogni progetto, ed è il primo lavoro di un'agenzia seria saperla guidare con onestà.

Sviluppo nativo (Swift per iOS, Kotlin per Android): il codice viene scritto separatamente per ogni piattaforma usando i linguaggi ufficiali. Garantisce performance massima, accesso a qualsiasi funzionalità del dispositivo, look-and-feel perfettamente conforme alle linee guida di Apple e Google. Lo svantaggio è strutturale: due codebase significano due sviluppi, con costi quasi doppi sia in fase iniziale sia in manutenzione, e ogni modifica va fatta due volte. Ha senso quando l'app usa intensivamente realtà aumentata, machine learning on-device, grafica 3D, oppure quando una sola delle due piattaforme è davvero importante per il pubblico target.

Cross-platform (React Native, Flutter): un'unica codebase produce app native per entrambe le piattaforme. I componenti sono reali, non simulazioni web, le animazioni girano a 60fps, le performance per il 95% delle applicazioni business sono indistinguibili dal nativo. Il vantaggio è un risparmio del 30-40% sullo sviluppo iniziale e circa il 50% sulla manutenzione, perché ogni correzione o nuova funzionalità si implementa una volta sola. Per la maggior parte dei progetti PMI utilizziamo React Native, il framework di Meta. Le app Aida VoIP e ParkCheck che gestiamo internamente come prodotti SaaS proprietari sono entrambe React Native: significa che ne conosciamo limiti, pattern di ottimizzazione e workaround dalla nostra esperienza diretta quotidiana, non solo dai manuali.

Progressive Web App (PWA): tecnicamente non è un'app ma un sito web ottimizzato che il browser può "installare" sulla home screen come un'icona. Costo molto inferiore, niente review degli store, distribuzione istantanea via URL, aggiornamenti immediati per tutti gli utenti. Lo svantaggio è la copertura funzionale limitata: niente presenza su App Store e Play Store con il discovery e la fiducia che comportano, e su iOS restano limiti rilevanti su notifiche push e storage locale. Ha senso quando il budget è contenuto, il pubblico cerca il servizio via motore di ricerca e non in store, le funzionalità non sono native, oppure in fase di validazione pre-app.

Per un nuovo progetto, React Native è il nostro default. Deviamo verso il nativo solo quando il requisito è specifico, ad esempio integrazione profonda con ARKit. Suggeriamo PWA quando il budget e l'esigenza si prestano. Questa trasparenza decisionale è ciò che garantisce un investimento ottimizzato: niente sovra-ingegnerizzazione, niente compromessi qualitativi solo per vendere di più.

Quanto costa sviluppare un'app: i fattori che fanno variare il preventivo

Non pubblichiamo un listino fisso, perché ogni progetto è diverso e dare un range generico sarebbe disonesto. Quello che possiamo dire è cosa fa variare concretamente il preventivo finale, in modo che ciascuno possa orientarsi prima ancora del contatto diretto.

Il primo fattore è numero e complessità delle schermate: cinque schermate informative costano una frazione di trenta schermate con logica interconnessa. Il secondo è dato dalle funzionalità native richieste: notifiche push, geolocalizzazione real-time, biometria, pagamenti in-app, accesso fotocamera — ognuna porta lavoro di implementazione e test specifico. Il terzo riguarda le integrazioni con sistemi esistenti: se il gestionale del cliente espone già un'API REST, ci si collega direttamente; se non ce l'ha, bisogna svilupparla, ed è di fatto un progetto a parte.

Il design UI/UX incide più di quanto si pensi: un prototipo Figma custom contro un template adattato è la differenza tra un'app usata e una disinstallata in tre giorni, che è il dato medio di settore per le app con UX scadente. Il backend e l'infrastruttura rappresentano spesso il 40-60% del lavoro totale: l'app è il client, ma serve un server che gestisce dati, autenticazione e business logic. Il numero di piattaforme (Android e iOS contemporaneamente, default con React Native, oppure una sola) e il supporto post-lancio scelto (da basic con monitoraggio e bug critici, a evolutivo con nuove feature continue) chiudono il quadro dei fattori principali.

Come si arriva al preventivo concreto: una call di discovery di 30 minuti per ascoltare il problema, capire contesto e priorità. Se serve approfondire si fanno una o due sessioni più tecniche, e si chiude con un preventivo dettagliato in 24-48 ore che spacchetta cosa fa cosa nel totale. Niente cifra unica buttata lì, niente sorprese in corso d'opera. Per un'analisi più ampia sui range di mercato 2026 abbiamo scritto un articolo dedicato: Quanto costa sviluppare un'app mobile nel 2026, con confronti native vs cross-platform e i 5 fattori che fanno saltare il budget.

Il nostro processo in 6 fasi: dalla validazione al rilascio sugli store

Ogni progetto segue queste fasi, con timing variabili in base alla complessità. Il principio fondamentale è semplice: mai un colpo di scena. Il cliente sa sempre dove siamo, cosa abbiamo fatto e cosa stiamo facendo nelle prossime due settimane.

1. Discovery (una settimana). Call iniziale per capire problema operativo, pubblico target, vincoli tecnici, ambizioni di crescita. Da qui esce un documento di scope condiviso. Se il progetto è grande, in questa fase definiamo insieme un MVP: la versione minima che dimostra valore senza rischiare l'intero budget.

2. Prototipo Figma (1-2 settimane). Disegniamo tutte le schermate principali in Figma con flussi cliccabili. Il prototipo si testa direttamente sullo smartphone del cliente via Figma Mirror, prima che venga scritta una sola riga di codice. Modifiche, ripensamenti, cose che "su carta sembravano una cosa e sullo schermo sono un'altra" si gestiscono qui a costo zero, non in fase di sviluppo dove costerebbero dieci volte di più.

3. Sprint di sviluppo bisettimanali (8-16 settimane tipiche). Ogni due settimane consegniamo una versione testabile sul dispositivo del cliente, via TestFlight per iOS e link APK o Play Store internal per Android. Il team cliente usa l'app, segnala cosa va e cosa no, e nello sprint successivo correggiamo e costruiamo il prossimo pezzo. Questo elimina l'effetto "consegna alla fine e speriamo bene".

4. QA su matrice di dispositivi reali (1-2 settimane). Testiamo l'app su dispositivi fisici, non solo su emulatori. La matrice tipica include iPhone vecchio, medio e nuovo modello più iPad, e quattro Android tra Samsung medio-gamma, Pixel attuale, Xiaomi e un Android "anziano" su versione 11-12 ancora molto diffusa in Italia. Verificare il comportamento reale (consumo batteria, performance, comportamento offline) è quello che separa un'app che viene usata da una che viene disinstallata.

5. Pubblicazione su App Store e Google Play (1-2 settimane). Ci occupiamo dell'intero rilascio: preparazione degli asset grafici, compilazione delle schede store, dichiarazione privacy, gestione della review di Apple (che può richiedere 1-3 iterazioni — abbiamo esperienza consolidata con le App Store Review Guidelines), configurazione di TestFlight per la distribuzione beta e di Google Play Console. Il cliente non deve imparare niente del processo, gestiamo noi.

6. Post-lancio: monitoraggio e evoluzione continua. Un'app pubblicata non è un progetto concluso. Monitoriamo crash con strumenti dedicati (Firebase Crashlytics, Sentry), seguiamo l'andamento delle recensioni, gestiamo gli aggiornamenti annuali di iOS e Android che richiedono adeguamenti di compatibilità. Con React Native possiamo distribuire aggiornamenti over-the-air (OTA) per correzioni rapide bypassando la review degli store.

Case study: Aida VoIP e ParkCheck, due app che gestiamo come SaaS proprietari

Questo è il differenziale più importante che possiamo offrire: non sviluppiamo solo app per clienti, abbiamo due SaaS nostri con app mobile in produzione attiva. Quando il cliente deve prendere una decisione tecnica, parla con qualcuno che l'ha già presa per i propri prodotti.

Aida VoIP è il nostro centralino cloud che integra agente vocale AI, gestione chiamate e CRM. L'app mobile (Android e iOS, React Native) permette agli utenti di gestire l'intero centralino dallo smartphone: effettuare e ricevere chiamate VoIP con qualità nativa, consultare il registro chiamate, gestire la rubrica condivisa, configurare regole di inoltro. La sfida tecnica principale è stata mantenere la qualità audio identica al desktop su connessioni cellulari instabili, risolta con WebRTC ottimizzato e gestione automatica del codec in base alla banda disponibile.

ParkCheck è la piattaforma SaaS che usano i comuni italiani per gestire censimento, ispezioni e manutenzione dei parchi gioco pubblici. L'app mobile permette agli operatori sul campo di compilare report di ispezione strutturati e conformi alla norma EN 1176, allegare foto delle attrezzature, geolocalizzare gli interventi e sincronizzare i dati anche dopo essere stati offline in zone senza copertura di rete. Il backend gestisce un sistema di AI Vision per riconoscere automaticamente difetti tipici delle attrezzature dalle foto caricate.

Cosa significa in pratica: scegliere noi non vuol dire affidarsi a un fornitore che "fa app", ma a un team che ogni giorno vive in prima persona il ciclo completo — pubblicazione, monitoraggio crash post-lancio, lettura recensioni, aggiornamenti per nuove versioni di iOS, ottimizzazioni di performance, gestione del backend in produzione, fatture da Apple e Google. Esperienza diretta, non manualistica.

Operiamo da Jesi (Ancona) e serviamo clienti in tutta Italia

La nostra sede operativa è a Jesi (Ancona), ma i nostri clienti sono distribuiti su tutto il territorio italiano, dal Piemonte alla Sicilia. Per progetti di sviluppo software il modello remoto con on-site selettivo è oggi lo standard più efficiente, e funziona bene quando è strutturato con cura.

Per progetti medio-grandi (sopra le 12 settimane) preferiamo una mezza giornata di kick-off in presenza presso la sede del cliente, per allineare team, raccogliere il contesto operativo direttamente sul campo, e costruire il rapporto umano che rende fluida tutta la collaborazione successiva. Lo sviluppo e i check-in poi sono al 100% remoti, con strumenti consolidati: prototipi su Figma cliccabili dal team cliente, demo sprint via Google Meet o Microsoft Teams, condivisione progressi via Linear o Notion, comunicazione daily via Slack o canale dedicato. Stesso fuso orario, stessa lingua, stesse festività, fatturazione italiana semplice, conformità GDPR garantita per progettazione.

Torniamo on-site quando ha senso operativamente: presentazioni intermedie a board, sessioni di formazione del team cliente sull'app, kick-off di fasi successive (ad esempio una nuova major release dopo un anno di produzione). La distanza geografica non è mai stata un problema operativo nei nostri progetti.

Pubblicazione su App Store e Google Play: gestiamo tutto noi

Pubblicare un'app non è solo "premere submit". Ci sono passaggi tecnici, legali e di policy che fanno la differenza tra un rilascio fluido e settimane di rincorse alle richieste degli store.

Lato Apple Developer aiutiamo a creare l'account a nome del cliente (99 dollari l'anno) per garantire la proprietà completa dell'app. Gestiamo poi tutta la configurazione di certificati, profili di provisioning, App Store Connect e TestFlight. Lato Google Play Console stessa logica con l'account a nome del cliente (25 dollari una tantum, valido a vita): configuriamo signing key, processo di internal/closed/open testing, e store listing ottimizzato per la scoperta organica nella ricerca interna Play Store.

Su asset e scheda store progettiamo screenshot, icone, video preview, descrizione localizzata in italiano (e in inglese se serve), keyword per ASO (App Store Optimization). Sono lavori di "marketing del prodotto" che fanno la differenza tra un'app trovata e una invisibile. La review di Apple è la parte più imprevedibile: ha policy stringenti che applica in modo non sempre lineare. Progettiamo le app conformi fin dall'inizio e quando arrivano richieste di modifica le gestiamo nella stessa giornata. Tipicamente serve 1-3 iterazioni per il primo rilascio, poi i successivi sono lineari.

Supporto post-lancio e manutenzione evolutiva

Un'app è viva. Le versioni di Android e iOS si aggiornano ogni anno, e ogni nuova versione major può rompere comportamenti che funzionavano. Le policy degli store cambiano: Apple negli ultimi anni ha stretto su privacy, Google ha aumentato i requisiti API target ogni 12 mesi. Gli utenti si abituano e chiedono nuove funzionalità.

I nostri piani di manutenzione sono modulari e si scelgono in base all'esigenza reale. Il piano base Monitoring & Critical Fixes include tracking crash continuo (Firebase Crashlytics o Sentry), risposta a bug critici entro SLA definito e aggiornamenti di compatibilità per nuove versioni Android e iOS. Il piano Maintenance Evolutiva aggiunge sviluppo di piccole feature incrementali mensili o trimestrali su roadmap concordata, ottimizzazioni performance e aggiornamenti delle dipendenze. Per relazioni di lungo termine offriamo Partnership di Prodotto, dove il nostro team diventa di fatto il team di prodotto del cliente, con roadmap condivisa e sprint dedicati.

Un esempio concreto dal nostro vissuto: per ParkCheck il monitoraggio post-lancio ha rivelato che gli operatori usavano in modo intensivo la funzione di ispezione rapida, ma quasi nessuno apriva la sezione "report annuali". Le release successive hanno concentrato lo sviluppo sulla parte intensamente usata, eliminando feature non viste e dedicando tempo a velocità ed esperienza dove serviva davvero. Questo tipo di iterazione data-driven funziona solo con dati reali in produzione, non con assunzioni.