Native iOS (SwiftUI) vs. Capacitor-WebView-Hülle — Tiefenrecherche

Für: Dennis (Silverscale Family Hub) · Stand: 07.06.2026 · Datenbasis: echtes Frontend (app/frontend/src/, 7.617 Zeilen), app/ARCHITEKTUR.md (ADR-1–44), CLAUDE.md, Webrecherche (Quellen unten), Apple-Dev-Doku-Recherche von here.now.

1. Executive Summary — klare Empfehlung

Bleib bei der Capacitor-WebView-Hülle. Reimplementiere NICHT. Aber hol dir den Apple-Developer-Account (99 €/Jahr) und gehe Option A (inkrementell nativ): Hülle behalten, gezielt native Extensions danebenstellen (Widget + Live Activity für „Restbudget heute", später eine watchOS-Begleit-App). Den Live-Kamera-Scanner kannst du als Option B in einem nativen Capacitor-Plugin (VisionKit DataScannerViewController) kapseln, wenn die zxing-wasm-Lösung im Alltag nervt — das ist der einzige Web-Schmerzpunkt mit echtem nativem Mehrwert.

Die Begründung in einem Satz: Ein Voll-Reimplement (Option C) würde ~7.600 Zeilen UI plus das in 44 ADRs verdichtete Detailwissen plus ein zweites Frontend (Desktop-Web bleibt!) duplizieren — für eine 2-Personen-Familien-App, deren reale UX-Lücken (Widgets, Live Activities, Watch, Scanner) sich alle auch mit der Hülle + nativen Extensions schließen lassen, ohne die für dich entscheidende LLM-Sekunden-Iterationsschleife auf dem VPS aufzugeben.

Konfidenz der Gesamtempfehlung: hoch (85 %). Der einzige Faktor, der das kippen könnte, ist nicht-technisch: wenn dir das Bauen einer nativen App als Lern-/Spaßprojekt mehr wert ist als die Iterationsgeschwindigkeit — das ist eine Wert-, keine Architekturentscheidung.

2. In einfachen Worten

Du hast eine richtig gute Web-App, die auf dem Server lebt. Claude kann sie dort in Sekunden ändern, neu ausliefern und sich selbst per Screenshot anschauen — das ist eine ungewöhnlich schnelle Bau-Schleife. Die iPhone-„App" ist nur ein dünner Rahmen (Capacitor), der diese Web-App im Vollbild lädt; jeder Frontend-Deploy erreicht das iPhone sofort, ohne neue App-Installation.

Eine native App (SwiftUI) würde sich an ein paar Stellen einen Tick wertiger anfühlen und kann Sachen, die das Web nie kann: Widgets auf dem Sperrbildschirm, Live Activities („Restbudget 420 kcal" als lebendige Kachel), eine Apple-Watch-App. Aber: Du müsstest die komplette App nochmal bauen — in einer Sprache, in der Claude nicht mehr in Sekunden, sondern nur über deinen Mac mit langsameren Bau-/Test-Runden iterieren kann. Und die Desktop-Web-Version (die ihr behaltet) müsstest du dann doppelt pflegen.

Die elegante Mitte: Hülle behalten, und genau die paar nativen Schmankerl (Widget, Live Activity, Watch, evtl. Kamera-Scanner) als kleine native Bausteine danebenstellen. Das geht mit Capacitor problemlos. Dafür brauchst du nur den 99-€-Apple-Account — der nebenbei das nervige 7-Tage-SideStore-Refresh-Problem löst.

3. Top 10 (mit Konfidenz)

1. Voll-Reimplement lohnt sich nicht für eine 2-Personen-App mit dieser Feature-Fläche. (hoch, 85 %)
2. Der 99-€-Apple-Dev-Account ist der eigentliche Hebel — er löst das 7-Tage-SideStore-Treadmill (→ TestFlight, 90-Tage-Builds) UND schaltet Widgets/Live Activities/Watch/echtes APNs-Push frei. Diese Entscheidung ist von „nativ vs. Web" unabhängig und sollte zuerst fallen. (sehr hoch, 95 %)
3. Widgets & Live Activities erfordern KEIN Reimplement — native Extensions laufen neben der Capacitor-Hülle (geteilter App-Group-State via JSON), fairer Vergleich. (hoch, 88 %)
4. Der LLM-Workflow ist das stärkste Pro-Web-Argument: Svelte auf dem VPS = Claude deployt + screenshottet selbst in Sekunden (Playwright in app/.venv). SwiftUI = Build nur auf dem Mac, kein gleichwertiger Self-Screenshot-Loop. (hoch, 85 %)
5. Der einzige echte native UX-Gewinn im Kernflow ist der Live-Kamera-Scanner (VisionKit DataScannerViewController vs. zxing-wasm + dokumentierte WebKit-Kamera-Bugs ADR-18/31). Lässt sich als isoliertes Plugin nachrüsten. (mittel-hoch, 75 %)
6. Du würdest 7 ADRs an hart erarbeitetem WebView-„fühlt-sich-nativ-an"-Wissen wegwerfen (ADR-18, 31, 40, 41, 42, 43, 44) — aber ~80 % davon (Edge-Swipe, Sheet-Dirty, Safe-Area, Haptik-Punkte, Skeleton-Timing) wären in SwiftUI schlicht gratis vorhanden. Der Verlust ist real, aber kleiner als er wirkt. (mittel, 70 %)
7. Zwei Frontends statt eins: Desktop-Web bleibt definitiv (Statistik/Stammdaten am großen Schirm). Ein SwiftUI-Reimplement ADDIERT ein Frontend, es ersetzt keins. Doppelte Wartung jeder künftigen Funktion. (hoch, 85 %)
8. Swift Charts ist Chart.js mindestens ebenbürtig (nativ, performant, 3D ab iOS 26) — aber kein Grund zu migrieren, weil Chart.js euren Bedarf längst deckt. (hoch, 80 %)
9. SwiftUI ist 2026 reif für diese App-Klasse (@Observable + SwiftData/REST + NavigationStack + Swift Charts + VisionKit). Reife ist NICHT das Problem — der Workflow ist es. (hoch, 85 %)
10. watchOS ist der attraktivste „nativ-only"-Zuwachs (kcal-Budget am Handgelenk, Komplikation) und am saubersten als reine Companion-App baubar, ohne die iPhone-Hülle anzufassen (Option D). (mittel, 65 %)

4. Body

4.1 Ist-Analyse des Frontends (Zahlen)

Umfang (gemessen in app/frontend/src/):

API-Kopplung: ~70 distinkte /api/*-Endpunkte über 157 Call-Sites. Das Backend (FastAPI) ist die einzige Wahrheit; das Frontend ist ein dünner REST-Client mit lokalem State (Svelte stores). Wichtig für den Reimplement-Aufwand: Ein SwiftUI-Client müsste exakt diese ~70 Endpunkte als typisierte Swift-Modelle + Decodable + async/await-Client nachbauen — das Backend bliebe unverändert (großer Vorteil, halbiert das Reimplement-Risiko gegenüber „alles neu").

Feature-Fläche (vollständig erfasst): - Tagebuch mit editierbaren Nährwert-Snapshots (Gramm/Portionen, Server rechnet neu), Quell-Badges, Undo-Löschen - Wochenplan (Gerichte + Artikel, HF-Box, shared/Wir-Modus, Plan↔Tagebuch) - Gerichte mit Markdown-Schritten (marked), Bildern, KI-Naming, HF-Feedback, Favoriten - Einkaufsliste je Woche (Merge-Regeln, Vorrats-/Preishinweis) - Vorräte + Bestandsjournal - Bon-Archiv (Einkäufe) mit Deeplinks - Statistik (Chart.js: kcal/Preis/Overview) + 🤖 Insights - Aktivitäten-Dashboard (eGYM + Garmin: Besuche, Geräte mit Verlauf, Körperdaten, Outdoor) — Chart.js-schwer (Activity/Machine/Visit-Seiten) - Barcode-Scan an 4 Einbauorten (ScanSheet, FoodSheet, Dish, Article) via BarcodeDetector + zxing-wasm-Fallback - KI-Job-Polling (AiProgress, globaler Poller, determinate Stages) - Mehrnutzer-Switcher, Dark Mode, Haptics, Edge-Swipe (native.js)

Tech-Abhängigkeiten: chart.js 4.4, marked 18, zxing-wasm 2.2, @fontsource (Fraunces/Inter Tight), Capacitor-Plugins (Browser/Haptics/StatusBar/SplashScreen/App/AppLauncher).

Quantifizierung des „fühlt-sich-nativ-an"-Aufwands (das Kern-Pro-Nativ-Argument, fair bewertet):

Von 44 ADRs sind 7 rein WebView-Nativ-Kompensation: ADR-18 (Scan-Fallback wegen fehlender Shape-Detection-API), ADR-31 (PWA-Kamera-Falle, hängendes getUserMedia, WebKit #185448/#215884), ADR-40 (Geräte-Code-Login weil WKWebView kein WebAuthn), ADR-41 (Touch-Semantik, alle 29 :hover hinter @media (hover:hover), Sheet-Dirty-Check, Safe-Area, externe Links kapern die WebView), ADR-42 (Netz-Robustheit, Skeletons, Bundle-Hash-Reload, Haptik), ADR-43 (19+3 Gerätefunde einer einzigen Testwelle: WKWebView-Zurück-Geste rendert veraltete Snapshots → eigener JS-Edge-Swipe, Body-Scroll-Lock, Drag-to-dismiss, Doppeltipp-Zoom), ADR-44 (Animationsschichtung-Flackern, Bottom-Nav-Safe-Area, Dark-Kontrast).

Das ist substanziell — grob ~1,5 ADR-Tagessessions wurden allein in „die Website darf nicht wie eine Website wirken" investiert. ABER, ehrlich quantifiziert: Der Großteil dieser Funde wäre in einer nativen App gar nicht erst entstanden: Swipe-Back, Scroll-Lock, Safe-Area, Touch-vs-Hover, Sheet-Drag-to-dismiss, Haptik, native Kamera-Permission, Snapshot-freies Zurück sind in SwiftUI eingebautes Standardverhalten. Das ist das ehrliche, stärkste Argument für nativ. Der Gegenwert: Diese Arbeit ist bereits bezahlt (sunk cost, aber erledigt und stabil), und sie war Lernarbeit am System, nicht Wegwerf-Code — die App fühlt sich laut deinen eigenen Gerätetests inzwischen nativ genug an, dass „die Nutzerin nie merkt, dass eine Website darunter liegt" (ADR-41-Ziel).

4.2 UX-Decke: Was kann nativ, was Web nie kann — und ist es für 2 Personen relevant?

Fazit UX-Decke: Genau vier Fähigkeiten überschreiten die Web-Decke spürbar (Widget, Live Activity, Watch, Scanner). Drei davon (Widget, LA, Watch) sind additive Extensions, die die Hülle nicht antasten. Der vierte (Scanner) ist als gekapseltes Plugin nachrüstbar. Keine dieser vier erzwingt einen Voll-Reimplement.

4.3 Die vier Optionen im Detail

Option A — Hülle behalten + native Extensions (Widgets / Live Activities / watchOS) · EMPFOHLEN

Was: Capacitor-Hülle bleibt der Träger. Du fügst dem Xcode-Projekt native Targets hinzu: ein WidgetKit-Widget (Restbudget/nächste Mahlzeit), optional eine ActivityKit-Live-Activity, optional eine watchOS-Companion-App. Geteilter State über App Group (UserDefaults/JSON); ein dünner Capacitor-Bridge-Plugin schreibt Daten aus der WebView in die App Group, das Widget liest sie. Reife Community-Plugins existieren (@capgo/capacitor-widget-kit, capacitor-widget-bridge, capacitor-live-activities).

Aufwand: Widget (statisch, Budget+Datum): ~1–2 LLM-Sessions auf dem Mac. Live Activity: ~2–3 Sessions (Push-Token-Handling). watchOS-Begleiter: ~3–5 Sessions (eigene SwiftUI-Views + REST-Aufrufe gegen euer bestehendes Backend — die ~70 Endpunkte sind schon da).

Risiko: Niedrig. Die WebView bleibt unberührt, Frontend-Deploys laufen weiter. Einzige neue Abhängigkeit: Xcode-Build auf dem Mac für jeden Extension-Release (aber NICHT für Frontend-Änderungen). Voraussetzung: Apple-Dev-Account (Extensions sind ohne nicht signierbar/installierbar jenseits 7 Tagen).

Warum gewinnt das: Du holst dir 3 der 4 nativen Killer-Features, behältst den LLM-Sekunden-Loop fürs Haupt-UI, behältst ein einziges großes Frontend, riskierst keine ADR-Regression.

Option B — Einzelne native Screens in der Hülle (insb. Scanner)

Was: Capacitor erlaubt, einzelne Funktionen als natives Plugin zu kapseln und aus der WebView aufzurufen. Konkret lohnend: ein Scanner-Plugin um VisionKit DataScannerViewController — JS ruft scan(), ein nativer Vollbild-Scanner öffnet sich, liefert die EAN zurück. Das ersetzt zxing-wasm/getUserMedia an den 4 Einbauorten durch Apples eingebauten, fokus-/highlight-fertigen Scanner und umgeht die WebKit-Kamera-Bugs (ADR-18/31) komplett.

Aufwand: Scanner-Plugin: ~2–3 LLM-Sessions (UIViewControllerRepresentable + Capacitor-Plugin-Boilerplate + JS-Bridge). Frontend-seitig nur lib/scan.js um einen „nativen-Plugin-zuerst"-Pfad erweitern (analog zur bestehenden hasNativeDetector()-Logik — die Architektur ist API-agnostisch designt, das passt).

Risiko: Niedrig-mittel. Plugin-Wartung wird Swift/Mac-gebunden, aber isoliert. Fallback (zxing-wasm) bleibt für Web/Desktop.

Empfehlung: Nur machen, wenn der zxing-Scanner im Alltag tatsächlich nervt. Es ist die UX-stärkste Einzelmaßnahme, aber kein Muss-Tag-1.

Option C — Voll-Reimplement in SwiftUI

Was: Alle 15 Seiten + 22 Komponenten in SwiftUI neu, ~70 Endpunkte als typisierter Swift-Client, Chart.js → Swift Charts, marked → natives Markdown/AttributedString, zxing → VisionKit, Svelte-Stores → @Observable, lokale Persistenz optional SwiftData.

Aufwand (realistisch): Die UI ist nicht trivial — Dish.svelte (905 Z.) und Activity.svelte (774 Z., chart-schwer) sind eigene Mini-Projekte. Schätzung für Feature-Parität v1.7: 8–14 Kalenderwochen LLM-gestützter Arbeit, getrieben durch die langsamere Bau-/Test-Schleife (siehe 4.4), NICHT durch reine Tipparbeit. Das Backend bleibt zwar (halbiert den Aufwand ggü. „alles neu"), aber jede der ~70 Endpunkt-Antworten braucht ein korrektes Decodable-Modell, und jede der 44 ADR-Detailentscheidungen müsste im neuen Client bewusst nachgezogen werden.

Risiko: HOCH. Die 44 ADRs sind verdichtetes Verhaltenswissen (Snapshot-Semantik, Plan↔Tagebuch-uneat, shared-Modus loggt in beide Tagebücher, Merge-statt-Reset bei Einkaufsliste, Vorrats-Abzug-Einheitenlogik, EAN-Korrektur-Affordances, KI-Stage-Verankerung …). Ein Reimplement ist ein riesiges Einfallstor für stille Regressionen — Funktionen, die heute „einfach richtig" sind, müssten alle neu verifiziert werden. Zudem: Desktop-Web verschwindet nicht → du betreibst danach zwei Frontends mit divergierender Feature-Geschwindigkeit.

Wann sinnvoll: Praktisch nie für 2 Nutzer — außer als bewusstes Lern-/Hobbyprojekt, bei dem Geschwindigkeit egal ist.

Option D — watchOS-only nativ als Companion

Was: iPhone bleibt komplett Capacitor-Hülle. Du baust ZUSÄTZLICH eine eigenständige watchOS-App (SwiftUI + Swift Charts), die direkt euer Backend spricht: Restbudget-Ring, schnelles „gegessen"-Logging, Komplikation auf dem Zifferblatt.

Aufwand: ~3–6 LLM-Sessions. Klein gehalten (kein Feature-Spiegel, nur 2–3 Kern-Views).

Risiko: Niedrig, weil vollständig additiv und isoliert. Eigener Code, aber keine Berührung mit iPhone-Hülle oder Web.

Empfehlung: Stärkster „echt nativer" Zuwachs mit dem besten Aufwand/Wow-Verhältnis — eine gute Phase 2 nach den Widgets. Kann mit Option A gebündelt werden (watchOS ist technisch ein weiteres Target im selben Apple-Account).

4.4 LLM-Workflow-Kapitel (das entscheidende Kriterium)

Dein Entwicklungsmodell ist „Claude baut, Dennis reviewt/testet". Damit wird die Iterationsschleife des LLM zum härtesten Auswahlkriterium — härter als jede UX-Decke.

Web/Svelte auf dem VPS (Ist-Zustand) — Sekunden-Loop: - Claude editiert .svelte → npm run build (Node 22 user-lokal) → docker compose up -d --build silverscale → live. - Selbst-Verifikation: Playwright + Chromium in app/.venv, authentifizierte Screenshots gegen 127.0.0.1:9300 mit X-Internal-Token (mobil/Desktop/dark). Claude sieht das Ergebnis ohne menschliches Zutun. - Eine schreibende Session auf der Zielmaschine, kein Geräte-Hop. Das ist eine außergewöhnlich enge Schleife — und der Grund, warum 44 ADRs an einem Wochenende entstehen konnten.

SwiftUI (Ziel-Zustand) — Mac-gebundener, längerer Loop: - Build geht nur auf dem Mac (kein Linux-Xcode). Der VPS — wo das Repo und die Haupt-Session leben — kann SwiftUI weder bauen noch rendern. - Self-Screenshot-Äquivalente existieren, sind aber schwächer als Playwright: - xcrun simctl + simctl io booted screenshot → Simulator-Screenshots headless (machbar, aber Boot-/Build-Zeiten in Minuten, nicht Sekunden). - XcodeBuildMCP (59 Tools) und Apples xcrun mcpbridge (20 Tools) geben Agents 2026 strukturierten Zugriff auf Build/Test/Simulator/Debug — das ist der vielversprechendste Pfad, real existierend, aber neu und Mac-zentriert. - SwiftUI-Previews / RenderPreview (Apple MCP) für headless Layout-Checks; swift-snapshot-testing für visuelle Regression. - XCTest/swift test für Logik — aber UI-Verhalten testet man auf iOS notorisch schlechter als Web. - Was verloren geht: die VPS-lokale Sekunden-Schleife, der eine-Maschine-Komfort, Playwright-Parität, „deploy und screenshot in einem Rutsch". Der Mac wird zum zwingenden Build-Server in der Schleife; Latenz pro Iteration steigt von Sekunden auf Minuten. - Was besser wird: SwiftUI-Code ist für LLMs gut generierbar (Apple trainierte „UICoder" genau dafür; iOS-LLM-Benchmarks zeigen brauchbare SwiftUI-Generierung). Der Compiler fängt mehr Fehler statisch ab als JS. Aber das wiegt den Schleifen-Latenz-Verlust für dein Setup nicht auf.

Bewertung: Für eine Extension/Watch-App (Optionen A/B/D) ist die langsamere Mac-Schleife akzeptabel — es ist wenig, abgegrenzter Code, selten geändert. Für ein Voll-Reimplement (Option C) multipliziert sich der Latenz-Verlust über ~7.600 Zeilen × 44 ADR-Verhaltensregeln und macht den Loop zum Hauptkostentreiber. Das ist der Kern, warum C ausscheidet und A/B/D tragbar sind.

Mac-Tooling-Voraussetzung für A/B/D: ein erreichbarer Mac als Build-Knoten (du hast bereits einen Mac-Klon, der via receive.denyCurrentBranch=updateInstead direkt in den VPS pusht — derselbe Mac kann der Xcode-Build-/Screenshot-Knoten sein). XcodeBuildMCP/mcpbridge dort einrichten, damit Claude Builds + Simulator-Screenshots fahren kann.

4.5 Entscheidungsmatrix

Gewichtung 1–5 nach Relevanz für eine 2-Personen-Familien-App mit LLM-Entwicklung. Score je Option 1 (schlecht) – 5 (ideal).

Lesart: „Status quo" und „A" liegen gleichauf — A ist Status quo PLUS die nativen Schmankerl, ohne dessen Stärken zu opfern. D ist knapp dahinter und ideal als additive Phase 2. C ist klar abgeschlagen. Die Matrix sagt: inkrementell ausbauen, nicht ersetzen.

4.6 Roadmap-Vorschlag

Phase 0 — Entscheidung entkoppeln (sofort, unabhängig von nativ/Web): - Apple-Developer-Account (99 €/Jahr, Individual, kein D-U-N-S, ~24 h). Löst das 14.06.-SideStore-7-Tage-Refresh-MVP-Kriterium dauerhaft via TestFlight (Builds 90 Tage gültig, quartalsweiser Re-Upload, bis 100 interne Tester ohne Review). Das ist ohnehin auf eurer Liste und der größte Einzelgewinn.

Phase 1 — Hülle stabilisieren (läuft): Jaqueline komplett onboarden (Pocket-ID + Installation, jetzt via TestFlight statt SideStore-Frickelei). Mehrfach-Scan, OFF-Write-Back etc. wie geplant am Web-Frontend (Sekunden-Loop).

Phase 2 — erstes natives Extra (Option A): Restbudget-/nächste-Mahlzeit-Widget (WidgetKit + App-Group-Bridge). Kleinster nativer Code, höchster täglicher Sichtbarkeitswert. Mac-Build-Knoten (vorhandener Mac-Klon) mit XcodeBuildMCP einrichten.

Phase 3 — watchOS-Companion (Option D): kcal-Ring + Schnell-Logging + Komplikation. Spricht das bestehende Backend.

Phase 4 (optional, bedarfsgetrieben): Live Activity (Workout/Budget) · nativer VisionKit-Scanner als Plugin (Option B), falls zxing im Alltag nervt.

Nie (es sei denn Hobby): Phase „Voll-Reimplement" (Option C).

4.7 Offene Fragen

1. Mac-Verfügbarkeit/Zuverlässigkeit als Build-Knoten: Optionen A/B/D setzen einen erreichbaren, eingerichteten Mac voraus, auf dem Claude Xcode-Builds + Simulator-Screenshots fahren darf. Der Mac-Klon existiert — aber ist er als CI-/Build-Server für Claude konfigurierbar (SSH/MCP, Xcode-Version, Signing-Profile)? Nicht verifiziert.
2. Reifegrad von XcodeBuildMCP / xcrun mcpbridge in eurer konkreten Umgebung: Recherchiert als existierend und vielversprechend (2026), aber nicht von mir praktisch getestet. Wie gut der LLM-Loop damit real wird, ist die größte verbleibende Unbekannte für A/B/D.
3. Wert nativer Haptik/Premium-Gefühl für Jaqueline: Das „fühlt-sich-nativ-an"-Ziel ist laut ADR-41 schon erreicht. Ob der Rest-Delta zu „echt nativ" für die Nutzerin spürbar/relevant ist, kann nur ein A/B-Test am Gerät klären — nicht aus dem Code ableitbar.
4. Web-Push-Zuverlässigkeit heute: Ihr habt VAPID-Push (ADR-17). Wie oft scheitert es real auf iOS (PWA-Gebundenheit)? Wenn häufig, steigt der Wert von APNs (Apple-Account) — Datenlage fehlt.
5. Capacitor-Plugin-Reife für Widgets/Live Activities: Die genannten Community-Plugins existieren, ihr Wartungsstand/Versions-Fit zu iOS 26 wurde nicht im Detail verifiziert — vor Phase 2 kurz prüfen.

Quellen

• Apple-Developer-Account-Recherche (here.now): https://liminal-haven-gke3.here.now/ — 99 €/Jahr Individual, TestFlight 90-Tage-Builds/100 Tester, Widgets/Live Activities/watchOS/APNs erfordern ADP, „native Extensions neben Capacitor + Remote-Code-Push behalten" empfohlen.
• Swift 6 iOS Development 2026: https://softaims.com/blog/swift-ios-development-guide-2026
• State of Swift 2026: https://devnewsletter.com/p/state-of-swift-2026/
• REST API Clients in Swift: https://oneuptime.com/blog/post/2026-02-02-swift-rest-api-clients/view · https://matteomanferdini.com/swift-rest-api/
• SwiftData (Apple): https://developer.apple.com/documentation/swiftdata · Observation/Model data (Apple): https://developer.apple.com/documentation/SwiftUI/Managing-model-data-in-your-app
• DataScannerViewController (Apple): https://developer.apple.com/documentation/visionkit/datascannerviewcontroller · VisionKit in SwiftUI: https://medium.com/@ramesh_aran86/how-to-use-visionkit-in-swiftui-for-text-and-barcode-scanning-on-ios-e3f66c9006f2 · Vision barcodes: https://www.createwithswift.com/reading-qr-codes-and-barcodes-with-the-vision-framework/
• Building iOS Apps with AI Agents (XcodeBuildMCP 59 Tools, xcrun mcpbridge 20 Tools): https://blakecrosley.com/guides/ios-agent-development
• iOS LLM Arena (AI-Generated SwiftUI Benchmark): https://ronnierocha.dev/blog/ios-llm-arena-a-head-to-head-benchmark-for-ai-generated-swiftui/ · Apple UICoder: https://9to5mac.com/2025/08/14/apple-trained-an-llm-to-teach-itself-good-interface-design-in-swiftui/
• Capacitor Widgets iOS/Android: https://medium.com/@kisimedia/how-to-add-widgets-to-your-capacitor-app-ios-android-76fefbea5cb8 · @capgo/capacitor-widget-kit: https://capgo.app/docs/plugins/widget-kit/ · capacitor-live-activities: https://github.com/ludufre/capacitor-live-activities · capacitor-native-widgets: https://github.com/alesmraz/capacitor-native-widgets
• Best SwiftUI Charts Libraries 2026: https://theswiftk.it.com/best/swiftui-charts-libraries · Swift Charts 3D WWDC 2025: https://dev.to/arshtechpro/wwdc-2025-swift-charts-3d-a-complete-guide-to-3d-data-visualization-40nc
• WebKit for SwiftUI WWDC 2025: https://dev.to/arshtechpro/wwdc-2025-webkit-for-swiftui-2igc · PWA iOS Limitations 2026: https://www.magicbell.com/blog/pwa-ios-limitations-safari-support-complete-guide · WKWebView (NSHipster): https://nshipster.com/wkwebview/ · Native vs Hybrid 2025: https://kodexolabs.com/hybrid-apps-vs-native/

Codebasis-Belege: app/frontend/src/ (43 Dateien, 7.617 Z., 15 Seiten/22 Komponenten/6 lib, ~70 API-Endpunkte/157 Call-Sites), app/ARCHITEKTUR.md ADR-1–44 (davon 7 reine WebView-Nativ-Kompensation: 18/31/40/41/42/43/44), app/frontend/src/lib/native.js + lib/scan.js + lib/api.js, app/ios-shell/capacitor.config.json.