O que aconteceria se o seu iPhone pudesse conversar com seus próprios servidores MCP em qualquer lugar? Foi exatamente isso que eu construí com o app iOS do MCP MCP Connect, um cliente móvel nativo para o Model Context Protocol. Neste artigo, eu explico como o desenhei, enviei e implantei, e por que essa abordagem importa se você quer ferramentas reais de IA no celular.
O que é o MCP Connect?
O MCP Connect é meu app iOS do MCP para conectar a servidores MCP via HTTP, navegar por ferramentas e conversar com IA em movimento. Eu o construí em Swift e SwiftUI para que ele pareça nativo, seja rápido e estável no iPhone.
O app permite que você:
Eu queria que o app tivesse uma sensação premium, não como um simples wrapper. Então eu o desenhei com um estilo de cinema escuro, glassmorphism, animações de mola e feedback tátil. Essa escolha de design importa porque ferramentas de IA no celular precisam parecer rápidas e claras, especialmente quando os usuários alternam entre conversas e servidores.
Por que eu construí um app iOS do MCP
Eu construí este app iOS do MCP porque queria acesso direto às minhas próprias ferramentas pelo meu telefone. Fluxos de trabalho apenas no desktop te desaceleram quando você está longe da sua mesa. No iPhone, eu queria o mesmo controle que eu já tinha no navegador e no meu Mac.
Na minha experiência construindo produtos em Gotemburgo, os melhores apps móveis resolvem bem um problema doloroso e bem específico. O MCP Connect faz isso por mim. Ele me dá acesso seguro aos meus servidores MCP, e faz isso sem adicionar mais uma camada complicada.
Isso também se encaixa na direção do próprio Model Context Protocol. A especificação de MCP da Anthropic é construída em torno de um modelo cliente-servidor limpo, o que a torna uma ótima combinação para apps móveis que precisam de acesso estruturado a ferramentas. Eu mantive a implementação alinhada com essa ideia para que o app continue fácil de manter à medida que o protocolo evolui.
O problema do usuário que eu resolvi
A maioria das ferramentas de IA ainda assume que você está sentado em um desktop. Isso quebra quando você precisa verificar um servidor, disparar uma ferramenta ou inspecionar um resultado enquanto viaja. Com o MCP Connect, eu reduzi essa fricção.
O resultado é simples: eu consigo abrir o app, selecionar um servidor e interagir com minhas ferramentas em segundos. Essa velocidade é o objetivo inteiro do app iOS do MCP.
A stack de tecnologia por trás do app iOS do MCP
Eu mantive a stack focada e moderna. Eu não queria uma arquitetura inchada nem dependências desnecessárias.
| Camada | Tecnologia |
|---|---|
| --- | --- |
| Plataforma | iOS 17+, Swift 6, SwiftUI |
| Arquitetura | MVVM + Coordinators |
| Backend | Supabase (Auth, PostgreSQL, Realtime) |
| Transporte MCP | JSON-RPC sobre HTTP |
| Persistência | SwiftData |
| IAP | StoreKit 2 |
| i18n | String Catalogs (EN + SV) |
| Deploy | Xcode + XcodeGen |
Essa stack me deu uma base forte para o app iOS do MCP. O SwiftUI cuidou bem da interface, o SwiftData suportou armazenamento offline-first, e o Supabase forneceu autenticação e sincronização sem sobrecarga extra de backend.
Eu também usei ferramentas de produção familiares, como Keychain para segredos e StoreKit 2 para assinaturas. Isso manteve o app focado na qualidade do produto, em vez de ruído de infraestrutura.
Passo 1: eu desenhei o sistema primeiro
Eu sempre começo pelo sistema de design, porque isso economiza tempo depois. Neste projeto, eu construí os tokens e os componentes compartilhados antes de escrever o código das funcionalidades.
A paleta Dark Cinema usa pretos profundos, superfícies discretamente elevadas e um acento índigo. Cada superfície usa um tratamento de glassmorphism com `.ultraThinMaterial` e uma borda fina, para que a UI pareça em camadas, mas sem ficar pesada.
O sistema inclui:
Eu construí componentes reutilizáveis como `GlassCard`, `AccentButton`, `StatusBadge`, `ShimmerLoader` e `GlassTextField`. Isso tornou o app iOS do MCP mais fácil de escalar, porque novas telas herdaram a mesma linguagem visual.
Passo 2: eu separei modelos de persistência
Eu separei modelos de domínio de modelos de persistência do SwiftData. Isso manteve a lógica de negócio limpa e testável.
Os principais modelos são:
Essa separação importou mais do que parece. Ela me deu espaço para mudar detalhes de armazenamento sem reescrever a lógica do app. Para um app iOS do MCP, esse tipo de fronteira torna recursos futuros mais fáceis de entregar.
Decisão de segurança: Keychain apenas para chaves de API
Eu criei uma regra que eu não quebraria: chaves de API nunca tocam o Supabase. Eu armazeno apenas um `apiKeyRef` no banco de dados, enquanto a chave real fica no iOS Keychain.
Isso significa que uma violação do banco de dados não expõe credenciais. A troca é que as chaves não sincronizam automaticamente entre dispositivos. Os usuários precisam inseri-las novamente em um novo telefone, mas isso leva segundos e elimina um risco sério de segurança.
Passo 3: eu construí o cliente MCP
O cliente usa JSON-RPC sobre HTTP, que combina com o transporte HTTP Streamable na especificação do MCP. Cada requisição sai como um HTTP POST padrão com um corpo JSON-RPC.
O app suporta quatro operações principais:
Eu carrego tokens de autorização do Keychain no momento da requisição. Isso mantém o app iOS do MCP seguro e evita armazenar segredos na memória por mais tempo do que o necessário.
Eu testei isso com meus próprios servidores até o fluxo de requisições parecer estável em uso real. O resultado foi uma latência previsível e uma experiência móvel muito melhor do que eu esperava no começo.
Passo 4: eu conectei o Supabase
Eu usei o Supabase para autenticação e sincronização porque ele me dá um caminho rápido para produção. O backend tem quatro tabelas:
Cada tabela tem Row Level Security. Isso significa que os usuários só podem acessar seus próprios registros. Eu também adicionei um trigger no banco de dados que cria um perfil automaticamente após o signup.
A autenticação suporta Sign in with Apple e email/senha. Isso me deu um fluxo de cadastro limpo, sem forçar os usuários a escolher um único método de login. Para um app iOS do MCP, essa flexibilidade ajuda na adoção.
Passo 5: eu construí as principais funcionalidades
O app tem três áreas principais: chat, gerenciamento de servidores e configurações. Eu mantive cada uma focada para que a experiência continue rápida em um telefone.
Interface do chat
O chat usa uma máquina de estados: `idle` → `sending` → `streaming` → `toolCalling` → `idle`. As chamadas de ferramentas aparecem inline como cards expansíveis com o nome da ferramenta, argumentos, resultado e tempo de execução.
Essa UI importa porque ajuda os usuários a confiarem no que a IA está fazendo. Eles conseguem ver cada etapa em vez de ficar adivinhando.
Gerenciamento de servidores
Os usuários podem adicionar, editar e excluir servidores. Eu adicionei validação de URL, swipe-to-delete e diálogos de confirmação para que as mudanças nos servidores pareçam seguras e deliberadas.
Cada tela de detalhes do servidor mostra dados de saúde, gráficos de latência com Swift Charts e um Tool Explorer que lista as ferramentas disponíveis e os schemas de parâmetros. Isso tornou o app iOS do MCP mais útil do que um simples frontend de chat.
Navegação e configurações
Eu usei um layout de três abas com `NavigationStack` e rotas com tipagem segura. Deep linking funciona através do esquema de URL `mcpconnect://`.
As configurações incluem:
Passo 6: eu implantei o endpoint do servidor MCP
A parte mais difícil foi tornar um servidor MCP baseado em stdio acessível a partir do celular. Meu servidor MCP pessoal originalmente rodava como um processo Node.js local com `StdioServerTransport`.
Para expô-lo ao app iOS do MCP, eu adicionei uma rota de API ao meu site Next.js no Vercel. A rota usa o `InMemoryTransport` do MCP SDK para fazer a ponte entre requisições JSON-RPC e a implementação local do servidor.
Cada requisição cria um par novo de servidor/cliente com `createLinkedPair()`, executa a operação e retorna a resposta. Essa abordagem funciona bem com infraestrutura serverless porque evita conexões de longa duração.
O endpoint fica em `https://uygarduzgun.com/api/mcp` e expõe 15 ferramentas que eu posso chamar a partir de qualquer cliente MCP. Essa configuração transformou um servidor local de ferramentas em um serviço pronto para celular, sem redesenhar todo o backend.
Por que essa arquitetura funciona
Na prática, funciona porque cada requisição é sem estado e isolada. Isso reduz o risco operacional e torna o escalonamento muito mais fácil. Se você construir um app iOS do MCP, esse padrão vale a pena considerar para deploy serverless.
Passo 7: IAP e monetização
Eu usei StoreKit 2 para um modelo simples free/pro. O plano gratuito é utilizável, mas o Pro remove os limites que os power users atingem mais rápido.
| Recurso | Free | Pro ($4.99/mo) |
|---|---|---|
| --- | ---: | ---: |
| Servidores | 2 | Ilimitado |
| Conversas | 50 | Ilimitado |
| Histórico | 30 dias | Ilimitado |
| Temas | Dark + Light | + acento customizado |
| Busca | Chat atual | Busca full-text all |
Eu gosto desse modelo porque ele não pune usuários casuais. Ele entrega valor suficiente logo no começo e depois se expande naturalmente quando o app vira parte de um fluxo de trabalho real.
Estatísticas do projeto e resultados
A construção acabou ficando maior do que eu esperava, mas a estrutura permaneceu limpa.
Esses números importam porque mostram que o app é de nível produção, não um protótipo. Eu queria um app iOS do MCP de verdade, e eu enviei um.
Imagens que eu adicionaria para este artigo
Se eu publicar este post, eu incluiria screenshots com texto alternativo descritivo para ajudar os leitores e melhorar SEO.
Principais aprendizados
O MCP Connect mostra que a ideia do app iOS do MCP é prática, segura e pronta para uso real. Se você está construindo ferramentas de IA para mobile, essa arquitetura pode economizar seu tempo e reduzir riscos. Leia o post relacionado sobre níveis de sinal de áudio explicados ou deixe um comentário se você quiser que eu destrinche o código do servidor em seguida.