Come monetizzare un'app nel 2026: abbonamenti, acquisti una tantum, pubblicità o download a pagamento

Per monetizzare bene un'app, parti da una domanda: quale valore ottiene una persona, e con quale frequenza? Un servizio cloud, uno strumento offline e un gioco casual hanno costi e modelli d'uso diversi, quindi non hanno bisogno dello stesso paywall. Scegli prima il modello. Poi verifica le regole di pagamento degli store e le commissioni 2026, perché insieme determinano come puoi far pagare e quanto ti resta.

Quale modello di monetizzazione scegliere per la tua app?

Scegli il modello che corrisponde alla frequenza con cui un utente ottiene valore e a quanto ti costa servire ciascun utente. Ogni modello qui sotto si adatta a un tipo di prodotto diverso.

Un modello ibrido può funzionare, ma ogni modello in più è un'altra regola da spiegare e altri stati di acquisto da testare. Parti dal modello più semplice che riesci a spiegare con chiarezza. "Prova gratis, paga una volta per esportare" è più facile da capire di crediti, abbonamenti e pubblicità tutti insieme.

Quando ha senso un abbonamento e cosa richiede Apple?

Un abbonamento ha senso quando l'app continua a offrire valore. La Guideline 3.1.2(a) di Apple afferma che gli abbonamenti con rinnovo automatico "devono offrire un valore continuativo al cliente" e che il periodo "deve durare almeno sette giorni ed essere disponibile su tutti i dispositivi dell'utente".

Mettere la schermata delle impostazioni esistente dietro un prezzo mensile non soddisfa questo requisito. Sono adatti una sincronizzazione affidabile, contenuti sempre nuovi, l'elaborazione cloud o un servizio mantenuto nel tempo. Se trasformi un'app a pagamento esistente in un'app in abbonamento, la stessa linea guida dice che "non dovresti togliere le funzionalità principali che gli utenti esistenti hanno già pagato".

Prima dell'acquisto, la Guideline 3.1.2(c) chiede di "descrivere chiaramente cosa otterrà l'utente per quel prezzo". La pagina sugli abbonamenti di Apple elenca cosa deve contenere la schermata di iscrizione: nome e durata dell'abbonamento, cosa è incluso, il prezzo di rinnovo completo ben visibile, un modo per accedere o ripristinare gli acquisti e i link ai Termini d'uso e all'Informativa sulla privacy. Testa rinnovo, disdetta, scadenza e ripristino. Chi disdice oggi deve mantenere l'accesso fino alla fine del periodo pagato.

Quando conviene un acquisto una tantum o un download a pagamento?

Un acquisto una tantum è adatto a uno strumento autonomo i cui costi non crescono con l'uso, come un editor offline o un'utility che gira sul dispositivo. È poco adatto quando prometti elaborazione AI costosa, spazio di archiviazione o supporto manuale a tempo indeterminato in cambio di un unico pagamento.

Su iOS puoi comunque offrire una prova senza abbonamento. La Guideline 3.1.1 consente un acquisto in-app non consumabile al Price Tier 0 chiamato "XX-day Trial" (prova di XX giorni). Prima che la prova inizi, devi indicare quanto dura, cosa verrà bloccato e quanto costa l'accesso completo. Se vendi servizi a consumo come crediti consumabili accanto a uno sblocco una tantum, ricorda che i crediti acquistati tramite acquisto in-app "non possono scadere". Non pubblicizzare un uso "illimitato" per poi nascondere un limite rigido in una pagina di supporto.

La pubblicità è un buon modo per monetizzare una piccola app?

La pubblicità può finanziare un'app gratuita solo quando l'uso genera abbastanza impression. Con un pubblico piccolo o di nicchia, i ricavi pubblicitari potrebbero non coprire il lavoro sulla privacy e l'avvio più lento che un SDK pubblicitario comporta.

Misura se i posizionamenti pubblicitari danneggiano l'attività principale. In un'utility rapida, un annuncio interstitial mostrato prima del risultato può costare in utenti persi più di quanto fa guadagnare. Un upgrade senza pubblicità è un acquisto digitale: le norme sui pagamenti di Google citano "una versione senza pubblicità di un'app" tra le funzionalità premium che passano dalla fatturazione Play. Gli SDK pubblicitari raccolgono anche dati, quindi aggiorna le tue dichiarazioni. Il nostro audit degli SDK per le etichette sulla privacy spiega come fare questo controllo.

Quanto trattengono Apple e Google sui ricavi delle app nel 2026?

A ottobre 2026, Apple trattiene il 15% ai membri del Small Business Program e sugli abbonamenti dopo un anno di servizio a pagamento. Negli Stati Uniti, nel Regno Unito e nel SEE, Google Play applica una commissione di servizio del 10% più una commissione di fatturazione del 5% sugli abbonamenti pagati tramite la fatturazione Play.

La nuova struttura di Google è partita il 30 giugno 2026 negli Stati Uniti, nel SEE e nel Regno Unito, e il 30 settembre 2026 in Australia e Giappone, secondo la sua pagina sulle commissioni di servizio. In queste regioni, la commissione di fatturazione del 5% si applica solo agli acquisti effettuati tramite la fatturazione Google Play. Gli altri mercati mantengono le tariffe precedenti finché la modifica non li raggiunge.

Lo Small Business Program di Apple copre gli sviluppatori con proventi fino a 1 milione di dollari nell'anno solare precedente, oltre agli sviluppatori nuovi sull'App Store. Le prove gratuite non contano ai fini dell'anno di servizio a pagamento necessario per la tariffa dell'85% sugli abbonamenti Apple. Le commissioni dipendono dal programma e dalla transazione, quindi basa le previsioni sulle condizioni reali del tuo account anziché su un'unica percentuale.

Quando puoi usare un tuo link di pagamento invece dell'acquisto in-app?

Sullo storefront statunitense di Apple, le app ora possono includere pulsanti, link esterni o altri inviti all'azione che portano ad altri metodi di acquisto. Altrove, le funzionalità digitali devono usare l'acquisto in-app, a meno che non si applichi un entitlement specifico per regione o un'eccezione prevista.

• Apple, fuori dagli Stati Uniti: la Guideline 3.1.1(a) richiede lo StoreKit External Purchase Link Entitlement, disponibile solo in storefront specifici e su determinate piattaforme.
• Apple, beni fisici: la Guideline 3.1.3(e) stabilisce che beni fisici o servizi fruiti fuori dall'app devono usare metodi di pagamento diversi dall'acquisto in-app.
• Apple, servizi dal vivo uno a uno: in base alla 3.1.3(d), i servizi in tempo reale da persona a persona, come le lezioni private, possono usare altri metodi di pagamento. I servizi uno a pochi e uno a molti devono usare l'acquisto in-app.
• Google Play: i beni digitali usano la fatturazione Play, a meno che tu non ti iscriva a un programma di fatturazione alternativa o di offerte esterne per un paese idoneo. Beni fisici e servizi fisici non devono usare la fatturazione Play.

Quali errori di monetizzazione hanno fatto rifiutare altre app?

Il rifiuto più comune legato ai pagamenti riguarda lo sblocco di funzionalità a pagamento tramite qualcosa di diverso dal sistema di acquisto dello store. Gli sviluppatori provano spesso con codici o acquisti sul web per aggirare lo store.

In una discussione del 2019 sugli Apple Developer Forums, lo sviluppatore di un escape game all'aperto vendeva codici di gioco sul proprio sito e tramite partner. Gli utenti poi inserivano i codici nell'app. L'aggiornamento è stato rifiutato in base a "Guideline 3.1.1 - Business - Payments - In-App Purchase" perché l'app "consente agli utenti di sbloccare contenuti aggiuntivi acquistando un codice". Lo sviluppatore ha citato la 3.1.3(b). Le risposte hanno fatto notare che l'accesso multipiattaforma richiede comunque che gli stessi articoli siano "disponibili come acquisti in-app all'interno dell'app".

In una discussione di gennaio 2025, uno sviluppatore usava codici promozionali propri dei partner per mostrare il più economico tra due prodotti in-app validi. Apple ha rifiutato l'app perché "l'app usa un codice promozionale per sbloccare o abilitare funzionalità a pagamento". Il ricorso è stato respinto con questa indicazione: "Se vuoi offrire abbonamenti scontati nell'app, usa un offer code supportato da Apple."

Entrambi i casi insegnano la stessa cosa. Ad Apple non importa se il tuo codice sblocca direttamente i contenuti o cambia solo il prezzo. Se qualcosa al di fuori di StoreKit decide chi ottiene le funzionalità a pagamento, aspettati un rifiuto per la 3.1.1.

Come capire se la tua monetizzazione funziona?

Misura un cambiamento alla volta, partendo dall'attivazione e arrivando ai ricavi trattenuti e non rimborsati. Una conversione al primo acquisto più alta non è una vittoria se aumentano i rimborsi o i mancati rinnovi.

Esempio pratico: "Dopo che gli utenti completano la prima esportazione riuscita, mostra l'opzione di esportazione a pagamento con un'unica spiegazione chiara." Definisci la metrica (conversione all'acquisto e rimborsi a 30 giorni) e la finestra temporale prima di cambiare qualsiasi cosa. Un campione minuscolo non giustifica conclusioni sicure sui prezzi. Prima di pubblicare la versione a pagamento, segui questa checklist:

1. Verifica che un nuovo utente arrivi alla parte utile dell'app prima di vedere il paywall.
2. Mostra prezzo, periodo di fatturazione e cosa è incluso con un linguaggio semplice.
3. Testa in una build di release gli acquisti riusciti, in sospeso, non riusciti, rimborsati e ripristinati.
4. Controlla che gli entitlement sopravvivano a una reinstallazione e si estendano a tutti i dispositivi dell'utente.
5. Offri all'App Review un percorso funzionante verso ogni funzionalità a pagamento, con un account demo se è richiesto il login.
6. Per gli abbonamenti, monitora rinnovi e churn per coorte.

Se gli acquisti non funzionano durante la revisione, il piano di test della build di release per la 2.1 spiega come risolvere. La guida all'account demo per la revisione mostra come dare accesso ai revisori, e la checklist per l'invio all'App Store copre il resto del rilascio. Per pianificare il flusso di monetizzazione prima di costruirlo, scopri i nostri servizi.