Od osobnej aplikacji Flutter do dwóch aplikacji beta w Hotwire Native.

Klient miał już dojrzały produkt Rails i osobną aplikację Flutter. Celem nie było ponowne napisanie każdego ekranu w kolejnym odizolowanym kliencie. Chodziło o sprawdzenie architektury web-first, w której Rails nadal odpowiada za zachowanie produktu, a iOS i Android zapewniają natywną nawigację oraz wybrane możliwości urządzeń.

Uwaga o poufności: klient i produkt zostały zanonimizowane. Architektura, proces pracy i zakres dostarczonych bet pochodzą z rzeczywistego projektu; szczegóły identyfikujące oraz prywatne materiały zostały usunięte.

Osobna implementacja mobilna tworzy drugą ścieżkę rozwoju produktu

Klient wieloplatformowy może być właściwym wyborem, ale w tym produkcie oznaczał, że zachowanie istniejące już w Rails trzeba było zrozumieć i odtworzyć w osobnej aplikacji. Logowanie, nawigacja i zmiany produktu zyskiwały kolejną powierzchnię implementacji.

Migracja sprawdzała inną granicę: zachować w Rails te elementy produktu, które dobrze działają w webie, a kod natywny dodawać tam, gdzie wymagało go doświadczenie mobilne.

Dlaczego Hotwire Native pasował do produktu Rails

Hotwire Native wyświetla HTML dostarczany przez serwer w natywnej powłoce i zmienia nawigację linkami w przejścia ekranów właściwe dla platformy. Bridge Components łączą kontrolery Stimulus w Rails z odpowiednikami w Swift lub Kotlinie.

Dzięki temu migracja mogła być stopniowa: ekran pozostawał web-first, zyskiwał natywne sterowanie przez bridge albo stawał się w pełni natywny, gdy wymagała tego jakość interakcji lub API urządzenia.

Agenci pisali kod; kontekst sprawił, że ten kod mógł działać

Claude Code i Cursor analizowały zachowanie aplikacji Flutter, implementowały klientów Swift i Kotlin oraz pisały testy. Dostarczałem im model produktu: starą aplikację, zachowanie Rails, materiały z Figmy klienta, ograniczenia techniczne, zamknięte zadania i kryteria akceptacji.

Następnie budowałem każdą wersję, testowałem ją, porównywałem interfejs z Figmą i przekazywałem konkretne obserwacje do kolejnej iteracji. Użyteczną jednostką nie był prompt, lecz kontrolowana pętla od dowodów przez implementację do walidacji.

Od onboardingu do uwierzytelniania, nawigacji i powiadomień

Aplikacje rosły pionowymi fragmentami obejmującymi całą drogę od pierwszego uruchomienia i logowania po codzienną nawigację, powiadomienia oraz wybrane interakcje natywne. Praca musiała zachować znane użytkownikom zachowanie produktu, a jednocześnie przenosić odpowiedzialność w stronę Rails tam, gdzie taka granica miała sens.

Zespół Rails dostarczał webową część Bridge Components, a ja kierowałem budową i walidacją ich natywnych odpowiedników na iOS oraz Androidzie. Dzięki temu decyzje produktowe pozostawały blisko Rails, ale aplikacje mobilne nie stawały się jedynie generycznymi kontenerami webowymi.

Budowa w czasie, gdy ekosystem nadal szybko się zmieniał

Projekt powstawał, gdy Hotwire Native i ekosystem Bridge Components szybko się rozwijały. Tym ważniejsze były małe eksperymenty, research w kodzie źródłowym, jawne kontrakty między webem i warstwą natywną oraz bezpośrednia weryfikacja na obu platformach.

Przykłady z frameworka były punktem wyjścia, a nie dowodem, że integracja specyficzna dla produktu działa poprawnie.

Wygenerowany kod był akceptowany dopiero, gdy działał

Obie aplikacje miały testy automatyczne, a ja osobiście budowałem i sprawdzałem przepływy na iOS oraz Androidzie. Zachowanie wizualne porównywałem z ekranami Figmy dostarczonymi przez klienta, a osoby z zespołu klienta testowały również przepływy produktu.

Logowanie, nawigacja, sesja, WebView i powiadomienia były poprawiane na podstawie obserwowanego działania. Wynik agenta pozostawał kandydatem na implementację, dopóki nie potwierdziły go buildy, testy, porównanie z projektem i feedback produktowy.

Dwie wiarygodne bety, bez dopisywania wygodnego zakończenia

Oba natywne klienty osiągnęły etap beta. Aplikacja iOS była dystrybuowana przez TestFlight, przeszła szerokie testy i była blisko gotowości do wydania; Android pozostał w becie.

Decyzja o publikacji należała do klienta i nie otrzymałem ostatecznego powodu, dla którego żadna aplikacja nie została wydana. Rezultatem opisywanym tutaj jest dostarczona możliwość mobilna i powtarzalny proces pracy, a nie wdrożenie produkcyjne.