Vai al contenuto

Apple Foundation Models: cosa possono fare gli sviluppatori Mac indie con l'AI on-device

Un breve tour del framework, in cosa è bravo, in cosa non lo è, e le conseguenze per le piccole app che vogliono funzionalità AI senza un conto cloud.

9 min di lettura

Per circa tre anni, ogni sviluppatore indie che voleva rilasciare “funzionalità AI” doveva prendere la stessa scomoda decisione. O pagare un conto OpenAI o Anthropic che scala linearmente con gli utenti, o saltare del tutto le funzionalità AI. La matematica per un’app a pagamento una tantum era brutale. Qualche centesimo per utente al mese distrugge il margine su un’app a $9.99 per tutta la vita nel giro di mesi.

Il framework Foundation Models di Apple, annunciato al WWDC 2025 e distribuito in macOS 26 (Tahoe), cambia la matematica. Il framework dà agli sviluppatori accesso programmatico allo stesso modello linguistico on-device che alimenta le funzionalità di Apple Intelligence sul Mac dell’utente. Il modello gira localmente. La tua app non paga per l’inferenza. L’utente non ha bisogno di una chiave API. Il testo non lascia mai il dispositivo.

Questo post è un tour pratico di ciò che gli sviluppatori indie possono fare davvero con il framework, in cosa non è bravo e cosa significa il cambiamento architetturale per un’app Mac focalizzata.

Cosa ottieni

Il framework espone una LanguageModelSession che puoi interrogare con del testo. Il modello risponde con testo, e opzionalmente con un oggetto strutturato che specifichi con il macro @Generable. La modalità di output strutturato è quella più utile per la maggior parte delle app perché ti permette di dire “restituiscimi JSON conforme a questo schema” invece di cercare di analizzare testo in formato libero.

Un flusso tipico è così:

  1. Crea una sessione con istruzioni di sistema che descrivono il compito del modello.
  2. Invia un messaggio utente.
  3. Leggi la risposta strutturata.
  4. Usa la risposta per guidare la tua app.

Il tutto gira in millisecondi per prompt brevi e qualche secondo per quelli lunghi. Non c’è una chiamata di rete. Non c’è una chiave API. Non c’è un rate limit al di là di quello che il dispositivo stesso può sostenere.

Cloud LLM call versus on-device model call Diagram comparing two architectures. The top row shows a user prompt going from a Mac, over the public internet, to a cloud LLM provider, then back. The bottom row shows the same prompt staying entirely on the Mac, processed by Apple's Foundation Models framework. The on-device path has no network arrow and no provider box. CLOUD LLM Your Mac user prompt Public internet latency, $$, privacy risk Cloud LLM provider per-token billing ON-DEVICE (FOUNDATION MODELS) Your Mac user prompt Foundation Models local, free, private
Lo stesso prompt elaborato da un cloud LLM (in alto) o dal framework Foundation Models on-device di Apple (in basso). Il percorso on-device non ha salti di rete né fatturazione per chiamata.

In cosa il modello è davvero bravo

Il modello on-device è piccolo rispetto a un modello cloud all’avanguardia. Non è GPT-4. Trattarlo come tale porterà a delusioni. Dove brilla è una classe specifica di compiti:

  • Classificazione. “Questa stringa è una frase con data o no?” “A quale di queste cinque categorie appartiene questa attività?” Questi sono compiti che il modello on-device gestisce in modo affidabile e veloce.
  • Estrazione strutturata. Estrarre campi specifici da un input in testo libero. “A che ora del giorno fa riferimento questa frase?” “Qual è il verbo in questa frase?” La modalità di output strutturato del framework è costruita per questo.
  • Riscrittura di testo breve. Convertire una nota informale in un titolo pulito, riassumere un paragrafo in una frase, correggere la grammatica in una bozza. Il modello è bravo nelle trasformazioni di testo piccole e contenute.
  • Cambi di tono. Rendere una bozza più calda, più concisa o più professionale. Stessa limitazione: input brevi, output contenuti.

Questo è la maggior parte di ciò di cui un’app di produttività ha davvero bisogno. Nota cosa non è nella lista: generazione di testo lungo, ragionamento complesso, domande di conoscenza del mondo, generazione di codice. Il modello on-device può farlo, ma non bene quanto un modello cloud. Se questi sono fondamentali per il tuo prodotto, hai ancora bisogno del cloud.

In cosa il modello non è bravo

Tre classi di compiti in cui dovresti usare qualcos’altro:

  1. Contesto lungo. Il modello on-device ha una finestra di contesto più piccola di un modello cloud. Dargli un documento di 50 pagine e chiedere un’analisi non andrà bene. Dagli invece l’estratto rilevante.
  2. Scrittura creativa aperta. Può fare breve scrittura creativa, ma noterai la differenza rispetto a un modello cloud all’avanguardia. Se la tua app è un assistente di scrittura per romanzieri, probabilmente questo non è il tuo modello.
  3. Compiti in cui l’utente si aspetta qualità all’avanguardia. Se i tuoi utenti confronteranno il tuo output con ChatGPT e giudicheranno di conseguenza, perderai. Il modello è eccellente per utility invisibile, meno per compiti in cui l’AI è il prodotto visibile.

Il giusto inquadramento è: usa il modello on-device per rendere l’app più intelligente in background, non per essere il prodotto visibile.

Cosa significa per il pricing indie

La conseguenza più interessante del modello on-device è l’implicazione sul pricing. Per la maggior parte degli ultimi tre anni, il consiglio standard per gli sviluppatori indie che rilasciano funzionalità AI era “devi addebitare un abbonamento, perché i costi di inferenza sono reali e ricorrenti”. Quel consiglio era corretto.

Non è più corretto per le app in cui l’intelligenza on-device è sufficiente. L’intera ragione per cui un’app a pagamento una tantum non poteva rilasciare AI era il costo ricorrente. Se il costo ricorrente è zero, il modello si rompe. Puoi rilasciare funzionalità AI in un’app a pagamento una tantum e non andare in bancarotta.

Questo è importante per la piccola ondata di app Mac indie che cercano di far rivivere il modello di pagamento una tantum. Abbiamo scritto sulla tendenza più ampia ma il pezzo AI è uno dei motivi tecnici reali per cui funziona nel 2026.

Come iniziare

Il framework fa parte dell’SDK standard di Apple su macOS 26. Non c’è un download separato. Non c’è una chiave API. Non c’è un account da creare. Aggiungi import FoundationModels a un file Swift, crea una LanguageModelSession, invia un prompt, leggi la risposta.

Il modello è disponibile sui Mac Apple Silicon che soddisfano i requisiti di sistema per Apple Intelligence. I Mac Intel più vecchi non ricevono il framework, quindi la tua app ha bisogno di una strategia di fallback se vuoi supportarli. Per la maggior parte delle app Mac indie rilasciate oggi, un controllo della disponibilità e un percorso di degradazione elegante è sufficiente. L’utente senza il modello ottiene la versione basata su regex della funzionalità; l’utente con il modello ottiene la versione più intelligente.

Come appare in TodoBar

TodoBar usa il framework come fallback per il riconoscimento delle date in linguaggio naturale. Il percorso veloce sono le espressioni regolari, che catturano circa il 90% delle frasi con date in meno di un millisecondo. Quando il percorso regex fallisce, il modello on-device ci prova, con una latenza tipica di circa 50 millisecondi, e restituisce una classificazione strutturata di cosa intendeva l’utente. Abbiamo descritto il pipeline completo nel post sul riconoscimento delle date.

Il modello è invisibile all’utente. Non sa che è lì. Nota solo che “tra un paio di ore” funziona allo stesso modo di “tra 2 ore”. È così che si sente un buon AI on-device.

È anche il motivo per cui un’app a pagamento una tantum a $9.99 può rilasciare una funzionalità che avrebbe richiesto un abbonamento un anno fa. Finalmente i conti tornano.

TodoBar è una simpatica lista di cose da fare nella barra dei menu di macOS. Scadenze in italiano naturale, tasto rapido globale, sincronizzazione iCloud. Paghi una volta, è tuo per sempre.

Ottieni TodoBar sull'App Store