Wątek przeniesiony 2020-05-25 10:40 z Kariera przez cerrato.

Mobile Developer- przyszłość branży

0

Cześć piszę dzisiaj z pytaniem: jak według was będzie wyglądała przyszłość mobile developerów? Chodzi mi o ilość ofert na rynku i zarobki w porównaniu do ludzi piszących w innych technologiach z podobnym doświadczeniem.

Wiem, że często będą to wasze subiektywne opinie, ale chciałbym wiedzieć jak Wy widzicie przyszłość tej gałęzi, w jakim kierunku zmierza (czy może zostanie zastąpiona), jaki stack technologiczny będzie na topie etc.

Miłego :)

2

Myślę, że aplikacje natywne zawsze będą najlepszym wyborem w przypadku dużych, średnich albo nietrywialnych projektów. Pytanie co za 5 czy 10 lat będzie natywne. iOS myślę, że dalej będzie stał jak stoi. Google może będzie chciał przejść na Fuchsie. Zasadne jest też pytanie, czy teoretycznie porzucenie Androida przez Google, oznaczałoby śmierć tej platformy. Bardzo prawdopodobne, że nie.

Na pewno coraz bardziej popularne będą platformy hybrydowe, ale uważam, że to natywne aplikacje będą dalej wiodły prym. Może wyłoni się dobre natywne rozwiązanie do współdzielenia kodu. Na to mam nadzieję, ale ciężko wróżyć.

1

React Native/Flutter + do tego wiedza ze Swifta i Kotlina, która pozwala naskrobać coś natywnie jak jest potrzeba. Z takim stackiem otwiera się sporo drzwi i kasa jest niezła, ale oczywiście zbudowanie tego trochę trwa.

0

Ja robię iOS Natywnie i uważam że fluttery i inne wymysły przejmą jakiś mały % tanich aplikacji. Jestem całkowicie spokojny o swoją niszę.

1

Napisałeś "przejmą", co już jest błędem, bo to że sporo nowych apek powstaje w RN/Flutter i bardzo dużo działa już produkcyjnie jest faktem. Oczywiście dalej mamy przypadki gdzie w projekcie są dwa osobne teamy, które dowożą dwie natywne apki na Androida/iOS, ale jest to kosztowne i trzeba mieć rzeczywiście konkretne potrzeby żeby było to opłacalne. Nie wspominając już, że RN (Flutter częściowo też) pozwala dowozić aplikacje również na weba czy desktop (Windows/MacOS) i np. takich Microsoft bardzo mocno w to inwestuje:

https://www.theregister.co.uk/2019/11/07/microsoft_react_native/
https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-ditching-electron-react-native-uwp

0

SwiftUI pozwala na OSX dowozić aplikacje poprzez Catalyst na OSX z takim samym codebase. Na androidzie i windowsie może flutter ,,zrobi robotę'' lepszą niż xamarin i phonegap ale jakoś google się nie chwali market share aplikacji we Flutterze na AppStore. Napisałem przejmą w kontekście takim że firmy co nie mają kasy na dwa teamy będą (jak w przypadku xamarina i phonegapa i innych rzeczy) decydować się na rozwiązania crossplatformowe (tańsze) które historycznie zawsze kończyły się przepisaniem apki na native (np airbnb).

Apple nie wpuści fluttera bo sam robi swoje podobne technologie. Bez Apple Flutter będzie kolejnym react native'em który czasami jest dobrym pomysłem ale i tak lepiej natywnie.

1

decydować się na rozwiązania crossplatformowe (tańsze) które historycznie zawsze kończyły się przepisaniem apki na native (np airbnb)

Bzdura do kwadratu. Przykład pierwszy z brzegu:

https://blog.discord.com/how-discord-achieves-native-ios-performance-with-react-native-390c84dcd502
https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify

Apple nie wpuści fluttera bo sam robi swoje podobne technologie. Bez Apple Flutter będzie kolejnym react native'em który czasami jest dobrym pomysłem ale i tak lepiej natywnie.

Ale co masz na myśli pisząc, że Apple nie wpuści Fluttera? Przecież nie ma żadnych ograniczeń żeby robić apki na iOS przy użyciu Fluttera, a wiekszości API jest już dostępnych bezpośrednio z bibliotek dla Fluttera. Jeśli nie jest to przecież możesz to zrobić sam:

Flutter uses a flexible system that allows you to call platform-specific APIs whether available in Kotlin or Java code on Android, or in Swift or Objective-C code on iOS.

0
ktw_diver napisał(a):

SwiftUI pozwala na OSX dowozić aplikacje poprzez Catalyst na OSX z takim samym codebase. Na androidzie i windowsie może flutter ,,zrobi robotę'' lepszą niż xamarin i phonegap ale jakoś google się nie chwali market share aplikacji we Flutterze na AppStore. Napisałem przejmą w kontekście takim że firmy co nie mają kasy na dwa teamy będą (jak w przypadku xamarina i phonegapa i innych rzeczy) decydować się na rozwiązania crossplatformowe (tańsze) które historycznie zawsze kończyły się przepisaniem apki na native (np airbnb).

Apple nie wpuści fluttera bo sam robi swoje podobne technologie. Bez Apple Flutter będzie kolejnym react native'em który czasami jest dobrym pomysłem ale i tak lepiej natywnie.

Z jednej strony masz racje bo: każda platforma ma swoje jak to kiedyś w apache cordova było określone dziwactwa. Żeby pisać dobre rzeczy będziesz musiał znać i ios, andka i abstrakcje w postaci fluttera/rn. I to dlatego, że np trzeba ogarnąć bt, trzeba ogarnąć sobie też pewnie gps etc. I kiedyś zawsze się mówiło, że koszt produkcji większej apki hybrydowej jest jednak większy w późniejszych etapach. Ostatnio jednak mam wrażenie, że ta tendencja się trochę zmienia może przez dojrzałość tych rozwiązań hybrydowych. Ja osobiście przyglądam się dla fluttera jednak nie wydaje mi się, że apki natywne znikną z rynku - a nawet jeśli nadal będzie trzeba znać natywne rozwiązania (może w mniejszym stopniu) więc co najwyżej próg wejścia w mobile będzie większy.

0
don_draper napisał(a):

decydować się na rozwiązania crossplatformowe (tańsze) które historycznie zawsze kończyły się przepisaniem apki na native (np airbnb)

Bzdura do kwadratu. Przykład pierwszy z brzegu:

https://blog.discord.com/how-discord-achieves-native-ios-performance-with-react-native-390c84dcd502
https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify

Apple nie wpuści fluttera bo sam robi swoje podobne technologie. Bez Apple Flutter będzie kolejnym react native'em który czasami jest dobrym pomysłem ale i tak lepiej natywnie.

Ale co masz na myśli pisząc, że Apple nie wpuści Fluttera? Przecież nie ma żadnych ograniczeń żeby robić apki na iOS przy użyciu Fluttera, a wiekszości API jest już dostępnych bezpośrednio z bibliotek dla Fluttera. Jeśli nie jest to przecież możesz to zrobić sam:

Flutter uses a flexible system that allows you to call platform-specific APIs whether available in Kotlin or Java code on Android, or in Swift or Objective-C code on iOS.

No podesłałeś artykuły o technologiach na jakie zdecydowały się te firmy. Mój argument jest bardzo prosty, że native > nie native. Xamarin też potrafi stukać w natywne api bez problemu.

  • Flutter to kolejne dependency które jest utrzymywane przez firmę trzecią, a nie przez dostawcę platformy na którą developujesz. Apple deprecatuje/zmienia implementację/dodaje coś w SDK. Klienci czekają na update. Twój czas reakcji jest wydłużony o czas reakcji google'a jeżeli nie poradzisz sobie samemu z pisaniem plugina do nowych rzeczy.
  • Biblioteka Fluttera (Cupertino UI z tego co pamiętam) jest niekompletna. Zachowanie UI na IOS jest inne i po prostu wiesz że nie masz do czynienia z aplikacją natywną (gesty nawigacyjne, deceleration na listach, overscroll - wszystko zachowuje się inaczej). UI też po prostu przycina, w natywnych aplikacjach nie spotykam się z takim czymś.
  • Co do wpuszczania - nie masz pewności, że Apple nie uwali fluttera tak jak uwalił pare lat temu aplikacjie webowe (takie co odpalają webview i renderują w nim reactem swoje rzeczy) :). Tak jak pisałem, Apple robi swój produkt który od strony developerskiej jest równie przyjemny jak Flutter (SwiftUI).

Ogólnie flutter będzie sobie żył i będzie w nim praca, ale native zawsze będzie lepszy (mówię o iOS, nie o Androidzie - tam Google pokazuje dlaczego nie warto długoterminowo korzystać z ich rozwiązań. Od kolegów z pracy słyszę, że jest taki syf jeżeli chodzi o liczbę dostępnych libów do robienia UI/nawigowania że nie wiadomo z czego korzystać i co będzie uwalone w przyszłości.) .

Native nie zostanie wyparty przez rozwiązania hybrydowe. Apple nie daje nawet oficjalnie zainstalować swojego systemu (OSX) na nie-macach, trzyma swój ekosystem w zamkniętej pięści. Uważacie, że Apple pozwoli zdominować kurę znoszącą złote jaja (AppStore) innej firmie (Google)? Inny projekt Google'a (PWA) jest tak ograniczony na IOS że nikt tego nie używa :).

0

Ogólnie flutter będzie sobie żył i będzie w nim praca, ale native zawsze będzie lepszy

To trochę jak kilka(naście) lat temu twierdzenie, że lepiej pisać w samym WinAPI, bo wszystkie biblioteki, frameworki, MFC czy inne Delphi generują nadmiarowy kod, który tylko zamula i spowalnia. Może do pewnych specyficznych działań rzeczywiście native nie ma konkurencji, ale w większości przypadków takie rozwiązania w stylu Fluttera czy RN dają rade całkowicie dobrze.

0

@ktw_diver: Ja się z Toba zgadzam, że być native iOS developerem będzie na pewno opłacalne i to też jest ciekawy kierunek rozwoju(zresztą sam chce mocniej w to zainwestować), ale mylisz się po prostu z tym, że Flutter/RN to taka nisza, które nie może konkurować w żaden sposób z apkami natywnymi, bo biorąc pod uwagę kontekst biznesowy, wybór technologii hybrydowej w wielu przypadkach będzie lepsze.

0
cerrato napisał(a):

Ogólnie flutter będzie sobie żył i będzie w nim praca, ale native zawsze będzie lepszy

To trochę jak kilka(naście) lat temu twierdzenie, że lepiej pisać w samym WinAPI, bo wszystkie biblioteki, frameworki, MFC czy inne Delphi generują nadmiarowy kod, który tylko zamula i spowalnia. Może do pewnych specyficznych działań rzeczywiście native nie ma konkurencji, ale w większości przypadków takie rozwiązania w stylu Fluttera czy RN dają rade całkowicie dobrze.

Jak to mówili? Write once, run anywhere?

1

Moim zdaniem Apple ubije konkurencję crossplatformową jeżeli będzie zbyt poważna, nie będzie chciał oddać deweloperów Google'owi. Fuschia to temat mocno niepewny i może zostać jeszcze ubite przez Google. Przez najbliższe 3 lata nic się raczej nie zmieni :P

1

@cerrato:
Tylko tu piszesz o strachu przed ewolucją z tym WinAPI.

Tutaj nie ma ewolucji w robieniu software'u tylko masz równoległy projekt który stara się konkurować z innym (Flutter vs Native). Przypominam że piszę w kontekście iOS'a - Na Androidzie się nie znam.

Native nie jest tak jak WinAPI przestarzałe i toporne. Tworzenie UI wymagało odświeżenia i je otrzymało - w SwiftUI piszesz tak samo szybko i przyjemne jak we Flutterze. Moim głównym argumentem w tej dyskusji jest długofalowy support i możliwość rozwoju w projektu.

Aplikacje natywne są płynniejsze i dostają wszystkie bajery od Apple'a (np. nowy sposób prezentacji widoków modalnych. Od razu na flutterze widać że tego nie ma.)

@don_draper
Z apkami hybrydowymi masz wartość biznesową do pewnego momentu. Jak projekt jest już bardzo skomplikowany i masz mnóstwo kodu do obsługi androidowych i iosowych funkcjonalności za jakąś abstrakcją to sprawa się często wtedy rypie i szybciej i taniej byłoby utrzymywać dwie apki natywne.

0

Aplikacje natywne są płynniejsze i dostają wszystkie bajery od Apple'a (np. nowy sposób prezentacji widoków modalnych. Od razu na flutterze widać że tego nie ma.)

Ale czy przeciętny user na to zwróci uwagę? Może zauważy, że apka zachowuje się troszkę inaczej, ale co z tego? Będzie miał jakieś przyciski do wciskania, jakieś pola z tekstem i nawet jak będą się zachowywać trochę odmiennie, żadna tragedia się nie stanie, aplikacja będzie w pełni funkcjonalna i działająca. Tak samo jak np. w Windowsach (nowszych) aplikacja może dodać swoje polecenia do kliknięcia prawym klawiszem na przycisku na pasku zadań (np. "nowe okno" w przypadku przeglądarki internetowej - jak widać na poniższym obrazku). Niektóre aplikacje z tego korzystają, inne nie - ale nie przeszkadza to w niczym szczególnym. Podobne jest z mobilkami - to, że nie będzie w 100% zgodne z najnowszym UI nie jest dużym problemem.

screenshot-20200525110943.png

2

@cerrato:
Na iOS klienci są przyzwyczajeni do tego że cały system reaguje na dotyk nawet jeżeli czegoś nie da się zrobić. Ciężko jest to wytłumaczyć, ale praktycznie wszystkim na iOS da się ,,bawić'' i system bardzo płynnie reaguje na każdą naszą interakcję. Tu nie chodzi o zachowanie pojedyńczych textfieldów czy tam innych labeli. Jeżeli korzystasz normalnie z Andka to ciężko to będzie wyjaśnić.

Weźmy taki głupi modal o którym wyżej wspominałem. Natywny modal sa się dismissować gestem, można nim jeździć po całym ekranie. Pod spodem wszystko ma bardzo fajny efekt springu z dampingiem i efekt jest taki że ten modal ,,żyje''. Praktycznie każda kontrolka natywna ma coś takiego w sobie co sprawia że cały system jest integralny i spójny. Możesz być pewien że podobnie będzie się zachowywać modal w aplikacjach Telefon czy Ustawienia i że w podobne interakcje możesz wejść z każdą inną aplikacją natywną. Klient uczy się w ten sposób interakcji z systemem. Teraz jak dasz mu aplikację hybrydową w której modala nie może zdismissować takim gestem do którego przywykł, to na pewno się troszeczkę zirytuje. Aplikacje hybrydowe nie potrafią tego replikować dobrze. Na iOS jest to bardzo widoczne, na Androidzie nie bo tam nie przykłada producent aż takiej wagi do UX i płynności wszystkiego.

Największą zaletą aplikacji na iOS jest ich jakość (ludzie są raczej zgodni z tym że na iOS nawet google'owe aplikacje działają i wyglądają lepiej). Przyczyną nie jest tylko proces review u Apple ale właśnie bardzo przemyślane SDK dzięki któremu aplikacje są spójne z resztą systemu.

0

Pewnie masz rację. Ja Apple się brzydzę i nie używam ;)

W każdym razie - to, co napisałeś dało mi do zrozumienia, że wszystko zależy od perspektywy, z której się patrzy. Bo są apki dla mas, które muszą być piękne i dopieszczone, ale są tez aplikacje pisane dla konkretnych klientów, np. narzędzie dla handlowca, który może w terenie sprawdzić stany magazynowe, albo rodzic, który będzie miał wgląd w oceny swojego dziecka. I o ile rzeczywiście, w przypadku apki dla mas (np. jakaś aplikacja do monitorowania treningów na siłowni) to użytkownik może się zniechęcić brakiem gadżetów, o których piszesz, to katalog produktów hurtowni motoryzacyjnej, który będzie wykorzystywany przez handlowców oraz klientów, raczej takich rzeczy nie potrzebuje. Mi jest bliżej do drugiego wariantu, w którym ważna jest funkcjonalność i przydatność, a nie dzwonki i gwizdki, ale rozumiem, że inni mogą mieć inne spojrzenie i dla nich taki brak animacji okienka z komunikatem może być problemem.

1
ktw_diver napisał(a):

Największą zaletą aplikacji na iOS jest ich jakość (ludzie są raczej zgodni z tym że na iOS nawet google'owe aplikacje działają i wyglądają lepiej).

You make my day.

0

Jasne. Jest tak jak piszesz - jeżeli aplikacja jest typu enterprise i przeznaczona do umożliwienia komuś pracy to po prostu musi działać i nie wkurzać.

Jednak robiąc apkę natywną (na iOS) ułatwiasz sobie pracę bo klienci są już przyzwyczajeni do poruszania się po innych aplikacjach natywnych (gesty wstecz, force touch, kontrolki i menusy kontekstowe) i nie musisz ich tego w ogóle uczyć. Potrafią sami się poruszać po systemie bardzo szybko bo aplikacja działa tak jak cały iOS i inne aplikacje natywne.

To tak jakby nagle na Andku we flutterze stwierdzili że nie ma przycisku wstecz systemowego tylko musisz klikać strzałkę. Niby nic a by irytowało sporą część ludzi. :)

@cerrato
Też hejciłem Apple ale prawie 6 lat temu mnie pracodawca zmusił żebym na to zaczął kodzić i bardzo mi się teraz podoba. Może dlatego że nie kupuję sprzętu i nie muszę patrzeć na ceny tylko zazwyczaj dostaję :D.

1

Ja z kolei nie znam się na Apple, ale znam się trochę na Androidach i na desktopie (Windows). I widzę od kilku lat tendencję do rezygnacji z 100% natywnego wyglądu kontrolek i okien, na rzecz własnego designu, dostosowanego do konkretnego produktu, czy firmy. Na Windows często są to niestandardowe skóry i mało która aplikacja wygląda tak, jak natywne okna Windows, w WPF bardzo łatwo projektuje się niestandardowy wygląd aplikacji. Na Androidzie też jest analogicznie, aplikacje są często tak brandowane, że wygląd wszystkiego jest inny, niż domyślny wygląd kontrolek systemu. Flutter bardzo to ułatwia i tutaj większość firm stawia na identyczny, inny niż systemowy, a spójny pomiędzy platformami wygląd.

Przykład pierwszy z brzegu:
iOS: https://apps.apple.com/pl/app/iko/id597657968?l=pl
Android: https://play.google.com/store/apps/details?id=pl.pkobp.iko

Jak widać, aplikacja nie ma wyglądu natywnego, łącznie z przyciskami, polami edycyjnymi, menu głównym, jak i dialogami. Za to ma dokładnie identyczny wygląd na obu platformach, praktycznie co do piksela.

Taki trend powoduje, że odtworzenie 100% natywnego look and feel traci na znaczeniu tak naprawdę. Ważniejsze staje się osiągnięcie dokładnie takiego samego wyglądu na obu platformach. Flutter mam wrażenie też idzie bardziej w tym kierunku. Tam po prostu wszystko wygląda identycznie na wszystkich platformach, a można też różnicować wygląd, ale ten niby natywny look and feel jest też tylko odtworzony, bo żadna kontrolka nie jest natywna - a tylko odpowiednio ostylowana, żeby wyglądała jak natywna.

2
Meini napisał(a):

Taki trend powoduje, że odtworzenie 100% natywnego look and feel traci na znaczeniu tak naprawdę. Ważniejsze staje się osiągnięcie dokładnie takiego samego wyglądu na obu platformach. Flutter mam wrażenie też idzie bardziej w tym kierunku.

Czyli nie ważne co jest dobre dla użytkownika (natywne kontroli do których przywykł). Ważne jest co sobie biznes zażyczy

1

Patrząc na opinie o aplikacji IKO, nie widzę żeby użytkownicy narzekali, że wygląda inaczej niż natywnie. Pamiętaj, ze biznes nie idzie wbrew oczekiwaniom użytkowników (rozumianej jako większość użytkowników), bo to pieniądze użytkowników napędzają każdy produkt. Malkontenci zawsze się znajdą i będą narzekać, tak jak ty teraz. Ale to nie ma znaczenia. Przykłady takie jak IKO pokazują, że to nie 100% natywny wygląd jest dla użytkowników najważniejszy, a intuicyjność, stabilność i funkcjonalność aplikacji. Używanie natywnych kontrolek nie jest żadną wartością samą w sobie, a każda firma chce się wyróżniać oryginalnym designem swojej aplikacji.

1

@Meini:
Klienci na andku przyzwyczajeni są do X, na iOS do Y. Ujednolicanie ma jedną wartość przy kampaniach marketingowych - banki reklamują swoje apki w TV i wtedy spójny wygląd ma sens. Onboardingowanie klientów też jest łatwiejsze jak możesz pokazać mu coś na andku i będzie miał tak samo na iOS. Ale to raczej wartości tylko dla niektórych.

Opiniami firm których produktem nie jest aplikacja tylko np. usługi bankowe bym się nie sugerował bo takie osoby często oceniają apki przez pryzmat tego że łatwo da się przelew zrobić, blikiem zapłacić i mało awarii jest. Równie dobrze dla nich mogliby korzystać z mobilnej strony internetowej.

2

aplikacje się skończyły. Teraz przyszłością będą zdecentralizowane linki xD
tak TechLead mówi.

1
ktw_diver napisał(a):

@Meini:
Klienci na andku przyzwyczajeni są do X, na iOS do Y. Ujednolicanie ma jedną wartość przy kampaniach marketingowych - banki reklamują swoje apki w TV i wtedy spójny wygląd ma sens. Onboardingowanie klientów też jest łatwiejsze jak możesz pokazać mu coś na andku i będzie miał tak samo na iOS. Ale to raczej wartości tylko dla niektórych.

Opiniami firm których produktem nie jest aplikacja tylko np. usługi bankowe bym się nie sugerował bo takie osoby często oceniają apki przez pryzmat tego że łatwo da się przelew zrobić, blikiem zapłacić i mało awarii jest. Równie dobrze dla nich mogliby korzystać z mobilnej strony internetowej.

Wątpię. Większość aplikacji, nie tylko bankowych, ma swój własny, inny niż systemowy wygląd. Klienci w ogóle nie są przywiązani do wyglądu systemowego. Są przywiązani co najwyżej do nawigacji i sposobu obsługi. Jak słusznie zauważyłeś, klienci oceniają to, co mogą w aplikacji zrobić (w tym przypadku kod blik albo przelew), a nie to czy wygląda identycznie jak reszta systemu. Wystarczy, że będzie wyglądać estetycznie, nikt nie wymaga wyglądu natywnego.

P.S. obecnie prawie wszystko można zrobić równie dobrze na stronie internetowej, więc to akurat żaden argument. Gdyby wszyscy tak tęsknili za natywnym wyglądem, to ta aplikacja by się nie obroniła.

1 użytkowników online, w tym zalogowanych: 0, gości: 1