Frameworki crossplatform – jak stworzyć aplikację na iOS i Androida jednocześnie?

Paweł Dedio Programowanie 2018-12-15

Witajcie ponownie — dzisiaj dowiecie się, co to są frameworki crossplatform i po co ktokolwiek miałby ich używać. Nie chcę ukrywać, że nigdy nie byłem zwolennikiem takiego podejścia do tworzenia aplikacji, ale przy tym artykule postaram się odłożyć moje osobiste przekonania na bok i podać jak najwięcej suchych danych. Nie ma co przedłużać, zapraszam do konkretów!

Powstanie pomysłu

Jeśli używaliście przez dłuższy czas iOSa i Androida, to pewnie zauważyliście, że większość aplikacji wygląda identycznie na obu platformach. Czasami występują jakieś drobne różnice w interfejsie użytkownika, jednak zasada działania pozostaje taka sama. Chcąc stworzyć aplikacje w tradycyjny sposób, potrzebujemy dwóch zespołów programistów, po jednym na każdą platformę. Dodatkowo część kodu będzie zdublowana (oczywiście pod względem logicznym, ponieważ składnie Javy i Swifta mocno się różnią). Już na pierwszy rzut oka widać tutaj sporo miejsca na oszczędności. W pewnym momencie ktoś stwierdził, że zamiast pisać dwóch kompletnie osobnych porcji kodu, możemy napisać tylko jedną i skompilować ją osobno na iOS oraz Android. Dzięki takiemu podejściu moglibyśmy oszczędzić naprawdę sporo pieniędzy.

Błędy w założeniach

Zaletą oraz jednocześnie wadą takiego podejścia jest jego atrakcyjność pod względem marketingowym. Pomyśl sam, czyż nie wolałbyś napisać czegoś raz, tak żeby działało na obu platformach? Klient, słysząc takie coś, będzie zachwycony — dla niego oznacza to oszczędność 50% środków przeznaczonych na implementacje aplikacji. Jednak w rzeczywistości nie wygląda to tak kolorowo. O ile w prostych aplikacjach, posiadających kilka ekranów takie założenie jest bliskie prawdy, o tyle w tych bardziej skomplikowanych sprawy mają się nieco inaczej.

Czytając różne raporty dotyczące gotowych aplikacji stworzonych jako hybryda, można założyć, że stworzenie dwóch aplikacji w tej technologii zajmie 150% czasu wymaganego na stworzenie jednej aplikacji (na jedną platformę). Widać, że mimo wszystko jest oszczędność, jednak już nie tak duża jakby mogło się wydawać początkowo. Dodatkowo trzeba zaznaczyć, że często musimy korzystać z wiedzy dotyczącej konkretnej platformy. Tak więc nadal musimy posiadać w zespole ludzi doświadczonych w pisaniu na obie platformy. Możemy jedynie lekko zredukować ich ilość.

Różne podejścia

Frameworków crossplatform jest sporo — na końcu artykułu wymienię najważniejsze. Teraz chciałbym przedstawić trzy podejścia do tego tematu. Na potrzeby tego akapitu musisz wiedzieć, że wyróżniamy podział aplikacji na dwie warstwy. Pierwszą jest interfejs użytkownika, o którym już szerzej wspominaliśmy — jest to wszystko to, co widzi użytkownik po włączeniu naszej aplikacji: obrazki, przyciski i tak dalej. Drugą warstwą jest natomiast logika biznesowa, czyli wszystko to, co się dzieje pod spodem. Logiką biznesową jest na przykład to, że po kliknięciu przycisku „Zaloguj” wykonujemy zapytanie na serwer i logujemy użytkownika.

Jeśli to mamy wyjaśnione, to możemy wyróżnić najpopularniejsze podejścia do tematu aplikacji hybrydowych:

  • Współdzielenie samej logiki biznesowej — dzięki takiemu podejściu mamy pewność, że logika biznesowa na obydwu platformach będzie jednakowa. Z drugiej jednak strony mamy wolną rękę, jeśli chodzi o tworzenie interfejsu użytkownika. Możemy zrobić interfejs dostosowany zarówno do telefonów z iOS, jak i Androidem. Jednak jeśli chcemy mieć jednakowy wygląd na obu platformach, będziemy musieli pisać dwa razy to samo.
  • Współdzielenie logiki biznesowej oraz interfejsu użytkownika — to podejście jest podobne do tego wyżej, z tą różnicą, że również widoki są definiowane raz dla obu platform. Zaletą jest to, że nie musimy implementować dwa razy tego samego widoku, jednak nie możemy go również dostosować osobno pod każdą z platform (chociaż niektóre frameworki dopuszczają takie coś).
  • Współdzielenie interfejsu użytkownika — to podejście jest coraz rzadziej spotykane. Dawniej było bardziej popularne, jednak było implementowane w koszmarny sposób. Interfejs użytkownika był definiowany jako strona internetowa i wyświetlany w aplikacji na każdej z platform. Takie rozwiązanie było bardzo ciężkie i powodowało sporo błędów oraz potencjalnych niebezpieczeństw.

Jakie są zalety?

Tak jak wspominałem wyżej, największą zaletą jest niedublowanie logiki biznesowej. Mamy mniej miejsc na popełnienie błędów. Dodatkowo w przypadku zmiany wymagań klienta, wystarczy, że dokonamy zmiany w jednym miejscu i zaktualizujemy jednocześnie kod dla dwóch platform. Jest to ogromna oszczędność zasobów ludzkich oraz pieniędzy.

Kolejną zaletą jest oszczędność czasu. Przy standardowych aplikacjach (niewykorzystujących zaawansowanych funkcji systemowych) możemy zaoszczędzić nawet połowę czasu potrzebnej na napisanie jednej z platform. Czyli jeśli na napisanie aplikacji na Androida potrzebujemy 100% i tyle samo na aplikację na iOS, to na obie platformy jednocześnie wystarczy tylko 150%, a nie 200%.

Jakie są wady?

Jeśli chcesz pisać natywne aplikacje, to do Androida musisz użyć języka programowania Java lub Kotlin. Natomiast do iOS języka Swift (dawniej Objective C). Jednak niektóre frameworki wymagają do pisania jeszcze innego języka, tak więc nie wystarczy być programistą którejś z platform, aby móc pisać aplikację w tym frameworku.

Z wprowadzaniem osobnego języka wiąże się jeszcze jedna wada. Załóżmy, że Google wypuszcza jakąś super bibliotekę wymaganą do korzystania z funkcji systemowych. Jako że nie piszemy w Javie, nie możemy tak po prostu użyć tej biblioteki, musimy poczekać, aż wydawca używanego przez nas frameworka przepiszę tę bilbiotekę na odpowiedni język.

Kolejnym minusem jest dostęp do warstwy systemowej. W niektórych frameworkach aplikacja jest uruchomiona w dodatkowej warstwie abstrakcji — w przypadku wystąpienia błędu specyficznego dla systemu, możemy mieć ogromne problemy z odgadnięciem, co właściwie się dzieje i dlaczego nasza aplikacja nie działa.

Jakie frameworki są dostępne na rynku?

Nie chciałbym zagłębiać się za bardzo w szczegóły techniczne dotyczące każdego z frameworków, ponieważ nie każdego mogą one interesować. Mam zamiar opisać tylko podejście do tematu każdego z nich. Chciałbym również podziękować mojemu koledze Tomkowi za zrobienie porównania wszystkich najpopularniejszych frameworków, ponieważ mocno ułatwiło mi to pisanie tego akapitu. Dla zainteresowanych odsyłam do jego artykułu.

Dobra, dość ględzenia, oto obiecana lista:

  • Xamarin — jest to framework dość stary, o ugruntowanej pozycji na rynku. Używamy w nim języka C#. Oprócz logiki biznesowej możemy również współdzielić część interfejsu użytkownika. Największą wadą jest trudność w używaniu bibliotek systemowych.
  • Flutter — świeży framework stworzony przez Google. Do tworzenia aplikacji wykorzystujemy język Dart. W przypadku Fluttera współdzielimy zarówno logikę biznesową, jak i interfejs użytkownika (wszystko jest pisane w Darcie). Jeśli stosujemy się do wytycznych Google, nasza aplikacja będzie niesamowicie szybka.
  • React native — framework stworzony przez Facebooka. Aplikacje piszemy w języku JavaScript. Framework jest przyjazny dla programistów front end, którzy tworzyli już kiedyś w Reactcie. Współdzielimy tutaj zarówno widoki, jak i logikę biznesową. Największym minusem Reacta jest jego wydajność, ponieważ aplikacja cały czas utrzymuje uruchomione środowisko JavaScript, co może powodować spowolnienia przy bardziej wymagających aplikacjach.
  • Kotlin native — framework stworzony jako dodatek do Kotlina, oficjalnego języka do pisania aplikacji na Androida. Zgodnie z nazwą aplikacje piszemy tutaj w języku Kotlin. W tym frameworku współdzielimy jedynie logikę biznesową, wszystkie rzeczy działające bezpośrednio z systemem musimy napisać w kodach natywnych dla każdej z platform. Największym minusem jest to, że projekt jest obecnie w mocno początkowej fazie, wobec czego zdarzają się pewne błędy.
  • Unity 3D – jest to framework stworzony na potrzeby tworzenia gier. Piszemy tutaj w języku C#. Z zalet można wymienić wydajność przy renderowaniu grafiki. Framework nie jest zalecany do tworzenia zwykłych aplikacji, niemających nic wspólnego z renderowaniem skomplikowanych grafik.

To już koniec na dziś, dzięki za przeczytanie. Dajcie znać w komentarzach, jeśli korzystaliście z któregoś z frameworków i jakie są wasze odczucia. W sprawie crossplatform nie jestem jakimś wielkim ekspertem, także wszelkie słowa krytyki mile widziane. Widzimy się za tydzień, gdzie dowiecie się, jak obsługujemy kilka języków w jednej aplikacji. Do zobaczenia!

Zapraszam również na największe w Polsce forum dla programistów Android. Jeśli macie pytania odnośnie do kariery programisty — zapraszam do działu Kariera programowanie. Zachęcam również do przejrzenia działu Praca oraz zlecenia dla programistów — być może to właśnie tam znajdziesz swoją pierwszą pracę.

Poprzednie odcinki:

  1. Typowy dzień pracy programisty
  2. Wady pracy programisty
  3. Zalety pracy programisty
  4. [FAQ] Wszystko, co powinieneś wiedzieć, jeśli interesuje Cię praca programisty
  5. Co mnie zdziwiło w programowaniu?
  6. Motywacje – w jaki sposób nie stracić zapału do programowania?
  7. Jaką firmę wybrać na początku kariery programisty?
  8. Jak wygląda rozmowa o pracę na stanowisko programisty?
  9. Jak zacząć programować?
  10. Skąd czerpać wiedzę o programowaniu?
  11. Początki programowania — jaką technologię wybrać?
  12. Cykl życia aplikacji na Androida — co to takiego?
  13. Jak tworzymy interfejs użytkownika w aplikacjach na Androida?
  14. Jak system Android oszczędza energię?
  15. Jak działają i czym są powiadomienia push w Androidzie?
  16. W jaki sposób aplikacje pobierają dane z zewnętrznych serwisów i czym jest API?
  17. Jak działają pozwolenia w systemie Android?
  18. Śledzenie użytkowników — co wiedzą o nas aplikacje?
  19. Dlaczego aplikacje na Androida zajmują coraz więcej miejsca?


  • Grzegorz Madajczak

    Zabrakło jeszcze NativeJS

  • Xavar

    „tak więc nie wystarczy być programistom którejś z platform”… programistą

    • Paweł Dedio

      Poprawione, dzięki za czujność!

  • Martina Neumayer

    Do tego dochodzi jeszcze jedna i bodajże mocno istotna sprawa. Mianowicie cała polityka Apple odnośnie deveroperki dla ich platformy. Czyli sprzęt, bo zachodzi konieczność klepania na sprzęcie od nich, a także opłaty. Nie pamiętam ile teraz wynosi to roczne myto, ale nie jest to mała kwota. I póki tego jakoś rozsądnie nie zmienią, póty będzie mocno uciążliwa cała ta robota. Zwłaszcza, gdy się chce apkę udostępnić, czy sprzedawać w ich sklepie. Nie wspominając już o tym całym późniejszym „code review”, który bywa bardzo upierdliwy, czasochłonny i który także potrafi zniechęcić koderów do wspierania japcokowej platformy.

    • guziaster

      Ile lat programujesz na tą platformę, ze wygadujesz takie bzdury?
      Opłacenie konta deweloperskiego nie jest drogie- kosztuje 100 euro rocznie(przy założeniu ze standardowe aplikacje biznesowe kosztują od kilkudziesięciu tysięcy za projekt to jest to mała kwota). Żeby pisać na ta platformę lub uruchamiać na urządzeniach nie trzeba płacić tej opłaty, dopiero wypuszczenie do sklepu wymaga wniesienia tej opłaty, co przeważnie opłaca firma, która aplikacje chce publikować. Review nie są debilne, tylko dokładne. Apple jasno określa, co można a czego nie można robić, jeśli ktoś tego nie rozumie lub zapomni miły support informuje o tym, ze zabrakło tego lub tego lub to i to jest zabronione i można porozmawiać na czacie z osobą, która to sprawdza lub zastosować zaproponowane rozwiązanie problemu. Review trwa aktualnie około 24-48h. Tylko raz trwało dłużej ze względu na mechanizm płatności w aplikacji oraz gorący okres aktualizacji aplikacji po wydaniu nowej wersji systemu. Ani razu nie poczułem się zniechęcony, ani żaden z moich kolegów programistów tej platformy.

      • Martina Neumayer

        Tak, tak.. teoryjki swoje, a realia swoje. I pewnie dlatego ostatnimi czasy taka masa osób ot tak sobie dla kaprysu olewa kodowanie pod japco.. no bo pewnie się nudzą i nie mają nic innego do roboty. Uhum..
        Wiesz co? Nie chce mi się ani dyskutować ani też tracić czasu na jakieś takie twoje przepychanki. Toteż odpowiem wprost..
        Idź i opowiadaj te swoje japco fanbojowe rewelacje i piej peany komuś, kto jest aż tak naiwny i w to wierzy.
        A ludziom, którzy mają do czynienia z cyrkami, jakie ta firma wyprawia, praktycznie każdego jednego dnia, bądź tak łaskaw i oszczędź czasu.

  • Marcin

    Jakby ktoś był zainteresowany to zapraszam do zapoznania się z moimi doświadczeniami z React Native oraz Flutter:
    https://blogprogramisty.pl/blog/co-mysle-o-react-native
    https://blogprogramisty.pl/blog/flutter-konkurencja-od-google-dla-react-native

  • Mariusz Kaczmarczyk

    A cordova? A Ionic? Na teraźniejszą chwilę chyba najbardziej wspierane frameworki do pisania crossplatformowych aplikacji.

    • Paweł Dedio

      Brałem pod uwagę tylko te najpopularniejsze. W większości zestawień pojawiały się tylko te wymienione przeze mnie.

      • fckUeve

        cordova jest bardzo popularna…

      • davidns

        Cordova/Phonegap/Ionic są mega popularne

      • Jeśli Cordova/Phonegap i Ionic nie zaliczają się najpopularniejszych, to chyba te zestawianie czytałeś w IE …

        • Paweł Dedio

          Wybacz za brak wymienionych przez ciebie frameworków w tym zestawieniu. Nigdy nie miałem z nimi kontaktu, a śledząc różne artykuły i konferencje związane z rynkiem mobilnym, nie zauważyłem jakiegoś mega zainteresowania tymi frameworkami, przeważnie pojawiają się te podane przeze mnie. Lekcja na przyszłość aby poszerzyć źródła 😉

  • Tomasz

    Flutter generuje kod pod jeszcze jeden system: fuschie.

    • Paweł Dedio

      Zgadza się, pominąłem również informację o tym, że Xamarin umożliwiał tworzenie aplikacji na platformę mobilną od Microsoftu. Chciałem się skupić głównie na dwóch, wiodących platformach mobilnych. Nie mniej dzięki za czujność!

  • Michał Derej

    Świetny artykuł, bardzo ciekawie prezentujesz wszystkie informacje. Dla przyszłego studenta informatyki jak znalazł. Dzięki!