Ich entwickelte beide Versionen allein und stimmte das Verhalten sowie den Release-Zeitplan der Android-App auf die iOS-App ab.
Die Anwendung ist in Kotlin mit AndroidX-Views, Hilt, Coroutines und einer Deep-Link-Policy auf Android-11-Niveau geschrieben, die das koreanische Bezahl- und Banking-Ökosystem sauber durchläuft. Die Native-Shell trägt den Storefront-Traffic über eine WebView-Surface mit derselben Konfiguration wie bei Certilife.
Der schwierige Teil einer koreanischen Commerce-Shell ist alles rund um das Bezahlen. Seit Android 11 muss eine App vorab deklarieren, welche externen Apps sie überhaupt sehen will — also wird die Shell mit einer expliziten Allowlist für die Bezahl- und Banking-Apps des Landes ausgeliefert. Feuert der Storefront einen Bezahl-Intent, parst ihn die Shell, startet die passende App, wenn sie installiert ist, und weicht andernfalls auf den Store-Eintrag aus — die Schleife „erst installieren, dann bezahlen", die koreanische Payment-Gateways erwarten, erledigt, ohne dass die Web-Schicht etwas davon merkt.
Die Token-Brücke und die Anruf-Brücke spiegeln die iOS-Verträge eins zu eins, die WebView stellt sich dem Server auf dieselbe Weise vor, und selbst das randlose Inset-Handling wurde mit dem Safe-Area-Verhalten von iOS als Referenz geschrieben. Der Foto-Upload aus dem Storefront öffnet einen nativen Auswahldialog — Kamera oder Galerie —, verdrahtet über Androids Scoped-File-APIs, der regelkonforme Weg, ein Web-Datei-Eingabefeld zu bedienen. Und ein Schalter, den es nur im Debug-Build gibt, führt die Shell ohne Rebuild durch die Serverumgebungen.