Im Internet kursieren bereits zahlreiche Inhalte über die Wahl von Mobile-Technologie. In diesem Artikel möchten wir keine bereits bekannten Fakten wiederholen. Vielmehr möchten wir unsere Erkenntnisse aus jahrelanger Erfahrung in der Entwicklung von Apps für Finanzdienstleister teilen.

Es gibt keine einfachen Pro-und-Kontra-Listen in diesem Artikel. Stattdessen erläutern wir technische und organisatorische Themen, die wir als besonders wirkungsvoll erachten. Anschließend werden wir unsere Empfehlungen für Technologien, die sich für unterschiedliche Anwendungsfälle eignen, vorstellen.

Warum gibt es keine Vergleichstabellen?

Wenn Sie sich bereits mit den Merkmalen mobiler Technologien beschäftigt haben, sind Sie vielleicht schon auf folgende Aussagen gestoßen:

• Native Apps sind sicherer
• Plattformübergreifende Apps lassen sich schneller implementieren.
• Mit hybriden Apps können Sie denselben Code im Web und auf mobilen Geräten nutzen.

Diese Aussagen treffen im Allgemeinen zu. Und gerade ihre Einfachheit ist wertvoll, da sie Ihnen sehr schnell einen Eindruck von den verschiedenen Technologien vermitteln kann.

Aus näherer Betrachtung sollten wir jedoch immer hinzufügen, dass es auf den Kontext ankommt.

Es ist sehr wahrscheinlich, dass sich eine Kamera-App wie Halide nicht schneller als übergreifende Plattform implementieren lässt. Und wenn Sie eine Einkaufslisten-App schreiben, kann jede mobile Technologie sicher genug sein, ohne viel Aufwand.

Wir sehen oft, dass das Vertrauen in diese allgemeinen Aussagen zu einer Substitution von Attributionsansprüchen führt: Die Frage, die Unternehmen wirklich interessiert, ist: „Welche Technologie ist die beste für uns?“

Aber diese Frage ist nicht leicht zu beantworten. Unbewusst werden stattdessen einfachere Fragen gestellt: „Mit welcher Technologie können wir noch mehr Code teilen?“ oder „Welche Technologie hat die übersichtlichste Benutzeroberfläche?“

Deshalb betrachten wir bei der Wahl einer Technologie zuerst die Anforderungen näher und prüfen dann, welche Technologie besser passt. Konkret untersuchen wir in diesem Artikel, wie sich diese Anforderungen auf die vergleichende Kapitalrendite (ROI) verschiedener Technologien auswirken.

Das Kernthema der Wahl mobiler Technologien ist die Wiederverwendung von Code. Wenn Sie eine App nativ entwickeln, können Sie sicher sein, dass Sie den größtmöglichen Nutzen aus jeder Plattform ziehen, auf der sie ausgeführt wird. Der Nachteil ist, dass Sie zwei völlig getrennte Codebasen haben. Alle plattformübergreifenden oder hybriden Technologien sind so ausgelegt, dass Code wiederverwendet werden kann (oder dass es „eine Codebasis“ gibt).

Solange Sie „denselben Code“ schreiben, wird geteilter Code die Kosteneffizienz erhöhen. Aber in einigen Fällen kann es jedoch sein, dass Sie am Ende mehr Code oder komplexeren Code haben.

Verwendung der Plattform-API

Es überrascht nicht, dass alle Plattformfunktionen über native Tools zur Verfügung gestellt werden. Nicht-native Technologien bieten gleichwertige Funktionen für gängige Anwendungsfälle, bei denen der fehlende direkte Zugriff auf die Plattform-API kein Problem darstellt.

Aber keine nicht-native Technologie bietet eine vollständige Abdeckung. Wenn Sie eine Funktionalität benötigen, die das Framework Ihrer Wahl nicht abdeckt, muss die App nativen Code für jede Plattform schreiben, plus weiteren Code zur „Überbrückung“ der nativen Funktionalität für die Verwendung innerhalb des nicht-nativen Frameworks.

Dies bedeutet nicht nur, dass Sie effektiv drei Codebasen anstatt einer haben, sondern auch, dass es sich um komplexeren Code handelt, der schwieriger zu entwickeln und zu testen ist, da er in zwei oder möglicherweise drei verschiedenen Sprachen geschrieben ist und in einer Vielzahl von Umgebungen getestet werden sollte.

Dasselbe Argument gilt übrigens auch für die Integration von Dienstleistungen Dritter. Einige bieten möglicherweise SDKs für gängige Frameworks wie Flutter und React Native an, aber grundsätzlich konzentrieren sich die SDKs zunächst auf ihre native API.

Beispiele (Postausgang):

• Sichere Speicher- und biometrische APIs sollten aus nativem Code überbrückt werden.
• Die Integration von Siri und Widgets auf iOS muss in Swift erfolgen.
• Web-Ansichten, die von Hybrid-Apps verwendet werden, können nicht im Hintergrund ausgeführt werden, weshalb eine benutzerdefinierte Lösung erforderlich ist.

Unterschiedliche Plattformen in Einklang bringen

Auch wenn es offensichtlich ist: Unterschiedliche Plattformen haben unterschiedliche Eigenschaften. Selbst ähnliche Funktionen können je nach Plattform unterschiedlich ausgeführt werden.

Beim Schreiben von Code, der für jeden Plattformtyp bestimmt ist, müssen Sie nur Szenarien berücksichtigen, die auf dieser Plattform vorkommen können. Shared Code hingegen kann komplexer sein, da er für alle Plattformen geeignet ist.

Wie eine zweckmäßige Architektur auch die Bedürfnisse des Teams und der Organisation berücksichtigt, haben wir in einem früheren Artikel erörtert. Ebenso kann es von der Organisation abhängen, welche Technologie die richtige Wahl ist.

Organisatorische Überlegungen sind vielschichtiger, als wir es in diesem Artikel angemessen darstellen können. Um jedoch zu verdeutlichen, wie sich dies auf die Technologie auswirkt, schauen wir uns zwei Enden eines Spektrums an:

• Ein kleines Start-up-Unternehmen, das mit Prepaid- oder Kreditkarten einen neuen und innovativen „bankähnlichen“ Service anbieten möchte
• Eine etablierte Bank mit bestehendem Kundenstamm, mobiler App und Online-Banking. Beide wollen ihre App modernisieren.

Wenn es um die Wahl einer Mobile-Technologie geht, kommt es, wie wir eingangs sagten, stets „darauf an“. Wenn Sie uns jedoch eine gewisse Verallgemeinerung zugestehen, empfehlen wir auf Basis unserer Erfahrung folgendes:

Banking-Apps

Wir empfehlen Banken, eine native App zu entwickeln oder zumindest einen minimalen Kern der App nativ zu halten. Sie haben viele verschiedene Berührungspunkte mit nativen APIs, deren Verwaltung durch Framework-Plugins sowohl riskant als auch teuer sein kann.

Es ist immer noch möglich, Code unter Beibehaltung eines nativen Kerns wiederzuverwenden:

• Der native Kern ist für die Sicherheit und die Gesamtkoordination der App verantwortlich
• App-Logik kann mit einer Technologie wie Kotlin-Multiplatform gemeinsam genutzt werden.
• Die gemeinsame Nutzung von UI-Code ist mit Web-Technologien oder Compose Multiplatform immer noch möglich – allerdings müssen Sie eine klare Strategie erarbeiten und festlegen, wo und wie diese eingesetzt werden sollen. Aktuell empfehlen wir, diese Technologien als Sprungbrett hin zu vollständig nativen Apps zu betrachten und gleichzeitig die anfänglichen Kosten und die Zeit bis zu Markteinführung zu reduzieren.

Für Banken, die von einer anderen Technologie migrieren, bietet der native Kern die beste Möglichkeit, das Migrationsrisiko zu steuern und die Migration so schrittweise wie möglich zu gestalten.

• 80 Prozent der Top-Banking-Apps (in Großbritannien) sind nativ geschrieben. Dies gilt sowohl für etablierte als auch für neue Banken. Der Rest verwendet React Native oder hybride Technologien.

Weitere Finanz-Apps

Für Apps, die nicht die Komplexität einer vollwertigen Banking-App aufweisen und sich auch nicht an die strengeren Vorschriften eines Zahlungsdienstleisters halten müssen, ist die Bandbreite der Möglichkeiten größer.

Wenn Sie eine reine App-Dienstleistung anbieten oder erwarten, dass Ihre Kunden Ihre App häufig verwenden, können plattformübergreifende Frameworks wie Flutter oder React Native eine gute Lösung sein.

Wenn Sie zusätzlich über ein Webportal verfügen, könnte eine hybride Lösung gut für Sie geeignet sein – vor allem, wenn die Interaktionen nur selten oder in geringem Umfang stattfinden.