Napisz raz, wdrażaj wszędzie: kiedy przejść na natywny?

Write Once, Deploy Everywhere (WODE) to obietnica wielu frameworków programistycznych w ciągu ostatniej dekady, których celem jest złagodzenie bólu związanego z pisaniem wielu aplikacji natywnych. Ustalenie, którą ścieżkę wybrać, jest jedną z najważniejszych decyzji, jakie musi podjąć kierownik projektu ze względu na wysoki koszt uruchomienia, wpływ na zespół programistów i potencjalną niemożność odwrócenia.

Rozwiązania hybrydowe, takie jak Ionic, wykorzystują technologie internetowe do renderowania aplikacji na różnych platformach, ale często produkt końcowy nie spełnia oczekiwań użytkownika dotyczących natywnego wyglądu i działania.

Jednak nawet termin „natywny” został ostatnio zaciemniony przez frameworki, które kompilują się do kodu natywnego (np. React Native, Xamarin itp.).

W tym artykule przedstawiono wady i zalety różnych ścieżek rozwoju urządzeń mobilnych i porównano je ze składem zespołu, kosztami i doświadczeniem użytkownika, aby umożliwić menedżerom produktów podejmowanie bardziej świadomej decyzji.

Napisz raz, wdrażaj wszędzie

Koncepcja Napisz raz, wdrażaj wszędzie odnosi się do zdolności zespołu programistycznego do jednorazowego napisania aplikacji — przy użyciu pojedynczego stosu programistycznego, abstraktu platformy (platform), na której aplikacja zostanie wdrożona — przy jednoczesnym zachowaniu możliwości wdrażania aplikację na wszystkie pożądane platformy, np. Android, iOS, Windows itp. W idealnym przypadku jest to realizowane bez poświęcania łatwości konserwacji, wydajności lub doświadczenia użytkownika (UX).

Alternatywna – i historyczna – metoda tworzenia aplikacji mobilnych polega na prostym procesie prostego napisania oddzielnej aplikacji dla każdej platformy, co oczywiście niesie ze sobą swój potencjalny wysoki koszt czasu i zasobów.

Ogólnie rzecz biorąc, czynniki, które należy wziąć pod uwagę przy wyborze ścieżki rozwoju, obejmują:

• Wiek projektu
• Skład i wielkość zespołu programistów
• Pożądana platforma (platformy) do dystrybucji
• Wymagany harmonogram wprowadzenia na rynek
• Dostępna przepustowość do zmiany na inną ścieżkę, jeśli trzeba

Niestety zastosowanie każdego z tych czynników do każdej z dostępnych ścieżek, a także przedzieranie się przez niezliczone dostępne opinie na ten temat, może być dość zniechęcające. Co więcej, proces ten często pozostawia kierownikowi projektu poczucie niepewności, która ścieżka jest najlepsza, aby spełnić wymagania aplikacji.

Na wysokim poziomie różne ścieżki rozwoju mobilnego można podzielić na dwie kategorie: natywne lub WODE, tj. natywne lub wszystko inne. Mówiąc prościej, albo pisze się aplikację natywną, albo nie. Kategoria WODE dzieli się dalej na dwie grupy:

• Struktury hybrydowe — te, które wykorzystują technologie internetowe do renderowania aplikacji na wielu platformach.
• Frameworki niehybrydowe — te, które używają natywnych komponentów interfejsu użytkownika (np. przycisków, pól tekstowych, a nawet menedżerów układu) zamiast renderowania widoku internetowego wewnątrz aplikacji, tak jak robią to frameworki hybrydowe.

Większość frameworków WODE jest hybrydowa ; Jednak w celu poprawy zarówno wydajności, jak i ograniczeń UX frameworków hybrydowych, przy jednoczesnym zapewnieniu korzyści z frameworka WODE, obecny trend zmierza w kierunku niehybrydowym . W związku z tym trendem na popularności zyskują takie frameworki jak React Native, Xamarin czy Appcelerator.

Każda z tych ścieżek — natywna, hybrydowa i niehybrydowa — ma różne mocne i słabe strony, w wyniku czego każda ma inne przypadki użycia, do których jest najbardziej odpowiednia. W dalszej części tego artykułu omówiono zalety i wady każdej ścieżki rozwoju mobilnego, biorąc pod uwagę konkurencyjne priorytety, takie jak skład zespołu, koszt projektu i UX. Z wyjątkiem kilku wyspecjalizowanych przypadków użycia, pisanie aplikacji natywnych maksymalizuje wygodę użytkownika przy nieco wyższych kosztach.

Ogólnie obowiązuje powiedzenie „ dostajesz to, za co płacisz ”, więc jeśli koszt jest ważniejszy niż wrażenia klientów, natywny może nie być właściwym wyborem. Jednak gdy UX staje się kluczowy, aplikacje natywne stają się oczywistym wyborem, ponieważ w celu poprawy UX aplikacje oparte na WODE ponoszą znaczne koszty w postaci czasu lub wiedzy natywnej, co jest sprzeczne z celem wyboru nienatywnego ścieżkę rozwoju w pierwszej kolejności.

Co więcej, nawet jeśli ten koszt zostanie zapłacony, produkt końcowy oparty na WODE zawsze zapewni gorszy UX w porównaniu do swojego rodzimego odpowiednika. W rezultacie natywny jest prawie zawsze właściwym wyborem dla większości zespołów programistycznych i dla większości projektów.

Aplikacje natywne

Aplikacje natywne są pisane w podstawowym języku danej platformy. Na przykład aplikacje na Androida są napisane w Javie, podczas gdy aplikacje na iOS są napisane w Obj-C lub Swift. Wymagają od inżyniera programisty zrozumienia języka, a także niuansów specyficznych dla platformy, które obejmują na przykład integrację pakietów innych firm, zarządzanie układem, interakcję z systemem operacyjnym (OS) i tak dalej.

Plusy

Wysoce konfigurowalny . Ponieważ każda aplikacja jest napisana z wykorzystaniem komponentów natywnych, jedynym ograniczeniem dostosowywania jest interfejs do podstawowych frameworków, a czasem nawet nie. Jak potwierdzi większość rodzimych inżynierów programistycznych, często istnieje sposób na wykonanie danego zadania pomimo ograniczonego interfejsu.

Prosty dowód tego pomysłu można znaleźć przeglądając społeczności wsparcia dla danej platformy. Można znaleźć liczne przykłady tego, jak wykonać zadanie, które może być „niezastrzeżone”, pomimo ograniczeń podstawowych ram.

Konkretnym przykładem takiego pozornie prostego zadania dla systemu iOS może być pokazanie nakładki pełnoekranowej, przede wszystkim zewnętrznych elementów interfejsu użytkownika, np. paska kart, paska nawigacji itp. Jak pokazano na rysunku 1 , zwykle jest to poza zakresem obecnie prezentowana jest normalna warstwa interfejsu użytkownika. W związku z tym, aby mieć nakładkę pełnoekranową, należy ją dodać do ukrytej warstwy nad paskiem kart w stosie widoków. Ten rodzaj dostosowywania jest zwykle możliwy tylko w aplikacjach natywnych.

Najwyższa wydajność . Zgodnie z oczekiwaniami, natywna aplikacja wyznacza punkt odniesienia dla wydajności. Ponieważ większość innych typów struktur dodaje jedną lub więcej warstw pośrednich, z natury działają one wolniej niż aplikacje natywne.

Najłatwiejsze w utrzymaniu . Systemy operacyjne stale się zmieniają. Okres. Kiedy tak się dzieje, w zależności od tego, czy dokonano istotnych zmian, aplikacja musi być aktualizowana w odpowiednim czasie, aby nie stracić części bazy użytkowników, która aktualizuje się do nowszego systemu operacyjnego. Oczywiście im mniej czasu upływa między udostępnieniem zmiany użytkownikom a aktualizacją aplikacji, tym lepiej. Ten czas jest minimalizowany, gdy nie ma zależności, które wymagają aktualizacji, aby obsługiwać nowy system operacyjny, co ma miejsce podczas pracy na aplikacji natywnej.

Cons

Dodatkowe zasoby . Pisząc aplikacje na wiele platform, zespół programistów zazwyczaj składa się z co najmniej jednego inżyniera oprogramowania mobilnego dla każdej obsługiwanej platformy. To oczywiście nieodłącznie zwiększa wielkość i koszt zespołu programistów. Wymaga również, aby zespół inżynierów posiadał różnorodne umiejętności, w przeciwieństwie do jednorodnej bazy umiejętności. Może to spowodować rozdrobnienie zespołu pod względem wsparcia i współpracy.

Wolniejszy cykl rozwoju . Aplikacje natywne mogą mieć wolniejszy cykl rozwoju po prostu dlatego, że dla każdej pożądanej platformy należy napisać osobną aplikację. Skrajnym przypadkiem jest sytuacja, gdy w zespole jest jeden inżynier ds. programowania mobilnego, ponieważ każda aplikacja jest zasadniczo napisana w seriach.

Niska wydajność . Może wydawać się dziwne, że występy są zarówno zawodowcem, jak i przeciwnikiem. Z jednej strony aplikacje natywne dają programistom wystarczająco dużo miejsca na stworzenie precyzyjnie dostrojonej, wysokowydajnej aplikacji. Z drugiej jednak strony dają deweloperowi wystarczająco dużo liny, by mógł się powiesić. Jeśli nie wiedzą, co robią, w końcu w najlepszym razie otrzymają słabą aplikację.

Uwaga: ogólnie dotyczy to wszystkich ścieżek frameworka (natywnej, hybrydowej i niehybrydowej). Jeśli inżynierowie opracowujący aplikację nie mają wystarczających umiejętności do tego, czego próbują, powstała aplikacja prawdopodobnie nie spełni wymagań projektowych ani nie zostanie dobrze zaakceptowana przez użytkowników.

Aplikacje hybrydowe

Aplikacje hybrydowe są zazwyczaj pisane przy użyciu HTML/CSS/LESS do projektowania interfejsu użytkownika: „V” we wzorcu projektowym MVC. „C” lub kontroler jest wtedy zwykle pisany w JavaScript - najlepiej przy użyciu frameworka JavaScript MVC, takiego jak AngularJS. Użycie frameworka takiego jak AngularJS pozwala na lepsze rozdzielenie klas i odpowiedzialności niż jest to zwykle możliwe przy użyciu tylko jQuery.

Przykładem tego typu stosu ram hybrydowych może być warstwa widoku Ionic wspierana przez AngularJS, która jest ostatecznie konwertowana i renderowana w widoku internetowym na żądanej platformie przy użyciu PhoneGap i Cordova. Oczywiście ten rodzaj frameworka WODE wiąże się z dodatkową złożonością.

Ponadto użycie JavaScript niesie ze sobą własne ograniczenia projektowe i problemy związane z językiem. Celem tego artykułu nie jest dyskusja nad zaletami lub wadami jednego języka; jednak, jako kierownik projektu, nie należy lekceważyć wyboru użycia JavaScript w swoim mobilnym stosie technicznym. Oto tylko kilka przykładów dobrze napisanych artykułów o tym, dlaczego należy unikać JavaScript, jeśli to możliwe:

• Problem JavaScript
  
• Dlaczego nie jestem programistą React Native

Plusy

Minimalny zespół programistów . Platformy hybrydowe umożliwiają małemu zespołowi programistycznemu — a zwłaszcza takiemu, którego podstawową bazą wiedzy jest tworzenie stron internetowych — szybkie tworzenie prostych aplikacji na wielu platformach. Pozwala to kierownikowi projektu na utrzymanie niewielkiego zespołu, a także eliminuje potrzebę uczenia się przez jego zespół języków natywnych i frameworków dla wielu platform.

Szybszy cykl rozwoju . Oprócz mniejszego zespołu, struktury hybrydowe zapewniają szybszy cykl rozwoju podczas wdrażania na wielu platformach, ponieważ tylko jedna warstwa widoku musi być zaprojektowana przy użyciu technologii internetowych.

Cons

Potencjalnie słaby UX . Wadą konieczności napisania tylko jednej warstwy widoku jest to, że pozostaje jedna warstwa widoku. Może to skutkować słabym UX, ponieważ uniwersalne podejście do projektowania interfejsu użytkownika nie zapewnia aplikacji wyglądu wygodnego i znanego użytkownikom na wszystkich platformach. Ponadto, ponieważ aplikacje hybrydowe są zasadniczo widokami internetowymi osadzonymi w interfejsie użytkownika, mogą sprawiać wrażenie, że faktycznie przeglądają stronę internetową zamiast wchodzić w interakcję z aplikacją natywną. To doświadczenie prawie zawsze ma negatywny wpływ na satysfakcję użytkowników, a ostatecznie na retencję.

Kosztowne dostosowanie . Ulepszanie UX poprzez projektowanie dostosowanych interfejsów użytkownika dla każdej platformy skutkuje złożonymi i unikalnymi strukturami interfejsu użytkownika, które mogą być kosztowne w tworzeniu i trudne w utrzymaniu w czasie. Ponadto, aby stworzyć elementy interfejsu użytkownika, które pomogą wyróżnić aplikację (np. animację, niestandardowe widoki itp.), należy utworzyć niestandardowe komponenty pomostowe, aby przetłumaczyć projekt interfejsu użytkownika wysokiego poziomu na coś, co struktura niższego poziomu , jak Cordova, zrozumieją. Ogólnie rzecz biorąc, im bardziej dostosowujemy i poprawiamy UX aplikacji hybrydowej, tym bardziej zmniejszamy korzyści płynące z szybkiego i niedrogiego cyklu projektowania.

Niższa wydajność . Ponieważ aplikacje hybrydowe renderują widoki aplikacji w widoku sieciowym, istnieje duże prawdopodobieństwo popełnienia błędów implementacyjnych w przypadku struktur systemu operacyjnego (np. sieci, Bluetooth, kontaktów na urządzeniu itp.), co skutkuje znacznie obniżoną wydajnością. Warto również zauważyć, że nawet jeśli przywiązuje się dużą wagę do wydajności, ponieważ wszystko jest wyświetlane za pośrednictwem podglądu internetowego, maksymalna wydajność aplikacji hybrydowych zawsze będzie nieco mniejsza niż ich natywnych odpowiedników.

Nietrywialne zarządzanie wtyczkami . Pamiętasz te niestandardowe funkcje, które zespół projektantów spędził tygodnie na polerowaniu, po czym nastąpiło kolejne kilka tygodni, podczas gdy zespół programistów stworzył niezbędne komponenty mostu, aby Cordova mogła z nimi pracować? Cóż, nie będą działać, jeśli nie będzie wtyczki Cordova wspierającej to, co zespół stara się osiągnąć. Oznacza to jedną z dwóch rzeczy: albo zespół tworzy go samodzielnie, albo trzeba będzie znaleźć odpowiednią wtyczkę innej firmy, która wykona zadanie. Niestety najczęściej opcja druga nie istnieje. W rezultacie utworzenie niestandardowych wtyczek wymaga dodatkowego czasu na rozwój, a następnie — w miarę upływu czasu — wysiłku wsparcia kompilacji, aby zarządzać rosnącą biblioteką wtyczek Cordova wymaganych przez aplikację. Oczywiście, gdy pojawią się aktualizacje Cordova, istnieje duże prawdopodobieństwo, że te wtyczki również będą wymagały aktualizacji.

Opóźnienie w obsłudze systemu operacyjnego . Wspomniany wcześniej problem z komponentem mostka kaskadowego/wtyczką Cordova pogarsza się jeszcze bardziej, gdy system operacyjny zmienia podstawową funkcjonalność. Po zaktualizowaniu Cordova, PhoneGap i Ionic w celu obsługi zmian, możliwe jest, że niestandardowe wtyczki i komponenty mostu również będą musiały zostać zaktualizowane. Niezależnie od tego, jakiego rzędu wymagałaby ta praca, skutkuje to dodatkowym czasem, w którym aplikacja nie obsługuje użytkowników końcowych, którzy dokonali aktualizacji do nowego systemu operacyjnego. To oczywiście najgorszy scenariusz, w którym Apple lub Google wprowadzają przełomowe, niekompatybilne wstecz zmiany, co nigdy się nie zdarza… prawda? Ogólnie rzecz biorąc, każdy pośredni framework, który jest poza kontrolą programisty i który musi zostać najpierw zaktualizowany, służy jedynie do opóźnienia procesu. Wreszcie, poleganie na pośrednim frameworku może być dla kierowników projektów problemem przy planowaniu, ponieważ czas ich wprowadzenia jest tak nieznany.

Aplikacje niehybrydowe

Aplikacje niehybrydowe zaczynają życie tak samo jak ich hybrydowe odpowiedniki – warstwa interfejsu użytkownika zaprojektowana w nienatywnym języku platformy: React Native wykorzystuje HTML/CSS wspierany przez JavaScript lub Xamarin, który jest oparty na C# ze względu na swoje korzenie .NET.

Na tym jednak kończy się podobieństwo. Aplikacje niehybrydowe kompilują się do kodu natywnego i renderują aplikację przy użyciu komponentów natywnych dla platformy zamiast renderowania za pośrednictwem widoku internetowego. Skutkuje to ramą WODE, która, przynajmniej na pierwszy rzut oka, ma to, co najlepsze z obu światów.

Jak wspomniano wcześniej, wybór użycia JavaScriptu nie powinien być decyzją podjętą pochopnie i może być przełomem dla zespołu programistów, który nie chce się uczyć lub nie jest zainteresowany używaniem JavaScript.

Plusy

Wyższa wydajność niż hybrydy . Jak można się spodziewać, aplikacje niehybrydowe z natury mają wyższą wydajność niż aplikacje hybrydowe ze względu na ich zdolność do renderowania aplikacji przy użyciu natywnych komponentów interfejsu użytkownika (przycisków, widoków, menedżerów układu itp.), zamiast polegania na wbudowanym widoku sieciowym. Oczywiście programiści nadal mogą napisać aplikację, która działa wyjątkowo lub okropnie. Zaletą aplikacji niehybrydowych jest po prostu to, że mają one wyższą linię bazową wydajności w porównaniu z podobnymi aplikacjami hybrydowymi.

Minimalny zespół programistów . Podobnie jak frameworki hybrydowe, platformy niehybrydowe umożliwiają małemu zespołowi programistycznemu — a zwłaszcza takiemu, którego podstawową bazą wiedzy jest tworzenie stron internetowych — szybkie tworzenie prostych aplikacji na wielu platformach. Pozwala to kierownikom projektów na utrzymanie małego zespołu i uniemożliwienie zespołowi uczenia się języków i frameworków natywnych dla wielu platform.

Szybszy cykl rozwoju . Oprócz mniejszego zespołu struktury niehybrydowe zapewniają szybszy cykl rozwoju podczas wdrażania na wielu platformach, ponieważ wystarczy zaprojektować tylko jedną warstwę widoku.

Szybsze iteracje (Reakcja) . Framework React zapewnia potężną funkcję, która umożliwia renderowanie zmian w aplikacji w czasie rzeczywistym: nie ma potrzeby ponownej kompilacji, przebudowy itp. W rezultacie emulator React jest niesamowicie potężnym narzędziem programistycznym, które znacznie skraca czas trwania każdej implementacji cykl.

Cons

Kosztowne dostosowanie . Podobnie jak w przypadku hybrydowego odpowiednika, gdy aplikacje niehybrydowe wymagają ulepszenia UX poprzez zaprojektowanie niestandardowych interfejsów użytkownika dla każdej platformy, skutkuje to złożonymi i unikalnymi komponentami interfejsu użytkownika, które mogą być kosztowne w tworzeniu i trudne w utrzymaniu w czasie. Oznacza to również pisanie niestandardowych komponentów mostu, aby uzupełnić luki w obsłudze elementów natywnych frameworka. Podobnie jak w przypadku hybryd, ten koszt zmniejsza korzyści płynące z szybkiego i niedrogiego cyklu projektowania, ale w przeciwieństwie do aplikacji hybrydowych, komponenty pomostowe są napisane dla każdej pożądanej platformy w ich ojczystym języku . Oznacza to, że zamiast aplikacji niehybrydowych będących elastyczną alternatywą dla zespołu składającego się głównie z twórców stron internetowych, zespoły wybierające ścieżkę niehybrydową muszą nauczyć się nie tylko konkretnego języka frameworka (np. JSX lub C#), ale także ojczysty język każdej platformy (Java, Obj-C lub Swift).

Zależności innych firm . To ograniczenie przybiera dwie różne formy. W przypadku React Native przyjmuje postać wielu zależności, tj. około 650. W rezultacie istnieje bardzo duża szansa, że ​​w danym momencie co najmniej jedna z tych zależności jest nieaktualna. Oznacza to również, że w przypadku dużej zmiany na poziomie systemu operacyjnego istnieje duże prawdopodobieństwo, że większość lub wszystkie z tych zależności będą wymagały aktualizacji. Potencjalną zaletą jest to, że Facebook używa Reacta, więc w swoim kącie będzie miał 300 funtów goryla.

W przypadku Xamarin problem zależności zewnętrznych polega po prostu na tym, że niezwykle trudno jest je zintegrować w pierwszej kolejności. Xamarin zdaje sobie sprawę z tego problemu i udostępnia narzędzie o nazwie Sharpie. Celem narzędzia jest pomoc w części integracji, ale niestety Sharpie często próbuje skompilować i połączyć nieprawidłowe zasoby, co zmusza programistę do podjęcia żmudnego i czasochłonnego zadania ręcznego modyfikowania niskopoziomowych parametrów kompilacji w celu pomyślnego ukończenia integracja.

Opóźnienie w obsłudze systemu operacyjnego . Aplikacje niehybrydowe są nękane przez ten sam problem, co hybrydowe. Wszelkie ramy pośrednie, które są poza kontrolą programisty i które muszą zostać najpierw zaktualizowane, służą jedynie opóźnieniu procesu aktualizacji aplikacji w celu obsługi zaawansowanych użytkowników. Co więcej, jak wspomniano wcześniej, poleganie na pośrednich ramach może być bólem głowy dla kierowników projektów przy planowaniu, ponieważ terminy tych ram są tak nieznane.

Wsparcie długoterminowe (React Native) . Ten problem jest specyficzny dla React Native i odnosi się do dziwnego faktu, że do tej pory Facebook nie zobowiązał się do długoterminowego planu wsparcia dla swoich ram. Można powiedzieć, że jest to niewielkie ryzyko, ponieważ firma wykorzystuje własne ramy dla swoich aplikacji mobilnych, ale warto zatrzymać się, aby każdy kierownik projektu zastanowił się, dlaczego Facebook odmówił komentarza na ten temat.

Wybór właściwego podejścia

Gdy koszt nie jest najważniejszy, Rysunek 2 pokazuje, że pisanie aplikacji natywnych jest prawie zawsze najlepszym wyborem, gdy wykorzystuje się skład zespołu programistów do wymagań aplikacji. Kiedy jest mniej inżynierów programistów niż liczba pożądanych platform, robi się nieco ciekawiej. W takim przypadku użycie Reacta jest właściwym wyborem, jeśli zespół ma bardzo napięty harmonogram wydań; w przeciwnym razie przejście na natywny jest nadal najlepszą opcją.

Kiedy zespół jest przede wszystkim zespołem programistów stron internetowych i wymagany jest dostosowany UX, lepiej jest, aby niektórzy członkowie zespołu zmienili czapki lub dodać kilku członków zespołu, aby uczynić swoje aplikacje natywnymi. Naprawdę nie ma wykonalnej, możliwej do utrzymania opcji frameworka, jeśli aplikacja wymaga elementów niestandardowych, co robi wiele aplikacji.

Jeśli jednak niestandardowy UX nie jest wymagany, wtedy, w zależności od harmonogramu wydań, lepiej wybrać Ionic lub React. Jeśli czyjś zespół nie ma czasu na naukę JSX, to Ionic jest właściwym wyborem. W przeciwnym razie lepiej wybrać React, ponieważ wymaga on już wielu zależności zewnętrznych, a dodanie kolejnych nie wpłynie na cykl rozwoju.

Gdy koszt projektu jest głównym problemem, zwykle istniejący skład zespołu staje się mniej priorytetem, ponieważ pierwszym krokiem byłoby umieszczenie odpowiedniego zespołu w celu wykonania planu projektu dla przewidywanych kosztów. Jak pokazano na rysunku 3 , aplikacje natywne mają wyższy koszt początkowy niż ich odpowiedniki WODE, ale mają również wyższy potencjalny UX. Co więcej, aplikacje WODE zawsze będą ograniczone w swoim UX, niezależnie od tego, ile pieniędzy i zasobów zostanie włożonych w projekt.

Mam nadzieję, że ten artykuł rzucił nieco światła na zalety i wady różnych ścieżek rozwoju mobilnego, a także pomógł w ocenie składu zespołu w odniesieniu do wymagań aplikacji i kosztów projektu. Jego przesłaniem nie było przekazanie, że frameworki WODE są gorsze i nigdy nie należy ich szukać, ale raczej, że chociaż istnieją uzasadnione przypadki użycia, w których nie można przejść na natywny, należy w pełni zrozumieć konsekwencje takiego postępowania.