Eine Codebasis, drei Plattformen

Die meisten App-Projekte scheitern nicht an der Technik, sondern an der Frage davor. Nämlich, ob es überhaupt eine App braucht. Ich stelle diese Frage im Erstgespräch, und in etwa der Hälfte der Fälle ist die Antwort nein. Eine gute mobile Website ist schneller da, kostet weniger und muss nicht durch eine Store-Prüfung.

Wenn die Antwort ja ist, dann meistens aus einem dieser Gründe: Nutzer greifen täglich oder wöchentlich zu, es braucht Push-Benachrichtigungen, es muss offline funktionieren, oder Kamera und andere Gerätefunktionen stehen im Zentrum.

Wie ich baue

Aus einer Codebasis für alle Plattformen. Der Kern ist Web-Technologie, darum liegen native Brücken für die Dinge, die eine App ausmachen: Kamera, Haptik, Push, Anmeldung über Apple, Google oder Facebook, Zahlungen. Für iOS und Android nutze ich Capacitor, für Desktop-Anwendungen Tauri.

Das ist eine bewusste Entscheidung und keine Notlösung. Zwei getrennt entwickelte native Apps bedeuten zwei Entwicklungen, zwei Testzyklen und dauerhaft zwei Baustellen bei jeder Änderung. Für Fach- und Geschäftsanwendungen rechtfertigt der Unterschied im Ergebnis diesen Aufwand selten. Wo er es tut, bei 3D, Spielen oder schwerer Verarbeitung auf dem Gerät, sage ich dir das, statt dir mein Werkzeug zu verkaufen.

Ein Nebeneffekt, der im Alltag mehr wiegt als gedacht: Inhaltliche und funktionale Änderungen im Web-Kern sind sofort auf allen Geräten da, ohne neues Store-Release und ohne dass Nutzer ein Update installieren müssen. Nur Änderungen an den nativen Teilen brauchen den Weg durch den Store.

Zwei eigene Apps als Beleg

events ist ein Planer für Feiern und Vereinsveranstaltungen. Die App gibt es für iOS und Android, gebaut mit Capacitor auf einem Laravel-Backend, mit Kamera für Fotos, Anmeldung über Google und Apple, Zahlungen über Stripe und Haptik-Feedback. Gäste können zusagen, Mitbring-Listen führen und Fahrgemeinschaften bilden, ohne sich zu registrieren.

zeit ist Zeiterfassung und Abrechnung für Selbstständige, mit einer Desktop-Anwendung auf Tauri-Basis und einer iOS-Anbindung. Beide laufen produktiv, mit echten Nutzern und regelmäßigen Releases.

Diese beiden Projekte sind der Grund, warum ich App-Entwicklung überhaupt anbiete. Ich habe sie nicht gebaut, um sie als Referenz zu zeigen, sondern weil ich die Werkzeuge selbst gebraucht habe. Was dabei gelernt wurde, an Store-Prozessen, Zertifikaten, Push-Diensten und den Eigenheiten beider Plattformen, steckt in jedem Kundenprojekt.

Der Ablauf und was er kostet

Nach dem Erstgespräch steht der Schnitt: welche Plattformen, welche Funktionen in Version eins, welche später. Dann ein klickbarer Prototyp auf dem echten Gerät, denn auf dem Handy fühlt sich vieles anders an als in einem Entwurf am großen Bildschirm. Danach Entwicklung in Zwei-Wochen-Schritten mit Builds, die du selbst installieren und ausprobieren kannst.

Eine Zahl ohne Gespräch wäre geraten. Deutlich günstiger wird es in jedem Fall, wenn bereits eine Webanwendung existiert, die als Grundlage dient, weil dann der Kern schon steht. Wenn du erst am Anfang stehst, ist oft genau das der richtige Weg: zuerst die Webanwendung, die im Browser läuft und beweist, dass das Konzept trägt. Die App kommt danach, auf derselben Basis.