Apple Foundation Models: o que os programadores indie de Mac podem fazer com IA no dispositivo

Durante cerca de três anos, cada programador indie que queria lançar “funcionalidades de IA” teve de tomar a mesma decisão desconfortável. Ou pagar uma fatura à OpenAI ou Anthropic que escala linearmente com os utilizadores, ou ignorar completamente as funcionalidades de IA. A matemática para uma app de compra única era brutal. Alguns cêntimos por utilizador por mês destroem a margem de uma app de $9.99 vitalícia em meses.

O framework Foundation Models da Apple, anunciado na WWDC 2025 e lançado no macOS 26 (Tahoe), muda a matemática. O framework dá aos programadores acesso programático ao mesmo modelo de linguagem no dispositivo que alimenta as funcionalidades da Apple Intelligence no Mac do utilizador. O modelo corre localmente. A tua app não paga pela inferência. O utilizador não precisa de uma chave de API. O texto nunca sai do dispositivo.

Este artigo é uma visita prática ao que os programadores indie podem realmente fazer com o framework, em que não é bom, e o que a mudança arquitetural significa para uma app Mac focada.

O que obtens

O framework expõe uma LanguageModelSession que podes fazer prompt com texto. O modelo responde com texto, e opcionalmente com um objeto estruturado que especificas com a macro @Generable. O modo de saída estruturada é o mais útil para a maioria das apps porque te permite dizer “devolve-me JSON conforme a este schema” em vez de tentar analisar texto livre.

Um fluxo típico parece assim:

1. Criar uma sessão com instruções de sistema descrevendo a tarefa do modelo.
2. Enviar uma mensagem do utilizador.
3. Ler a resposta estruturada.
4. Usar a resposta para conduzir a tua app.

Tudo corre em milissegundos para prompts curtos e alguns segundos para os longos. Não há chamada de rede. Não há chave de API. Não há limite de taxa além do que o próprio dispositivo pode sustentar.

Em que o modelo é realmente bom

O modelo no dispositivo é pequeno em comparação com um modelo de nuvem de última geração. Não é o GPT-4. Tratá-lo como tal levará à deceção. Onde brilha é numa classe específica de tarefas:

• Classificação. “Esta string é uma frase de data ou não?” “A qual destas cinco categorias pertence esta tarefa?” Estas são tarefas que o modelo no dispositivo trata de forma fiável e rápida.
• Extração estruturada. Extrair campos específicos de uma entrada de texto livre. “A que hora do dia referencia esta frase?” “Qual é o verbo nesta frase?” O modo de saída estruturada do framework foi construído para isto.
• Reescrita de texto curto. Converter uma nota informal num título limpo, resumir um parágrafo numa frase, corrigir a gramática num rascunho. O modelo é bom em pequenas transformações de texto contidas.
• Mudanças de tom. Tornar um rascunho mais caloroso, mais conciso ou mais profissional. Mesma restrição: entradas curtas, saídas contidas.

Isto é a maioria do que uma app de produtividade realmente precisa. Nota o que não está na lista: geração de texto longo, raciocínio complexo, perguntas de conhecimento do mundo, geração de código. O modelo no dispositivo pode fazer essas coisas, mas não tão bem como um modelo na nuvem. Se essas forem o núcleo do teu produto, ainda precisas da nuvem.

Em que o modelo não é bom

Três classes de tarefas onde deves recorrer a outra coisa:

1. Contexto longo. O modelo no dispositivo tem uma janela de contexto menor do que um modelo na nuvem. Alimentá-lo com um documento de 50 páginas e pedir análise não vai correr bem. Alimenta-o com o excerto relevante.
2. Escrita criativa aberta. Consegue fazer escrita criativa curta, mas vais notar a diferença em comparação com um modelo de nuvem de fronteira. Se a tua app é um assistente de escrita para romancistas, provavelmente este não é o teu modelo.
3. Tarefas em que o utilizador espera qualidade de última geração. Se os teus utilizadores vão comparar a tua saída com o ChatGPT e julgar em conformidade, vais perder. O modelo é excelente para utilidade invisível, menos para tarefas em que a IA é o produto visível.

O enquadramento certo é: usa o modelo no dispositivo para tornar a app mais inteligente em segundo plano, não para ser o produto visível.

O que isto significa para os preços indie

A consequência mais interessante do modelo no dispositivo é a implicação nos preços. Durante a maior parte dos últimos três anos, o conselho padrão para programadores indie a lançar funcionalidades de IA era “tens de cobrar uma subscrição, porque os custos de inferência são reais e recorrentes.” Esse conselho estava correto.

Já não está correto para apps onde a inteligência no dispositivo é suficiente. A razão toda pela qual uma app de compra única não podia lançar IA era o custo recorrente. Se o custo recorrente é zero, o modelo muda. Podes lançar funcionalidades de IA numa app de compra única e não ir à falência.

Isto é importante para a pequena vaga de apps Mac indie a tentar reviver o modelo de compra única. Escrevemos sobre a tendência mais ampla mas a parte da IA é uma das razões técnicas reais pelas quais funciona em 2026.

Como começar

O framework faz parte do SDK padrão da Apple no macOS 26. Não há descarregamento separado. Não há chave de API. Não há conta para criar. Adiciona import FoundationModels a um ficheiro Swift, cria uma LanguageModelSession, envia um prompt, lê a resposta.

O modelo está disponível em Macs Apple Silicon que satisfaçam os requisitos do sistema para a Apple Intelligence. Os Macs Intel mais antigos não recebem o framework, por isso a tua app precisa de uma estratégia de fallback se quiseres suportá-los. Para a maioria das apps Mac indie a lançar hoje, uma verificação de disponibilidade e um caminho de degradação elegante são suficientes. O utilizador sem o modelo fica com a versão baseada em expressões regulares da funcionalidade; o utilizador com o modelo fica com a versão mais inteligente.

Como isto parece no TodoBar

O TodoBar usa o framework como fallback para análise de datas em linguagem natural. O caminho rápido são as expressões regulares, que capturam cerca de 90% das frases de data em menos de um milissegundo. Quando o caminho de expressões regulares falha, o modelo no dispositivo tenta, com uma latência típica de cerca de 50 milissegundos, e devolve uma classificação estruturada do que o utilizador quis dizer. Descrevemos o pipeline completo no artigo sobre análise de datas.

O modelo é invisível para o utilizador. Não sabe que está lá. Apenas nota que “daqui a um par de horas” funciona da mesma forma que “daqui a 2 horas.” É assim que parece uma boa IA no dispositivo.

É também por isso que uma app de compra única de $9.99 pode lançar uma funcionalidade que teria exigido uma subscrição há um ano. A matemática finalmente funciona.