diff --git a/apps/manacore/apps/web/src/app.html b/apps/manacore/apps/web/src/app.html index 77a5ff52c..28f42a234 100644 --- a/apps/manacore/apps/web/src/app.html +++ b/apps/manacore/apps/web/src/app.html @@ -3,7 +3,12 @@ - + + + + + + %sveltekit.head% diff --git a/apps/manacore/apps/web/src/lib/components/OfflineIndicator.svelte b/apps/manacore/apps/web/src/lib/components/OfflineIndicator.svelte new file mode 100644 index 000000000..8b894a712 --- /dev/null +++ b/apps/manacore/apps/web/src/lib/components/OfflineIndicator.svelte @@ -0,0 +1,180 @@ + + +{#if showBanner} +
+
+ + + +
+ {$_('pwa.offline', { default: 'Offline — Änderungen werden lokal gespeichert' })} + +
+{/if} + +{#if showSyncBadge} +
+ + + {networkStore.pendingCount} + {$_('pwa.pendingChanges', { default: 'Änderungen warten auf Sync' })} + +
+{/if} + +{#if showSyncing} +
+ + {$_('pwa.syncing', { default: 'Synchronisiere...' })} +
+{/if} + + diff --git a/apps/manacore/apps/web/src/lib/components/PwaUpdatePrompt.svelte b/apps/manacore/apps/web/src/lib/components/PwaUpdatePrompt.svelte new file mode 100644 index 000000000..8139ec041 --- /dev/null +++ b/apps/manacore/apps/web/src/lib/components/PwaUpdatePrompt.svelte @@ -0,0 +1,161 @@ + + +{#if showPrompt} + +{/if} + + diff --git a/apps/manacore/apps/web/src/lib/stores/network.svelte.ts b/apps/manacore/apps/web/src/lib/stores/network.svelte.ts new file mode 100644 index 000000000..e67b9b593 --- /dev/null +++ b/apps/manacore/apps/web/src/lib/stores/network.svelte.ts @@ -0,0 +1,58 @@ +/** + * Network status store — tracks online/offline state and pending sync changes. + * + * Integrates with the unified sync manager to show sync status + * and pending change counts in the UI. + */ + +import type { SyncStatus } from '$lib/data/sync'; + +let isOnline = $state(typeof navigator !== 'undefined' ? navigator.onLine : true); +let syncStatus = $state('idle'); +let pendingCount = $state(0); + +let cleanups: (() => void)[] = []; + +function initialize() { + if (typeof window === 'undefined') return; + + const handleOnline = () => (isOnline = true); + const handleOffline = () => (isOnline = false); + + window.addEventListener('online', handleOnline); + window.addEventListener('offline', handleOffline); + + cleanups.push(() => { + window.removeEventListener('online', handleOnline); + window.removeEventListener('offline', handleOffline); + }); +} + +function destroy() { + for (const fn of cleanups) fn(); + cleanups = []; +} + +function setSyncStatus(status: SyncStatus) { + syncStatus = status; +} + +function setPendingCount(count: number) { + pendingCount = count; +} + +export const networkStore = { + get isOnline() { + return isOnline; + }, + get syncStatus() { + return syncStatus; + }, + get pendingCount() { + return pendingCount; + }, + initialize, + destroy, + setSyncStatus, + setPendingCount, +}; diff --git a/apps/manacore/apps/web/src/routes/(app)/+layout.svelte b/apps/manacore/apps/web/src/routes/(app)/+layout.svelte index e23217153..2eb8bbd2d 100644 --- a/apps/manacore/apps/web/src/routes/(app)/+layout.svelte +++ b/apps/manacore/apps/web/src/routes/(app)/+layout.svelte @@ -34,6 +34,8 @@ import { linkLocalStore, linkMutations } from '@manacore/shared-links'; import { manacoreStore } from '$lib/data/local-store'; import { createUnifiedSync } from '$lib/data/sync'; + import { networkStore } from '$lib/stores/network.svelte'; + import { db } from '$lib/data/database'; import { dashboardStore } from '$lib/stores/dashboard.svelte'; import { THEME_DEFINITIONS, @@ -306,6 +308,16 @@ trackReturnVisit(); const getToken = () => authStore.getValidToken(); unifiedSync = createUnifiedSync(SYNC_SERVER_URL, getToken); + unifiedSync.onStatusChange(async (s) => { + networkStore.setSyncStatus(s); + // Update pending count when sync status changes + try { + const count = await db.table('_pendingChanges').count(); + networkStore.setPendingCount(count); + } catch { + // DB not ready yet + } + }); unifiedSync.startAll(); userSettings.load().catch(() => {}); diff --git a/apps/manacore/apps/web/src/routes/+layout.svelte b/apps/manacore/apps/web/src/routes/+layout.svelte index 90c03a089..9ccb53d1e 100644 --- a/apps/manacore/apps/web/src/routes/+layout.svelte +++ b/apps/manacore/apps/web/src/routes/+layout.svelte @@ -3,8 +3,11 @@ import { onMount } from 'svelte'; import { theme } from '$lib/stores/theme'; import { authStore } from '$lib/stores/auth.svelte'; + import { networkStore } from '$lib/stores/network.svelte'; import { loadAutomations } from '$lib/triggers'; import SuggestionToast from '$lib/components/SuggestionToast.svelte'; + import OfflineIndicator from '$lib/components/OfflineIndicator.svelte'; + import PwaUpdatePrompt from '$lib/components/PwaUpdatePrompt.svelte'; let { children } = $props(); @@ -12,6 +15,9 @@ // Initialize theme const cleanupTheme = theme.initialize(); + // Initialize network status tracking + networkStore.initialize(); + // Initialize auth await authStore.initialize(); @@ -20,9 +26,12 @@ return () => { cleanupTheme(); + networkStore.destroy(); }; }); {@render children()} + + diff --git a/apps/manacore/apps/web/src/routes/offline/+page.svelte b/apps/manacore/apps/web/src/routes/offline/+page.svelte index 645202281..21f09f9e5 100644 --- a/apps/manacore/apps/web/src/routes/offline/+page.svelte +++ b/apps/manacore/apps/web/src/routes/offline/+page.svelte @@ -4,6 +4,6 @@ diff --git a/apps/manacore/apps/web/static/apple-touch-icon.png b/apps/manacore/apps/web/static/apple-touch-icon.png new file mode 100644 index 000000000..910b29b26 Binary files /dev/null and b/apps/manacore/apps/web/static/apple-touch-icon.png differ diff --git a/apps/manacore/apps/web/static/pwa-192x192.png b/apps/manacore/apps/web/static/pwa-192x192.png new file mode 100644 index 000000000..ccd9fc2c2 Binary files /dev/null and b/apps/manacore/apps/web/static/pwa-192x192.png differ diff --git a/apps/manacore/apps/web/static/pwa-512x512.png b/apps/manacore/apps/web/static/pwa-512x512.png new file mode 100644 index 000000000..5aaee085f Binary files /dev/null and b/apps/manacore/apps/web/static/pwa-512x512.png differ diff --git a/apps/manacore/apps/web/vite.config.ts b/apps/manacore/apps/web/vite.config.ts index 58e6204f2..7729b5603 100644 --- a/apps/manacore/apps/web/vite.config.ts +++ b/apps/manacore/apps/web/vite.config.ts @@ -18,6 +18,24 @@ export default defineConfig({ shortName: 'ManaCore', description: 'ManaCore App Ecosystem', themeColor: '#6366f1', + registerType: 'prompt', + preset: 'full', + shortcuts: [ + { name: 'Dashboard', short_name: 'Home', url: '/', description: 'Zum Dashboard' }, + { + name: 'Neue Aufgabe', + short_name: 'Aufgabe', + url: '/todo', + description: 'Neue Aufgabe erstellen', + }, + { + name: 'Kalender', + short_name: 'Kalender', + url: '/calendar', + description: 'Kalender öffnen', + }, + { name: 'Chat', short_name: 'Chat', url: '/chat', description: 'Chat öffnen' }, + ], }) ), ], diff --git a/docs/MOBILE_DESKTOP_APP_STRATEGY.md b/docs/MOBILE_DESKTOP_APP_STRATEGY.md new file mode 100644 index 000000000..f7691f810 --- /dev/null +++ b/docs/MOBILE_DESKTOP_APP_STRATEGY.md @@ -0,0 +1,279 @@ +# Mobile & Desktop App Strategie + +> Analyse der Optionen, die bestehende ManaCore SvelteKit-App als native Mobile- und Desktop-App auszuliefern. +> +> Stand: April 2026 + +## Ausgangslage + +Die ManaCore Unified App ist eine SvelteKit 2 + Svelte 5 Anwendung mit: + +- **27+ Module** in einer einzigen App (`apps/manacore/apps/web`) +- **Local-first Architektur** mit Dexie.js / IndexedDB (120+ Collections) +- **Tailwind CSS** für Styling +- **Hintergrund-Sync** via mana-sync (Go, WebSocket) +- Bestehende **Expo/React Native Mobile-Apps** im Monorepo (einzelne Module) + +Ziel: Die gesamte unified App auf iOS, Android, macOS, Windows und Linux bringen — idealerweise mit maximaler Code-Wiederverwendung. + +--- + +## Optionen + +### 1. Tauri v2 + +**Funktionsweise:** Nutzt die native WebView des Betriebssystems (WebKit auf macOS/iOS, WebView2 auf Windows, WebKitGTK auf Linux, Android WebView). Backend in Rust. Kein gebündelter Browser. + +**Plattformen:** iOS, Android, macOS, Windows, Linux — alles mit einer Codebase. + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Sehr gut — SPA via `adapter-static`, Svelte ist First-Class-Citizen | +| IndexedDB/Dexie.js | Funktioniert, aber iOS-WebKit-Limit ~500 MB | +| Native APIs | Gut — Dateisystem, Notifications, Clipboard, Biometrics, Updater u.v.m. Eigene Plugins in Rust/Swift/Kotlin | +| Bundle-Grösse | 2–10 MB (kein Chromium gebündelt) | +| App Store Distribution | Alle Stores unterstützt | +| Performance | Sehr gut auf Desktop. Auf Mobile abhängig von System-WebView-Qualität | +| Community | ~85k GitHub Stars, aktive Entwicklung | + +**Vorteile:** + +- Einziges Framework das alle 5 Plattformen mit einer Codebase abdeckt +- Winzige Bundles im Vergleich zu Electron +- Svelte/SvelteKit offiziell unterstützt +- Gute Plugin-Architektur + +**Nachteile:** + +- Mobile-Support erst seit Oktober 2024 stabil — für eine komplexe App mit 27+ Modulen ein Risiko +- WebView-Inkonsistenzen zwischen Plattformen (besonders ältere Android-Geräte) +- Rust-Toolchain für eigene Plugins nötig +- Plugin-Ökosystem kleiner als Capacitor oder Electron + +--- + +### 2. Capacitor (Ionic) + +**Funktionsweise:** Wrapping-Framework, das eine Web-App in einer nativen WebView-Shell ausführt. Entwickelt von Ionic (Nachfolger von Cordova). Bridge zu nativen APIs. + +**Plattformen:** iOS und Android (Kernfokus). Desktop nur via Electron-Plugin. + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Gut — SPA via `adapter-static`, offizielle Anleitungen verfügbar | +| IndexedDB/Dexie.js | Funktioniert, selbes iOS-WebKit-Limit wie Tauri | +| Native APIs | Sehr umfangreich — grösstes Plugin-Ökosystem aller WebView-Frameworks (Camera, Filesystem, Push, Haptics, Contacts, etc.) | +| Bundle-Grösse | 15–30 MB | +| App Store Distribution | Exzellent — explizit dafür gebaut, tausende Apps in den Stores | +| Performance | Gut für die meisten Anwendungsfälle | +| Community | Sehr gross, Version 6, produktionsbewährt (Burger King, Sworkit) | + +**Vorteile:** + +- Grösstes Plugin-Ökosystem für Mobile +- Sehr ausgereift und produktionsbewährt +- Einfache Integration (`npx cap sync`) +- Niedriger Wartungsaufwand + +**Nachteile:** + +- Kein nativer Desktop-Support — braucht zusätzlich Electron oder Tauri +- Für "alle Plattformen" sind zwei Frameworks nötig +- Selbe iOS-IndexedDB-Einschränkungen + +--- + +### 3. Electron + +**Funktionsweise:** Bündelt eine vollständige Chromium-Instanz + Node.js mit der Web-App. Die App läuft in ihrem eigenen Chrome-Browser. + +**Plattformen:** macOS, Windows, Linux. Kein Mobile-Support. + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Gut — SPA oder SSR mit Node-Adapter möglich | +| IndexedDB/Dexie.js | Exzellent — eigenes Chromium, keine Limits, konsistentes Verhalten | +| Native APIs | Sehr umfangreich — Dateisystem, Tray, Menüs, Dialoge, Shortcuts, Autostart, Protocol Handler u.v.m. Volles npm-Ökosystem | +| Bundle-Grösse | 80–200+ MB (Chromium + Node.js gebündelt) | +| App Store Distribution | Möglich (VS Code, Slack, Discord im Mac App Store) | +| Performance | Gut für UI, hoher RAM-Verbrauch (100–300 MB Baseline) | +| Community | Industriestandard seit 2013, riesige Community | + +**Vorteile:** + +- Beste IndexedDB-Unterstützung (eigenes Chromium, keine Plattform-Abhängigkeit) +- Ausgereiftestes Desktop-Framework +- Riesiges Ökosystem +- Node.js-Zugriff für Server-seitige Operationen + +**Nachteile:** + +- Kein Mobile-Support +- Sehr grosse Bundles (80–200 MB) +- Hoher RAM-Verbrauch +- Regelmässige Chromium-Sicherheitsupdates nötig + +--- + +### 4. PWA (Progressive Web App) + +**Funktionsweise:** Die bestehende Web-App wird mit Service Worker und Web App Manifest erweitert. Kein nativer Wrapper — läuft direkt im Browser. + +**Plattformen:** Alle (via Browser installierbar). iOS eingeschränkt. + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Perfekt — 100%, keine Anpassungen nötig | +| IndexedDB/Dexie.js | Funktioniert, aber **kritisch auf iOS: Safari löscht IndexedDB-Daten nach 7 Tagen Inaktivität** | +| Native APIs | Begrenzt — Notifications, Geolocation, Camera, Share API, Clipboard. Kein echtes Dateisystem (iOS), eingeschränkter Hintergrund-Sync | +| Bundle-Grösse | 0 MB zusätzlich | +| App Store Distribution | Schwierig — Apple lehnt reine WebView-Apps zunehmend ab. Google Play via TWA möglich | +| Performance | Identisch zur Web-Version | +| Community | Web-Standard, aber Apple treibt PWA-Support nicht voran | + +**Vorteile:** + +- Zero Aufwand — Service Worker + Manifest hinzufügen +- Sofort installierbar auf allen Plattformen +- Kein App-Store-Review nötig +- Updates sofort verfügbar + +**Nachteile:** + +- **Für local-first auf iOS nicht verlässlich** (7-Tage-IndexedDB-Löschung) +- Begrenzte native APIs +- Apple akzeptiert reine WebView-Apps kaum noch im App Store +- Keine echte "App-Erfahrung" auf iOS + +--- + +### 5. React Native / Expo + +**Funktionsweise:** Echte native UI-Komponenten, gesteuert durch JavaScript. Kein WebView — rendert direkt UIKit (iOS) bzw. Android Views. Neue Architektur (Fabric + TurboModules) seit 2024 Standard. + +**Plattformen:** iOS und Android (Kernfokus). Desktop experimentell (react-native-macos/windows von Microsoft). + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Keine — komplett andere Technologie (React + JSX statt Svelte) | +| IndexedDB/Dexie.js | Nicht verfügbar — Alternativen: SQLite, MMKV, WatermelonDB | +| Native APIs | Exzellent — voller Zugriff auf alle nativen APIs. 50+ Expo-Module | +| Bundle-Grösse | 20–50 MB | +| App Store Distribution | Exzellent — EAS Build + EAS Submit für automatisierte Store-Submissions | +| Performance | Beste Mobile-Performance aller Optionen (native Rendering) | +| Community | Sehr gross — Meta, Microsoft, Amazon, Shopify nutzen React Native | + +**Vorteile:** + +- Beste Performance auf Mobile (kein WebView-Overhead) +- Voller Zugang zu allen nativen APIs +- Bestehende Expo-Erfahrung und Apps im Monorepo +- OTA-Updates via EAS Update + +**Nachteile:** + +- **Kein Code-Sharing mit SvelteKit** — komplettes UI-Rewrite nötig +- Dexie.js/IndexedDB nicht verfügbar, Datenschicht muss komplett neu gebaut werden +- 27+ Module doppelt pflegen = enormer Aufwand +- Kein verlässlicher Desktop-Support + +--- + +### 6. Wails + +**Funktionsweise:** Wie Tauri, aber Backend in Go statt Rust. Nutzt die System-WebView. Go-Funktionen direkt aus dem Frontend aufrufbar. + +**Plattformen:** macOS, Windows, Linux. Kein Mobile-Support. + +| Aspekt | Bewertung | +|--------|-----------| +| SvelteKit-Wiederverwendung | Gut — SPA, Svelte offiziell unterstützt | +| IndexedDB/Dexie.js | Wie Tauri — abhängig von System-WebView | +| Native APIs | Basis — Fenster, Menüs, Dialoge, Events, Clipboard. Eigene APIs in Go | +| Bundle-Grösse | 5–15 MB | +| App Store Distribution | Desktop-Stores möglich | +| Performance | Gut auf Desktop | +| Community | Mittel (~26k Stars), Wails v3 seit langem in Entwicklung | + +**Vorteile:** + +- Passt zur bestehenden Go-Expertise (6 Go-Services im Monorepo) +- Kleine Bundles +- Go-Backend kann direkt auf bestehende Service-Logik zugreifen + +**Nachteile:** + +- Kein Mobile-Support +- Deutlich kleinere Community als Tauri oder Electron +- Weniger Native APIs als Tauri +- Wails v3 Entwicklung schleppend + +--- + +## Vergleichsmatrix + +| Kriterium | Tauri v2 | Capacitor | Electron | PWA | React Native | Wails | +|---|---|---|---|---|---|---| +| **iOS** | Ja (seit 2024) | Ja (ausgereift) | Nein | Eingeschränkt | Ja (ausgereift) | Nein | +| **Android** | Ja (seit 2024) | Ja (ausgereift) | Nein | Ja | Ja (ausgereift) | Nein | +| **macOS** | Ja | Via Electron | Ja | Via Browser | Experimentell | Ja | +| **Windows** | Ja | Via Electron | Ja | Via Browser | Experimentell | Ja | +| **Linux** | Ja | Via Electron | Ja | Via Browser | Nein | Ja | +| **SvelteKit direkt nutzbar** | Ja (SPA) | Ja (SPA) | Ja (SPA/SSR) | Ja (100%) | Nein | Ja (SPA) | +| **IndexedDB/Dexie.js** | Gut¹ | Gut¹ | Exzellent | Riskant² | N/A | Gut¹ | +| **Native API Umfang** | Gut | Sehr gut | Sehr gut | Begrenzt | Exzellent | Basis | +| **Bundle-Grösse** | 2–10 MB | 15–30 MB | 80–200 MB | 0 MB | 20–50 MB | 5–15 MB | +| **App Store tauglich** | Ja | Ja | Ja (Desktop) | Schwierig | Ja | Ja (Desktop) | +| **Community** | Gross (85k★) | Gross | Sehr gross | Web-Standard | Sehr gross | Mittel (26k★) | +| **Wartungsaufwand** | Mittel | Niedrig–Mittel | Mittel | Minimal | Hoch (2. Codebase) | Niedrig | + +¹ iOS-WebKit-Limit ~500 MB für IndexedDB +² iOS Safari: Löschung nach 7 Tagen Inaktivität + +--- + +## Empfehlung + +### Primärstrategie: Tauri v2 + +Tauri v2 ist das einzige Framework, das alle 5 Zielplattformen (iOS, Android, macOS, Windows, Linux) mit einer einzigen SvelteKit-Codebase abdeckt. Svelte ist offiziell unterstützt, die Bundles sind winzig, und die Plugin-Architektur ist erweiterbar. + +**Risiken die im Auge behalten werden müssen:** + +- Mobile-Support ist jung — gründliches Testing mit allen 27+ Modulen nötig +- WebView-Inkonsistenzen auf älteren Android-Geräten +- iOS-WebKit-Limit für IndexedDB (~500 MB) bei wachsender Datenmenge + +### Fallback: Capacitor (Mobile) + Tauri (Desktop) + +Falls Tauri v2 Mobile sich für die Komplexität der 27+ Module als zu unreif erweist: + +- **Capacitor** für iOS/Android — ausgereifter, grösstes Mobile-Plugin-Ökosystem +- **Tauri v2** für Desktop — leichtgewichtig, Svelte-First-Class +- Dieselbe SvelteKit SPA-Codebase für beide Wrapper + +### PWA als sofortige Massnahme + +Unabhängig von der nativen Strategie: Service Worker und Web App Manifest hinzufügen. Kostet fast nichts, bringt sofortige Installierbarkeit auf Desktop (Chrome/Edge). Auf iOS für local-first allerdings nicht verlässlich. + +### React Native / Expo nur für dedizierte Einzel-Apps + +Die bestehenden Expo-Apps im Monorepo machen Sinn für Module, die eine fundamental native Mobile-UX brauchen (z.B. Cards mit Swipe-Gesten, Chat mit nativen Push Notifications). Für "die gesamte unified App auf Mobile bringen" ist der Aufwand (komplettes Rewrite) nicht verhältnismässig. + +### IndexedDB-Risiko mitigieren + +Das grösste technische Risiko über alle WebView-Ansätze hinweg ist das iOS-WebKit-Verhalten: + +- **SQLite-Plugin als Alternative auf Mobile** — Tauri hat `tauri-plugin-sql`, Capacitor hat `@capacitor-community/sqlite` +- **Hybride Strategie:** IndexedDB im Web, SQLite im nativen Wrapper +- **Dexie.js** arbeitet an experimentellen SQLite-Backends (Dexie Cloud) + +--- + +## Nächste Schritte + +1. **PWA-Grundlagen einbauen** — Service Worker + Manifest für sofortige Desktop-Installierbarkeit +2. **Tauri v2 Proof-of-Concept** — SvelteKit-App als SPA mit adapter-static bauen, in Tauri laden, auf allen 5 Plattformen testen +3. **IndexedDB-Limits evaluieren** — Tatsächlichen Speicherbedarf der 120+ Collections messen, iOS-Verhalten unter Last testen +4. **SQLite-Fallback prototypen** — Dexie.js mit SQLite-Backend oder Storage-Abstraktionsschicht evaluieren +5. **Entscheidung treffen** — Basierend auf PoC-Ergebnissen: Tauri allein oder Capacitor+Tauri Kombi diff --git a/docs/PLAN_TAURI_V2.md b/docs/PLAN_TAURI_V2.md new file mode 100644 index 000000000..af0f4e2e7 --- /dev/null +++ b/docs/PLAN_TAURI_V2.md @@ -0,0 +1,627 @@ +# 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: + +```typescript +// 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: + +```js +// 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: + +```typescript +// src/lib/config/env.ts +export async function getApiUrl(key: string): Promise { + 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: + +```json +{ + "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: + +```rust +#[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 |