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.

 


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 Swfit.

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.


Pierwsza część devdebaty dotyczącej wieloplatformowych technologii za nami. W przyszłym tygodniu opublikujemy drugą część z jeszcze ciekawszymi pytaniami. A teraz jesteśmy ciekawi, jak Wy odpowiedzielibyście na któreś z powyższych pytań. Co sądzicie o podejściu cross-platform?

Zapraszamy do dyskusji