[PL] Jaką technologię wybrać do stworzenia mobilnej aplikacji cross-platform?

Damian Antonowicz

Artykuł ukazał się oryginalnie w dwóch częściach na portalu justgeek.it (część 1, część 2). W tym wpisie znajduje się jego kopia.

Wstęp

Dlaczego warto oraz jak tworzyć aplikacje mobilne, korzystając z wieloplatformowych technologii takich jak: Cordova, Xamarin i React Native. Temat jest ważny, gdyż wielu programistów zmaga się z dylematem jak tworzyć aplikacje mobilne. A odpowiedź na to pytanie nie jest prosta.

Tworzyć aplikacje natywnie? Wieloplatformowo? A może PWA? Obecnie podejść jest naprawdę wiele, a już pojawiają się nowe: Flutter czy Kotlin Native. Potrzeba dużo czasu do zweryfikowania każdej technologii z osobna w praktyce, by móc później wybrać tą, która najlepiej sprawdzi się w naszej aplikacji. To kosztuje.

Od strony technologicznej na Wasze pytania odpowiedzą programiści, którzy zjedli na nich zęby: Damian Antonowicz (Xamarin), Luuk van Venrooij (Cordova) oraz Michał Pierzchała (React Native). Pytania zadaje Łukasz Olbromski.

Pytania zadaje:

Łukasz Olbromski. Ambitny programista, projektant, architekt z pasją i ponad dziesięcioletnim doświadczeniem zawodowym. Od 2015 roku pracuje jako freelancer. Obecnie związany z Omada A/S, gdzie rozwija system z obszaru Identity Governance and Administration. Swoje doświadczenie zdobywał w firmach takich jak: Capgemini, Credit Suisse, czy Microsoft. Specjalizuje się w tworzeniu aplikacji full stack na platformie .NET, legacy code, accessibility i testowaniem oprogramowania. Dzieli się swoją pasją i doświadczeniem jako promotor idei Make SENSE in IT.

Odpowiedzi udzielają:

Damian Antonowicz. Certyfikowany programista Xamarin tworzący aplikacje mobilne na platformy Android oraz iOS. Związany od wielu lat z platformą .NET i ekosystemem Microsoft, a szczególnie z systemem Windows Phone, na który tworzył aplikacje jeszcze przed jego premierą. Podczas swojej kariery zawodowej pracował nad różnorodnymi aplikacjami związanymi z bankowością, finansami, zdrowiem publicznym, motoryzacją. Pasjonat nowych technologii, bloger, prelegent i fan whisky.

 

Michał Pierzchała. Programista JavaScript, który pasjonuje się tworzeniem aplikacji webowych i mobilnych. Uwielbia poprawiać narzędzia i jakość kodu, dzielić się wiedzą. Jest jednym z głównych kontrybutorów frameworka do testowania Jest.

 

 

Luuk van Venrooij. Lider techniczny w firmie ABB Enterprise Software. Obecnie zajmuje się tworzeniem aplikacji hybrydowych w oparciu o Cordova/ReactJS/ASP.Net Core do zarządzania elektrowniami. Miłośnik otwartych standardów webowych, minimalizmu i prostoty. W wolnych chwilach gra, bawi się technologiami AR/VR oraz delektuje piwami rzemieślniczymi typu IPA.

Lista pytań:

Pytanie #1. Dlaczego tworzysz aplikacje w podejściu cross-platform?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

W tradycyjnym podejściu stworzylibyśmy zupełnie oddzielne aplikacje na interesujące nas platformy. Może, choć nie musi, powodować to pewne problemy. Np. jeśli w trakcie trwania projektu zmienią się wymagania biznesowe to będziemy musieli zmieniać implementację na każdej platformie. Również będziemy potrzebowali większego zespołu programistycznego o różnych kompetencjach do wytworzenia takiej aplikacji. Z kolei w fazie utrzymania aplikacji będziemy potrzebować co najmniej jedną osobę na platformę. To wszystko może zakończyć się większymi kosztami wytworzenia aplikacji w podejściu natywnym.

Podejście cross-platform może nam pomóc w zmniejszeniu potencjalnych kosztów wytworzenia jak i utrzymania aplikacji. Będziemy potrzebować mniejszego zespołu programistycznego, będziemy mogli szybciej reagować na zmieniające się wymagania, będziemy mogli szybciej dostarczyć MVP aplikacji na rynek.

Odpowiada Michał Pierzchała, JavaScript Developer:

Tego oczekują od nas klienci. Zgodzę się tu z Damianem i dodam jedynie, iż z mojego doświadczenia wynika, że takie podejście po prostu lepiej się skaluje. Mając jedną osobę odpowiedzialną za daną funkcjonalność łatwo utrzymać modułowość i rozdział odpowiedzialności. Unikamy również dublowania procesu poznawczego i weryfikacji wymagań przez kilka osób.

Odpowiada Luuk van Venrooij, Lider techniczny:

Currently we target Android, iOS and the UWP platform with our apps. Using Cordova as our cross-platform approach gives is the following advantages:

1: We can have a smaller team where the main competency is focused on web development instead of a larger team where we need specialized people for each platform. An added benefit for us that it’s easy to onboard new developers with a background in web development.

2: We have a single codebase where we share up to 95% of our core application code across platforms. Note that in our case we don’t need to follow platform specific design patterns which helps us achieve the 95%.

3: Having a small team and a single codebase helps us to reduce costs of development and maintenance. It also makes time to market much faster.

Pytanie #2. Kiedy stworzyłbyś aplikację natywnie, a kiedy cross-platform?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Aplikację stworzyłbym natywnie w przypadku jeśli do tej aplikacji należałoby użyć wielu natywnych bibliotek. Xamarin dostarcza mechanizmy tzw. bindowania natywnych bibliotek napisanych w Javie lub Objective-C. Jednak z mojego doświadczenia wynika, że proces dołączania natywnej biblioteki do projektu tworzonego w Xamarinie potrafi być dość żmudny. Czasami, mimo naszych najszczerszych chęci, zewnętrzna biblioteka po prostu nie działa z jakiegoś powodu. Następuje wtedy rozwiązywanie problemu metodą prób i błędów. Po pomoc nie ma się do kogo zwrócić, bo mało osób ma w tym doświadczenie – takich rzeczy nie robi się na co dzień. Osobiście jeśli mogę to unikam dołączania natywnych bibliotek.

Odpowiada Michał Pierzchała, JavaScript Developer:

To zależy od oczekiwań klienta oraz doświadczenia developera. Misją Callstack jest tworzenie aplikacji działających na każdej platformie, więc jeśli mam odpowiedzieć krótko – zawsze stworzyłbym aplikację cross-platform, tego oczekują ode mnie klienci. Dzisiaj zrobiłbym to w React Native – jutro, kto wie.

Czasem wystarczy jednak stworzyć MVP na jedną platformę i dalej albo rozwijać projekt już na dwie platformy, albo porzucić, bo pomysł się nie sprawdził. W takim wypadku jeśli mamy dużo więcej doświadczenia w pisaniu natywnych aplikacji, moim zdaniem lepsze dla projektu będzie napisanie go natywnie, a potem zdecydowanie, co będzie lepsze z punktu widzenia doświadczenia naszego teamu.

Dużą zaletą React oraz React Native jest to, że obie biblioteki zostały zaprojektowanie z myślą o inkrementalnym wdrażaniu ich do istenijących produktów (np. www.facebook.com czy aplikacji AirBnB). Możemy zacząć apkę natywnie, dołożyć moduł napisany w React Native albo na odwrót. Mamy kilku developerów doświadczonych z React, ale kilku siedzi tylko w iOS? Proszę bardzo, pierwsi mogą zacząć aplikację JS z szablonu RN a drudzy napisać swoje moduły w Swift.

Odpowiada Luuk van Venrooij, Lider techniczny:

One thing that is hard to get right with Cordova is the native look and feel of a given platform and in certain cases the performance. So, if these would be a key requirement I would consider going native. But before I would go full native I still would consider alternatives like for example React Native or Flutter which would still give me the benefits of cross-platform development with native components and a near native performance.

Pytanie #3. Dlaczego programujesz w danej technologii?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Przez wiele lat tworzyłem aplikacje na system Windows Phone. Niestety system Microsoftu nie odniósł sukcesu na rynku systemów mobilnych. Z tego powodu postanowiłem przerzucić się na inną technologię mobilną. Nie chciałem ponownie zamykać się tylko na jeden system jak miało to miejsce w przypadku Windows Phone. Chciałem mieć możliwość tworzenia aplikacji również na iOS oraz Androida. Xamarin dawał mi taką możliwość i pozwalał wykorzystać posiadane doświadczenie w C#, .NET, XAML czy MVVM – nie musiałem zaczynać kompletnie od zera. Przejście na Xamarina było dla mnie bardzo naturalnym krokiem.

Odpowiada Michał Pierzchała, JavaScript Developer:

Wynika to wprost z mojego doświadczenia jako developer stron i aplikacji webowych, co wiąże się ze znajomością JavaScriptu. Po fascynacji deklaratywnym podejściem do pisania UI z React, przyszła pora na spróbowanie sił w pisaniu aplikacji mobilnych z pomocą React Native – w pełni open-source na licencji MIT.

Muszę przyznać jednak, że coraz bardziej interesujący wydaje się być Flutter – cross-platformowy framework od Google, kompilujący kod Dart bezpośrednio to natywnych API (podejście podobne do Xamarina).

Odpowiada Luuk van Venrooij, Lider techniczny:

Having been doing front end development for a few year prior starting with mobile development Cordova was kind of the easiest way to get started. Also, it is a very good fit with the requirements for the current project.

Pytanie #4. Z jakich narzędzi korzystasz podczas codziennego dnia pracy?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Na co dzień pracuję na macOS i szczerze polecam takie podejście przy tworzeniu aplikacji cross-platform. Do kompilacji aplikacji pod iOS potrzebujemy właśnie macOS. Można pracować z Xamarinem pod Windowsem, ale do kompilacji iOS i tak będziemy potrzebować komputera Apple. Znacznie wygodniej i bezproblemowo jest pracować na jednym sprzęcie. macOS pozwala również na wirtualizację Windowsa, co w drugą stronę może sprawiać problemy prawne.

Moim głównym środowiskiem programistycznym jest Rider od JetBrains. Jest to wieloplatformowe IDE do pisania kodu w C#. Rider posiada wbudowanego ReSharpera co znacznie ułatwia i przyspiesza pisanie kodu. Jednak Rider ma pewne braki i nie da się w nim zrobić wszystkiego, więc na co dzień używam również Visual Studio for Mac. A czemu nie piszę całkowicie w VS na macOS? VS for Mac nie posiada wspomnianego wcześniej ReSharpera, przez co kod będziemy pisać po prostu wolniej. Do pisania skryptów, szybkich notatek czy podglądu plików używam Visual Studio Code.

Do dystrybucji testowych wersji aplikacji oraz zbierania crash logów używamy HockeyApp, a do automatycznego budowania aplikacji oraz uruchamiania testów używamy Visual Studio Team Services. Z VSTS korzystamy również w kontekście projektowego wiki jak planowania zadań projektowych.

W ostatnim projekcie zwróciliśmy też uwagę na nową usługę Microsoftu Visual Studio App Center. W ramach tej usługi możemy automatycznie budować aplikację, dystrybuować ją, zbierać analityki czy testować aplikację na fizycznych urządzeniach. VS App Center nie ogranicza się tylko do aplikacji napisanych w Xamarinie. Jeśli mam aplikację napisaną natywnie czy w React Native to również możemy skorzystać z usługi Microsoftu. Warto mieć na uwadzę, że Microsoft planuje za jakiś czas zamknąć HockeyApp i Xamarin Test Cloud – funkcjonalności tych usług mają znaleźć się docelowo w VS App Center. My w ostatnim projekcie używaliśmy App Center do uruchamiania naszych automatycznych testów UI na fizycznych urządzeniach.

Odpowiada Michał Pierzchała, JavaScript Developer:

Tak jak wspomniał Damian, obecny kształt rynku systemów mobilnych nie daje nam wielkiego wyboru w kwestii systemu operacyjnego. Chcesz wysłać apkę do AppStore – musisz mieć sprzęt Apple z macOS. W moim przypadku jest to też system, z którego korzystam na co dzień.

Do edycji kodu JavaScript i danych tekstowych w zupełności wystarcza mi open-sourcowy Visual Studio Code z ogromnym ekosystemem rozszerzeń. Rzadko zdarza mi się pisać w Xcode lub Android Studio, jednak będą one dużo bardziej pomocne przy rozwijaniu natywnych modułów lub debugowaniu problemów z kodem natywnym. Do tego codziennie używam narzędzi do statycznej analizy kodu, jak ESLint, czy Flow lub TypeScript, które dodają typy i podpowiadanie składni dla dynamicznie typowanego JavaScriptu. Fenomenalny Prettier do automatycznego formatowania kodu. Oraz Jest do testowania jednostkowego i Detox do end-to-end.

W zależności od projektu i potrzeb klienta dochodzi integracja z jakimś serwerem CI – CircleCI, Travis, Jenkins, AppCenter, nie ma reguły. Niezależnie jednak od wybranego CI automatyzujemy budowanie, releasowanie i podpisywanie certyfikatów za pomocą Fastlane.

Kod wersjonujemy za pomocą gita, w miarę możliwości hostując go na GitHubie, często open-sourcowo, jednak tutaj bywa różnie i zdarzało mi się już korzystać z Gitlaba, BitBucketa oraz Team Foundation Server.

Jeśli chodzi natomiast o zarządzanie zależnościami projektu, preferujemy Yarn dla JS, domyślny Gradle dla Androida i CocoaPods dla iOS, jeśli zajdzie taka potrzeba. Korzystam z debuggera w Google Chrome.

Odpowiada Luuk van Venrooij, Lider techniczny:

My development machine is a MacBook Pro. In order to build applications for iOS its required. Support for web and Android development is also excellent on Mac. When dealing with the UWP I use a Windows 10 VM running from VMWare Fusion.

My IDE of choice is currently Visual Studio Code. It has excellent support for JavaScript development with a whole bunch of plugins available to make life easier.

My final tool would be any terminal for git, npm/yarn, running dev-servers, mock data and testing suites.

For build and test infrastructure we use several VMs hosted on both Azure and AWS. Our current tool for continues development is TeamCity with Upsource for code reviews. The iOS builds are done from a local Mac Mini which is connected as an additional build agent to TeamCity.

We currently don’t use any tools or Appstore for deploying our applications since most of our customers have their own custom MDM solutions a prefer to sign and sideload the apps themselves.

Pytanie #5. Z jakich wzorców projektowych korzystasz?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

W przypadku aplikacji tworzonych w Xamarinie najczęściej korzysta się ze wzorca MVVM, czyli Model-View-ViewModel. View określa jak dane powinny zostać wyświetlone, ViewModel określa co powinno zostać wyświetlone jak i manipuluje modelem (odczyt z bazy danych, dostęp do zasobów sieciowych, wywołanie logiki biznesowej, itp.). View używa tzw. bindowania do danych dostarczanych przez ViewModel. Jeśli dane we VM się zmienią to ten fakt jest oznajmiany dla View przy pomocy interfejsu INotifyPropertyChanged.

W celu ułatwienia tworzenia aplikacji zgodnie ze wzorcem MVVM powstało wiele różnych bibliotek. Do najbardziej popularnych mogę zaliczyć MvvmCross, MvvmLight, Prism, ReactiveUI czy Caliburn.Micro. Jednak należy pamiętać, żeby przypadkiem nie wyciągnąć armaty na muchę. Niektóre frameworki są naprawdę rozbudowane i trzeba dostosować odpowiedni framework w zależności od potrzeb aplikacji jaką tworzymy. MVVM to nie jest rocket science i w części przypadków może się okazać, że tak naprawdę możemy wszystko napisać sami (jeśli wymagania aplikacji nie są rozbudowane). Wszystko bardzo zależy od konkretnego przypadku.

Odpowiada Michał Pierzchała, JavaScript Developer:

Zwykło się mówić, że React to tylko V w MVC. Programowanie w React (a więc i React Native) opiera się o jednokierunkowy przepływ danych pomiędzy komponentami, a cała reszta zależy od nas.

Komponenty są podstawową jednostką budowania aplikacji, na wejściu otrzymują argumenty, tzw. “propsy”, a na wyjściu renderują (albo i nie) jakiś widok, co pozwala myśleć o nich jak o funkcjach. Naturalne staje się pisanie deklaratywnego kodu poprzez kompozycję, która może zostać osiągnięta na kilka sposobów, np. poprzez Higher-order Functions (w świecie React nazywa się to HoC – Higher-order Copmonent).

Popularnym wzorcem, szeroko rozpowszechnionym w całym community, jest Flux (co nie powinno dziwić znając założenia Reacta), implementowany na wiele sposobów, w zależności od potrzeb.

Odpowiada Luuk van Venrooij, Lider techniczny:

With Cordova it depends on the frontend framework you choose. We currently have projects with:

  • Sencha which would be MVC.
  • AngularJS which can be MVC or MVVM depending on how you use it.
  • ReactJS with Redux which I would consider to be Reactive with Command pattern.

Pytanie #6. Jak testujesz aplikacje mobilne?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Aplikacje warto testować przede wszystkim na fizycznym urządzeniu, żeby sprawdzić jak będzie się ona zachowywać na docelowym sprzęcie. Jednak podczas codziennej pracy zdecydowanie góruje testowanie aplikacji na emulatorach. W przypadku Apple nie mamy wyboru i musimy korzystać z oficjalnych emulatorów bezpośrednio na Macu. Z kolei w przypadku Androida korzystam z emulatorów dostarczanych razem z SDK. Te emulatory kiedyś działały bardzo wolno, ale jakiś czas temu Google poprawiło szybkość ich działania.

Do testów jednostkowych zazwyczaj używaliśmy połączenia NUnit oraz Moq. Chociaż w ostatnim projekcie skierowaliśmy się w stronę xUnit oraz NSubstitute. Osobiście nie jestem fanem mierzenia ilości pokrycia kodu testami jednostkowymi. Taka miara mówi nam jedynie, ile procent kodu jest uruchamianego podczas wykonywania testów. Z kolei nie wiemy czy testy jednostkowe są napisane poprawnie oraz czy napisaliśmy już wszystkie wymagane testy. Dążenie do jakiejś określonej ilości procentowego pokrycia może doprowadzić do sytuacji, gdzie będziemy pokrywać testami klasy dla samego ich pokrycia. Z tego powodu wolę zdefiniować te obszary aplikacji, które pokrycie testami jednostkowymi przyniesie najwięcej korzyści w perspektywie czasu.

Z kolei testy UI tworzymy w C#. Same testy UI powinny według mnie testować konkretne przypadki użycia aplikacji. Same testy uruchamiamy automatycznie każdej nocy na emulatorach, żeby sprawdzić poprawność założeń biznesowych. Testy uruchamiane są w nocy, ponieważ wykonują się one po prostu długo.

Testy UI nadają się lepiej np. do sprawdzenia poprawności nawigacji w aplikacji. Jeśli chcielibyśmy pokryć tą funkcjonalność testami jednostkowymi to musielibyśmy użyć mockowania i w ten sposób uzależnilibyśmy się od konkretnej implementacji sposobu nawigacji w aplikacji. Jeśli chcielibyśmy zmienić framework do MVVM to również musielibyśmy zmieniać nasze testy jednostkowe. Testy UI są pod tym względem lepsze, że operują na interfejsie graficznym i nie są zależne od wewnętrznych mechanizmów aplikacji. W ostatnim projekcie testy UI przydały się do zweryfikowania poprawności aplikacji po tym jak usunęliśmy z projektu framework MvvmCross.

Odpowiada Michał Pierzchała, JavaScript Developer:

React Native pozwala na jednoczesne podpięcie wielu urządzeń, więc normą jest rozwijanie projektu renderując go w symulatorze iOS i emulatorze Android w tym samym czasie. Niewątpliwą zaletą RN jest niesamowita szybkość, z jaką jesteśmy w stanie wprowadzać zmiany w aplikacji – po zapisaniu pliku, aplikacja zostanie całkowicie lub jedynie częściowo (np. z zachowaniem stanu aplikacji) przeładowania w czasie poniżej sekundy.

Bardzo ważne jest jednak testowanie na prawdziwych urządzeniach, więc warto mieć przynajmniej po jednym pod ręką.

Jeśli chodzi o automatyzację, do testowania kodu JS używamy naszej ulubionej platformy do testowania Jest. Pozwala nam na testowanie logiki biznesowej, działania i współdziałania komponentów, modułów, nawigacji. Plusem jest wykonywanie się tych testów tylko poprzez JavaScript, więc uruchomimy je na każdej maszynie, jednak wiele natywnych API zostaje zamockowanych.

Pisanie wszystkiego w JavaScripcie (lub pochodnych) staje się po pewnym czasie całkiem wygodne, dlatego do klikania po aplikacji w symulatorach i na CI używamy Detox. Takie testy wykonują się zwykle w czasie kilku-kilkunastu minut, w zależności od ilości, więc z powodzeniem możemy uruchamiać je przy każdym “pull requescie”.

W przypadku testowania na większej ilości urządzeń, musimy opuścić JS-ową strefę komfortu i zdać się rozwiązania natywne, np. Appium uruchamiane na wielu urządzeniach w AppCenter (vide wypowiedź Damiana).

Odpowiada Luuk van Venrooij, Lider techniczny:

Besides unit tests to cover core functionality we also have end to end testing suites for most of the applications to test the general flow and processes. We use a few different libraries to facilitate the unit end e2e tests depending on the frontend stack used.

Both sets of tests are run on a browser level on each build. Additionally, the end to end tests are also run on Android and iOS devices using Appium. Windows UWP is not supported unfortunately.

Finally there is the manual testing on actual devices. We do this to validate the layouts across platforms and to make sure all interaction with physical hardware (camera, GPS, flashlight etc) are working properly across devices.

Pytanie #7. Jak wygląda społeczność skupiona wokół technologii?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

W Polsce mamy bardzo fajną grupę offline XaMarines spotykającą się w Krakowie. Na spotkaniach są poruszane ciekawe tematy i przychodzi zawsze sporo osób. Można wymienić się doświadczeniem i poznać nowe zagadnienia. Zdecydowanie polecam, szczególnie jeśli mieszka się w Krakowie. Z kolei osoby z trójmiasta i okolic może zainteresować niedawno powstała grupa Xamarin Meetup Gdańsk.

Jeśli chodzi o społeczność online to wydaje mi się ona bardzo prężnie działającą społecznością. Z ciekawy inicjatyw mogę wymienić np. cotygodniowy newsletter z nowościami: Weekly Xamarin , agregator blogów: Planet Xamarin , Xamarin Chat na Slacku, gdzie zawsze można zadać pytanie, blog Xamarin Help z ciekawymi i przydatnymi wpisami. Warto również wspomnieć o GitHubie Jamesa Montemagno gdzie znajdziemy wiele przydatnych bibliotek.

Oczywiście to nie jedyne ciekawe miejsca w sieci i na pewno można by jeszcze do tej listy dodać wiele innych. Na samym GitHubie jest sporo różnych projektów związanych z Xamarinem. Jeśli zabrakło nam czegoś przy tworzeniu projektu to właśnie na GitHubie znajdowaliśmy potrzebne nam komponenty. Jest tego naprawdę mnóstwo. Zawsze możemy też zwrócić się w stronę komercyjnych rozwiązań np. od Telerika czy DevExpress.

Odpowiada Michał Pierzchała, JavaScript Developer:

Społeczność React Native jest dosyć młoda (sam framework dostępny jest dopiero 3 lata) i bardzo dynamiczna. Większość zainteresowanych pochodzi z ogromnej społeczności sympatyków React. Istnieje oficjalny kanał wsparcia na Discordzie Reactiflux , forum na Discuss oraz oczywiście cała masa wiedzy na ulubionym portalu programistów – Stack Overflow.

Od 2017 roku powstają pierwsze konferencje poświęcone w całości temu frameworkowi, jak amerykańskie Chain React czy europejskie React Native EU (organizowane przez Callstack). Organizujemy również okazjonalnie meetupy we Wrocławiu oraz innych europejskich miastach. Z racji sporego powiązania z JS-em, sympatycy React Native spotykają się również na meet.js oraz grupach związanych z Reactem.

Odpowiada Luuk van Venrooij, Lider techniczny:

Cordova is probably one of the oldest and still most widely used cross-platform development technology and I would consider it just after its peak. The community is huge, and the various supported platforms and plugins are well maintained and regularly updated. Lots of other cross-platform development frameworks like Ionic, PhoneGap and Framework7 are based on Cordova making the community even larger.

Pytanie #8. Którą technologię byś wybrał?

Odpowiada Damian Antonowicz, Xamarin Certified Mobile Developer & Consultant:

Chyba nie będzie niespodzianki jeśli powiem, że Xamarin? Każda technologia ma swoje wady i zalety. Na pewnym poziomie w każdej technologii będziemy robić to samo tylko przy pomocy innych narzędzi oraz metod. Ostatecznie sprowadza się to po prostu do stworzenia aplikacji mobilnej. Na pewno przy wyborze technologii ważne jest doświadczenie/upodobania jakie mamy. Osobiście od zawsze byłem związany z .NET i to jest technologia, w której dalej chce działać i się rozwijać. Wszystkiego można się nauczyć, ale pamiętajmy, że doba ma tylko 24h, a z wiekiem ilość wolnego czasu coraz bardziej maleje.

Odpowiada Michał Pierzchała, JavaScript Developer:

Z racji swojego doświadczenia, oczywistym wyborem będzie React Native. Jeśli będzie to mała aplikacja, do jej rozwijania użyłbym Expo (zestaw narzędzi upraszczających pracę z RN). Jeśli coś większego, zdecydowałbym się na czysty React Native. Nie jest natomiast oczywiste w jakim języku pisałbym swój kod. Wcale nie musi być to JavaScript. Na fali języków kompilowanych do JS, powstały ciekawe propozycje jak ReasonML – czyli niestandardowa składnia i zestaw narzędzi do silnie typowanego OCamla z świetnym systemem typów, co zaowocowało biblioteką ReasonReact, w pełni wspierającą RN.

Dodatkowo, Google wydał ostatnio w miarę stabilną (kto śledzi rozwój produktów Google, ten wie o czym mówię) wersję beta Flutter, o którym wspomniałem wcześniej. W podobnym kierunku może pójść open-sourcowy rozwój React Native i np. w niedalekiej przyszłości być może pojawi się biblioteka kompilująca ReasonML bezpośrednio do kodu natywnego, pomijając całkowicie wątek JavaScriptowy.

Odpowiada Luuk van Venrooij, Lider techniczny:

When Cordova was introduced it was designed to fill the gap to give web applications the ability to interact with the various hardware and software features. With the HTML5 spec this gap is getting smaller and smaller every year ( https://whatwebcando.today/ ). Lots of things we used to need Cordova and some plugin for we can now do in plain HTML5.

Then there is the push of several big companies like Google, Apple and Microsoft to properly support Progressive Web Apps ( https://developers.google.com/web/progressive-web-apps/ ) on their various platforms. This gives web applications the ability to be installed like native applications without the need for a wrapper like Cordova.

Finally, there is the appearance of new technologies like web-assembly which will give a huge boost in performance and the use of other languages besides JavaScript to create PWAs.

With all these developments I think that HTML5 based PWAs will be one of the easiest ways in the future to create cross-platform applications. Until that time I’m sticking with Cordova.

Podsumowanie

Jestem ciekawy jak byście odpowiedzieli na postawione wyżej pytania. Dajcie znać w komentarzach, kiedy decydujecie się na tworzenie aplikacji w podejściu cross-platform, a kiedy natywnie.