Android-App modernisieren oder neu entwickeln?
Jedes Release dauert länger. Eine kleine Änderung verursacht an anderer Stelle Fehler. Die Person, die die schwierigen Teile kannte, ist nicht mehr im Team. Bevor Sie eine Neuentwicklung beauftragen, sollten Sie klären, welche Probleme tatsächlich einen Ersatz erfordern.
Mein Ausgangspunkt
Ich würde zuerst prüfen, ob sich die bestehende App stabilisieren und in sinnvollen Schritten verbessern lässt. Ein Ersatz wird dann plausibler, wenn ein klar abgegrenzter Teil die Produktanforderungen mit vertretbarem Aufwand nicht mehr erfüllen kann. Dazu gehört ein tragfähiger Plan für den Übergang und die Betreuung bestehender Nutzer.
Eine ältere Programmiersprache oder ein älteres UI-Framework reicht als Begründung allein nicht aus.
Was blockiert das Produkt tatsächlich?
„Die App ist Legacy“ beschreibt ihre Geschichte. Daraus ergibt sich noch nicht, ob die nächste Investition in die Oberfläche, den Build, die Backend-Anbindung oder eine schwierige Übergabe fließen sollte.
Nehmen Sie eine konkrete Änderung, die unerwartet aufwendig war. Was hat Zeit gekostet: das Verständnis des Verhaltens, langsame Builds, Regressionen oder die Veröffentlichung? Hilfreich sind ein fehlerhafter Nutzerablauf, ein Pipeline-Durchlauf, ein Crash-Bericht oder die Arbeitsschritte für eine einzelne Funktion.
Wenn vor allem Builds und Tests zu langsam Rückmeldung geben, sollten Sie das untersuchen, bevor Sie Produktcode ersetzen. Build- und Testverbesserungen lassen sich getrennt von einer Neugestaltung der App angehen.
Den Umfang vergleichen, nicht nur die Technologie
Es gibt mehr Möglichkeiten, als alles unverändert zu lassen oder neu anzufangen. Die Tabelle ist eine Gesprächsgrundlage, keine automatische Entscheidung.
| Ansatz | Wann er infrage kommt | Was zuerst zu klären ist |
|---|---|---|
| Bestehende App stabilisieren | Einige Fehler oder Release-Probleme blockieren eine ansonsten brauchbare Anwendung. | Kann das Team die Fehler reproduzieren und das betroffene Verhalten durch geeignete Prüfungen absichern? |
| Schrittweise modernisieren | Das Produkt erfüllt seinen Zweck, aber Änderungen sind aufwendig und einzelne Abhängigkeiten, Module oder Ansichten brauchen Aufmerksamkeit. | Lässt sich ein Bereich verbessern und veröffentlichen, ohne das gesamte System gleichzeitig zu verändern? |
| Einen abgegrenzten Teil ersetzen | Eine bestimmte Schnittstelle, Integration oder die Oberfläche muss grundlegend verändert werden. | Was bleibt bestehen, und wie erhält der Ersatz das Verhalten, auf das Nutzer angewiesen sind? |
| Die Anwendung neu entwickeln | Das Team kann begründen, weshalb die aktuelle Grundlage die vereinbarten Anforderungen mit vertretbarem Aufwand nicht erfüllen kann. | Sind Umfang, Betreuung der bisherigen App, Nutzermigration und Prüfung des Ersatzes geklärt? |
Eine repräsentative Funktion kann helfen, den Ansatz zu prüfen. Wählen Sie etwas, das die problematischen Schnittstellen tatsächlich berührt. Ein hübscher Einstellungsbildschirm sagt wenig über eine unzuverlässige Geräteverbindung aus.
Zwei Beispiele aus meiner Arbeit
J&C Bachmann: Modernisierung während der Weiterentwicklung
Die vorhandene Java-Anwendung musste weiterentwickelt und schrittweise auf Kotlin umgestellt werden. Meine Arbeit umfasste die Modernisierung und Erweiterung der Android-App sowie Arbeiten am Node.js-Backend und am Vue.js-Portal.
Das ist ein Beispiel dafür, ein etabliertes Produkt zu verbessern und gleichzeitig an seiner umgebenden Plattform zu arbeiten. Daraus folgt nicht, dass jede Java-Anwendung ersetzt werden muss. Zum Projekt J&C Bachmann (Englisch).
Zuriga: Eine neue Oberfläche innerhalb eines bestehenden Produkts
Bei Zuriga übernahm ich eine bestehende Kotlin-Multiplatform-App für die Verbindung mit einer Kaffeemaschine. Ich baute die Oberfläche für Android und iOS mit Compose Multiplatform neu auf und verbesserte die BLE-bezogene Geschäftslogik, in Zusammenarbeit mit dem Designteam.
Der Umfang war konkret: eine neue Oberfläche und Verbesserungen der Maschinenkommunikation innerhalb eines bestehenden Produkts. Die pauschale Bezeichnung „Neuentwicklung“ würde diese wichtigen Grenzen verschleiern. Zum Projekt Zuriga (Englisch).
Diese Beispiele sind keine Zeit- oder Kostenschätzung für Ihre App. Sie zeigen unterschiedliche Umfänge einer Veränderung.
Was beim Ersatz berücksichtigt werden muss
Auch eine neue Codebasis muss mit vorhandenen Nutzerkonten, gespeicherten Daten, Geräteverhalten und Integrationen umgehen. Klären Sie vor dem Vergleich von Angeboten, wie diese Bereiche den Übergang überstehen.
- Bestehendes Verhalten: Welche Abläufe müssen erhalten bleiben, einschließlich der nicht dokumentierten Sonderfälle?
- Daten und Integrationen: Was muss mit Backend, lokalem Speicher, Authentifizierung und verbundener Hardware kompatibel bleiben?
- Laufende Betreuung: Wer behebt dringende Fehler in der bisherigen App, während am Ersatz gearbeitet wird?
- Veröffentlichung und Wiederherstellung: Wie prüft das Team den Übergang, erkennt Probleme und reagiert auf ein fehlgeschlagenes Update?
Lassen Sie sich neben einer Schätzung auch Annahmen und Ausschlüsse nennen. „App neu bauen“ ist kein brauchbarer Leistungsumfang, wenn Migration und laufende Betreuung fehlen.
Erfordert der Wechsel zu Compose eine komplette Neuentwicklung?
Nein. Die offizielle Anleitung zur Compose-Migration beschreibt einen schrittweisen Ansatz, bei dem Views und Compose nebeneinander bestehen. Teams können neue Ansichten mit Compose entwickeln und vorhandene Oberflächen nach und nach migrieren. Das ermöglicht eine schrittweise UI-Migration, entscheidet aber noch nicht über Architektur oder Wirtschaftlichkeit Ihres Vorhabens.
Was Sie für eine erste Prüfung vorbereiten können
Eine perfekte Spezifikation ist nicht nötig. Diese Fragen machen das erste Gespräch konkreter:
- Was macht die App, und welche Nutzer oder Geräte sind auf sie angewiesen?
- Welche Änderung oder welcher Fehler verursacht die größten Schwierigkeiten? Nennen Sie ein konkretes Beispiel.
- Kann das Team die aktuelle Version aus dem Repository bauen und veröffentlichen?
- Welche Backend-Dienste, Hardwareverbindungen und lokalen Daten müssen weiterhin funktionieren?
- Welche Produktanforderung steht als Nächstes an, und welche Termin- oder Budgetgrenzen sind bekannt?
- Wer kann das aktuelle Verhalten erklären und das Ergebnis später betreuen?
Eine hilfreiche Prüfung trennt unmittelbare Blockaden von längerfristigen Verbesserungen, benennt offene Fragen und grenzt einen ersten überprüfbaren Arbeitsschritt ab. Vereinbaren Sie vorher Umfang und erwartete Ergebnisse der Prüfung.
Sie möchten Ihre Android-App unabhängig prüfen lassen?
Ich biete gezielte Reviews und praktische Unterstützung bei der Modernisierung an. Beschreiben Sie kurz, was die App macht und wo es hakt. Das reicht für ein erstes Gespräch.