Zwei plattformübergreifende Desktop-Apps: Geocaching (offline-first) & Aufgabenverwaltung (Cloud-Sync)

[TimmyDuese]

Hallo zusammen,
ich plane aktuell zwei eigene Software-Projekte, die plattformübergreifend auf macOS und Windows laufen sollen. Bevor ich mit der Umsetzung starte, überlege ich mir gerade, welcher Technologie-Stack sich dafür am besten eignet.
Wichtig ist mir dabei, keine Webtechnologien wie Electron oder ähnliche Frameworks zu verwenden. Die Anwendungen sollen sich wie native Desktop-Programme verhalten und entsprechend effizient sein.

---

1) Geocaching-Verwaltung (offline-first)​

Ziel:
Eine Desktop-App, mit der ich Geocaching-Daten lokal verwalten, filtern und auf Offline-Karten darstellen kann.

Geplante Funktionen:

• Im-/Export von GPX/CSV (mit Dublettenprüfung)
• Filter & Suche nach Typ, D/T, Status, Owner, Radius, Datum, Tags
• Offline-Karten (MBTiles/Vektorkarten), Clustering, Overlays
• Tourenlisten, Notizen & Anhänge
• Lokale SQLite-Datenbank, kein Cloud-Zwang

---

2) Aufgaben- & Planungstool (mit Cloud-Sync)​

Ziel:
Eine flexible Aufgaben-App mit Kanban-, Listen- und Kalenderansicht, die plattformübergreifend synchronisiertwerden kann.

Geplante Funktionen:

• Frei definierbare Felder pro Aufgabe
• Drag & Drop, Zeitblöcke/Termine
• Zentrales Backend / Cloud-Datenbank für den Sync (optional selbst gehostet oder Managed)
• Lokaler Cache für Offline-Nutzung + saubere Konfliktlösung
• Export/Backups, einfache und klare UI

---

Mein Hintergrund & Technologie-Überlegung​

Ich habe Erfahrung mit Swift (iOS/macOS) und etwas Python. Für diese Projekte möchte ich bewusst eine neue Sprache lernen und schwanke aktuell zwischen zwei Ansätzen:

• Rust + Tauri → kleine Builds, sehr gute Performance, moderne UI über System-WebView (stark für Karten & komplexe Filter).
• Go + Fyne → einfacher Einstieg, native UI ohne Web-Stack; bei komplexeren Oberflächen voraussichtlich mehr Eigenaufwand.

Entscheidungskriterien:

• Geocaching-App: Offline-Karten, Performance, kompakte Pakete
• Aufgabenverwaltung: stabiler Cloud-Sync, flexible Datenstruktur, gute UX
• Beide: echte Plattformunabhängigkeit auf dem Desktop, ohne Electron oder vergleichbare Webframeworks

---

Status & Frage an euch​

Ich befinde mich derzeit in der Planungsphase und möchte zuerst kleinere Prototypen bauen, um den passenden Stack zu finden.
Mich würde interessieren:

• Welche der beiden Varianten würdet ihr für solche Projekte bevorzugen?
• Gibt es Punkte, die ich eurer Meinung nach vorher noch bedenken sollte (z. B. Build-Prozess, Distribution, Framework-Erfahrungen)?
• Habt ihr vielleicht eigene Erfahrungen mit Rust+Tauri oder Go+Fyne in ähnlichen Szenarien?

Ich freue mich über Meinungen, Hinweise oder auch kritische Gedanken, bevor ich in die eigentliche Umsetzung starte.

 

[Knighty]

1) Geocaching-Verwaltung (offline-first)

Ich kann da leider nichts beitragen, aber soll das so etwas wie GSAK werden, was ja mehr oder weniger nicht mehr weiterentwickelt wird?

 

[TimmyDuese]

@Knighty Ja vom Prinzip her schon, allerdings auf Windows und Mac gleichzeitig nutzbar.

 

[madmax2010]

Der stack ist meiner Meinung nach kaum relevant. Bau womit du Spaß hast.
Python geht sehr hübsch und portabel, wenigstens so lange du wxwidgets u.a vermeidest

 

[KitKat::new()]

Rust + Tauri → kleine Builds, sehr gute Performance, moderne UI über System-WebView (stark für Karten & komplexe Filter).

widerspricht sich doch mit folgendem:

Wichtig ist mir dabei, keine Webtechnologien wie Electron oder ähnliche Frameworks zu verwenden. Die Anwendungen sollen sich wie native Desktop-Programme verhalten und entsprechend effizient sein.

Webframework fürs UI notwendig -> weder besonders effizient noch hast du Programme, die sich wie native Desktop-Programme verhalten.

Soweit ich das sehe hast du bei diesen Anforderungen die folgenden Optionen:

• .NET MAUI: Framework bietet Abstractions für die jeweiligen Plattformen an, die intern native UI Controls nutzen
• Crux: Der nachfolgende Ansatz in ein Framework gepackt, jedoch noch ohne Desktop Support
• Plattformnative UI Views (in C# (WPF oder WinUI 2.0 - WinUI 3.0 ist zwar "die Zukunft" aber MS kommt diesbezüglich nicht wirklich mehr in die Potte) auf Windows, Kotlin auf Android, Swift auf iOS, beliebiges Framework im Web (kann auch in Rust sein)), und Cross-Plattform Core in Rust (kann inkl. View Models für die GUI alles bereit stellen): Bindings kannst z.B. mit UniFFI generieren

Meine Einschätzung wäre, dass .NET MAUI ggf. etwas weniger Aufwand ist, aber dafür wohl nicht unbedingt die optimalsten und flexibelsten UIs bietet, weil die Abstraktionen ggf. Eigenheiten von Plattformen nicht perfekt darstellen, während du mit den anderen beiden Ansätzen flexibler wärst.

Zwei weitere Optionen wären: QT (wie .NET MAUI, jedoch kein native mobile Plattformen), React Native (wie .NET MAUI, aber langsamer)

 

[TimmyDuese]

Sorry, das mit den Webtechnologien hatte ich irgendwie falsch ausgedrückt. Ich meinte eher, dass ich kein React, Vue oder Electron und nichts in diese Richtung verwenden möchte.

Ein wenig uneinig bin ich mir leider immer noch zwischen Go und Rust, was sind eure Meinungen. Rust eher für GUI Anwendungen?

 

[KitKat::new()]

Bei Rust + Tauri benutzt du zwar kein Elektron, aber hast trotzdem ein ähnliches Konzept, in der Hinsicht, dass ein webbasiertes Framework (z.B. React, aber auch wenn du Rust nimmst wie z.B. Leptos) in einer Browserengine läuft (nur halt in diesem Fall eine von der Plattform zur Verfügung gestellte, anstatt Chromium)

 

[sandreas]

Also Tauri basiert auf Rust, aber das UI schreibt man üblicherweise mit Web-Frameworks, wie react, svelte, vue oder so. Das ist in deinem Fall meiner Ansicht nach aber nichts Schlechtes.
Wenn du allerdings keine Erfahrung mit Rust hast und gerne schnell was fertig hättest, dann halte ich Rust für die falsche Wahl. Das ist nix für zarte Gemüter ohne Geduld. Allerdings hat Rust einen weiteren Riesenvorteil. Wenn die was machen, machen sie es richtig. Folglich ist da das meiste gute dokumentiert und läuft auch schnell und stabil.

Go ist da etwas... sagen wir einsteigerfreundlicher aber auch fummliger. Programmieren geht einfacher von der Hand, die Lernkurve ist nicht so steil, das Ökosystem ist aber meist etwas mehr Aufwand, etwas schlechter dokumentiert und weniger "sauber" und "durchdacht" (in Ermangelung eines besseren Ausdrucks) - ich denke, der Grundgedanke ist klar.

Von MAUI (C#) würde ich in deinem Fall eher Abstand nehmen. C# ist ne tolle Sprache, aber MAUI ist bestenfalls in einem fragwürdigen Zustand, grade im Cross-Platform Bereich. Die Binaries werden recht groß (50MB Minimum) und es fühlt sich auch nicht wirklich flott an. Ebenso gilt dies für die anderen UI-Libs in C# (AvaloniaUI und Uno Platform), wobei diese meiner Ansicht nach immer noch besser sind, als MAUI.

Du könntest dir für eine UI auch mal Flutter (Dart) anschauen - das läuft auch überall und viele schwören drauf. Mein Fall wars nicht.

Sehr viele gute GUIs sind auch in Java / Kotlin geschrieben (so blöd / altmodisch das klingt, aber Java / Kotlin ist ne echte Alternative hier). Android z.B. setzt stark auf Kotlin und hier gibt es auch Ansätze wie Kotlin Multiplatform oder sogar Kotlin/Native, wo man Kotlin code ohne JRE direkt nativ kompilieren kann.

Ich würde an deiner Stelle erstmal Tauri nehmen - aber dafür etwas Zeit einplanen. Das ist sehr ordentlich gemacht und geht gut von der Hand. Die Herausforderungen von Rust sind schwieriger zu meistern, aber es lohnt sich am Ende. Außerdem ist zu erwarten, dass Rust langfristig im UI Bereich deutlich mehr bietet als go, denn daran wird schon eine Weile gearbeitet. Ich versuche mich grade an einem embedded Projekt mit Slint, das ging bisher auch hervorragend von der Hand - ist aber lizenztechnisch vielleicht problematisch für dich (da GPLv3).