Smartfony zdobywają coraz więcej miejsca pod słońcem, nie tylko jako narzędzie do konsumowania zdjęć kotów i filmów xxx, ale także jako narzędzie pracy. Dlatego rośnie zapotrzebowanie na rozwój mobilny. Ogólnie przyjmuje się, że prawdziwe i fajne są Objective-C/Swift dla iOS i Java/Kotlin dla Androida. Bez wątpienia to prawda i fajnie, ale istnieje wiele rzeczywistych scenariuszy, w których korzystanie z platform międzyplatformowych jest bardziej preferowane w porównaniu z narzędziami natywnymi.

Niektórzy programiści oczekują, że wieloplatformowe frameworki rozwiążą wszystkie ich problemy życiowe, podczas gdy inni postrzegają je z wrogością. Oba „wojujące obozy” mają swoje własne błędne wyobrażenia spowodowane niezrozumieniem tego, jak i co działa. To dodaje oliwy do ognia, ponieważ zamiast argumentów technicznych używa się emocji.

Również wśród programistów, zwłaszcza początkujących, istnieje wiele mitów na temat międzyplatformowych frameworków mobilnych. W naszym artykule przeanalizujemy najpopularniejsze z nich. Ale najpierw spójrzmy na rozwój mobilny oczami firmy, która daje pieniądze na cały IT blackjack.

Dlaczego potrzebujemy narzędzi wieloplatformowych?

Historycznie rzecz biorąc, na rynku komputerowym zawsze istniała konkurencja, a każdy producent dostarczał optymalny zestaw tzw. natywnych (natywnych) narzędzi do tworzenia aplikacji dla swoich systemów operacyjnych i urządzeń.

Narzędzia natywne = dostarczone przez właściciela ekosystemu.

Wszystkie inne oznaki „narodzenia” są WTÓRNE — zachowanie i interfejs aplikacji, dostęp do funkcji systemu operacyjnego, wydajność i tak dalej.

Ponadto prawie zawsze okazywało się, że natywne narzędzia są ze sobą niekompatybilne nie tylko na poziomie języków programowania, przyjętych konwencji i architektur, ale także na poziomie mechanizmów pracy z systemem operacyjnym i bibliotekami. W rezultacie, aby zaimplementować te same algorytmy i interfejsy, konieczne było napisanie aplikacji dla kilku środowisk w różnych językach programowania, a następnie utrzymanie jej na zasadzie „jednej komendy na platformę”. Jednocześnie możliwości i wygląd aplikacji na różne platformy ah prawie zawsze identyczne o 90%. Dla ciekawości porównaj implementację swoich ulubionych programów na iOS i Androida.

Drugi ważny punkt- dostępność niezbędnej wiedzy i doświadczenia w zespole: jeśli nie, nauka zajmie trochę czasu.

W celu rozwiązania obu tych problemów od dawna na rynku pojawiły się wieloplatformowe narzędzia programistyczne (nie tylko mobilne), oferujące:

  • zmaksymalizować wspólną bazę kodu w jednym języku programowania, aby produkt był łatwiejszy w rozwoju i utrzymaniu;
  • wykorzystaj posiadane kompetencje i specjalistów do wdrażania aplikacji na nowych platformach.

Ponieważ istnieje obecnie wiele języków programowania (i środowisk) (i specjalistów, którzy je znają), istnieje sporo narzędzi do rozwoju międzyplatformowego. Jako przykład skupimy się na popularnych w naszej okolicy PhoneGap, Xamarin, React Native i Qt.


Teraz możemy porozmawiać o mitach.

Mit 1. Magia

Najczęstszym mitem, który nawiedza umysły początkujących programistów, jest wiara w superalgorytmy (i superprogramistów, którzy je stworzyli), które w magiczny sposób zmieniają aplikacje międzyplatformowe w natywne. Coś w stylu „konwertowania kodu JavaScript na Swift, a następnie kompilacji aplikacji Swift”. Mit ten podsycają sami twórcy narzędzi wieloplatformowych, obiecując w rezultacie stworzenie „natywnych aplikacji”. I nie chodzi o to, że ktoś jest tu sprytny, ale bogata wyobraźnia i brak zrozumienia podstawowych mechanizmów czasami skłania deweloperów do myślenia o szamańskich sztuczkach.

Główną zasadą leżącą u podstaw rozwiązań wieloplatformowych jest podział kodu na dwie części:



Aby połączyć „rodzimy” świat ze światem „międzyplatformowym”, konieczne jest użycie specjalnego most, to on określa możliwości i ograniczenia cross-platformowych frameworków.

Podczas korzystania z mostu wydajność jest zawsze zmniejszana przez konwersję danych między „światami”, a także konwersję wywołań API i bibliotek.

Tak więc wszystkie aplikacje wieloplatformowe muszą mieć natywną część, w przeciwnym razie system operacyjny po prostu nie będzie w stanie ich uruchomić. Przyjrzyjmy się więc bliżej, jakie systemowe API i mechanizmy udostępniają same iOS, Android i Windows. Przejdźmy do następnego mitu.

Mit 2. Nie natywny!

Mamy więc wieloplatformową część aplikacji, która żyje w środowisku wirtualnym i współdziała z systemem operacyjnym za pośrednictwem infrastruktury frameworka i mostu.

Wszystkie systemy operacyjne: iOS, Android i Windows UWP - zapewniają dostęp do następujących podsystemów (zestawów systemowych API):

  • WebView (przeglądarka internetowa wbudowana w aplikację) jest używana w aplikacjach hybrydowych opartych na PhoneGap i działa de facto jako lokalne środowisko uruchomieniowe witryny;
  • Silniki JavaScript są używane w React Native i jego odpowiednikach do szybkiego wykonywania kodu JS i wymiany danych między Native a JS;
  • OpenGL ES (lub DirectX) jest używany w silnikach gier i aplikacjach opartych na Qt/QML lub podobnym do renderowania interfejsu;
  • Podsystem UI odpowiada za natywny interfejs użytkownika aplikacji, co jest istotne dla React Native i Xamarin.


Aplikacje wieloplatformowe mają część natywną i taki sam pełny dostęp do systemowych interfejsów API, jak aplikacje „natywne”. Różnica polega na tym, że wywołanie metody systemowej przechodzi przez infrastrukturę mostu i frameworka:

widok internetowy- aplikacja działa w przeglądarce internetowej, podobnie jak witryna jednostronicowa. Brak dostępu do natywnych kontrolek (przycisków, list itp.), wszystko oparte na HTML/CSS/JavaScript. Z drugiej strony web developer poczuje się jak kaczka do wody.

Silniki JavaScript stał się popularny stosunkowo niedawno, ponieważ podobny mechanizm został dodany do iOS dopiero w wersji 7.0. Spośród funkcji warto zastanowić się nad koniecznością serializacji złożonych struktur danych przenoszonych między środowiskami JavaScript i Native do JSON. Jeśli krótko opiszemy taką klasę rozwiązań, to w środowisku JavaScript wykonywany jest kod JS sterujący aplikacją natywną.

OpenGL ES i DirectX są podsystemami niskiego poziomu i służą do rysowania interfejsu użytkownika w grach i na przykład Qt/QML. Oznacza to, że podczas korzystania z OpenGL / DirectX programiści sami rysują kontrolki i animacje, które mogą być tylko podobne do natywnych. Z drugiej strony jest to podsystem niskiego poziomu o bardzo wysokiej wydajności, dlatego jest używany również w międzyplatformowych silnikach gier.

Wszystkie aplikacje wieloplatformowe mają część natywną, a zatem potencjalnie taki sam pełny dostęp do systemowych interfejsów API jak „natywne”. Ponadto aplikacje wieloplatformowe są budowane i pakowane przez „natywne” narzędzia w „natywne” pakiety instalacyjne. Kluczowym pytaniem jest, jak zorganizowana jest interakcja między częścią wieloplatformową a częścią natywną. Na przykład wewnątrz WebView lub przy użyciu Open GL ES / DirectX nie ma możliwości stworzenia interfejsu użytkownika z całkowicie natywnym wyglądem i odczuciem, ale jest pełny dostęp do GPS, powiadomień Push i innych funkcjonalności. A kod JavaScript lub C# może całkiem swobodnie kontrolować natywną aplikację i jej zachowanie, zapewniając całkowicie natywny wygląd.

Podsumowując – tak, „nienatywny” pod względem użytych narzędzi programistycznych (nie od Apple, Google). Jednak aplikacja może być całkowicie natywna pod względem dostępu do systemowych interfejsów API i zapewniać całkowicie natywny wygląd i działanie. I przechodzimy do następnego mitu.

Mit 3. Kula o kuli

Należy tutaj rozumieć, że natywne API nie są domyślnie uważane za kule (chociaż są tu różne opinie), więc całe oburzenie kieruje się na część międzyplatformową. Oczywistym jest, że środowisko wykonawcze (np. WebView, silnik JavaScript czy Mono) też trudno nazwać kulą – dojrzałe, dojrzałe rozwiązania z długą historią.

Wygląda na to, że kula jest sposobem, w jaki wieloplatformowa część integruje się z natywną. Aby lepiej zrozumieć, jak działają różne frameworki, posłużymy się przykładem PhoneGap, Xamarin, Qt i React Native, aby przyjrzeć się tym mechanizmom systemu operacyjnego, które są używane do łączenia części międzyplatformowych i natywnych.

Zaczniemy od PhoneGap. Poniżej znajduje się architektura aplikacji najwyższego poziomu oparta na tym frameworku.



Aplikacja PhoneGap jest w rzeczywistości aplikacją natywną, która wyświetla WebView jako jedyną kontrolkę interfejsu użytkownika. To dzięki niemu odbywa się interakcja z rodzimą częścią. Wszystkie standardowe WebViews w iOS, Android i Windows UWP obsługują możliwość dodawania natywnych programów obsługi dla właściwości i metod JS. Jednocześnie kod JS żyje w swoim odizolowanym środowisku i nie wie nic o części natywnej - po prostu ściąga potrzebne metody JS lub zmienia niezbędne właściwości JS. Wszystko jest wewnątrz standardowego webowego DOM, który po prostu dodaje nowe elementy związane z natywną implementacją.



Tworząc aplikacje na React Native, programista prawie zawsze będzie musiał zaimplementować natywną część w Objective-C, Java lub C#, a zarządzanie samą natywną aplikacją będzie pochodzić z JavaScript. W rzeczywistości silnik JavaScript to element WebView, który jest dostępny osobno. Interakcja przechodzi przez ten sam most JS, co w przypadku PhoneGap. Jednak w React Native kod JS nie zarządza drzewem DOM sieci, ale natywną aplikacją.

Należy pamiętać, że ze względu na ograniczenia iOS (nie ma możliwości implementacji JIT), kod JavaScript jest interpretowany w locie, a nie kompilowany. Ogólnie rzecz biorąc, nie wpływa to znacząco na wydajność w prawdziwe aplikacje ale warto o tym pamiętać.

Rozważmy teraz klasyczne platformy Xamarin. iOS i Xamarin. Android, ponieważ platforma Xamarin. Forms (obsługująca platformę Windows UWP) jest do nich dodatkiem.



Xamarin używa biblioteki Mono do interakcji z docelowym systemem operacyjnym, co umożliwia wywoływanie kodu natywnego przy użyciu mechanizmu P/Invoke. Służy również do komunikacji z natywnymi API w iOS/Android. Oznacza to, że wrappery w C# są tworzone dla wszystkich publicznych natywnych metod API, które z kolei wywołują systemowe API. W ten sposób dostęp do wszystkich systemowych interfejsów API można uzyskać z aplikacji platformy Xamarin.

I na koniec spójrzmy na Qt, ponieważ jest wiele pytań na ten temat od doświadczonych programistów.



Qt jest "rzeczą samą w sobie", ma zarówno plusy, jak i ograniczenia. Biblioteki Qt po prostu łączą się z systemowymi API C++ znajdującymi się we wszystkich systemach operacyjnych. Do rysowania interfejsu użytkownika wykorzystywane są mechanizmy niskopoziomowe, ale własny silnik graficzny obsługujący stylizację natywną. Jednocześnie w systemie Android musisz uzyskać dostęp do interfejsu Java API za pośrednictwem specjalnego mostka (mostek JNI), a w przypadku platformy Windows UWP użyj konwertera wywołań Open GL ES na DirectX, ponieważ Open GL nie jest dostępny dla platformy UWP.

Podsumowując: wszystkie cross-platformowe frameworki wykorzystują standardowe natywne funkcje systemów operacyjnych, są dojrzałe, tworzone przez doświadczone zespoły i społeczność open source przy wsparciu gigantów branży IT. I wreszcie czas na najbardziej „silny” argument.

Mit 4. Powoli

Ważnym atutem, którego ludzie lubią używać w sporach dotyczących platform międzyplatformowych, jest niska wydajność. Ponownie, w zależności od tego, z czym porównywać i w których papugach liczyć.

Przypomnijmy, że cechą aplikacji wieloplatformowych jest równoległe istnienie dwóch światów połączonych mostem:

  • PhoneGap: HTML/JS i natywna Java / Objective-C / C#;
  • React Native: JS i natywna Java / Objective-C / C#;
  • Xamarin: Mono i natywna Java / Objective-C;
  • Qt: C++ i natywna Java/Objective-C.

Dlatego przy porównywaniu wydajności należy wziąć pod uwagę szybkość pracy:

  • część wieloplatformowa;
  • część natywna;
  • most.

Jeśli na przykład wpiszesz w wyszukiwarkę, zareagujesz natywną vs szybką wydajność, możesz zobaczyć wiele różnych testów, a wiele z nich zauważa, że ​​wydajność gwałtownie spada podczas aktywnego korzystania z mostu, w tym aktywnego manipulowania interfejsem użytkownika z kodu międzyplatformowego. W przypadku Xamarin sytuacja wygląda podobnie – część wieloplatformowa jest bardzo szybka i porównywalna z natywną w przetwarzaniu danych, jednak przy korzystaniu z mostu wydajność może spaść. Qt generalnie działa na poziomie C++, który sam w sobie jest szybki. Jeśli weźmiemy pod uwagę rozwiązania oparte na PhoneGap, to tutaj wydajność będzie w dużym stopniu zależna od WebView, ale nadal nie należy aktywnie zmieniać interfejsu użytkownika w kodzie JavaScript ani wykonywać obliczeń naukowych.

Powoli? Tak, spadki wydajności są możliwe ze względu na nieudolną interakcję z systemem operacyjnym przez most. Jednak same światy międzyplatformowe są tak samo szybkie, jak te rodzime.

Aplikacje mobilne stały się nieodzownym towarzyszem naszego życia. Z ich pomocą możemy nie tylko dobrze się bawić i upraszczać sobie życie, robić zakupy czy zamawiać określone usługi przez Internet, ale także promować nasz biznes, powiększać bazę klientów, a co za tym idzie pomnażać zyski. A jeśli nikt nie może wątpić w potrzebę stworzenia aplikacji dla swojego biznesu, to przy wyborze typu aplikacji mobilnej mogą pojawić się pewne trudności.

Wszystko nowoczesne aplikacje dla urządzeń mobilnych można podzielić na natywne i wieloplatformowe, a każda z tych dwóch grup ma swoje własne silne strony jak również jego braki.

Aplikacje natywne to aplikacje opracowane specjalnie dla konkretnej platformy w odpowiednim języku programowania. Tak więc podczas tworzenia aplikacji na Androida używana jest Java, a dla aplikacji IOS Objective-c lub Swift. Tworząc takie projekty, specjaliści biorą pod uwagę wszystkie cechy platform, zwracając szczególną uwagę na projektowanie UI/UX, wymagania/rekomendacje twórców systemów operacyjnych, a także najnowsze trendy w branży mobilnej. Jeden specjalista nie będzie w stanie w pełni opanować wszystkich powyższych języków, dlatego aby opracować jeden natywny produkt na różne platformy, konieczne jest połączenie różnych programistów, a to jest dodatkowy koszt, a czas rozwoju będzie imponujący. Ale jednocześnie aplikacje zostaną „wyostrzone” pod konkretną platformę, uzyskają dostęp do wewnętrznych zasobów i funkcji urządzenia oraz będą działać tak wydajnie, jak to tylko możliwe.

Pomimo sporej listy zalet programowania natywnego, klienci nie zawsze chcą poświęcać czas i pieniądze na ich rozwój, łącząc w proces tworzenia kilku mistrzów. Najlepszą opcją w takich przypadkach jest rozwój wieloplatformowy, który pozwala tworzyć aplikacje na dowolną platformę przy użyciu standardowych technologii internetowych. W takim przypadku opracowanie może wykonać jedna osoba, która ma: niezbędna wiedza i doświadczenie z HTML5, JavaScript i CSS3. Programy wieloplatformowe można skompilować do pliku .apk dla systemu Android i pliku .ipa dla systemu IOS. W ten sposób na podstawie jednego opracowania można uzyskać dwie aplikacje na popularne systemy operacyjne, wydając na to mniej czasu i pieniędzy. Jednak takie rozwiązania mają również swoje wady, dlatego bardzo pożądane jest indywidualne podejście do każdego konkretnego przypadku i wybranie najbardziej odpowiedniej opcji - rozwoju natywnego lub wieloplatformowego.

Części klienckie i serwerowe aplikacji

Większość poważnych aplikacji ma swoją własną stronę kliencką, często nazywaną frontendem, oraz stronę serwerową, czyli backend. Frontend odpowiada za to, co widzisz na ekranie Twojego urządzenia mobilnego, czyli za całą wizualną reprezentację aplikacji, w tym wygląd, rozmiar i lokalizację okien, menu, przycisków, strzałek i wszelkich innych elementów. Frontend odpowiada również za reakcję aplikacji na określone działania użytkownika mające na celu przechodzenie do różnych sekcji aplikacji, wywoływanie nowych menu i tak dalej.

Backend jest częścią serwerową aplikacji i znajduje się na zdalnym serwerze, który może być zlokalizowany w dowolnym miejscu i kontrolowany za pomocą szerokiej gamy narzędzia programowe. Relacja pomiędzy częściami klienta i serwera realizowana jest poprzez API (interfejs programowania aplikacji). Innymi słowy, API jest rodzajem pośrednika między frontendem a backendem, który przesyła żądania ze strony klienta do serwera, zwracając dane niezbędne dla użytkownika.

Rozwój frontendu

Część kliencka aplikacji jest niezwykle ważna, ponieważ sam użytkownik sobie z nią poradzi, a jego ogólna idea aplikacji będzie zależeć od wygody frontendu. Można go tworzyć zarówno ręcznie, ale do tego trzeba dobrze orientować się w HTML5, CSS3 i java-script oraz przy pomocy tzw. frameworków. W pierwszym przypadku często wykorzystywane jest środowisko programistyczne Apache Cordova, powszechnie znane również jako PhoneGap. Korzystając z tej struktury, możesz tworzyć aplikacje dla dowolnej platformy przy użyciu technologii internetowych, które Cordova konwertuje na kod zrozumiały dla konkretnej platformy. Cordova otwiera praktycznie nieograniczone możliwości dla twórców stron internetowych, którzy nie muszą uczyć się Objective-C lub Swift, Java lub Kotlin, aby tworzyć aplikacje dla konkretnych systemów operacyjnych.

Chociaż Cordova nie ma ograniczeń w interfejsie użytkownika i logice, frameworki oferują gotowe rozwiązania szablonowe. Z jednej strony znacznie przyspiesza to i upraszcza proces tworzenia, ponieważ specjalista może korzystać z gotowych przycisków, list, pól wejściowych, kart i innych elementów UI. Z drugiej strony specjalista może używać do programowania tylko tych narzędzi i elementów, które są dostępne w wybranym frameworku. Najpopularniejszym z nich jest Ionic, który pozwala na tworzenie aplikacji wieloplatformowych na każdy gust. Ten framework ma dużą wbudowaną kolekcję elementy standardowe, które wizualnie naśladują aplikacje natywne, ale ich wygląd można zmienić w razie potrzeby. Jednocześnie programista może podłączyć wiele dodatkowych wtyczek, które rozszerzają możliwości frameworka ionowego, a projekt stworzony na tym frameworku można uruchomić bezpośrednio w oknie przeglądarki i ocenić, jak będzie wyglądał i działał. tworzona aplikacja bez konieczności posiadania emulatora lub instalacji na smartfonie.

Rozwój zaplecza

Podczas gdy po stronie klienta zaangażowani są projektanci i programiści ze znajomością HTML, CSS, JS i frameworków, w backend zaangażowani są programiści o innym profilu. Do konfiguracji serwerów można wykorzystać różne języki programowania i narzędzia, najważniejsze jest odpowiednie skonfigurowanie ich pracy i interakcji z częścią kliencką. Tutaj musisz użyć odpowiednie systemy zarządzanie bazami danych (bazy danych). Może to być tradycyjna baza danych MySQL, Redis, PostgreSQL lub dowolna inna baza danych (na przykład MongoDB), która nadaje się do realizacji konkretnego projektu i w której programista back-end jest dobrze zorientowany. Programiści mogą używać PHP, NodeJS, C#, Ruby, Python, Java i innych języków programowania do tworzenia strony serwerowej aplikacji.

Specjaliści z mobile-studio KitApp podchodzą do kwestii tworzenia frontendu i backendu w sposób kompleksowy i maksymalnie odpowiedzialny. Nasi programiści stworzą dla Ciebie wieloplatformową aplikację o dowolnej złożoności i kierunku tak szybko i skutecznie, jak to możliwe! Skontaktuj się z nami, a nasi specjaliści szybko odpowiedzą na wszystkie Twoje pytania!

Aplikacje wieloplatformowe - być albo nie być? Pytanie nie jest proste, ponieważ każda firma ma swoje cele i wymagania dotyczące aplikacji mobilnych. Ale dzisiaj na pewno dowiemy się, jaki rozwój jest dla Ciebie odpowiedni.

Co to są aplikacje międzyplatformowe?

Aplikacje wieloplatformowe to aplikacje, które są rozwijane, a następnie uruchamiane jednocześnie w systemie Android i iOS. Istotą rozwoju jest źródło aplikacja jest tłumaczona na język natywny, czyli zrozumiały dla konkretnego urządzenia mobilnego. W rezultacie program może wchodzić w interakcje z zainstalowanym na nim systemem operacyjnym.

Przypomnijmy: aplikacje natywne, w przeciwieństwie do aplikacji wieloplatformowych, są napisane dla konkretnego systemu operacyjnego.

Zalety rozwoju wieloplatformowego

  • rozbudowa bazy użytkowników dzięki pojawieniu się aplikacji jednocześnie w kilku sklepach;
  • pojedynczy kod źródłowy pozwala uniknąć konieczności zatrudniania wielu programistów dla każdej platformy;
  • 75% bazy kodu aplikacji wieloplatformowej można ponownie wykorzystać, dostosowując ją do nowych projektów.

Wady rozwoju wieloplatformowego

1. Wysoka zależność od urządzenia mobilnego

Aplikacje wieloplatformowe zwykle nie działają w trybie offline. Dlatego ich możliwości są w dużym stopniu uzależnione od posiadania przez użytkownika stabilnego połączenia z Internetem. Wersja system operacyjny i model urządzenia są również ważne. Aplikacja wieloplatformowa niemal gwarantuje obniżenie wydajności urządzenia starszego niż rok do dwóch lat. Podczas gdy natywna aplikacja będzie działać stabilnie nawet na starożytnym gadżecie z przestarzałym oprogramowaniem. Jeśli więc nie chcesz, aby Twoi klienci czytali gniewne recenzje o tym, jak Twoja aplikacja w końcu „dokończyła” czyjś smartfon, wybierz programowanie natywne.

2. Nieprzyjazny interfejs użytkownika

Użytkownicy są tak uzależnieni od wygląd zewnętrzny i funkcjonalności swoich gadżetów, aby od zainstalowanych na nich aplikacji oczekiwać maksymalnej responsywności. Chcą mieć pewność, że każdy przycisk jest na swoim miejscu, że strona przewija się z optymalną dla nich prędkością, a po każdej podjętej akcji następuje natychmiastowa reakcja. Aplikacje wieloplatformowe są zwykle trudne do dostosowania do urządzenia i nie mogą pochwalić się wysoką wydajnością.

Problem polega na tym, że nie ma wytycznych dotyczących rozwoju międzyplatformowego - standardów programistycznych od twórców systemu operacyjnego. Dlatego wieloplatformowa aplikacja stworzona „na Androida” nie będzie wygodna dla użytkownika iOS i vice versa. Możesz oczywiście tworzyć osobne projekty dla każdej platformy, ale pod względem kosztów pracy będzie to równoznaczne z utworzeniem dwóch różnych aplikacji, choć w tym samym języku.

3. Walka o dominację wśród narzędzi programistycznych

Na rynku wieloplatformowych rozwiązań programistycznych konkurencja z każdym dniem staje się coraz ostrzejsza. Do tej pory najbardziej popularne wśród programistów są React Native i Xamarin, ale na przykład Vue Native może je wyprzedzić. W takim przypadku byli liderzy wyścigu stracą najważniejszą zaletę - obsługę kodu operacyjnego. A to może się zdarzyć za pomocą dowolnego narzędzia wieloplatformowego.

Natywny rozwój nie boi się takiego problemu. Wprowadzanie nowych narzędzi odbywa się stopniowo, a znajomość kilku języków programowania, która jest obowiązkowa dla wąskiego specjalisty, pozwoli mu szybko uporać się ze wszystkimi nowinkami. Ponadto wokół każdego systemu operacyjnego istnieją ogromne społeczności zawodowe, w wyniku czego wszelkie powstałe trudności rozwiązuje się, wyszukując podobny problem na forach, gdzie tysiące osób jest gotowych zasugerować i pomóc go rozwiązać.

Która aplikacja jest odpowiednia dla Twojej firmy?

Przed udzieleniem odpowiedzi na to pytanie niezwykle ważne jest przeanalizowanie swojego biznesu. Segmenty konsumenckie, wartość zasobów czasowych i finansowych, pożądana głębokość integracji aplikacji z urządzeniami użytkowników oraz jasno określone cele długoterminowe – minimum, od którego będzie zależał Twój wybór. Ale ułatwimy Ci to, jeśli odpowiesz na odpowiednie pytania już teraz.

1. Z czego korzystają Twoi odbiorcy?

Jeśli wiesz, że stosunek liczby użytkowników iOS i Androida wśród Twoich klientów jest bliski 50/50, wybierz programowanie natywne. To pokaże, że jednakowo szanujesz potrzeby wszystkich swoich klientów, niezależnie od poziomu ich dochodów.

Związek między wyborem urządzenia mobilnego a poziomem wypłacalności po raz kolejny potwierdził App Annie. W wyniku badania liczby pobrań i sprzedaży aplikacji mobilnych w Google Play oraz Sklep z aplikacjami w pierwszym kwartale 2018 roku okazało się, że użytkownicy smartfonów z Androidem pobrali o 135% więcej aplikacji niż odwiedzający sklep iOS. Jednocześnie App Store przyniósł swoim właścicielom o 85% więcej przychodów niż Google Play.

Droga do sukcesu jest oczywista: graj na dwóch polach jednocześnie. Dokładniej dwa sklepy. Wystarczy obliczyć, w którym z nich aplikacja powinna pojawić się jako pierwsza. Oczywiście, jeśli jednoczesne wydanie nie jest częścią Twojej strategii cyfrowej).

2. Ile masz czasu na rozwój?

Od odpowiedzi na to pytanie zależą koszty finansowe projektu. Faktem jest, że z punktu widzenia czasu poświęconego na rozwój, aplikacja wieloplatformowa tylko wydaje się bardziej opłacalnym rozwiązaniem. W rzeczywistości dostosowanie go do platform może zająć prawie tak długo, jak stworzenie dwóch natywnych aplikacji, ponieważ programiści będą musieli napisać dodatkowe części kodu dla obszarów problemowych.

Przy natywnej aplikacji na pewno nie będzie takich problemów, co jest bardzo ważne dla zachowania wyjątkowo nietolerancyjnych odbiorców błędów i błędów. Według statystyk Compuware, 79% użytkowników jest gotowych do ponownego uruchomienia aplikacji, jeśli nie działała poprawnie podczas pierwszego uruchomienia, ale tylko 16% zgadza się dać jej kolejną szansę. Reszta najprawdopodobniej po prostu odinstaluje program.

3. Z jakich funkcji urządzenia planujesz korzystać?

Mówiliśmy już o tym, że tylko aplikacje natywne są w stanie szybko i bez utraty jakości odtworzyć ciężką grafikę. Ale to zalety techniczne rozwój natywny nie jest ograniczony. Weźmy na przykład aplikację Facebook. Dzięki wydaniu osobnych wersji na Androida i iOS przewijanie stało się płynniejsze, czas ładowania obrazu został skrócony, a wszystkie problemy z pamięcią podręczną zostały rozwiązane.


Co więcej, aplikacje natywne mają bezpośredni dostęp do wszystkich usług urządzenia, dzięki czemu możesz uzyskać informacje o lokalizacji użytkownika lub liście kontaktów. Aplikacje wieloplatformowe muszą korzystać ze specjalnych natywnych wtyczek, co negatywnie wpływa na szybkość przesyłania danych i przeciążenia Baran urządzenia.

4. Jakich wyników szukasz?

Strategia cyfrowa to lista celów, które Twoja firma może osiągnąć za pomocą narzędzi cyfrowych. Wybór tego ostatniego w dużej mierze zależy od korzyści, jakie w końcu chcesz uzyskać.


Rozłóż proces punkt po punkcie od pomysłu do wyniku, biorąc pod uwagę wszystkie dostępne zasoby. Odkrycia mogą być najbardziej nieoczekiwane.

Na przykład może się okazać, że przetłumaczenie responsywnej witryny z wieloma funkcjami i interaktywnymi elementami na aplikację wieloplatformową, zgodnie z pierwotnym zamierzeniem, jest zbyt kosztownym zadaniem. Lub wreszcie upewnij się, że witryna mobilna zawsze przegrywa z aplikacją mobilną — tak jak rozwój międzyplatformowy przegrywa z natywną. A wśród powodów znajdź te, o których mówiliśmy powyżej.

Wniosek: wieloplatformowa aplikacja jest korzystna tylko w jednym przypadku - tworzysz wersję demonstracyjną aplikacji, jesteś ograniczony pod względem czasu, pieniędzy i wąskich specjalistów. We wszystkich innych przypadkach aplikacja natywna daje wielokrotnie więcej korzyści, ponieważ jest to jakościowo inny poziom rozwoju.

Wydawałoby się, że mamy tu do czynienia z rozwojem wieloplatformowym, co umożliwia tworzenie uniwersalnych aplikacji na różne platformy. Napisałem aplikację szybciej, od razu ją udostępniłem wszędzie - zysk! I nie jest potrzebny natywny rozwój. Czy jest nadal potrzebny? Zapytaliśmy naszych ekspertów o niuanse obu podejść do tworzenia aplikacji mobilnych.

„Programista mobilny” to szerokie pojęcie. Programista, który wdraża części mobilnego systemu operacyjnego, jest również programistą mobilnym. A jeśli celem jest zostać właśnie takim programistą, musisz zacząć ogólnie od nauki C++, mobilnego systemu operacyjnego i sprzętu urządzeń mobilnych.

Jeśli masz na myśli programistę wdrażającego niestandardowe aplikacje mobilne, musisz zacząć od programowania natywnego.

Dlaczego? Programowanie natywne pozwala lepiej i głębiej badać możliwości konkretnych systemów operacyjnych (i aplikacji dla nich) oraz sprzętu mobilnego.

Z punktu widzenia użytkownika zdecydowanie wygrywa program natywny. Aplikacje natywne działają szybciej, ich interfejs jest bardziej responsywny i znajomy użytkownikom konkretnego mobilnego systemu operacyjnego, lepiej wykorzystują możliwości sprzętowe urządzeń, działają lepiej offline i są mniej „zabugowane”.

Pierwotną ideą rozwoju wieloplatformowego jest zmniejszenie kosztów pracy dewelopera. W skrócie można to wyrazić następująco: „Raz to zrobiłem, działa na wszystko”. Pomysł jest dobry i poprawny (z punktu widzenia dewelopera), ale pojawiają się pytania o jakość. Każda wszechstronność od samego początku wiąże się z kompromisem, a rozwój mobilny nie jest wyjątkiem.

Wybierając rodzaj rozwoju do konkretnego zadania, deweloper musi ocenić, czy ten kompromis jest akceptowalny. Istnieje szereg zadań, w których wykorzystanie wieloplatformowego rozwoju byłoby całkiem uzasadnione, na przykład w projektach testowych, mobilnych wersjach witryn, grach wykorzystujących frameworki, takie jak Unity 3D.

Jednocześnie dla projektów rozwiązujących mobilne problemy biznesowe (przy dużym obciążeniu, konieczności obsługi trybu offline, nastawionych na długoterminowy rozwój) rozwój natywny jest postrzegany jako jedyny optymalny (a dla niektórych zadań jedyny możliwy ) opcja.

Jednocześnie głównymi wadami programowania natywnego są czas programowania (wymagane jest więcej) oraz potrzeba zróżnicowanych zasobów (programistów w różnych natywnych językach programowania). Istnieją sposoby na złagodzenie tych niedociągnięć - na przykład wykorzystanie do programowania pewnego rodzaju platformy aplikacji mobilnych (klasa MEAP), która umożliwia tworzenie aplikacji natywnych.

Zmień na starszą wersję

, Dyrektor ds. Rozwoju Technologicznego firmy informatycznej "ID - Technologie Zarządzania"

Każda wieloplatformowa biblioteka lub framework opiera się na tych samych mechanizmach natywnych, które bezpośrednio implementują programowanie natywne. Tyle, że w przypadku rozwiązań wieloplatformowych przepływy pracy są budowane w taki sposób, aby „wygładzić rogi” pod kątem sprowadzenia interfejsu finalnego rozwiązania do pewnego wspólnego mianownika.

Z reguły uniwersalizm nie zawsze jest odpowiedzią na zadanie stworzenia działającego rozwiązania mobilnego: deweloper pracuje tym lepiej, im głębiej rozumie mechanizmy urządzenia różne procesy od środka, jak mówią, „pod maską”.

Również całkowicie działającym modelem byłoby jednoczesne opanowanie podstawowych elementów obu podejść, nie ma nic niemożliwego w takim zadaniu uczenia się na początkowym etapie. Na przykład taki scenariusz może okazać się całkiem wykonalny i obiecujący: zacznij pracować w paradygmacie wieloplatformowym, a równolegle, samodzielnie lub z pomocą kolegów, przestudiuj, jakie są rodzime możliwości rozwoju obecnych rozwiązań i jak mogą one być stosowane w praktyce.

W tym przypadku łatwiej jest uzyskać całościowe zrozumienie, jak w zasadzie działa proces rozwoju mobilnego, który nazywa się end-to-end. Jest to również przydatne, ponieważ każda, nawet najbardziej zaawansowana, uniwersalna platforma pozostaje w tyle za natywnymi możliwościami: producenci sprzętu i mobilnego systemu operacyjnego często współpracują ze sobą i stale zwiększają możliwości finalnych rozwiązań – możliwości mobilnych platform programistycznych, zwłaszcza rozwiązań międzyplatformowych , nieuchronnie pozostają w tyle .

Na rynku cały czas pojawiają się nowe produkty w segmencie mobile, część z nich znacznie wyprzedza swój czas – weźmy na przykład Samsunga i jego rozwój urządzenia ze składanym ekranem: to oczywiste, że ze względu na radykalnie inny front-end , istniejące platformy programistyczne nie są gotowe na takie rzeczy.

W tym miejscu pomoże dogłębna znajomość platform natywnych: tylko programista z głęboką, systemową wiedzą na temat rozwoju mobilnego, czyli platform natywnych, może zrekompensować naturalne opóźnienie w stosunku do sprzętu i systemu operacyjnego. Tylko taki specjalista będzie mógł zwiększyć funkcjonalność swojego rozwiązania o najnowsze urządzenia mobilne oparte o dostępne w tej chwili niezbyt zaawansowane platformy programistyczne.

Programowanie międzyplatformowe świetnie nadaje się do prototypowania, szybkiego testowania pomysłu itp. Gdy tylko dochodzi do tworzenia naprawdę podstawowych produktów, programista nieuchronnie pojawia się w potrzebie dogłębnego przestudiowania podstawowych elementów procesu, czyli programowania natywnego.

Zmień na starszą wersję

, Dziekan Wydziału iOS Development GeekUniversity, portal edukacyjny GeekBrains

Krótka odpowiedź: jeśli nie masz doświadczenia w programowaniu, to oczywiście musisz wybrać programowanie natywne. Programowanie międzyplatformowe jest dobre dla profesjonalistów, którzy przechodzą z dziedzin pokrewnych do programowania mobilnego. Na przykład, jeśli jesteś programistą front-end z dobrą znajomością JavaScript, korzystając z frameworka React Native (opartego na frameworku React) możesz szybko i bezboleśnie spróbować opanować programowanie mobilne. Podobnie jak w przypadku dewelopera .NET, łatwiej będzie opanować framework Xamarin.

Rozwój wieloplatformowy jest również korzystny dla klienta – łatwiej jest znaleźć jeden zespół programistów, którzy według wspólnego wzorca opracują aplikację na dwie platformy jednocześnie.

Zalety są oczywiste, ale jakie są wady rozwoju wieloplatformowego?! Uważa się, że im bardziej złożona i subtelna funkcjonalność w aplikacji mobilnej, tym trudniejsza, jeśli nie niemożliwa, jej implementacja za pomocą narzędzi wieloplatformowych - często przewyższa to wszystkie zalety narzędzi uniwersalnych. Z mojego doświadczenia wynika, że ​​istnieje kilka dużych firm, które wraz z rozwojem aplikacji zostały zmuszone do porzucenia cross-platform na rzecz rozwoju natywnego. Tak więc w przypadku małych projektów i ewentualnie zadań niezależnych wystarczą rozwiązania ogólne, natomiast w przypadku dużych projektów lepiej sprawdzają się rozwiązania natywne.

Popyt na oba obszary jest dość wysoki, ale na rozwój rodzimy jest nieco wyższy: na prośbę Swifta na hh.ru w Rosji - 369 wolnych, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. Ale reszta zapewniam, że dobry specjalista w żadnej dziedzinie nie będzie.

Zmień na starszą wersję

Na początek należy zauważyć, że każda aplikacja mobilna składa się z kilku warstw:

  • UI - co widzi użytkownik;
  • logika biznesowa - do czego jest napisana aplikacja;
  • inne komponenty platformy - praca z siecią, bazami danych i innymi komponentami systemu, z których korzysta logika biznesowa.

W zależności od konkretnego zastosowania wielkość elementów na tych warstwach może się znacznie różnić. Na przykład aplikacja czytnika wiadomości w witrynie będzie bardzo różniła się od klienta VPN.

Sam rozwój można podzielić na trzy typy: natywny, w pełni cross-platformowy i hybrydowy.

rodzimy rozwój

W programowaniu natywnym wszystkie trzy warstwy są pisane przy użyciu tego samego zestawu narzędzi. Dzięki temu mogą wchodzić ze sobą w interakcje bez dodatkowej złożoności.

Korzyści z rozwoju natywnego:

Rozwój hybrydowy

Ten rodzaj rozwoju łączy oba poprzednie podejścia. Warstwa logiki biznesowej jest budowana jako komponent „przenośny”, a integracja interfejsu użytkownika i platformy jest tworzona przy użyciu standardowych narzędzi. Istnieje kilka języków do pisania logiki ogólnej: C/C++ (dojrzały i potężny), KotlinNative (bardzo aktywnie rozwijany) i JavaScript (najmniej powszechny).

Zalety:

  • najbardziej odpowiednie do tego składniki pozostają natywne;
  • wspólna logika jest tworzona raz.

Wady:

  • jeśli wspólny komponent będzie tworzony przez zespół mobilny, konieczne jest pozyskanie ekspertyzy w innym języku;
  • istnieje narzut na integrację komponentów międzyplatformowych.

Od jakiego rodzaju rozwoju najlepiej zacząć?

Aby odpowiedzieć na to pytanie, musisz zrozumieć, jakie projekty chcesz stworzyć. Małe projekty mogą być czysto wieloplatformowe i będzie to w pełni uzasadnione. Tutaj radzę przyjrzeć się Flutterowi.

Ale dzisiaj zacząłbym od rodzimego rozwoju. Po pierwsze, większość dzisiejszych projektów jest tworzona natywnie. Oznacza to, że będziesz miał więcej możliwości zmiany projektów/firm. Po drugie, z czasem możliwe będzie przejście na hybrydowy rozwój wieloplatformowy. Pozwoli ci to rozwijać się w kwestiach technicznych.

Zmień na starszą wersję

Moim zdaniem najlepiej zacząć od natywnego, a następnie, jeśli naprawdę chcesz, opanować jedno lub więcej narzędzi międzyplatformowych. Wyjątkiem może być tworzenie gier, ponieważ są one pisane głównie w Unity, a jest to silnik wieloplatformowy.

Jeśli mówimy o zaletach programowania natywnego, to dla programisty oznacza to mniej przeszkód i więcej różnych narzędzi do pracy. Będzie miał też więcej źródeł informacji do rozwiązywania złożonych problemów, które pojawiają się w procesie tworzenia aplikacji – nie jest tajemnicą, że porad i trików dotyczących natywnego programowania w Internecie jest o wiele więcej niż przy programowaniu międzyplatformowym.

Dla użytkownika końcowego programowanie natywne oznacza, że ​​aplikacja będzie miała znajome, przewidywalne interfejsy i wzorce zachowań – pod warunkiem, że aplikacja jest napisana zgodnie ze wszystkimi wytycznymi.

Aplikacja wieloplatformowa nie zawsze jest w stanie w pełni dostosować się do wytycznych obu platform, co może powodować dodatkowe trudności dla programisty i użytkownika. Najprostszy przykład- sytuacja z przyciskiem „Wstecz”: w Androidzie jest on obecny na prawie wszystkich ekranach, natomiast w iOS nie. Jeśli tworzysz aplikację wieloplatformową bez tego przycisku, niektórzy użytkownicy Androida mogą odczuwać dyskomfort.

Warto również wspomnieć o różnicach w kosztach rozwoju. Jeśli projekt jest prosty, to wybór rozwoju wieloplatformowego pozwala zaoszczędzić budżet, ponieważ w rzeczywistości nie tworzysz oddzielnych produktów dla różnych platform, ale jeden dla wszystkich. Ale jeśli projekt się rozwinie, szala zacznie przechylać się w przeciwnym kierunku, a rozwój natywny może być bardziej opłacalny.

Jeśli chodzi o szybkość aplikacji, produkty wieloplatformowe są wolniejsze. Na przykład te, które są oparte na technologiach webowych, mają przeglądarkę jako warstwę, co znacznie spowalnia działanie aplikacji.

Zmień na starszą wersję

Wybór podejścia wieloplatformowego lub natywnego zależy w rzeczywistości od dwóch czynników: charakteru rozwoju mobilnego, który osobiście chcesz robić, lub prośby pracodawców, z którymi jesteś zainteresowany współpracą. Jeśli więc np. spojrzymy na Upwork (platformę do wyszukiwania zdalnych specjalistów do projektów i zadań), to widzimy wyraźną przewagę ofert w kierunku Xamarin i React Native. Zalety tutaj są oczywiste: jest tani, szybki i pozwoli na realizację projektów na wszystkich platformach jednocześnie. Jeśli jednak weźmiemy pod uwagę duże firmy IT poszukujące pracowników we własnym zakresie, to duży nacisk kładzie się na rozwój natywny, mimo że ten typ wymaga więcej czasu i jest droższy.

W naszej firmie ustalamy priorytety i wybieramy programowanie natywne, ponieważ pozwala projektantom i programistom na stworzenie płynniejszego, bardziej intuicyjnego UX/UI. Ponadto programowanie natywne daje bardziej elastyczną kontrolę nad funkcjami systemu.

Zmień na starszą wersję

Jeśli chcesz zostać programistą mobilnym, odpowiedź jest oczywista: musisz wybrać dowolne z natywnych środowisk programistycznych i oprzeć się na Objective-C/Swift dla iOS lub Java/Kotlin dla Androida. W takim przypadku wszystkie funkcje systemu są do Twojej dyspozycji, możesz kontrolować prawie każdy niuans.

Jeśli chcesz po prostu napisać program, który będzie działał również na telefonach, to nie możesz dużo myśleć i wybierać, w czym bardziej jest twoja dusza lub w czym masz jakieś godne uwagi doświadczenie: C++, React Native, Xamarin czy pięćset tysięcy Frameworki JS do rozwoju międzyplatformowego. Lub nawet kontynuuj tworzenie własnych [responsywnych] stron internetowych.

Szczerze mówiąc, jestem raczej sceptyczny co do samego pomysłu wieloplatformowego rozwoju na tak różnych (i rozbieżnych) platformach, jak Android i iOS. Żaden z dostawców nie lubi „niewłaściwych” deweloperów, którzy próbują siedzieć na dwóch krzesłach jednocześnie. Wszyscy starają się powiązać programistów z narzędziami i środowiskami i nie ma tendencji do konwergencji w dającej się przewidzieć przyszłości. Co tu dużo mówić, Apple w tym wyścigu nawet porzucił OpenGL, najbardziej wieloplatformową ze wszystkich bibliotek po Curl, ale teraz mają swój własny Metal, który wydaje się robić to samo, tylko lepiej i w innym języku.

Z drugiej strony bardzo często rozwój mobilny to tworzenie dwóch aplikacji, które wyglądają tak samo dla jakiejś usługi sieciowej. Klienci nie zawsze są gotowi zapłacić za dwa produkty, które wyglądają zupełnie nie do odróżnienia, więc zapotrzebowanie na wieloplatformowe technologie programistyczne istnieje i, co prawda, jest dość wysokie. Programiści też nie mają nic przeciwko oszczędzaniu, zwłaszcza jeśli chcą sprzedawać aplikację mobilną, nie ma ochoty na naukę Swift/Kotlin, ale JS/C# jest już na wyciągnięcie ręki.

Oczywiście rozwój wieloplatformowy niesie ze sobą wiele nieoczywistych niuansów. Wszystkie uniwersalne rozwiązania zmuszają do budowania zamków w piasku: albo opierając się na skomplikowanych i delikatnych rozwiązania technologiczne(jak Xamarin) lub na urządzeniach mobilnych Silniki JavaScript jak React Native. Jednocześnie dostawcy platform nawet nie myślą o wspieraniu żadnego z rozwiązań, a każda aktualizacja natywnego SDK jest dużym bólem głowy dla każdego wieloplatformowego frameworka. Nie mówiąc już o takich specyficznych dla systemu funkcjach jak dostęp do aparatu, pęku kluczy czy nawet banalnej galerii zdjęć, którą każdy z różnym skutkiem próbuje ominąć. Deweloperzy, którzy wybierają uniwersalną ścieżkę, są zakładnikami swoich ram i często rozwój, który obiecywał znaczne oszczędności, zamienia się w walkę z prowizją.

Również często w rozwiązaniach wieloplatformowych zwyczajowo rezygnuje się z tego, co określa się terminem user experience (UX): wiele frameworków próbuje używać kontrolek, które są jak najbardziej ogólne dla obu systemów i prawie zawsze to rozwiązanie jest równie niewygodne dla wszystkich . Albo zwolnij. Albo z mody. Lub rozładowuje baterię. Kontynuuj listę samodzielnie.

Wyróżniają się aplikacje wieloplatformowe, których jądra są napisane na niskim poziomie, najczęściej dla wszystkich systemów operacyjnych: w językach takich jak C/C++. W tym przypadku zwyczajowo uogólnia się użycie kodu obsługującego logikę biznesową, a interfejs jest pisany dla każdej platformy osobno. Najlepiej byłoby, gdyby można było uniknąć powielania krytycznej części aplikacji, zachowując jednocześnie wrażenia użytkownika charakterystyczne dla każdej platformy. Jednak w prawdziwym życiu sprawy są bardziej skomplikowane. Na przykład Dropbox przez kilka lat z rzędu próbował żyć z niskopoziomowym rdzeniem, ale ostatecznie z wielu powodów zrezygnował i teraz jest zadowolony z aplikacji na platformę natywną. Zainteresowanych odsyłam do ich ciekawego artykułu na ten temat.

Moim zdaniem oszczędzanie na cross-platformowych frameworkach jest zawsze iluzoryczne. Prawdopodobnie w niektórych trywialnych projektach, gdzie aplikacja jest tylko wersją strony głównej, super zoptymalizowaną pod kątem urządzeń mobilnych, działa uogólnione podejście. W innych przypadkach ryzykujesz powtórzenie losu Dropbox. Moja rada jest taka, jeśli chcesz zostać programistą mobilnym, zainwestuj w naukę platformy. Zawsze się opłaci, nawet jeśli będziesz musiał uczestniczyć w projekcie międzyplatformowym.

Zmień na starszą wersję

, Starszy programista w Accenture Tver Technology Center

Rynek aplikacji mobilnych aktywnie się rozwija, a zestaw technologii do ich rozwoju odpowiednio się powiększa. Istnieje wiele narzędzi, których możesz użyć.

Do programowania natywnego na platformie Android jest Java lub wrapper na JVM - Kotlin. W przypadku iOS możesz użyć Objective-C lub otoki nad nim - Swift. Są to wszystkie języki OOP, które odziedziczyły wiele po Smalltalk i C.

Do rozwoju wieloplatformowego używany jest teraz Flutter od Google, do którego musisz znać Dart. Lub React Native z Facebooka.

Dla początkującego programisty mobilnego najprawdopodobniej decydującym czynnikiem będzie jego przeszłe doświadczenie i znajomość języków. Jeśli podstawą jego zestawu narzędzi jest Java, będzie mógł znacznie szybciej poznać świat programowania mobilnego za pośrednictwem platformy Android, korzystając z tej samej Javy lub Kotlina.

Jednocześnie Objective-C dla iOS zaczerpnął wiele z Smalltalka, a także Javy, więc jeśli chcesz, możesz dokonać wyboru na korzyść iOS. Pamiętaj jednak, że tworzenie Androida może odbywać się na Windows lub Linux, ale iOS wymaga MacOS X. Ale dla programisty JavaScript ze znajomością React, React Native jest oczywiście najszybszym sposobem. Podobnie jak dla deweloperów Darta, wybór będzie na korzyść Fluttera.

Po tym, jak początkujący programista zorientuje się, jak wygląda rozwój mobilny, jakie są plusy i minusy wybranej ścieżki, sam zdecyduje, czy pracować z jednym podejściem, czy rozwiązywać problemy za pomocą rozwiązań międzyplatformowych.

Takie podejście ma swoje zalety: metoda wieloplatformowa umożliwia nieco szybsze udostępnienie projektu w środowisku produktywnym, zużywając mniej zasobów. Ponadto jest łatwiejszy w utrzymaniu. Ale ma też oczywiste wady zarówno dla programisty, jak i użytkownika. Na przykład programista nie musi znać natywnych technologii, ale należy wziąć pod uwagę wytyczne platformy, ponieważ aplikacja napisana zgodnie z wytycznymi iOS będzie sprawiać trudności użytkownikom Androida i vice versa.

Aplikacje wieloplatformowe nie mogą osiągnąć tego samego poziomu integracji urządzeń, co aplikacje natywne. Oznacza to, że jeśli aplikacja mówi o interakcji z urządzeniem, takim jak aparat, kalendarz lub używanie moc obliczeniowa urządzeń, łatwiej to osiągnąć przy użyciu natywnego podejścia, a będzie to szybsze i bardziej produktywne.

Tworząc aplikację wieloplatformową, specjaliści biorą pod uwagę możliwości frameworka, który nakłada ograniczenia. Warto też wziąć pod uwagę, że do rozwoju produktu na technologiach natywnych potrzebni są specjaliści od każdej platformy.

Jeśli pracujesz jako freelancer lub masz na celu pokrycie maksymalnej liczby urządzeń przy minimalnych funduszach, skup się na rozwoju międzyplatformowym w przypadku skupienia się na rozwiązania mobilne lub praca front-endowa.

Jakie są główne zalety i wady mobilnego rozwoju natywnego i wieloplatformowego? Sam rozwój natywny jest kosztowny, ponieważ firma musi zainwestować w dwa zespoły – iOS i Android. W przypadku prostych aplikacji szybkość programowania Flutter / React Native jest szybsza.

Ale plusem jest to, że infrastruktura jest już ukształtowana i zrozumiała. Masz dostęp do dowolnych zasobów urządzenia i możesz rozwijać się pod inteligentny zegarek, samochody i nie tylko.

Rozwój międzyplatformowy również jest fajną rzeczą. Ale nie jest jeszcze wysoko rozwinięty na rynku pracy IT w Rosji. Rozsądni specjaliści - licz na palcach. Infrastruktura ramowa jest młoda, ale sytuacja stopniowo zmienia się na lepsze. To rozwinięcie umożliwia pisanie na kilku urządzeniach jednocześnie. Nawet jeśli piszesz na przykład we Flutterze, łatwo integruje się z kodem natywnym.

Zmień na starszą wersję

Rozwój wieloplatformowy ma na celu szybkie rezultaty i znaczne oszczędności budżetowe - piszemy jeden kod na wszystkie urządzenia. Obszary jego zastosowania to albo rozwiązanie do użytku wewnętrznego, gdzie użyteczność produktu nie jest tak ważna, a funkcjonalność odgrywa dominującą rolę, albo stworzenie szybkiego projektu „pilotażowego”, gdy klient musi pokazać zasadę lub pomysł aplikacji. Ponadto, jeśli nie ma dokładnego zrozumienia urządzenia, z jakim systemem operacyjnym będzie oglądany prototyp, wyjściem jest rozwój międzyplatformowy. Musisz jednak z góry zrozumieć, że wszystkie urządzenia mają inną architekturę, więc fizycznie jest prawie niemożliwe wykonanie wysokiej jakości aplikacji na tylko jednym kodzie międzyplatformowym. W złożonych scenariuszach będziesz musiał napisać kod natywny. Dodatkowo, ze względu na swoją specyfikę, rozwój wieloplatformowy wiąże się z kosztami, które nie pozwalają na osiągnięcie maksymalnej wydajności aplikacji. Jest to zrozumiałe, w tym przypadku pośredni kod międzyplatformowy musi zostać przetłumaczony dla każdej z platform, co sprawia, że ​​aplikacja jest bardziej „ciężka” ze względu na to, że oprócz kodu funkcjonalnego zawiera ona również jego środowisko wykonawcze.

Wyraź inną opinię

Wszystko jasne, przedstaw wnioski

Więc jakie podejście do rozwoju powinieneś przyjąć?

Wszystko zależy od zadania. Jeśli potrzebujesz napisać prototyp aplikacji na wiele platform lub wersja mobilna witryny, możesz szukać platform międzyplatformowych. Dzięki nim prawdopodobnie napiszesz aplikację szybciej niż przy programowaniu natywnym, zwłaszcza jeśli pracujesz na frameworku podobnym do zwykłego narzędzia, takiego jak React Native.

Z drugiej strony uniwersalność aplikacji wieloplatformowych musi zostać w jakiś sposób zrekompensowana. Gdzieś wyskakuje „nienatywny” element interfejsu, gdzieś interakcja z systemem jest gorsza, gdzieś spada prędkość pracy itp. Pomimo tego, że natywny rozwój wymaga więcej zasobów, wiele firm go preferuje, ponieważ na wyjściu jest bardziej stabilny i natywnie wyglądający produkt.

W związku z tym, jeśli dopiero zaczynasz programowanie mobilne, lepiej byłoby najpierw wykonać programowanie natywne. W tym celu możesz znaleźć więcej informacji w Internecie, lepiej zrozumiesz możliwości platformy i nie będą Cię niepokoić indywidualne niuanse rozwoju międzyplatformowego. Co więcej, jeśli zdecydujesz się w przyszłości na rozwój międzyplatformowy, zdobyta wiedza na pewno nie będzie Ci przeszkadzać.

Przypominamy, że możesz zadać pytanie ekspertom, a my zbierzemy na nie odpowiedzi, jeśli okaże się interesujące. Pytania, które zostały już zadane, można znaleźć na liście problemów. Jeśli chcesz dołączyć do grona ekspertów i wysłać odpowiedź od swojej firmy lub od Ciebie osobiście, napisz na , powiemy Ci, jak to zrobić.

Rozwój wieloplatformowy pozwala na stworzenie aplikacji mobilnej, która będzie działać jednocześnie w środowiskach iOS i Android. Jest to budżetowa alternatywa dla tworzenia aplikacji dla każdego systemu operacyjnego z osobna.

Funkcje rozwoju wieloplatformowego

Tworzenie jednej aplikacji na różne platformy jest jednocześnie dobre i złe. Ano dlatego, że można to zrobić szybciej i taniej niż kilka aplikacji dla każdego systemu operacyjnego. A to źle, bo kompromis odbija się na działaniu aplikacji.

Te cechy należy wziąć pod uwagę przed rozpoczęciem projektu:

  • W środowisku wieloplatformowym kod jest pisany raz. Aby aplikacja działała na innym systemie operacyjnym, kod jest tłumaczony na inny język programowania. Czas i pieniądze poświęcone na rozwój są 1,5 razy mniejsze.
  • Aplikacje mogą nie działać poprawnie. W rozwoju wieloplatformowym niemożliwe jest uwzględnienie wszystkich niuansów pracy z architekturą każdego systemu operacyjnego, więc aplikacje mogą działać wolniej niż te zaprojektowane specjalnie dla systemu iOS lub Android.
  • Interfejs i wymagania projektowe dotyczące elementów różnią się w zależności od systemu operacyjnego.. Na przykład w iOS nie ma przycisku Wstecz, jak w Androidzie. Podczas opracowywania zunifikowanego projektu należy wziąć pod uwagę ten punkt: w iOS przycisk albo pozostanie, ale nie będzie działał, albo będzie musiał zostać wycięty ręcznie, a to dodatkowa praca z kodem.

Większość błędów przejścia z jednej platformy na drugą jest naprawiana ręcznie, ale niemożliwe jest całkowite rozwiązanie problemów związanych z adaptacją do „nienatywnego” systemu operacyjnego.

Więc rozwój międzyplatformowy jest zły?

Nie, rozwój wieloplatformowy jest w porządku, o ile nie wymagasz od niego więcej, niż może dać.

Opcję tę można wybrać w następujących przypadkach:

  • Obejmuj wszystkie systemy operacyjne przy ograniczonym budżecie. Jeśli grupy docelowej bardziej aktywnie korzystając z iOS lub Androida, możesz zacząć od aplikacji natywnej dla jednego systemu operacyjnego. Jeśli od razu ważny jest maksymalny zasięg, lepiej wybrać opcję wieloplatformową.
  • Sprawdź niszę. Jeśli jest obiecujący pomysł, ale nie ma pewności, że się sprawdzi, ryzykowne jest natychmiastowe zainwestowanie dużego budżetu w rozwój. Warto zacząć od rozwoju wieloplatformowego, badać reakcje użytkowników i na tej podstawie podejmować strategiczne decyzje.
  • Aplikacja nie wykorzystuje złożonej animacji i nie wykonuje obliczeń. Operacje te poważnie obciążają urządzenie, a wieloplatformowa aplikacja nie jest zoptymalizowana pod kątem pełnego wykorzystania zasobów konkretnej platformy.
  • Aplikacja korzysta tylko z podstawowych funkcji urządzenia. Wyświetlaj informacje, przesyłaj pliki, korzystaj z geolokalizacji, złóż zamówienie – z tym wszystkim poradzi sobie wieloplatformowa aplikacja. Wymagana jest głębsza integracja możliwości urządzenia - będziesz musiał wybrać programowanie natywne.
  • Aplikacja korporacyjna dla pracowników. Jeśli aplikacja jest przeznaczona do wąskich zadań wewnętrznych i ludzie będą z nią pracować za pomocą osobistych gadżetów, najlepszym rozwiązaniem będzie aplikacja wieloplatformowa.

Nie ma uniwersalnej odpowiedzi na pytanie, czy możliwe jest zastosowanie wieloplatformowych rozwiązań w Twoim projekcie. Wypełnij poniższy formularz: przeanalizujemy Twój projekt i wybierzemy najlepszą opcję jego realizacji.