Vad om din iPhone kunde prata med dina egna MCP-servrar var som helst? Det är exakt vad jag byggde med MCP iOS-app MCP Connect, en inbyggd mobilklient för Model Context Protocol. I den här artikeln förklarar jag hur jag designade, lanserade och deployade den, och varför det här tillvägagångssättet spelar roll om du vill ha riktiga AI-verktyg på mobil.
Vad är MCP Connect?
MCP Connect är min MCP iOS-app för att ansluta till MCP-servrar via HTTP, bläddra bland verktyg och chatta med AI när du är på språng. Jag byggde den i Swift och SwiftUI så att den känns inbyggd, snabb och stabil på iPhone.
Appen låter dig:
Jag ville att appen skulle kännas premium, inte som en wrapper. Så jag designade den med en mörk biografkänsla, glassmorphism, fjäderanimationer och haptisk feedback. Det designvalet spelar roll eftersom mobila AI-verktyg behöver kännas snabba och tydliga, särskilt när användare växlar mellan chattar och servrar.
Varför jag byggde en MCP iOS-app
Jag byggde den här MCP iOS-appen eftersom jag ville ha direkt åtkomst till mina egna verktyg från min telefon. Arbetsflöden som bara fungerar på desktop saktar ner dig när du är borta från skrivbordet. På iPhone ville jag ha samma kontroll som jag redan har i webbläsaren och på min Mac.
I min erfarenhet av att bygga produkter i Göteborg är de bästa mobilapparna de som löser ett smärtsamt, smalt problem riktigt bra. MCP Connect gör det för mig. Den ger mig säker åtkomst till mina MCP-servrar, och den gör det utan att lägga till ännu ett komplicerat lager.
Det här passar också den riktning som Model Context Protocol själv rör sig i. Anthropics MCP-spec är byggd kring en ren klient–server-modell, vilket gör den till en stark match för mobilappar som behöver strukturerad verktygsåtkomst. Jag höll implementationen i linje med den idén så att appen förblir lätt att underhålla när protokollet utvecklas.
Användarproblemet jag löste
De flesta AI-verktyg utgår fortfarande från att du sitter vid en dator. Det faller när du behöver kolla en server, trigga ett verktyg eller inspektera ett resultat när du är på resande fot. Med MCP Connect minskade jag friktionen.
Resultatet är enkelt: jag kan öppna appen, välja en server och interagera med mina verktyg på sekunder. Den hastigheten är hela poängen med MCP iOS-appen.
Teknikstacken bakom MCP iOS-appen
Jag höll stacken fokuserad och modern. Jag ville inte ha en övervuxen arkitektur eller onödiga beroenden.
| Lager | Teknologi |
|---|---|
| --- | --- |
| Plattform | iOS 17+, Swift 6, SwiftUI |
| Arkitektur | MVVM + Coordinators |
| Backend | Supabase (Auth, PostgreSQL, Realtime) |
| MCP Transport | JSON-RPC över HTTP |
| Persistens | SwiftData |
| IAP | StoreKit 2 |
| i18n | String Catalogs (EN + SV) |
| Deployment | Xcode + XcodeGen |
Den här stacken gav mig en stark grund för MCP iOS-appen. SwiftUI hanterade gränssnittet bra, SwiftData stödde offline-first-lagring, och Supabase gav mig autentisering och synk utan extra overhead i backend.
Jag använde också välbekanta produktionverktyg som Keychain för hemligheter och StoreKit 2 för prenumerationer. Det höll appen fokuserad på produktkvalitet istället för infrastrukturbrus.
Steg 1: Jag designade systemet först
Jag börjar alltid med designsystemet, eftersom det sparar tid senare. I det här projektet byggde jag tokens och delade komponenter innan jag skrev funktionskod.
Paletten Dark Cinema använder djupa svarta toner, subtilt upphöjda ytor och en indigo-accent. Varje yta använder en glassmorphism-behandling med `.ultraThinMaterial` och en tunn kantlinje så att UI:t känns lager-på-lager men inte tungt.
Systemet innehåller:
Jag byggde återanvändbara komponenter som `GlassCard`, `AccentButton`, `StatusBadge`, `ShimmerLoader` och `GlassTextField`. Det gjorde MCP iOS-appen enklare att skala eftersom nya skärmar ärvde samma visuella språk.
Steg 2: Jag separerade modeller från persistens
Jag delade domänmodeller från SwiftData-persistensmodeller. Det höll affärslogiken ren och testbar.
De viktigaste modellerna är:
Den separationen betydde mer än det låter. Den gav mig utrymme att ändra lagringsdetaljer utan att skriva om appens logik. För en MCP iOS-app gör den typen av gräns framtida funktioner enklare att lansera.
Säkerhetsbeslut: Keychain endast för API-nycklar
Jag satte en regel som jag inte skulle bryta: API-nycklar rör aldrig Supabase. Jag lagrar bara en `apiKeyRef` i databasen, medan själva nyckeln finns i iOS Keychain.
Det betyder att ett databasläckage inte exponerar autentiseringsuppgifter. Avvägningen är att nycklar inte synkas automatiskt mellan enheter. Användare måste skriva in dem igen på en ny telefon, men det tar bara sekunder och eliminerar en allvarlig säkerhetsrisk.
Steg 3: Jag byggde MCP-klienten
Klienten använder JSON-RPC över HTTP, vilket matchar Streamable HTTP-transporten i MCP-specen. Varje begäran skickas som en standard HTTP POST med en JSON-RPC-body.
Appen stödjer fyra kärnoperationer:
Jag laddar auktoriseringstokens från Keychain vid begäranstillfället. Det håller MCP iOS-appen säker och undviker att lagra hemligheter i minnet längre än nödvändigt.
Jag testade den mot mina egna servrar tills request-flödet kändes stabilt i verklig användning. Resultatet blev förutsägbar latens och en mycket bättre mobilupplevelse än jag förväntade mig i början.
Steg 4: Jag kopplade in Supabase
Jag använde Supabase för auth och synk eftersom det ger mig en snabb väg till produktion. Backend har fyra tabeller:
Varje tabell har Row Level Security. Det betyder att användare bara kan komma åt sina egna poster. Jag lade också till en databas-trigger som skapar en profil automatiskt efter signup.
Auth stödjer Sign in with Apple och email/password. Det gav mig ett rent signup-flöde utan att tvinga användare in i en enda inloggningsmetod. För en MCP iOS-app hjälper den flexibiliteten till adoption.
Steg 5: Jag byggde huvudfunktionerna
Appen har tre kärnytor: chat, serverhantering och inställningar. Jag höll varje del fokuserad så att upplevelsen förblir snabb på en telefon.
Chatgränssnitt
Chatten använder en tillståndsmaskin: `idle` → `sending` → `streaming` → `toolCalling` → `idle`. Verktygsanrop visas inline som expanderbara kort med verktygsnamn, argument, resultat och exekveringstid.
Det UI:t spelar roll eftersom det hjälper användare att lita på vad AI:t gör. De kan se varje steg istället för att gissa.
Serverhantering
Användare kan lägga till, redigera och ta bort servrar. Jag lade till URL-validering, svep-för-att-ta-bort och bekräftelsedialoger så att serverändringar känns trygga och genomtänkta.
Varje servers detaljvy visar hälsodata, latensdiagram med Swift Charts, och en Tool Explorer som listar tillgängliga verktyg och parameterscheman. Det gjorde MCP iOS-appen mer användbar än en enkel chat-front-end.
Navigation och inställningar
Jag använde en trefliks-layout med `NavigationStack` och typsäkra routes. Deep linking fungerar via URL-schemat `mcpconnect://`.
Inställningar inkluderar:
Steg 6: Jag deployade MCP-serverendpointen
Den svåraste delen var att göra en stdio-baserad MCP-server åtkomlig från mobil. Min personliga site MCP-server körde ursprungligen som en lokal Node.js-process med `StdioServerTransport`.
För att exponera den för MCP iOS-appen lade jag till en API-route till min Next.js-site på Vercel. Routen använder MCP SDK:ts `InMemoryTransport` för att överbrygga JSON-RPC-förfrågningar till den lokala serverimplementationen.
Varje begäran skapar ett nytt server-/klientpar med `createLinkedPair()`, kör operationen och returnerar svaret. Det tillvägagångssättet passar serverless-infrastruktur bra eftersom det undviker långlivade anslutningar.
Endpointen ligger på `https://uygarduzgun.com/api/mcp` och exponerar 15 verktyg som jag kan anropa från vilken MCP-klient som helst. Den här setupen gjorde att en lokal verktygsserver blev en mobilredo tjänst utan att jag behövde redesigna hela backend.
Varför den här arkitekturen fungerar
I praktiken fungerar den eftersom varje request är stateless och isolerad. Det minskar operativ risk och gör skalning mycket enklare. Om du bygger en MCP iOS-app är det här mönstret värt att överväga för serverless-deployment.
Steg 7: IAP och intäktsmodell
Jag använde StoreKit 2 för en enkel free/pro-modell. Gratisnivån går att använda, men Pro-nivån tar bort de gränser som power users snabbt stöter på.
| Funktion | Gratis | Pro ($4.99/mo) |
|---|---|---|
| --- | ---: | ---: |
| Servrar | 2 | Obegränsat |
| Konversationer | 50 | Obegränsat |
| Historik | 30 dagar | Obegränsat |
| Teman | Mörk + Ljus | + anpassad accent |
| Sökning | Nuvarande chatt | Fulltext allt |
Jag gillar den här modellen eftersom den inte straffar casual-användare. Den ger tillräckligt värde direkt, och expanderar sedan naturligt när appen blir en del av ett verkligt arbetsflöde.
Projektsiffror och resultat
Bygget blev större än jag förväntade mig, men strukturen förblev ren.
De siffrorna spelar roll eftersom de visar att appen är produktionsredo, inte en prototyp. Jag ville ha en riktig MCP iOS-app, och jag levererade en.
Bilder jag skulle lägga till för den här artikeln
Om jag publicerar det här inlägget skulle jag inkludera skärmdumpar med beskrivande alt-texter för att hjälpa läsare och förbättra SEO.
Viktiga takeaways
MCP Connect visar att idén med MCP iOS-appen är praktisk, säker och redo för verklig användning. Om du bygger mobila AI-verktyg kan den här arkitekturen spara tid och minska risk. Läs det relaterade inlägget om audio signal levels explained eller lämna en kommentar om du vill att jag ska bryta ner serverkoden nästa gång. ---