Jest 2026 rok. W przeglądarce da się zrobić prawie wszystko: od paneli magazynowych po narzędzia inżynierskie. A mimo to, gdy tworzysz prosty kalkulator kalorii w SPA — serio, formularz + trochę matematyki — Apple potrafi zamienić to w drogę przez mękę, jakbyś pisał system operacyjny, a nie aplikację do policzenia, czy obiad miał 650 czy 900 kcal.
Bo w świecie Apple rzeczy proste muszą być trudne. Szczególnie jeśli mogłyby działać bez App Store.
Zwykły kalkulator kalorii: 3 pola, 1 wynik, 0 powodów na App Store
Wyobraź sobie normalny scenariusz:
Masz SPA w React:
- wpisujesz wagę, wzrost, wiek,
- wybierasz aktywność,
- klikasz „Oblicz”,
- dostajesz kalorie na utrzymanie / redukcję.
Koniec. Proste. Szybkie. Aktualizacja? Wrzucasz nowy build i działa u wszystkich.
W normalnym świecie.
W świecie Apple pojawia się pytanie:
„A czy na pewno chcesz, żeby to było łatwe?”
Instalacja PWA na iPhonie: „zgadnij, gdzie schowaliśmy guzik”
Na Androidzie user dostaje komunikat: „Zainstalować aplikację?” — klika i po sprawie.
Na iOS? Nie, nie, nie. Tu jest „premium experience”:
- Użytkownik musi w ogóle wiedzieć, że istnieje coś takiego jak instalacja PWA.
- Potem musi kliknąć Udostępnij.
- Następnie znaleźć magiczną opcję „Dodaj do ekranu początkowego”.
- I wreszcie zatwierdzić.
To nie jest proces instalacji. To jest escape room.
A ty, jako developer, kończysz z overlayem pokazującym palcem ikonkę Share, bo inaczej user myśli, że aplikacja „nie da się zainstalować”.
Po co wam web, skoro możecie zrobić „prawdziwą aplikację”?
Najlepsze jest to, że kalkulator kalorii to idealny przykład czegoś, co web ogarnia perfekcyjnie:
- działa online,
- nie potrzebuje uprawnień,
- nie potrzebuje GPS,
- nie potrzebuje kamer,
- nie potrzebuje tła,
- nie potrzebuje 100MB zasobów.
To jest formularz, kilka wzorów, trochę UI.
Ale Apple patrzy na to i mówi:
„Zrób to natywnie.”
Czyli:
- Xcode,
- certyfikaty,
- provisioning,
- review,
- publikacja,
- aktualizacje z opóźnieniem,
- i najlepiej jeszcze „subskrypcja”, bo wtedy jest sens ekonomiczny.
Tylko po to, żeby ktoś mógł policzyć, ile kalorii ma owsianka.
Deweloper SPA: człowiek, który chciał dobrze, a wyszło jak zawsze
Jeśli tworzysz SPA, to chcesz:
- szybko iterować,
- poprawiać UX co tydzień,
- dodawać funkcje bez czekania na „review team”.
A Apple mówi:
„Nie, poczekaj. Najpierw zatwierdzimy.”
Dla prostego kalkulatora kalorii to brzmi jak absurd — bo to jest absurd.
To nie jest troska o użytkownika. To jest troska o to, żeby:
- dystrybucja była w jednym miejscu,
- płatności były w jednym miejscu,
- i żeby przypadkiem web nie okazał się „wystarczający”.
A najgorzej, że ludzie naprawdę tego potrzebują online
Kalkulator kalorii to nie rocket science, ale:
- w podróży,
- na siłowni,
- w domu
User mógłby mieć to na pulpicie, a nie szukać w przeglądarce…
Poza tym, robisz aplikację w React dodajesz PWA, cache, IndexedDB, firebase i gotowe.
Na Android, Windows, Linux: działa tak jak powinno…
Na iOS: zaczynasz od tłumaczenia użytkownikowi, gdzie jest „Dodaj do ekranu”.
W 2026 roku… Kiedyś się Steve śmiał z Microsoftu xD
Podsumowanie: Nic dla idei – zysk to idea.
Kalkulator kalorii w SPA to doskonały test zdrowego rozsądku:
- Czy to powinno być natywne? Nie.
- Czy to musi przejść przez App Store? Nie.
- Czy użytkownik powinien instalować 150MB, żeby policzyć obiad? Nie.
A jednak cały ekosystem jest ustawiony tak, żeby web był „gorszy”, a sklep był „naturalnym wyborem”.
Nie dlatego, że to lepsze technicznie.
Tylko dlatego, że to lepsze biznesowo — dla Apple.
I to jest cała puenta.
Artykuł ma charakter satyryczny! Chciałem pokazać jak absurdalnie działają korporacje. Zysk, zysk, zysk – a gdzie user? Ich 100$ rocznie zysku to czasami 30 tys $ straty dla firmy – bo trzeba utrzymywać dwie lub trzy aplikacje zamiast jednej webowej.
