Mobile-Entwicklung & Rettung
Manche Mobile-Projekte müssen gebaut werden. Mehr von ihnen müssen gerettet werden — vor verrottenden Native-Modulen, dem App-Store-Limbo oder einer Framework-Entscheidung, die vor einem Jahr aufgehört hat, richtig zu sein.
Wann Sie mich anrufen
- Ihre React-Native-App ertrinkt in Native-Modul-Problemen, und das Team hängt seit drei Wochen am selben Upgrade fest.
- Sie stecken in einer App-Store-Ablehnungsschleife, und jede neue Einreichung verbrennt einen weiteren Review-Zyklus.
- Sie wägen einen Framework-Wechsel mitten im Projekt ab und brauchen jemanden, der das wirklich gemacht hat — keinen Vergleichsartikel.
- Sie brauchen eine App für Lager- oder Außendienst-Betrieb — die Sorte, bei der ein falscher Zustandsübergang echten Bestand kostet.
Was ich mache
- Framework-Entscheidungen nach dem Kriterium "langweilig gewinnt" — der Stack, den Ihr Team in zwei Jahren noch warten kann, schlägt den, der dieses Quartal aufregend ist.
- Migrationen mitten im Projekt — ich habe eine laufende App in sechs Wochen von React Native zu Flutter umgezogen, ohne den Release-Plan einzufrieren.
- App-Store-Prozessmanagement — Review-Notizen, Antworten auf Ablehnungen und die Metadaten-Details, die Builds tatsächlich durch die Prüfung bringen.
- FSM-basierte Operations-Apps — explizite Zustandsmaschinen für Abläufe, in denen "ungefähr richtig" Geld verliert.
Zahlen statt Adjektive
Storks Mobile-Seite: eine laufende App, mitten im Projekt in sechs Wochen von React Native zu Flutter migriert, drei Apple-Ablehnungen gelöst und freigegeben, 1.800 Beta-Tester an Bord, und eine Lager-App, angetrieben von einer Zustandsmaschine mit 45 Zuständen, die mit einer Zoll-API spricht.
Notizen aus der Praxis
Wo wir anfangen
Discovery: ein Codebase-Audit plus eine Migrations-Risikokarte — welche Native-Module sich wehren werden, wo die Geschäftslogik wirklich lebt und was der realistische Zeitplan ist. Go/No-Go inklusive; manchmal lautet die Antwort "nicht migrieren".