iOS i Android naraz: dlaczego prawie nikt już nie płaci za dwie aplikacje (i kiedy natywna ma sens)

Decyzja już zapadła: aplikacja ma być mobilna, w obu sklepach, na telefonach z iOS i Androidem od pierwszego dnia. I właśnie wtedy przychodzi wycena, w której „iOS” i „Android” to dwie osobne pozycje, każda z własnym budżetem i harmonogramem. Rachunek mnoży się przez dwa, zanim powstał choćby jeden ekran.

Poradniki budżetowe nie pomagają: podają widełki rzędu 40–300 tys. zł za aplikację mobilną i hasło „wspólna technologia wychodzi 30–40% taniej”, ale nie pokazują, z czego ten procent się bierze ani co konkretnie jest w cenie. Trudno na takich liczbach cokolwiek zaplanować, a jeszcze trudniej porównać dwie oferty, które obie piszą „aplikacja na iOS i Android”.

W tym wpisie rozkładamy temat na godziny: jak dziś buduje się na dwa systemy naraz, które godziny są wspólne, a które trzeba by płacić podwójnie, i w których sytuacjach dwie osobne aplikacje natywne naprawdę się bronią. U nas każda praca ma jedną, publiczną stawkę: 600 zł netto za godzinę, więc cały rachunek da się prześledzić do końca.

Skąd się wzięło płacenie za dwie aplikacje

Jeszcze kilka lat temu ten podwójny rachunek miał techniczne uzasadnienie. Apple ma swój język programowania (Swift), Google swój (Kotlin), więc aplikacja „na oba systemy” oznaczała dwa osobne projekty: każdy ekran projektowany raz, ale pisany dwa razy, każda poprawka nanoszona dwa razy, testy prowadzone na dwóch wersjach, które nigdy nie były identyczne. Stąd biorą się widełki 40–300 tys. zł i stąd oferty, w których iOS i Android to dwie faktury.

Od dobrych kilku lat standardem jest inna droga: jedna wspólna baza kodu, budowana w technologii wieloplatformowej, która działa na obu systemach naraz. Piszemy raz, a użytkownik iPhone-a i użytkownik Androida dostają tę samą aplikację, każdą w swoim sklepie. Dla zdecydowanej większości produktów firmowych i startupowych to nie jest kompromis ani proteza – to domyślny sposób pracy, także u nas.

Co naprawdę jest wspólne, a co osobne

Kluczem do uczciwej wyceny jest proporcja: ile godzin dotyczy obu platform naraz, a ile trzeba wykonać dla każdej osobno. W typowej aplikacji firmowej wygląda to tak:

• Wspólne – zdecydowana większość godzin. Ekrany, logika, konta użytkowników, listy i formularze, koszyk, płatności, powiadomienia, połączenie z serwerem. To jest właściwy produkt i powstaje raz.
• Osobne, ale drobne. Różnice systemowe: wygląd systemowych okien, zgody na aparat, lokalizację czy powiadomienia, zachowanie przycisku wstecz. To pojedyncze godziny na dopasowanie, nie drugi projekt.
• Osobne zawsze. Przygotowanie wersji do dwóch sklepów: konta dewelopera, opisy, grafiki, zgodność z wymaganiami Apple i Google. Ta praca istnieje niezależnie od technologii – nawet dwie aplikacje natywne muszą przez nią przejść.

Proporcja nie wynosi 50/50, tylko coś bliżej 90/10. I właśnie dlatego mnożenie całej wyceny przez dwa jest sygnałem ostrzegawczym: podwojeniu ulega tylko wąski wycinek pracy, a nie produkt.

Rachunek w godzinach: raz czy dwa razy

Pierwsza działająca wersja produktu, czyli MVP, to u nas typowo 30 h, czyli 18 000 zł netto – i przy jednej wspólnej bazie kodu ta liczba dotyczy obu platform naraz. Wariant mobilny ze sklepami dokłada do zakresu godziny na systemowe zgody i przygotowanie wydań, ale to są pojedyncze godziny, nie osobny projekt; dokładny przedział podajemy po discovery, na piśmie, przed startem pracy.

Teraz ten sam zakres jako dwie aplikacje natywne. Większość z tych 30 godzin to ekrany i logika, które trzeba by napisać i przetestować dwa razy – rachunek rośnie orientacyjnie do 50–55 h, czyli 30 000–33 000 zł netto zamiast 18 000 zł. Rynkowe hasło „30–40% taniej” nagle przestaje być marketingiem: widać, z których godzin się bierze. Tyle że to dopiero początek różnicy.

Prawdziwy koszt dwóch baz kodu ujawnia się po wdrożeniu. Każda nowa funkcja, każda poprawka błędu i każde dostosowanie do nowej wersji systemu wykonywane jest dwukrotnie, w dwóch językach, często przez dwie różne osoby. Przy jednej bazie ta sama zmiana to jedna praca i jedna pozycja w logu. W perspektywie 2–3 lat życia aplikacji ta różnica potrafi przerosnąć koszt samej budowy.

wt · −3 h · ekran historii zamówień z filtrem po statusie i szczegółami pozycji – jedna implementacja, ta sama baza kodu działa na iOS i Androidzie

Kiedy dwie aplikacje natywne mają sens

Uczciwie: są produkty, przy których wspólna baza kodu przestaje wystarczać i osobne wersje natywne bronią się rachunkiem. To zwykle jedna z tych sytuacji:

• Ciężka grafika w czasie rzeczywistym. Gry, rozbudowane animacje 3D, edycja wideo z podglądem na żywo – tu różnice między systemami są zbyt duże, żeby je ukrywać pod wspólną warstwą.
• Intensywna praca ze sprzętem. Przetwarzanie obrazu z kamery na żywo, nietypowe czujniki, urządzenia podpinane kablem lub po Bluetooth w trybach, których wspólna technologia nie obsługuje wprost.
• Skrajne wymagania wydajności. Aplikacja, w której każde opóźnienie interfejsu jest problemem biznesowym, np. narzędzie pomiarowe albo muzyczne.
• Produkt z założenia na jedną platformę. Aplikacja tylko na iPady dla zespołu w terenie to jedna wersja natywna, nie dwie – i wtedy natywnie bywa najprościej.

Jeśli Twój produkt trafia w któryś z tych punktów, usłyszysz to od nas wprost na discovery, razem z godzinami przy każdej pozycji: która część kodu musi powstać dwa razy i co to znaczy dla estymaty. Decyzję podejmujesz na liczbach, nie na wierze w technologię. A dla kont, list, formularzy, koszyków, rezerwacji i płatności – czyli dla większości aplikacji, o które pytają firmy i founderzy – wspólna baza wygrywa bez dyskusji.

Zanim zapłacisz za jakąkolwiek wersję: makieta

Niezależnie od technologii, najtańszym krokiem pozostaje sprawdzenie pomysłu przed napisaniem kodu. Klikalna makieta to 10 h, czyli 6 000 zł netto: wygląda na telefonie jak prawdziwa aplikacja, można ją dać do klikania przyszłym użytkownikom i inwestorom, a każdy wniosek z tych rozmów jest tańszy niż przebudowa gotowego produktu. Dopiero na podstawie makiety powstaje estymata MVP – i decyzja, czy pierwsza wersja w ogóle musi być w sklepach, czy wystarczy jej przeglądarka. O tym wyborze pisaliśmy osobno; tu zostawmy jedno zdanie: jeśli produkt żyje z powiadomień i pracy bez internetu, mobilna wspólna baza od razu jest właściwą drogą.

Jak to policzyć u nas

Proces jest ten sam co przy każdej pracy: po płatności w 24 godziny odzywa się inżynier prowadzący, na discovery (30 minut) opowiadasz, co aplikacja ma robić i dla kogo, a estymatę godzin dostajesz na piśmie do akceptacji przed startem. Postęp widzisz w logu panelu: opis, liczba godzin, efekt do kliknięcia. Akceptujesz pracę co 2–8 godzin, więc kierunek koryguje się na bieżąco, nie po fakturze.

Godziny kupujesz na saldo, a przy większych pakietach saldo rośnie szybciej niż wpłata: za 30 opłaconych godzin masz na koncie 31,75 h, za 60 – 67,25 h. Niewykorzystane godziny nie przepadają, więc publikacja w sklepach, poprawki po pierwszych opiniach użytkowników czy kolejne funkcje schodzą z tego samego salda – bez nowej umowy i nowej wyceny.

Formalności: poufność obowiązuje od pierwszej wiadomości, wprost z regulaminu, bez podpisywania czegokolwiek. Pokazy i testy jadą na danych syntetycznych, kod i pełne prawa majątkowe są w 100% Twoje po każdym opłaconym etapie – także wtedy, gdy za rok zechcesz rozwijać aplikację z kimś innym. Fakturę VAT wystawia aveneo, software house działający od 2008 roku, którego marką jest uncrn.

Mamy sprawdzony pomysł i klientów, którzy czekają. Aplikacja ma działać na iOS i Androidzie od pierwszego dnia: konto, rezerwacje, płatności, powiadomienia. Dostaliśmy ofertę rozpisaną na dwa osobne projekty i budżet nam się rozjechał – da się to zrobić raz, a nie dwa razy?

← wszystkie wpisy