managarten/docs/PLAN_TAURI_V2.md

Implementierungsplan: PWA + Tauri v2 für ManaCore

Schrittweiser Plan um die ManaCore Unified Web App zuerst als PWA auszubauen und anschliessend als native Desktop- und Mobile-App via Tauri v2 auszuliefern — Plattform für Plattform.

Stand: April 2026

---

Übersicht

Roadmap

Phase 1     Phase 2      Phase 3       Phase 4        Phase 5       Phase 6       Phase 7       Phase 8
PWA      →  SPA-Modus →  macOS      →  Windows     →  Linux      →  Android   →  iOS        →  CI/CD & QA
(Web)       (Basis)      (Desktop)     (Desktop)      (Desktop)     (Mobile)      (Mobile)      (alle)

 ◄── geringster Aufwand                                                    höchster Aufwand ──►

Jede Phase liefert ein funktionsfähiges Release. Man muss nicht alle Plattformen gleichzeitig fertig haben.

Zielstruktur

apps/manacore/
├── apps/
│   ├── web/          # Bestehende SvelteKit-App (Web + PWA)
│   ├── tauri/        # NEU: Tauri v2 Shell (alle nativen Plattformen)
│   │   ├── src-tauri/
│   │   │   ├── src/          # Rust Backend
│   │   │   ├── capabilities/ # Permissions pro Plattform
│   │   │   ├── icons/        # App-Icons
│   │   │   ├── Cargo.toml
│   │   │   └── tauri.conf.json
│   │   └── package.json
│   └── ...

---

Phase 1: PWA ausbauen

Ziel: Die Web-App wird installierbar, offline-fähig und fühlt sich auf allen Geräten wie eine App an. Diese Arbeit ist direkte Vorarbeit für Tauri — nichts davon ist verschwendet.

Aufwand: 1–2 Wochen (davon Responsive UI der grösste Posten)

1.1 Service Worker Caching-Strategie

@vite-pwa/sveltekit ist bereits integriert. Was fehlt ist eine durchdachte Caching-Strategie:

• App-Shell (HTML, CSS, JS, Fonts) → Precaching (beim Install sofort cachen)
• Modul-Assets (Icons, Bilder) → Cache-First mit Stale-While-Revalidate
• API-Calls → Network-First mit Fallback auf Cache (für Offline-Lesbarkeit)
• Dexie.js Daten → Brauchen kein SW-Caching (liegen in IndexedDB)

Konfiguration in vite.config.ts erweitern:

// Workbox-Strategien für @vite-pwa/sveltekit
{
  workbox: {
    globPatterns: ['**/*.{js,css,html,ico,png,svg,woff2}'],
    runtimeCaching: [
      {
        urlPattern: /^https:\/\/.*\.mana\.how\/api\//,
        handler: 'NetworkFirst',
        options: { cacheName: 'api-cache', expiration: { maxEntries: 100 } }
      }
    ]
  }
}

1.2 Icons & Manifest vervollständigen

• App-Icons in allen Grössen generieren (16×16 bis 512×512)
• Maskable Icon für Android (sichere Zone beachten)
• Apple Touch Icons (180×180)
• manifest.json Felder prüfen:
  • display: "standalone" (kein Browser-Chrome)
  • orientation: "any"
  • theme_color und background_color
  • shortcuts für Quick-Actions (Neue Aufgabe, Neuer Termin, etc.)
  • categories: ["productivity", "utilities"]

1.3 Offline-UX

Da die App local-first ist, funktioniert sie offline bereits grundlegend. Was fehlt:

• Offline-Indikator — dezentes Banner/Icon wenn kein Internet
• Sync-Status-Anzeige — "3 Änderungen warten auf Sync"
• Graceful Degradation — Module die Backend brauchen (Chat AI, Picture AI) zeigen "Offline" statt Error
• Queued Actions — Pending Changes sichtbar machen

1.4 Update-Flow

• "Neue Version verfügbar" Dialog wenn Service Worker updated
• Sanfter Übergang — nicht mitten in der Arbeit neu laden
• Skip-Waiting Strategie mit User-Bestätigung

1.5 Responsive UI

Der grösste Einzelposten — aber identische Arbeit die für Tauri Mobile (Phase 6–7) sowieso anfällt:

• Audit: Welche der 27+ Module haben bereits Mobile-Breakpoints?
• Navigation: Sidebar → Bottom-Tab-Bar oder Hamburger-Drawer auf Mobile
• Touch-Targets: Mindestens 44×44px für alle interaktiven Elemente
• Keyboard-Handling: Input-Felder nicht von Soft-Keyboard verdeckt
• Viewport Meta-Tag: viewport-fit=cover für Edge-to-Edge
• Hover-States: Alternativen für Touch-Geräte (kein Hover)
• Modale/Dialoge: Full-Screen auf Mobile statt zentriertes Overlay

1.6 Validierung

• Chrome DevTools → Lighthouse PWA-Audit → Score 100
• App installieren auf: macOS (Chrome), Windows (Edge), Android (Chrome), iOS (Safari)
• Offline testen: Flugmodus → App öffnen → CRUD-Operationen → Internet an → Sync
• Update testen: Neue Version deployen → "Update verfügbar" erscheint

1.7 Bekannte PWA-Limitationen (beobachten, nicht lösen)

Diese Punkte sind der Grund warum Tauri als nächster Schritt folgt:

• iOS Safari: IndexedDB-Löschung nach 7 Tagen Inaktivität (betrifft local-first)
• iOS Safari: Keine Push-Notifications im Hintergrund
• Kein System Tray, keine globalen Shortcuts
• Kein Deep Link Protocol (manacore://)
• App Store Präsenz nicht möglich (ausser TWA auf Android)

---

Phase 2: SvelteKit SPA-Modus

Ziel: Die Web-App kann als statische SPA gebaut werden — Voraussetzung für Tauri.

Aufwand: 2–4 Tage

2.1 Adapter-Static Konfiguration

Aktuell nutzt die App @sveltejs/adapter-node. Für Tauri brauchen wir adapter-static:

• @sveltejs/adapter-static als Dependency hinzufügen
• Build-Flag für Tauri-Modus:

// svelte.config.js
import adapterNode from '@sveltejs/adapter-node';
import adapterStatic from '@sveltejs/adapter-static';

const isTauri = process.env.TAURI_ENV === 'true';

const config = {
  kit: {
    adapter: isTauri
      ? adapterStatic({ pages: 'build-static', assets: 'build-static', fallback: 'index.html' })
      : adapterNode({ out: 'build' }),
  },
};

• fallback: 'index.html' setzen für SPA-Routing (alle Routen → index.html)

2.2 Server-seitige Logik auflösen

hooks.server.ts — Runtime Env-Injection (grösste Hürde):

Aktuell injiziert hooks.server.ts ~15 API-URLs als window.__PUBLIC_*__ Variablen. Lösung:

• Config-Abstraktionsschicht bauen die Web und Tauri bedient:

// src/lib/config/env.ts
export async function getApiUrl(key: string): Promise<string> {
  if (window.__TAURI__) {
    const config = await invoke('get_config');
    return config[key];
  }
  return window[`__PUBLIC_${key}__`] || import.meta.env[`PUBLIC_${key}`] || '';
}

• Bestehende window.__PUBLIC_*__ Lösung bleibt für Web-Deployment intakt

hooks.server.ts — Subdomain-Routing & Security Headers:

• Beide irrelevant in Tauri — werden automatisch übersprungen

Server-Routes (routes/api/, routes/status/):

• routes/api/* Endpunkte inventarisieren
• Falls Client sie aufruft: auf direkte Backend-Aufrufe umstellen
• routes/status/+page.server.ts → Client-seitige Health-Checks

2.3 Validierung

• TAURI_ENV=true pnpm --filter @manacore/web build erzeugt build-static/ mit index.html
• build-static/ in einem einfachen HTTP-Server testen (npx serve build-static)
• Alle 27+ Module durchklicken — Client-Side-Routing funktioniert
• Go/No-Go: Falls fundamental SSR-abhängig → Plan überdenken

---

Phase 3: macOS Desktop

Ziel: ManaCore läuft als native Desktop-App auf macOS. Erste Tauri-Plattform.

Aufwand: 2–3 Tage (inkrementell über SPA-Basis)

Warum zuerst: Entwicklung passiert auf macOS → direktes Testen, kein Extra-Setup. Tauri Desktop seit 2022 stabil (4 Jahre Reife). WebKit auf macOS = gleiche Engine wie Safari, bekanntes Verhalten. Kein App Store nötig — DMG direkt verteilen.

3.1 Voraussetzungen

• Rust Toolchain installieren (rustup)
• Xcode installieren/aktualisieren (für macOS Builds)
• Tauri CLI: pnpm add -D @tauri-apps/cli

3.2 Tauri-Projekt initialisieren

• apps/manacore/apps/tauri/ erstellen
• package.json mit Workspace-Referenz zu @manacore/web
• tauri.conf.json konfigurieren:

{
  "build": {
    "beforeBuildCommand": "TAURI_ENV=true pnpm --filter @manacore/web build",
    "devUrl": "http://localhost:5173",
    "frontendDist": "../../web/build-static"
  },
  "app": {
    "title": "ManaCore",
    "windows": [
      {
        "title": "ManaCore",
        "width": 1280,
        "height": 800,
        "minWidth": 800,
        "minHeight": 600
      }
    ]
  },
  "bundle": {
    "identifier": "how.mana.manacore",
    "icon": ["icons/icon.png"]
  }
}

3.3 Rust-Backend Setup

• Minimales src-tauri/src/main.rs mit Config-Provider:

#[tauri::command]
fn get_config() -> serde_json::Value {
    serde_json::json!({
        "MANA_CORE_AUTH_URL": "https://auth.mana.how",
        "SYNC_SERVER_URL": "wss://sync.mana.how",
        // ...
    })
}

3.4 Capabilities & Permissions

• capabilities/default.json:
  • core:default (Fenster, Events)
  • http:default (HTTP-Requests an Backend-APIs)
  • notification:default (Benachrichtigungen)
  • clipboard-manager:default (Zwischenablage)
  • shell:default (URLs im Browser öffnen)

3.5 Dev-Workflow einrichten

• Turborepo-Tasks für tauri:dev, tauri:build
• Root-Level Script: "dev:manacore:desktop": "pnpm --filter @manacore/tauri dev"
• Tauri Dev-Mode nutzt Vite Dev-Server (devUrl: http://localhost:5173) → Hot Reload

3.6 IndexedDB auf macOS WebKit testen

• Dexie.js Persistenz: App schliessen → öffnen → Daten noch da?
• Speicherverbrauch der 120+ Collections messen
• WebSocket-Sync zu mana-sync funktioniert?
• Reconnect nach Sleep/Wake?

3.7 Validierung

• App startet als natives macOS-Fenster
• Login/Auth funktioniert (gegen mana-auth)
• IndexedDB/Dexie.js persistiert Daten
• Sync funktioniert (WebSocket zu mana-sync)
• Mindestens 10 Module durchklicken und testen
• Go/No-Go: IndexedDB/Sync stabil? → Weiter. Instabil? → Electron-Fallback evaluieren.

---

Phase 4: Windows Desktop

Ziel: ManaCore als native Windows-App.

Aufwand: 2–3 Tage (inkrementell über macOS)

Warum als Zweites: Relevanteste Desktop-Plattform nach macOS. Nutzt WebView2 (Chromium-basiert) — andere Rendering-Engine als macOS (WebKit). Das Testen hier bereitet auf Android vor (ebenfalls Chromium-basiert).

4.1 Voraussetzungen

• Windows-Testumgebung (VM, Dual-Boot, oder CI)
• WebView2 Runtime (auf Windows 10/11 vorinstalliert, Fallback für ältere Systeme einrichten)
• Rust Target hinzufügen: rustup target add x86_64-pc-windows-msvc

4.2 Plattform-spezifische Anpassungen

• NSIS oder MSI Installer konfigurieren in tauri.conf.json
• Code Signing Zertifikat beschaffen und einrichten
• Windows-spezifische Fenster-Optionen (Dekorationen, Startmenü-Integration)

4.3 Rendering-Unterschiede testen

Da WebView2 auf Chromium basiert (≠ macOS WebKit):

• CSS Rendering vergleichen (Flexbox, Grid, Scrollbars)
• IndexedDB-Verhalten prüfen (Chromium hat andere Limits/Verhalten als WebKit)
• Font-Rendering prüfen (Windows rendert Fonts anders)
• Scroll-Verhalten (Windows hat keine Rubber-Band-Scrolling)

4.4 Validierung

• App startet auf Windows 10 + 11
• Alle Module funktionieren (besonders UI-intensive: Calendar, Presi, Music)
• Installer erzeugt saubere Installation + Deinstallation
• Auto-Start Option funktioniert

---

Phase 5: Linux Desktop

Ziel: ManaCore als native Linux-App.

Aufwand: 0.5–1 Tag (inkrementell über macOS)

Warum als Drittes: Technisch fast identisch zu macOS (beide WebKitGTK-basiert). Geringster zusätzlicher Aufwand aller Plattformen. Kein Signing nötig.

5.1 Voraussetzungen

• Linux-Testumgebung (VM, WSL2, oder GPU-Server)
• WebKitGTK + System-Dependencies: sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev
• Rust Target: rustup target add x86_64-unknown-linux-gnu

5.2 Paketformate

• AppImage generieren (universell, kein Install nötig)
• DEB-Paket für Debian/Ubuntu
• Optional: RPM für Fedora, Flatpak für breitere Distribution

5.3 Validierung

• App startet auf Ubuntu 22.04+ und Fedora 38+
• WebKitGTK-spezifische Rendering-Checks
• AppImage funktioniert ohne Installation
• System-Tray Integration (falls in Phase 8 implementiert)

---

Phase 6: Android

Ziel: ManaCore als Android-App im Play Store.

Aufwand: 1–2 Wochen (inkrementell über Desktop)

Warum vor iOS: Android WebView basiert auf Chromium — ähnlich wie Windows WebView2, also bereits vertrautes Terrain. Kein Developer Account nötig zum Testen (APK Sideloading). Tauri v2 Android-Support ist etwas reifer als iOS.

6.1 Voraussetzungen

• Android Studio + Android SDK installieren
• Android Emulator oder physisches Testgerät
• Tauri Android-Target: tauri android init
• Keystore für Signing erstellen
• Google Play Developer Account (25$ einmalig)

6.2 Android-spezifische Anpassungen

• AndroidManifest.xml — Permissions (Internet, Notifications, Camera falls nötig)
• Minimum SDK Version festlegen (API 24 / Android 7.0 = WebView 80+)
• Status Bar / Navigation Bar Farben anpassen
• Back-Button Verhalten (Android Hardware-Back)
• Splash Screen (tauri-plugin-splash-screen)

6.3 Responsive UI auf echten Geräten testen

Die Responsive-Arbeit aus Phase 1.5 (PWA) wird hier validiert:

• Navigation auf kleinen Screens (Bottom-Tab / Drawer)
• Touch-Targets auf verschiedenen Bildschirmgrössen
• Landscape vs Portrait Orientation
• Soft-Keyboard schiebt Layout nicht kaputt
• Scroll-Performance in langen Listen

6.4 WebView-Versionen

Grösstes Android-spezifisches Risiko — die System-WebView variiert je nach Gerät:

• Minimum WebView-Version definieren und enforzen
• Auf älteren Geräten testen (Android 8, 9, 10)
• Feature-Detection für kritische APIs (IndexedDB, WebSocket)

6.5 Mobile-spezifische Plugins

• tauri-plugin-haptics — Haptisches Feedback bei Interaktionen
• tauri-plugin-biometric — Fingerprint für Login
• Push Notifications via FCM (Firebase Cloud Messaging)

6.6 Play Store Vorbereitung

• App-Icons in allen Android-Grössen (Adaptive Icons)
• Play Store Screenshots (Phone + Tablet)
• Privacy Policy URL
• App-Beschreibung (Deutsch + Englisch)
• Internal Testing Track einrichten
• AAB (Android App Bundle) statt APK für Store-Upload

6.7 Validierung

• App läuft auf Android 10+ stabil
• IndexedDB-Persistenz über App-Neustarts
• Sync funktioniert (inkl. Reconnect nach Background/Foreground)
• Play Store Internal Testing erfolgreich
• Go/No-Go: Android stabil? → Weiter zu iOS. Probleme? → Capacitor als Mobile-Fallback evaluieren.

---

Phase 7: iOS

Ziel: ManaCore als iOS-App im App Store.

Aufwand: 1–2 Wochen (inkrementell über Android)

Warum zuletzt: Höchster Overhead aller Plattformen: Apple Developer Account (99$/Jahr), Provisioning Profiles, Xcode-Pflicht, strengster App Store Review. iOS WebKit hat die strengsten IndexedDB-Limits. Hier entscheidet sich ob ein SQLite-Fallback nötig wird.

7.1 Voraussetzungen

• Apple Developer Account (99$/Jahr) — zwingend auch zum Testen auf echtem Gerät
• Xcode aktualisieren (neueste Version)
• Provisioning Profile + Signing Certificates erstellen
• Tauri iOS-Target: tauri ios init
• Physisches iOS-Gerät zum Testen (Simulator reicht nicht für alles)

7.2 iOS-spezifische Anpassungen

• Info.plist — Permissions, URL Schemes, Privacy Descriptions
• Safe Area Insets (Notch, Dynamic Island, Home Indicator)
• viewport-fit=cover + CSS env(safe-area-inset-*) für Edge-to-Edge
• iOS-spezifische Scroll-Bouncing / Overscroll-Verhalten
• Status Bar Style (Light/Dark Content je nach Theme)

7.3 IndexedDB Stresstest (kritisch)

Das ist der wichtigste Test der gesamten Roadmap:

• Speicherverbrauch der 120+ Collections unter realer Nutzung messen
• iOS WebKit-Limit (~500 MB) Stresstest — wie nah kommen wir?
• Persistenz: App schliessen → Tage warten → öffnen → Daten noch da?
• Vergleich: PWA Safari vs installierte Tauri-App (Tauri sollte stabiler sein)

Falls Limits zum Problem werden:

• tauri-plugin-sql (SQLite) als Fallback evaluieren
• Hybride Strategie: IndexedDB im Web, SQLite in Tauri iOS
• Storage-Abstraktionsschicht in Dexie.js integrieren

7.4 Mobile-spezifische Plugins (iOS)

• tauri-plugin-haptics — Taptic Engine Feedback
• tauri-plugin-biometric — Face ID / Touch ID
• Push Notifications via APNs (Apple Push Notification service)
• Optional: tauri-plugin-barcode-scanner für QR-Codes

7.5 App Store Vorbereitung

• App-Icons in allen iOS-Grössen (1024×1024 Store Icon)
• App Store Screenshots (iPhone 6.7", 6.1", iPad)
• App Store Beschreibung + Keywords (Deutsch + Englisch)
• Privacy Policy + Terms of Service URLs
• App Review Information (Demo-Account für Apple Reviewer)
• TestFlight einrichten für Beta-Tester

7.6 App Store Review vorbereiten

Apple prüft strenger als Google. Wichtige Punkte:

• Guideline 4.2 (Minimum Functionality) — App muss Mehrwert über Website hinaus bieten
• Tauri erzeugt echte native Apps (kein reiner WebView-Wrapper) → sollte akzeptiert werden
• Native Features dokumentieren (Notifications, Biometrics, Haptics) als Differenzierung zur Web-App
• Offline-Fähigkeit hervorheben

7.7 Validierung

• App läuft auf iOS 16+ stabil (iPhone + iPad)
• IndexedDB-Persistenz über Wochen (!) testen
• Face ID / Touch ID funktioniert
• Push Notifications kommen an
• TestFlight Beta-Test erfolgreich
• App Store Review bestanden

---

Phase 8: Desktop-Features, CI/CD & Qualitätssicherung

Ziel: Plattformübergreifende Stabilität, native Desktop-Features und automatisierte Builds.

Aufwand: 2–3 Wochen

8.1 Desktop-Features (alle Desktop-Plattformen)

• System Tray — tauri-plugin-positioner, Minimieren in Tray, Quick-Actions
• Auto-Updater — tauri-plugin-updater, Update-Server, In-App Dialog
• Native Notifications — tauri-plugin-notification, Calendar-Erinnerungen
• Globale Shortcuts — Cmd/Ctrl+N (Neues Item), Cmd/Ctrl+K (Quick-Suche), Cmd/Ctrl+1-9 (Modul wechseln)
• Deep Links — manacore:// Protocol für Links aus Emails/Chat
• Dateisystem — Drag & Drop, "Öffnen mit", Export (PDF/CSV)

8.2 Build Pipeline (Forgejo CI)

• macOS Build → DMG + App Bundle
• Windows Build → MSI + NSIS Installer
• Linux Build → AppImage + DEB
• Android Build → APK + AAB
• iOS Build → IPA
• Signing für alle Plattformen automatisieren
• Build-Artefakte als Releases veröffentlichen

8.3 Auto-Update Infrastruktur

• Update-Server / Release-Endpunkt auf Mac Mini
• Versionierung: SemVer aus Git-Tags
• Delta-Updates wo möglich

8.4 App Store Deployment

• Apple App Store: Upload via xcrun altool oder Transporter
• Google Play: Upload via Fastlane oder Play Console API
• Optional: Microsoft Store (MSIX), Snapcraft (Linux)

8.5 Testmatrix

Test	macOS	Windows	Linux	Android	iOS
App startet
Login/Auth
IndexedDB Persistenz
Sync (Push/Pull)
WebSocket Reconnect
Alle 27+ Module
Offline-Modus
Auto-Update
Deep Links
Native Notifications
Biometrics	—	—	—

8.6 Performance-Benchmarks

• Cold-Start: Ziel < 2s Desktop, < 3s Mobile
• RAM: Ziel < 150 MB Desktop, < 100 MB Mobile
• IndexedDB R/W Performance: Web vs Tauri vergleichen
• Scroll-Performance mit 1000+ Items in Listen

8.7 Edge Cases

• Kein Internet → App funktioniert offline
• Sleep/Wake → Sync reconnect
• Mehrere Desktop-Instanzen gleichzeitig
• Web-Nutzer öffnet Desktop-App → Daten synchronisieren automatisch

---

Aufwand-Übersicht

Phase	Plattform	Aufwand (inkrementell)	Kumuliert	Grösste Hürde
1	PWA (Web)	1–2 Wochen	1–2 Wochen	Responsive UI
2	SPA-Basis	2–4 Tage	~2.5 Wochen	hooks.server.ts → Client-Config
3	macOS	2–3 Tage	~3 Wochen	— (geringster Aufwand)
4	Windows	2–3 Tage	~3.5 Wochen	Andere Rendering-Engine (Chromium)
5	Linux	0.5–1 Tag	~3.5 Wochen	Nur Testen
6	Android	1–2 Wochen	~5.5 Wochen	WebView-Versionen älterer Geräte
7	iOS	1–2 Wochen	~7.5 Wochen	IndexedDB-Limits, App Store Review
8	CI/CD & QA	2–3 Wochen	~10 Wochen	Plattformübergreifende Stabilität

Gesamt: ca. 8–12 Wochen von PWA bis zur stabilen Auslieferung auf allen 5 Plattformen + App Stores.

Was jede Phase freischaltet

Nach Phase	Nutzer können...
Phase 1	App auf jedem Gerät aus dem Browser installieren (PWA)
Phase 3	ManaCore als macOS Desktop-App nutzen (DMG)
Phase 4	ManaCore als Windows Desktop-App nutzen (Installer)
Phase 5	ManaCore auf Linux nutzen (AppImage)
Phase 6	ManaCore aus dem Play Store installieren
Phase 7	ManaCore aus dem App Store installieren
Phase 8	Automatische Updates, native Features, stabile CI/CD

---

Risiken & Mitigationen

Risiko	Wahrscheinlichkeit	Impact	Mitigation
iOS WebKit IndexedDB-Limit	Mittel	Hoch	SQLite-Fallback evaluieren (Phase 7.3)
WebView-Inkonsistenzen Android	Mittel	Mittel	Minimum WebView-Version enforzen, Polyfills
Server-Routes im SPA-Modus	Sicher	Mittel	Phase 2.2 löst dies systematisch
Tauri Mobile Bugs	Mittel	Hoch	Capacitor als Fallback bereithalten
App Store Rejection (Apple)	Niedrig	Hoch	Native Features als Differenzierung betonen
Bundle-Grösse zu gross	Niedrig	Niedrig	Tauri-Bundles typisch 2–10 MB
Responsive UI Aufwand unterschätzt	Mittel	Mittel	In Phase 1 (PWA) anpacken, nicht aufschieben

---

Entscheidungspunkte (Go/No-Go)

Nach Phase	Frage	Falls Nein
Phase 2	Funktioniert die App stabil als SPA?	Falls fundamental SSR-abhängig → Architektur überdenken
Phase 3	Läuft Desktop auf macOS? IndexedDB/Sync stabil?	→ Electron als Desktop-Fallback
Phase 6	Android stabil? WebView-Performance akzeptabel?	→ Capacitor als Mobile-Fallback
Phase 7	iOS IndexedDB-Persistenz ausreichend?	→ SQLite-Fallback oder Capacitor + SQLite
Phase 7	App Store Review bestanden?	→ Native Features nachrüsten, ggf. Capacitor