Programmierung einer App-Oberfläche für Android und IOS

[Ryzzjx]

Moin zusammen,
ich möchte für ein Gemeinschaftsprojekt gerne eine Oberfläche für eine App entwickeln, die bestenfalls sowohl auf Android als auch auf IOS läuft möglichst mit identischem Code.
Hat jemand Erfahrungswerte mit welchen Sprachen / IDEs man dies realisieren kann? (Stehe noch ganz am Anfang und habe Basics in Java und HTML drauf)
Meine erste Anlaufstelle wäre Android Studio mit Kotlin.
Würde mich sehr über eine Antwort freuen.

Beste Grüße
Ryzzjx

 

[MoebiusHRO]

Bin Laie (kenne mich mit Java und Swift was aus)…aber wäre da RUST nicht geeignet?

 

[abcddcba]

Such dir z.B. von den Frameworks eins aus: https://kotlinlang.org/docs/cross-platform-frameworks.html

IDEs musst du dir dann eine deiner Wahl raussuchen, sowas wie VS Code oder z.B. aus dem Jetbrains Portfolio sollte alles ausreichen fuer eine App.

 

[Autokiller677]

Um für iOS zu entwickeln, brauchst du auf jeden Fall einen Mac, wenn es eine richtige App sein soll. Eine Website kann man natürlich überall entwickeln.

 

[MoebiusHRO]

Bin Laie (kenne mich mit Java und Swift was aus) aber wäre da RUST nicht geeignet?

 

[bif81]

Wenn Du schon Erfahrungen in Java gesammelt hast spricht nichts gegen Kotlin.
Alternativen wären z.B. MAUI (.NET) mit Visual Studio oder auch Flutter von google.
Allerdings gilt es zu bedenken, dass Du für IOS Builds einen mac benötigst (sofern noch nicht vorhanden)

 

[tomgit]

Bei der sehr detailliert beschriebenen App und deren Einsatzgebiet, könnte man auch überlegen, ob eine PWA vielleicht eine Option wäre.

 

[pseudopseudonym]

Als Nicht-Laie, der an sowas beruflich beteiligt ist, kann ich dir Flutter sehr empfehlen. Geht auch mit AndroidStudio, also hast du etwas Gewohntes. Um das ganze für iOS zu bauen, brauchst du entweder einen Mac oder bei Github einen MacOS-Worker. Das zweite dürfte definitiv die günstigere Variante sein. Wenn du den oft brauchst, kann es sich lohnen, einen Mac zu mieten (der dann nicht bei dir steht).
Für Flutter gibt's massig Tutorials und Pakete, wenn du etwas mit Online-Anbindung bauen willst, hast du eine sehr einfache Firebase-Anbindung mit Flutter.

 

[sandreas]

Mein Rat: Nimm Flutter. Obwohl es eine eher weniger verbreite Programmiersprache verwendet (Dart) sind die Konzepte nicht viel schwieriger zu verstehen, als die von anderen Sprachen. Es ist alles ein wenig anders, aber wenn man sich Zeit nimmt, geht's doch einigermaßen flott.

Ich sage das als jemand, der versucht hat, eine Cross-Platform-App (inkl. Desktop) mit Ionic / React UND mit C# zu entwickeln (sowohl mit MAUI als auch mit AvaloniaUI). Das ist alles Mist. Die Apps sind entweder riesig groß (>100MB), träge und / oder es fehlen grundsätzliche Features, die man eigentlich in fast jeder App braucht (Daten persistent speichern, Navigation zwischen Seiten, uvm.). Die Libraries sind bestenfalls "experimental" und in vielen Fällen voller nerviger Fehler, um die man herumarbeiten muss. Beispiele für C#:

• MAUI - Drag & Drop von Dateien nicht unterstützt (seit 2 Jahren offen)
• Für AvaloniaUI musste ich mir selbst was schreiben, um Views zu wechseln und Benutzereinstellungen zu speichern (auch Preferences genannt) - WebViews waren der blanke Horror.

Gar nicht davon zu reden, dass man mal was ausgefalleneres mit integrierter Hardware machen will, z.B. einen QR Code Scannen oder Musikplayer mit Tasten steuern.

Ich habe vermutet, das das mit Flutter als Cross-Platform Lösung ja wohl kaum besser sein kann... und habe mich geirrt. Es gibt viele gute Libraries für alles Mögliche, die meisten davon sind auf Cross-Platform ausgelegt und sehr sauber implementiert. Für kleine Dinge reicht auch oft schon die mitgelieferte Standard-Implementierung ganz ohne Library. Apps sind je nach Komplexität eher so im Bereich <30MB und wesentlich flotter. Das wirkt sich auch auf die Akkulaufzeit bei mobilen Geräten aus. Außerdem ist das Deployment sehr einfach via github actions zu machen, wenn man keinen Mac hat. Beispiel Libraries für das von mir genannte:

• Benutzereinstellungen - https://pub.dev/packages/shared_preferences
• Page Routing - https://pub.dev/packages/auto_route
• Service Locator / IoC - https://pub.dev/packages/get_it
• Lokale Datenbank (wie sqlite) - https://pub.dev/packages/isar
• Flutter audio service - https://pub.dev/packages/audio_service

Und das war nur ein kurzer Überblick, man beachte jeweils die Angabe, welche Platform unterstützt wird.

Viel Erfolg.

 

[KitKat::new()]

aber wäre da RUST nicht geeignet?

Rust wäre wohl die beste Wahl, wenn man die GUI nativ programmiert (Android -> Kotlin; iOS -> Swift) und trotzdem Code zwischen den Plattformen teilen möchte.
-> Bestes UI für die Benutzer (da muss man bei jedem Cross-Plattform Framework abstriche machen)
-> minimale Codeduplizierung
-> erstklassige Performance

 

[sandreas]

Rust wäre wohl die beste Wahl, wenn man die GUI nativ programmiert (Android -> Kotlin; iOS -> Swift) und trotzdem Code zwischen den Plattformen teilen möchte.

Rust ist eine low-level Sprache und für "einfache" Apps ohne High-Performance Anforderungen eher nicht erforderlich. Ja, Rust ist cross-platform und ja Rust ist eine sehr elegante Sprache mit großer Verbreitung, aber Rust ist eigentlich mehr für Systemnahe Programmierung gedacht und ziemlich komplex (der Borrow-Checker ist eher nix für Anfänger).

Falls man etwas Systemnahes in der App machen muss (z.B. Audiotags aus Dateien auslesen oder komplexe Bildalgorithmen), gibt es tatsächlich aber auch Bridges, die Rust-Libraries im Flutter-Code nutzen (https://github.com/fzyzcjy/flutter_rust_bridge oder https://github.com/cunarist/rinf), auch wenn diese das Deployment etwas verkomplizieren. So hätte man Rust-Performance wo mans braucht und Flutter-Einfachheit für den Rest. Die ganze App in Rust zu schreiben halte ich aber für zu aufwändig und daher den falschen Weg..

 

[MoebiusHRO]

@sandreas danke für diese Ausführung. Bin zwar nicht der TE aber da ich mich auch demnächst mal mit App-Entwicklung auf einer einfachen Ebene befassen wollte, hilft mir persönlich diese Erläuterung sehr weiter (hatte schon vorgehabt mich mit RUST zu befassen)! Werd mich dann mal auf Flutter stürzen 👍😎

 

[sandreas]

Werd mich dann mal auf Flutter stürzen 👍😎

Hier beginnen: https://flutter.dev/
Und dann mal ne Kleine App bauen. Das Video hier fand ich ne ganz gute Einführung in die Praxis:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

 

[KitKat::new()]

Rust ist eine low-level Sprache und für "einfache" Apps ohne High-Performance Anforderungen eher nicht erforderlich.

Das Fehlen eines GC macht aus Rust keine Low Level Sprache und sie ist auch nicht nur für systemnahe Programmierung gedacht, weil die Sprache die Möglichkeit dafür mitbringt.
Z.B. ist Rust DIE Anlaufstelle bei WASM im Browser, oder eben auch bei Crossplattform Applikationen, bei denen man Logik auf allen Plattformen (inkl. Browser) wiederverwenden mag.

Falls man etwas Systemnahes in der App machen muss (z.B. Audiotags aus Dateien auslesen oder komplexe Bildalgorithmen), gibt es tatsächlich aber auch Bridges, die Rust-Libraries im Flutter-Code nutzen (https://github.com/fzyzcjy/flutter_rust_bridge oder https://github.com/cunarist/rinf), auch wenn diese das Deployment etwas verkomplizieren. So hätte man Rust-Performance wo mans braucht und Flutter-Einfachheit für den Rest.

Das Problem mit Flutter ist, dass es eben nicht an das Niveau nativer GUIs ran kommt.
Das Problem kann man umgehen indem man native GUIs schreibt und den gemeinsamen Code dann in Form von Rust einbindet.
Hierfür kann man Uniffi einsetzen, was bindings direkt für mehrere Sprachen generieren kann (C#, Kotlin, Swift z.B.) (https://github.com/mozilla/uniffi-rs).
Aufwändiger als Flutter, aber weniger aufwändig als 2-4 mal den Code im verschiedenen Sprachen zu schreiben.

Also es geht nicht darum die ganze App in Rust zu schreiben und es ist auch nur eine zusätzliche Option.
Ich will dir Flutter nicht ausreden.

 

[sandreas]

Das Fehlen eines GC macht aus Rust keine Low Level Sprache und sie ist auch nicht nur für systemnahe Programmierung gedacht, weil die Sprache die Möglichkeit dafür mitbringt.

Alles vollkommen korrekt. Und Anfängern würde ich Rust als erste Sprache trotzdem nicht ans Herz legen wollen, grade für Cross-Platform-App-Programmierung nicht. Eher für ein kleines Kommandozeilentool oder sowas. Weiterhin finde ICH viel "low leveliger" (ist das ein Begriff?) als Rust gehts fast nicht mehr, auch wenn das tooling und die Sprachkonstrukte deutlich moderner sind als beispielsweise in C(++).

Z.B. ist Rust DIE Anlaufstelle bei WASM im Browser, oder eben auch bei Crossplattform Applikationen, bei denen man Logik auf allen Plattformen (inkl. Browser) wiederverwenden mag.

ICH finde, dass die Nutzung von mehreren Sprachen / toolsets für ein Projekt etwas ist, dass man eher vermeiden sollte, wenn es nicht unbedingt aus Gründen erforderlich ist. Und auch das kann man natürlich anders sehen.

Das Problem mit Flutter ist, dass es eben nicht an das Niveau nativer GUIs ran kommt.

Hier stimme ich voll und ganz zu, etwas, dass man dringend beachten sollte - man merkt, dass du viel Erfahrung hast. Das schafft leider kein Cross-Platform-Framework und Flutter löst gerade diesen Aspekt von allen verfügbaren meiner Ansicht nach mit Abstand am besten. Da können sich C# und React Native / Ionic noch ne dicke fette Scheibe abschneiden.

Flutter ist glaube ich auch nicht dazu da, um mit nativen Apps zu konkurrieren, sondern um den Entwicklungs- und Wartungsaufwand einer gemeinsamen UI gering zu halten, während es benutzbare Ergebnisse liefert. Eine Riesen-Applikation wie Photoshop oder ein Excel würde ich darin auch niemals programmieren - eher kleine bis mittelgroße "Helferlein". Mehr schafft man als Einzelentwickler oder kleines Team meistens auch nicht in endlicher Zeit.

Aufwändiger als Flutter, aber weniger aufwändig als 2-4 mal den Code im verschiedenen Sprachen zu schreiben.

Richtig, und ich denke es kommt bei einer Zentralisierung via Rust sogar noch etwas hinzu: Qualität, Wartbarkeit und Performance. Code EINMAL zu schreiben ist per se weniger fehleranfällig. Dazu kommt zusätzlich die gute Performance und der zielmlich gute Schutz vor Sicherheitslücken (sofern man richtig programmiert). Ich würde Rust auch einbinden, wenn es in Dart für etwas noch keine Library gibt und ich es bräuchte. Aber das ist echt selten.

 

[pseudopseudonym]

eher kleine bis mittelgroße "Helferlein"

"Helferlein" klingt so klein. Mit Flutter ging's in den letzten Jahren gut nach vorn. Mobil ist's mit Flutter 3 deutlich performanter geworden, im Webbrowser mit Flutter 3.16 ebenfalls (neuer Renderer). Da gehen auch komplexere Anwendungen inzwischen ziemlich gut. Wenn du dann Libs für komplexere Aufgaben einbindest, ist da auch in den seltensten Fällen alles in Dart implementiert, womit die Performancenachteile an den Stellen wegfallen. Die ganz komplexen Sachen laufen dann oft sowieso im Backend.

 

[oiisamiio]

Mein Rat: Nimm Flutter. Obwohl es eine eher weniger verbreite Programmiersprache verwendet (Dart) sind die Konzepte nicht viel schwieriger zu verstehen, als die von anderen Sprachen. Es ist alles ein wenig anders, aber wenn man sich Zeit nimmt, geht's doch einigermaßen flott.

Ich sage das als jemand, der versucht hat, eine Cross-Platform-App (inkl. Desktop) mit Ionic / React UND mit C# zu entwickeln (sowohl mit MAUI als auch mit AvaloniaUI). Das ist alles Mist. Die Apps sind entweder riesig groß (>100MB), träge und / oder es fehlen grundsätzliche Features, die man eigentlich in fast jeder App braucht (Daten persistent speichern, Navigation zwischen Seiten, uvm.). Die Libraries sind bestenfalls "experimental" und in vielen Fällen voller nerviger Fehler, um die man herumarbeiten muss. Beispiele für C#:

• MAUI - Drag & Drop von Dateien nicht unterstützt (seit 2 Jahren offen)
• Für AvaloniaUI musste ich mir selbst was schreiben, um Views zu wechseln und Benutzereinstellungen zu speichern (auch Preferences genannt) - WebViews waren der blanke Horror.

Fuer C# nimmt in der Regel Xamarin (Mono). MAUI ist eher experimentell und AvaloniaUI ein Community Proejkt...

Sorry. Aber ja Xamarin App Size ist nicht ohne: https://stackoverflow.com/questions/36561571/xamarin-apps-are-large-why-and-can-they-be-smaller

 

[sandreas]

Fuer C# nimmt in der Regel Xamarin (Mono). MAUI ist eher experimentell

Gewagte These. Insbesondere da Microsoft den Support nur noch bis Mai 2024 angibt... Xarmarin ist als Basis oft noch nötig, aber das wird sich in den nächsten Jahren ändern. Ich denke, das auch MAUI mit Pauken und Trompeten untergeht - auch wenn das sicher noch ein paar Jahre dauert. Dieser XAML-Mist ist einfach nix... Aber das ist nur meine persönliche Meinung.

AvaloniaUI ein Community Proejkt...

Was mir persönlich besser gefällt, als der Kram, den Microsoft seit Jaren verzapft. Es wird dauerhaft gepflegt und weiter entwickelt, es gibt eine saubere Code-Base und es nutzt die Skia Rendering Engine... Natürlich steckt nicht so viel Geld dahinter und auch dieses Framework wird, sofern es nicht aus Liebhaberei weiter gepflegt wird, vermutlich nie die Verbreitung erreichen, die nötig wäre, um es richtig groß zu machen.

Sorry. Aber ja Xamarin App Size ist nicht ohne:

Wenn das das einzige Problem von Xamarin wäre, würd ich damit leben. Aber ich bin schon über so viele Bugs gestolpert... das hat echt keinen Spaß gemacht. Anderen ging es wohl genau so...

 

[specialist]

Meine Empfehlung: Flutter. Die Sprache Dart ist jetzt nichts Besonderes, ja, aber einfach und das Flutter Framework ist leicht zu erlernen.
.NET Maui kann ich dir nicht empfehlen. Habe damals die Umstellung von Xamarin auf .NET Maui mitgemacht. Es hat vorher keinen Spaß gemacht, nachher noch weniger und wird vermutlich in Zukunft keinen Spaß machen.
Wenn dir (grafisch) Performance wichtig ist, kommst du wohl um native Entwicklung nicht drum herum. Dann brauchst du für iOS einen Mac. Allerdings, nativ mit iOS und Android anzufangen wird seine gewisse Einarbeitszeit fordern...

 

[Autokiller677]

AvaloniaUI ein Community Proejkt...

Avalonia ist zwar nicht offiziell von MS, aber Community klingt so nach "Freiwillige machen das nach Feierabend".

Da steht aber eine Firma hinter, die Support verkauft und auch noch andere Enterprise-Produkte wie XPF hat, die auf Avalonia aufbauen. Die Firma hat also ein überlebenswichtiges Interesse, dass Avalonia gut läuft und entwickeln daher dran weiter.