To jest 38. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tworzeniu aplikacji na platformę iOS. Merytoryczne rozmowy o IT wspiera polecaj.home.pl – program partnerski, w którym zyskujesz nawet 400 złotych za polecenie hostingu. www.polecaj.home.pl. Przypominam, że w poprzednim odcinku poruszyłem temat budowania wizerunku firmy programistycznej. Chcę poszerzać horyzonty ludzi z branży IT. Wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty będę to robił z sukcesem. Nazywam się Krzysztof Kempiński i życzę ci miłego słuchania. Odpalamy!

 

Krzysztof: Cześć! Dzisiaj moim gościem jest programista iOS z ponad dziesięcioletnim doświadczeniem oraz lider zespołów programistycznych. Poza programowaniem zainteresowany tematyką produktywności w ciągłym poszukiwaniu idealnego modelu pracy. Uwielbia elektroniczne gadżety. Prywatnie szczęśliwy mąż i ojciec dwójki dzieci. Moim i waszym gościem jest dzisiaj Marcin Bieda. Cześć Marcin! Bardzo miło cię gościć w podcaście. Cieszę się, że zgodziłeś się wystąpić. Fajnie jest mieć cię tutaj.

Marcin: Cześć Krzysiek! Witam drodzy słuchacze. Właściwie jesteśmy świeżo po WWDC 19. Nagrywamy to tydzień później, więc powinienem zacząć od klasycznej iOSowej wejściówki pod tytułem: „I’m so excited to be here!”. Ale nasłuchałem się już tego tak dużo przez ostatnie dni, że aż mnie to nudzi. Czasami się zastanawiam, że Apple z jednej strony stawia na kreatywność, a z roku na rok te same teksty. Mogliby coś popracować nad tym. Dzięki przede wszystkim Krzysiek za zaproszenie. Jestem naprawdę zaszczycony występując w podcaście, którego słucham od pierwszego odcinka. Pamiętam jak zaczynałeś, pamiętam przerwę. Bardzo ucieszyłem się, że wróciłeś z kolejnymi odcinkami. Praktycznie każdy odcinek miałem okazję wysłuchać. Mam nadzieję, że nasza pogawędka związana iOS będzie niosła jakąś wartość dla słuchaczy. My sobie możemy pogadać i towarzysko spędzić czas, ale jednak słuchacze poświęcają swój czas i liczą, że coś z tego podcastu wyciągną dla siebie.

Krzysztof: Cieszę się tym bardziej że jesteś moim gościem. Zdradziłeś po części temat naszej rozmowy. Będzie to programowanie aplikacji mobilnych na iOS. Ja trochę iOS i tworzenia aplikacji na tę platformę traktuję lekko sentymentalnie, bo miałem taką przygodę. Stworzyłem kilkanaście aplikacji i wypuściłem, ale do tego dojdziemy. Każdy odcinek rozpoczynam pytaniem, czy słuchasz podcastów? Podziel się, proszę listą swoich ulubionych?

Marcin: Słucham podcastów. Nie słuchałem, ale zacząłem słuchać odkąd zacząłem dojeżdżać dłużej do pracy i hobbystycznie więcej się ruszać, więcej biegać. Początkowo eksperymentowałem z audiobookami, w które wkręciłem się jak na Polaka przystało w  trakcie urlopu remontując mieszkanie. W pewnym momencie przerzuciłem się na podcasty i tak już zostało. Mam kilka swoich podcastów, których w miarę regularnie słucham, tak jak ten, w którym dzisiaj mam przyjemność występować. Biznes w IT Piotra Buckiego, podcasty Dominika Juszczyka, podcasty Radka Budnickiego. Jest też miejsce na klasykę na Michał Szafrański czy Marek Jankowski. Trochę z dala od naszej branży i tematów biznesowych jak Beyond the Grid Toma Clarsksona.

Krzysztof: Bardzo fajna lista podcastów. Również polecam. 

Jeśli myślałeś o porzuceniu etatu programisty i założeniu biznesu opartego o aplikację SaaS, to mam dla ciebie super zniżkę na kurs Bogusza Pękalskiego Od developera do foundera. Szczegóły na końcu tego podcastu.

Marcin, wspomniałem, że masz dziewięcioletnie doświadczenie z iOS-em. Jak to się stało, że swoją karierę programistyczną związałeś właśnie z tą platformą?

Marcin: To był przypadek. Na początku swojej drogi zawodowej trafiłem do małego producenta sprzętu RTV, gdzie prezes wpadł na pomysł, że spróbuje zrobić coś, co teraz nazywałoby się mianem startupu. Kiedyś to określenie nie było tak popularne. Była wizja, aby zrobić coś fajnego, totalnie niezwiązanego z branżą mobilna, która raczkowała. To był mniej więcej czas premiery pierwszego iPhone’a w Stanach. Ja w ogóle usłyszałem o tym kilka lat później. Ten producent postanowił stworzyć swój produkt, który był pod wieloma względami innowacyjny. Ja trafiłem do tej firmy jako inżynier produktu. Z jednej strony byłem członkiem zespołu, który rozwijał soft. Z drugiej strony zajmowałem się kontaktem z dostawcami komponentów sprzętowych. Z trzeciej strony organizowałem cały proces produkcji w fabryce, zaczynając od procesu na linii produkcyjnej, kończąc na instrukcji użytkownika. Z czwartej budowałem lokalnie mały zespół programistów. Pewnego dnia prezes podszedł do mojego biurka. Dosłownie rzucił MacBooka i iPhone 3G i stwierdził: „Marcin, napisz mi apkę. Zrobimy coś, czego nikt jeszcze nie ma”. Fakt faktem to co mieliśmy zrobić i to, co w kilka miesięcy stworzyliśmy, czyli apka, backend, integracja z fizycznym sprzętem było czymś fajnym. Nie twierdzę, że inni nad tym nie pracowali, bo mówimy o roku 2009, a to był początek smartfonów, jakie teraz znamy, więc wiele firm pewnie w swoim zaciszu kombinowało co z tym zrobić, jak to zintegrować ze swoimi produktami. Konkurencja wtedy wprowadziła działające rozwiązania koło 2012 roku, a my mieliśmy już działający prototyp na wiosnę 2010. Apka była już w tym samym roku w App Store. Niestety głównie z powodów sprzętowych, produkt jako całość opóźnił swój debiut na tyle, że konkurencja nas przegoniła. Ja, drobny żuczek rzucony na głęboką wodę programowania w iOS, gdzie wcześniej nigdy nie miałem smartfona czy Maca, to na tyle wkręciłem się w ten temat, że wracałem z pracy i dalej siedziałem na iOS-em. Kupiłem swojego iMaca, potem 3GS. Ten temat tak mnie pochłonął, aż stwierdziłem, że chcę to robić w życiu. Tak się odwdzięczyłem szefowi, który dał mi szansę, że pół roku później poluzowaliśmy współpracę. Jako freelancer skupiłem się głównie na tym.

 

Tak spodobało mi się tworzenie na iOS, że zostałem freelancerem i skupiłem się głównie na tym

 

Krzysztof: Wspomniałeś o tym początkach. To są czasy, kiedy z pewnością programowałeś w Objective-C, jeśli chodzi o iOS. Z tego, co widziałem, to ten język programowania w rankingach popularności języków jest nadal stosunkowo wysoko. Mógłbyś pokrótce o nim opowiedzieć? Lubisz w nim programować nadal? Jest sens uczyć się Objective-C w dzisiejszych czasach?

Marcin: Wbrew pozorom i wbrew hajpowi na Swifta, którego zresztą doskonale rozumiem, musimy pamiętać, że na rynku są setki tysiące aplikacji, które kiedyś powstały początkowo w Objective-C. Dalej w pewnym sensie musi być popularny, bo nie każdy właściciel aplikacji, który kiedyś stworzył produkt chce lub widzi sens przepisywania działającej aplikacji. Czasami po stworzeniu produktu, samoutrzymania, sprawdza się jedynie do przetestowania z nowymi wersjami systemu operacyjnego. Ewentualnie dostosowanie do nowych wymogów stawianych przez APU typu nowe urządzenia z notchami czy drobne zmiany we framwerokach. Też musimy pamiętać o tym, że to, co mamy w Swifcie dopiero od chwili, czyli ABI Stability jest w Objective-C latami. To są takie argumenty, żeby ten język jeszcze trochę pożył i był z nami. Raczej nie będzie rozwijał się dalej. Pewnie za chwilę przyjdzie taki moment, kiedy zacznie spadać w rankichag. Jeszcze jednak jest. Jednak jest trochę aplikacji, które są w nim napisane. Zaryzykowałbym wyrażenie swojej opinii, że za jakieś dwa lata zauważymy istotne odejście od Objective-C. Ten rok jest taki przełomowy dla Swifta. W tym roku zaczęliśmy od Swifta 5, który wprowadza ABI Stability. Za chwilę w 5.1 ma być Module Stability. Dosłownie tydzień temu zaprezentowany został SwiftUI  jako zupełnie nowe podejście do programowania i projektowania interfejsów. Rok 2019 to rok projektu Catalyst. Mamy 3 duże rzeczy, które zabierają argumenty przed dalszym korzystaniem z Objective-C. Myślę, że rok, dwa, trzy lata i spadek zainteresowania tym językiem będzie coraz bardziej widoczne. 

 

Myślę, że za rok spadek zainteresowania językiem Objective-C będzie bardziej widoczny

 

Krzysztof: Wróżysz, że jeszcze trochę ten język pożyje, ale rozpoczynanie swojej przygody z iOS z Objective-C nie ma sensu?

Marcin: Raczej nie. Ujmę to tak – nie znam dewelopera, który w ostatnich latach zacząłby naukę programowania na iOS i znałby lub zainteresowałby się dobrowolnie Objective-C. Nie ma co tego ukrywać. Powiedzmy sobie szczerze – składnia tego języka w porównaniu do Swifta jest okropna. Jest nietypowa. Jest przestarzała. Mimo polerowania Objective-C przy okazji kolejnych wersji, gdzie Apple trochę unowocześnił jego składnię i dodał parę ficzerów, dalej nie umywa się to do możliwości, jakie oferuje Swift. Swift jest po prostu seksi, a Objective-C nie. Kropka. Na ten moment jedyny powód, aby poznać Objective-C, to są potrzeby zawodowe związane z utrzymywaniem projektów Objective-C, które z racjonalnych często powodów nie jest przeportowany do Swifta.

Krzysztof: Skąd w ogóle Objective-C jako język? To jest pewna nadbudowa nad C, dosyć specyficzna, ze specyficzną składnią. Skąd pojawiła się myśl i potrzeba w Apple, aby swój język wypuszczać?

Marcin: To nawet nie był język, który wymyślił Apple. Został stworzony w latach 80 przez Stepstone. Ten język powstał na bazie C. Jego twórcy, którzy trochę inspirowali się pomysłami, które były w Small Talku, połączyli albo wciągnęli idee ze SmallTalka do C i w ten sposób powstał Objective-C. Firma NEXT licencjonowała ten język. Tu po drodze zamieszany był Steve. W momencie, kiedy Apple wykupił Nexta, to ten język trafił do Apple jako istniejący, działający, wykorzystywany produkcyjnie. Na bazie tego na początku powstały wcześniejsze generacje OS X, MacOS, a potem powstał iOS. Jego składnia jest mocno nietypowa. Nie jest to coś, co studenci normalnie spotykają na studiach. Jednak oddala się od C i C++. Pomimo tego polerowania, które było pod koniec aktywnego rozwijania, on doszedł do wersji 2.1, przez ponad 20 lat rozwoju. Swift w 5 lat doszedł do wersji 5.0, a już trwają pracę nad 5.1 Tempo jest szalone. Z wieloma rzeczami teraz tempo jest szalone, nie tylko z samymi językami.

Krzysztof: Zgadza się. W 2014 roku Apple wprowadziło nowy język Swift. Rozwija się on w zastraszającym tempie. Mamy już wersję piątą, co jest dosyć nietypowe, jeśli chodzi o rozwój języków programowania. Domyślam się, że jest to już dojrzałe narzędzie. Mógłbyś powiedzieć o twoich odczuciach związanych ze Swiftem? Może Swift jest dobrym wyborem dla początkujących?

Marcin: Z perspektywy iOS zdecydowanie TAK. Po tych burzliwych pierwszych latach, gdzie był Swift 1.0, 2.0, 3.0. Z wersji na wersje była to trochę rewolucja. Doszliśmy do pewnej standaryzacji. Zaryzykowałbym twierdzenie, że od wersji 3.0 mamy polerowanie – delikatną ewolucję, słuchanie społeczności, która prosi o zmiany, o spójność. Tutaj widać, że twórcy bardzo fajnie reagują na to i dostosowują, wprowadzają kolejne zmiany. Jeszcze bardziej optymalizują ten język, żeby pisało się przyjemniej i aby było to wszystko spójne. Pytałeś, czy ten język jest dobry, jako pierwszy język do nauki. Trochę musielibyśmy podywagować, jakie cechy miałby mieć pierwszy dobry język. Na szybko myśląc, Swift jest językiem wysokopoziomowym o składni zbliżonej do Pythona, Kotlina. Dzieje się tak, że te wszystkie nowoczesne języki są bardzo zbliżone składnią. Nie wiem z czego to wynika, ale takie są trendy. Jest językiem, który zapewnia bezpieczeństwo typów. Deklarując zmienne o określonym typie, już na etapie kompilacji możemy wykryć błędy. Co nie było takie oczywiste w Objective-C. To jest jedna z dużych różnic w porównaniu do Objective-C. Objective-C zakładał dużo większą wolność i świadomość programisty. Można było bardzo luźno pewne rzeczy przypisywać, zakładając, że to wszystko będzie dobrze działało. Swift ma większą kontrolę na etapie kompilacji, a nie samego runtime, więc jest to fajniejsze, bo można bezpieczniej na początku się z tym ogarnąć. Swift ma bardzo fajne środowisko testowe, tak zwany playground, który jest w Xcodzie, czyli w podstawowym środowisku programistycznym. Tam nie trzeba pisać wielkiej apki. Po prostu mamy pomysł, chcemy coś sprawdzić, piszemy, sprawdzamy, czy to działa. Jest językiem, za pomocą którego możemy tworzyć rzeczywiste aplikacje mobilne i desktopowe. Nie jest to język do zabawy jak Scratch. To jest język, gdzie możemy się pobawić, ale możemy stworzyć coś poważnego. Też jest językiem, za pomocą którego możemy tworzyć aplikacje serwerowe, chociażby tak popularne frameworki, jak Vapor czy Kitura pozwalają pisać całe backendy tak naprawdę. Na upartego w miarę ogarnięty deweloper korzystając jedynie ze Swifta napisze aplikację mobilną, desktopową i do tego backend w jednym języku. Z wykorzystaniem tych samych modeli, które się przenoszą między nimi. Jest to ciekawa opcja. Jest jeszcze jedna ważna rzecz – Swift ma bardzo dobrą dokumentację. Jest językiem otwartym, wokół którego zgromadziła się pokaźna społeczność. Bardzo fajnie ewoluuje. To są takie rzeczy, które brałbym poważnie pod uwagę myśląc o Swifcie jako o pierwszym języku do nauki. Na koniec dwie zasadnicze rzeczy, o których wspomniałem wcześniej. ABI Stability, którą mamy teraz i SwiftUI jako zupełnie nowe framework stworzony dla Swift do tworzenia uniwersalnych aplikacji na wszystkie platformy Apple, które po kilkunastu latach ma zastąpić UIkit, który był z nami od pierwszego iOSa, od pierwszego iPhone. To jest fajny moment.

 

 Swift jest językiem otwartym, społeczność fajnie ewoluuje. Jest to fajny moment, żeby Swift stał się pierwszym językiem do nauki

 

Krzysztof: SwiftUI i nowości jeszcze poruszymy, ale te cechy dają dosyć dobre warunki, aby rozpocząć programowanie od Swifta. Zwłaszcza że można go użyć w różnych środowiskach i to też jest nie do przecenienia. Powiedziałeś na początku, że jest mnóstwo aplikacji, mnóstwo bibliotek napisanych w Objective-C. Jeśli mam projekt, który jest napisany w Objective-C, a może częściowo w Objective-C, a częściowo w Swifcie, bo takie hybrydy są możliwe, to czy przepisywać na Swifta, czy można utrzymywać ten projekt w Objective-C? Jakie podejście jest według ciebie najlepsze?

Marcin: Podejrzewam, że nie ma jednej odpowiedzi na to. To wszystko zależy od projektu. Wypadałoby się zastanowić po co mielibyśmy przepisywać ten projekt. Przepisywanie dla samej frajdy przepisywania może okazać się jedynie sztuką dla sztuki i może nieść ze sobą ryzyko dodatkowych problemów – wprowadzenie dodatkowych błędów, może pojawić się okres przejściowy, gdzie aplikacja będzie mniej stabilna. Oczywiście, z pomocą przychodzą nam testy, które jeśli są dobrze napisane dla nowej aplikacji, to powinny pomóc nam wykryć ewentualne psikusy i zabezpieczyć się przed niespodziankami. To są kolejne dwa pytania – czy każde testy są dobre i czy każdą aplikację da się dobrze przetestować? Takie aplikacje jak nawigacja, gdzie można stworzyć sobie fajne środowisko symulacyjne i testować siedząc wygodnie na krześle. Czasami nie zastąpi to tego, aby wyruszyć w teren. Jeśli mamy kilka lat istniejącej aplikacji, gdzie ileś tysięcy czy milionów użytkowników przez kilka lat używało tej aplikacji i mamy feedback z terenu, to zawsze jest ryzyko, że trochę pogorszymy. Chwilowo, ale pogorszymy. Dlaczego warto, aby pomyśleć o przepisaniu? Trochę może to zależeć od architektury, w jakiej była napisana wcześniejsza wersja Objective-C. 

W pierwszych latach Apple zalecał stosowanie aplikacji zgodnie ze wzorcami MVC. Jednym z podstawowych komponentów jest ViewController. Do tego model. Teoretycznie mieliśmy projekt stworzony w architekturze zalecanej przez Apple. Trochę to ewoluowało. Teraz mamy fajne, sensownie rozwiązane MVVM. Mamy projektowanie reaktywne dosyć mocno rozwinięte, przetestowane, popularne. Może to jest taki argument, aby rzeczywiście stworzyć aplikację, która fajnie będzie się dało przetestować, będzie się dało napisać do niej fajne testy jednostkowe. Byłaby to okazja. Pomijając to, że trzeci raz wrócimy do tego, że od tygodnia mamy SwiftUI, który jest fantastyczną okazją do przepisania aplikacji w aplikację, która jest jeszcze bardziej multiplatformowa. To jest tak, że są pewne ograniczenia. Nie ma co się spieszyć, bo SwiftUI działa od iOS 13, który pojawi się dopiero na jesieni. Sam Apple dla istniejącej aplikacji zaleca kompatybilność przynajmniej o jedną wersję systemu wcześniej. Przynajmniej taka jest teoria. Praktyka rynkowa jest taka, że często klienci chcą wsparcia maksymalnie wstecz. Szczególnie jeśli aplikacja powstała kilka lat temu w iOS 8. Latami jest rozwijana. Trudno jest zrezygnować ze wcześniejszych użytkowników, nawet jeśli mówimy tu o kilku procentach użytkowników.

Krzysztof: Myślę, że to, co powiedziałeś, to reprezentuje zdrowe podejście. Nie ma konieczności, aby od razu przepisywać, ponieważ taka technologia istnieje czy dla samej technologii. Musi to się spinać od strony biznesowej, od strategii długofalowej. Jak to w IT, najlepszą odpowiedzią jest: „to zależy”. W tej sytuacji trzeba dobrać rozwiązanie do problemu. 

Marcin: Fajne jest to, że mamy różne opcje. Podejrzewam, że jak SwiftUI się trochę uleży, dotrze do świadomości. Pierwsze wersje nie są kompatybilne ze wszystkimi komponentami, które były wcześniej. Dajmy sobie rok, dwa.

Krzysztof: Brzmi sensownie. Pamiętam, gdy kilka lat temu bawiłem się trochę z iOS, tworzyłem aplikację, to pierwsze co mnie uderzyło to XCode, czyli środowisko programistyczne. Było tak dopieszczone, tak upraszczało tworzenie aplikacji, że dla mnie było to ewenementem, czymś, co nie powtarza się w innych języka i na innych platformach. Jestem ciekaw jak ty oceniasz XCod’a i czy według ciebie jest to jeden z elementów tego systemu deweloperskiego, który podnosi efektywność tworzenia aplikacji i uprzyjemnia ten proces?

Marcin: Trudno nie zgodzić się z tym, co powiedziałeś. Pracuje się fajnie. Nie mogę powiedzieć, że ostatnie wersje XCode są najstabilniejszymi z jakich korzystałem w życiu. Może to też przekłada się na złożenie projektów. Czasami nie dają sobie rady, aby wszystko na bieżąco indeksować. Czasami się zawiesi, czy na etapie indeksowania, czy przy crashach aplikacji, które zdarzają się w trakcie developmentu. W pełni się jednak z tobą zgodzę. Bardzo fajnie się projektu. Chwilę testowałem AppCode, kilka lat temu, który jest największym, najpoważniejszym rywalem rynkowym. XCode dostarczany przez producenta, który zawiera w sobie całkiem dużo fajnych rzeczy kontra AppCode, który też jest fajny. Ma trochę mądrzejsze autouzupełnianie na bazie kontekstu. Ma coś takiego jak sugestie dotyczące poprawnej składni i pewnych standardów kodowania, gdzie sugeruje refactoring pewnych rzeczy, które pisaliśmy. Takie rzeczy niekoniecznie w praktyce warte są płacenia. Tutaj trzeba podkreślić, że AppCode jest płatną alternatywą. Do XCoda jest trochę pluginów, stworzonych przez innych deweloperów. Jest, chociażby świetny framework Swiftlint, który te dobre praktyki deweloperskie podpowiada. Interfejs builder, po tych latach ewolucji jest naprawdę świetnym narzędziem do budowania interfejsu, do analizy w trakcie debugu. To jest świetna rzecz, jak można rozłożyć interfejs na czynniki pierwsze, na ekrany i zobaczyć, gdzie jest problem, jeśli coś nie działa. Ja bardzo żałuję, że nie miałem okazji przetestować Live Preview SwiftUI na Xcode 11, który się teraz pojawi, ale wymaga jeszcze Cataliny zainstalowanej na MacOS’ie. Nie miałem jeszcze takiej możliwości. To już kolejny przełom. Mamy aplikację skompilowaną, która jest wgrana na telefonie. Zmieniamy elementy na interfejsie i to się odświeża na bieżąco. 

Krzysztof: Wspomniałeś o MacOS, a z iOS bardzo mocno jest związany watchOS, czyli system operacyjny na zegarki od Apple’a. Mógłbyś krótko opowiedzieć o tym związku, o powiązaniu? Jest on dość ścisły. Miałeś okazję stworzyć aplikację na iWatch’a?

Marcin: Ta ścisłość jest poruszana w bardzo dobrym momencie historie WatchOS’a. Wygląda na to, że ta ścisłość będzie poluzowana niedługo. Od samego początku WatchOS, a właściwe aplikacje na WatchOS i sam WatchOS jako system operacyjny w Apple Watch’u jest mocno zintegrowany z iOS’em i iPhonem. Zegarek w praktyce nie funkcjonuje, jeśli nie jest sparowany z telefonem. Aplikacje, które są na tym zegarku, to są w praktyce aplikacjami, które są powiązane z aplikacją na iOS. Instalujemy sobie z App Store aplikację na swojego iPhone. Ta aplikacja ma rozszerzenie, jakim jest aplikacja na WatchOS’a. Możemy ją sobie z automatu instalować. Ta aplikacja trafia na nasz zegarek pod drodze z iOS. Mówiłem o tej ścisłości, ponieważ będzie pewne rozluźnienie. Będziemy mieć osobny sklep dla aplikacji na WatchOS. Te aplikacje będą mogły być niezależne. Doszliśmy do tego etapu, gdzie Apple Watch i WatchOS na tyle się rozwinął. Dzięki LTE, gdzie możemy mieć internet niezależnie od iPhone w zegarku. Doszliśmy do etapu, gdzie te aplikacje będą mogły być niezależne od aplikacji iOS. W tym momencie wygląda to tak, że jeśli chcemy stworzyć aplikację na WatchOS, to do naszej aplikacji głównej na iPhone dodajemy rozszerzenie stricte pod zegarem. Budujemy interfejs w WatchKicie, analogicznym do UIkit’a. Budujemy sobie moc komunikacji z wykorzystywaniem dedykowanego frameworka Watch Connectivity. Tworzy nam się przestrzeń wspólna, tak zwany Sandbox dla aplikacji głównej i aplikacji na zegarku. One ze sobą gadają asynchronicznie. Możemy dodać taką komunikację i w ten sposób ta aplikacja na Watch’a może komunikować się z aplikacją główną. Pytałeś, czy stworzyłem aplikację na WatchOS. Produkcyjnej nie miałem niestety przyjemności. Przygotowałem kilka dem, które nie trafiły nigdy do App Store. Zdarzyło mi się napisać kilka razy inne rozszerzenia, które bazują na podobnej filozofii. Na bazie podobnej filozofii rozszerzeń mamy widgety ToDay, które są na ekranie głównym, gdzie komunikacja odbywa się w podobny sposób. Mamy rozszerzenia do Safari, które też są mini aplikacjami komunikującymi się z naszą główną. Tu parę takich projektów napisałem i to nawet działa. Jest to forma otwarcia się, dodania nowych interfejsów. Strasznie jestem ciekaw, w jakim kierunku pójdzie wykorzystanie Apple Watch’a, jeśli rzeczywiście powstaną kolejne niezależne aplikacje i stanie się on jeszcze bardziej niezależnym urządzeniem.

 

Nie miałem okazji stworzyć aplikacji produkcyjnej na WatchOS

 

Krzysztof: Myślę, że to jest dobry kierunek rozwoju, który pozwoli otworzyć się na nowe możliwości. Pozwoli zlikwidować pewne ograniczenia, o których wspomniałeś, związane z developmentem, ze ścisłym połączeniem iPhone z Watch’em. Chciałem cię też zapytać o to, jakie jeszcze narzędzia dodatkowe lub frameworki, według ciebie są godne wspomnienia, jeśli chodzi o dewelopment na iOS’a?

Marcin: Jeśli chodzi o narzędzia, to już wspomniałem o AppCode, który jest główną alternatywną dla Xcod’a jako środowisko do tworzenia aplikacji. Jeśli chodzi o narzędzia kluczowe, to musimy pamiętać też o narzędziach do continuous integration, czyli mówi o XCode serwerze, Jenkinsie. Z najpopularniejszych frameworków – sam Apple dostarcza dużo frameworków. Z każdą wersją systemu pojawiają się kolejne wersje frameworków, które chcą mocno promować albo mocno rozwijać, albo zupełnie nowe frameworki dzięki temu, że otwiera ten system i dostarcza nowe możliwości, zarówno programistom, jak i użytkownikom. Po wielu latach jest masa dużych i popularnych frameworków firm zewnętrznych. Nie zaszkodzi wspomnieć o Fabric’u z Answeres’ami i Crashlytics’em, jako alternatywę dla testflight’a, którego Apple parę lat temu wykupił i wciągnął do swojego ekosystemu. Jest Firebase, którego Fabric stał się częścią ze swoim Messengingiem i pełnym pakietem związanym z push’ami. Dostajemy kompleksowe rozwiązanie dotyczące Push’ów. Są świetne bazy czasu rzeczywistego jak Realm czy Firebase’owe. Jest SwiftLint, o którym wspominałem, który dla projektów robionych w Swifcie daje nam fajną walidację tego, czy to, co piszemy jest zgodne z dobrymi nawykami i standardami rynkowymi. Aby ten kod był bardziej czysty. Są świetne frameworki do sieciówki na przykład Alamofire, do UI. Tu jestem bardzo ciekaw co się wydarzy, bo były alternatywy, tudzież nakładki na Auto layout, były snapkitczy stewia, a teraz pojawił się SwiftUI. Jestem ciekaw czy to nie jest pocałunek śmierci dla tych frameworków. Zobaczymy.

Krzysztof: Wydaje mi się, że mnogość różnych frameworków, dodatkowych narzędzi, które wymieniłeś, świadczy jednoznacznie o tym, że jest to bardzo dojrzałe środowisko, z wieloletnim rozwojem. W związku z tym można wybrać to, co jest potrzebne w danym projekcie. Moje kolejne pytanie jest związane z porównaniem tworzenia aplikacji na iOS’a i Androida. Czy według ciebie, na iOS’ie jest łatwiej ze względu na pewną ograniczoną i z góry znaną pulę urządzeń? Jest kilka wspieranych iPhone’ów, iPad’ów, iWatch’y. One mają zdefiniowane i z góry znane parametry. Inaczej to wygląda w przypadku Androida, gdzie jest mnogość rozdzielczości, wielkości, tego, co jest na wyposażeniu urządzenia. Czy w związku z tym według na iOS’a łatwiej się programuje i projektuje aplikacje?

 

Trudno jest doszukać się minusów programowania na iOS

 

Marcin: Projektuje się inaczej. Trochę. To, co powiedziałeś przed chwilą, to fantastyczne podsumowanie zalet projektowania na iOS, gdzie przewidywalność, spójność daje ogromną wygodę i komfort. Tutaj ze względu na kilka zalet biznesowych, modeli wielkości iPad’ów. Jest to dużo bardziej wygodne. Trudno mi się doszukać minusów. Wydaje mi się, z drugiej strony, na Androida jest fajniej w kwestii pewnych możliwości. Teraz to się zmienia, ale latami było tak, że na Androida deweloper miał dużo większą wolność. Dużo większy dostęp do pewnych usług, przestrzeni, gdzie na iOS’ie dużo rzeczy było zabronionych albo wymagało dodatkowych uprawnień. To dawało pewne ograniczenia. Nie mówię, że to było złe, bo to w jakiś sposób zabezpieczało użytkowników. To czasami komplikowało i dalej trochę komplikuje życie deweloperom. Jeśli mamy taką sytuację, że trzeba dostarczyć aplikację na dwie platformy, które mają określoną, spójną funkcjonalność. Nagle się okazuje, że na Androida da się to łatwo zrobić, a na iOS niekoniecznie. Aplikacja idzie do tła, po paru minutach się zamraża i trudno ją wybudzić, aby w tle zsynchronizowała się z bluetoothem z innym urządzeniem. Owszem, przypomniało mi się, że w iOS 13 będzie trochę poluzowanie kwestii serwisów działających w tle, co było mankamentem, jeśli chodzi o kodowanie na iOS. Strasznie wolno Apple starało się poluzować. Nie wiem, czy to jest kwestia dbania o baterię, ale trochę trudniej było przez lata i dalej trochę trudniej jest dowieść tę samą funkcjonalność, która jest na Androidzie.

Krzysztof: Kontynuując wątek mnogości sprzętu, czyli wielkości tego, co siedzi w  środku, chciałbym cię zapytać jak testuje się aplikację na iOS? Chodzi mi zarówno o testy automatyczne, jak i testy UI. Z jakich narzędzi się korzysta, aby dobrze przetestować aplikację?

Marcin: Podstawowym narzędziem, które jest dostarczone razem z XCodem jest XCTest, gdzie możemy tworzyć dwa typy testów. Zarówno testy jednostkowe, które testują specyficzną funkcjonalność w określonym kontekście, jak i też możemy pisać testy interfejsu. Możemy zaprojektować całą ścieżkę zachowania użytkownika po uruchomieniu aplikacji. Symulować jego gesty, symulować wciśnięcie konkretnych przycisków i sprawdzać, czy aplikacja zareagowała w odpowiedni sposób. Czy udało się zalogować do aplikacji i pokazał się jakiś ekran? Ulubiony test testerów manualny – czy jeśli mamy aplikację z 5 tabami i będę dwoma kciukami szybko naciskał na wszystkie 5 tabów po kolei, to czy aplikacja się crashuje, czy nie? To chyba jeden z takich popularniejszych testów manualnych jak widzę. Dzięki testom UI możemy dużo rzeczy przetestować automatycznie. Jeśli to sobie jeszcze zepniemy z Continuous Integration, postawimy serwer, który z każdą zmianą w kodzie przeleci te wszystkie testy i spróbuje zbudować na początku aplikację, przeleci testy i podpisze, żebyśmy mogli ją wykorzystać do tego, aby zaktualizować sklep, jeśli to będzie ta wersję, to może to upraszczać dużo rzeczy. Programowanie staje się dużo szybsze i wygodniejsze. 

 

Dzięki testom UI możemy przetestować dużo rzeczy automatycznie

 

Krzysztof: Brzmi to nieźle.

Marcin: Brzmi to nieźle, przy czym nie zastąpimy wszystkich testów automatycznymi, bo testy automatyczne też pisze człowiek. Często pisze je deweloper, który pisze aplikacje. Czasami może mu brakować pewnej wyobraźni, w jaki sposób użytkownik może używać tej aplikacji. Tester na bazie swojego doświadczenia z innymi aplikacjami może mieć inne wyobrażenie. Wydaje mi się, że jeśli chodzi o testy, to najlepsze jest mix testów automatycznych i manualnych. 

Krzysztof: Też mi się tak wydaje. Chciałbym teraz przejść w kierunku projektowania aplikacja od strony interfejsu użytkownika. Jak rozumiem zajmują też tym designerzy. Apple posiada coś takiego jak Human Interface Guidelines, czyli zbiór wytycznych jak takie interfejsy powinny wyglądać, jak powinny się zachowywać. Czy jest to coś, co przestrzega się w praktyce? Stosuje się go? Czy jest to zbiór wytycznych, które sobie wiszą i nikt z tego nie korzysta?

Marcin: Warto z tego korzystać. Jest to bardzo fajny zbiór zaleceń i wytycznych, który zawiera masę przykładów omawiających klasyczne sytuacje i w jaki sposób powinniśmy zaprojektować aplikację. Dlaczego warto z tego korzystać? Z dwóch powodów. Nie jest powiedziane, że musimy wszystko małpować jak małpki. Praca designerów nie miałaby sensu. Warto mieć to z tyłu głowy i warto projektując interfejs do aplikacji wiedzieć o tych guidelines, bo użytkownik, który jest użytkownikiem danego systemu operacyjnego, danego systemu mobilnego jest przyzwyczajony do pewnych elementów interfejsu. Jest przyzwyczajony do pewnych gestów, zachowania. Apple pomimo różnych wpadek stara się by swoje aplikacje, których masa jest zainstalowana na dzień dobry po uruchomieniu działały w podobny sposób. Użytkownik przyzwyczajony do pewnych gestów, pewnych elementów interfejsu jak pop-up’y, jak taby, jak nawigacja, która idzie w odpowiednim kierunku, umiejscowienie przycisku wstecz, to korzystając z twojej aplikacji w pewnym sensie spodziewa się, że będzie to w podobnym miejscu. Jeśli przycisk, który jest strzałką w lewo, to żeby ten przycisk cofał się do poprzedniego ekranu, a nie inicjował akcję share. To jest sytuacja trochę win-win. Jeśli my będziemy przestrzegać tych guidelines, z odrobiną fantazji, kreatywności, to aplikacja będzie dobrze wyglądała, będzie intuicyjna dla użytkownika, więc będzie chętnie używana i polecana przez innych użytkowników. Z jednej strony odbiór całego systemu będzie dobry. Kup iPhone, bo ma świetne aplikacje. Apple będzie się cieszył, bo będzie sprzedawał kolejne modele iPhone’ów. Z drugiej strony my się będziemy cieszyć, bo mamy aplikację, której ludzie chcą używać, bo jest intuicyjna.

Krzysztof: Wszystkim to służy. Powiedzmy, że mamy już dobrze zaprojektowany interfejs, mamy aplikację, która została zaprogramowana. Przechodzimy do deploymentu. Powiedz, proszę jak wygląda ten proces deploymentu aplikacji? Zawsze celem tego deploymentu musi być sklep z apkami od Apple, czyli App Store?

Marcin: W większości przypadków tak. Tutaj mamy tę sytuację, o której jest coraz głośniej w mediach, ze względu na naciski na osoby, którym nie podoba się prowizja nakładana przez Apple za dystrybucję aplikacji w App Store. Głównym i domyślnym celem aplikacji po jej stworzeniu jest jest deployment w App Store. W momencie, kiedy mamy aplikację, która jest zbudowana, jest przetestowana, to ją zarchiwizujemy za pomocą dodatkowe aplikacji, która w tym momencie jest zintegrowana z kodem. Kiedyś nie była, teraz jest. Niedługo podobno nie będzie. Mówię o Application Loader. Za jej pomocą możemy ten zarchiwizowany build przesłać do automatycznej weryfikacji w usługi App Store Connect. Jest to portal dystrybucyjny aplikacji w App Store. Jeśli mamy stworzoną aplikację, to możemy stworzyć tę aplikację nadając jej nazwę, ID. Opisać ją i przygotować różne materiały marketingowe, zdjęcia, słowa kluczowe. Przede wszystkim możemy tam załadować tego builda, po to, aby ta aplikacja mogła zostać opublikowana. Możemy określić jej cenę. Pamiętajmy, że nie jest tak, że możemy wymyślić sobie dowolną cenę typu 37 złotych i 15 groszy. Są pewne stawki, które są skończone. Tam jest kilkanaście różnych stawek, które są przeliczane na konkretny VAT, ale to są detale. 

 

App Store to najczęściej domyślna destynacja deploymentu naszej aplikacji

 

Krzysztof: Rzucamy, deployujemy. Powiedziałeś, że najczęściej jest to App Store jako domyślna destynacja naszego deploymentu. Są też inne prawda? Możemy deployować do środowisk testowych. Mógłbyś pokrótce powiedzieć co tutaj jeszcze jest dostępne?

Marcin: Zacząłem od końca. Powinienem od początku. Powiem coś a propo końca i wrócę do początku. App Store jest głównym i podstawowym kierunkiem, gdzie możemy deployować aplikację. Druga forma deployowania aplikacji produkcyjna to dystrybucja Enterprise. To jest dystrybucja w domyśle przeznaczona dla rozwiązań biznesowych do rozwiązań korporacyjnych, gdzie zamiast podpisywania aplikacji i dystrybuowania w App Store, sami odpowiadamy za dystrybucję. Natomiast powinniśmy ją dystrybuować w ograniczonym gronie. To jest tak, że my budujemy aplikację i podpisujemy do dystrybucji praktycznie w identyczny sposób jak App Store, ale z różnymi certyfikatami. Apple nie pomaga nam w żaden sposób, nie promuje i nie wspiera w kwestii samej dystrybucji. My sami musimy zadbać o to, aby tę aplikację udostępnić użytkownikom. My musimy pamiętać o tym, że w przeciwieństwie do aplikacji podpisanej dla App Store, ma ona swoją ważność, czyli certyfikaty, którym jest podpisana mają swoją ważność. Raz na jakiś czas, nie zaszkodzi zrobić aktualizacji z odświeżonym certyfikatem. Inaczej użytkownikom wyłączy się ta aplikacja. Musimy pamiętać o tym, że w zapisach licencyjnych dla kont Enterprise, które nota bene kosztują 3 razy więcej niż konta klasyczne, deweloperskie, bo to jest 300 dolarów na rok. Trochę to kosztuje. W zapisach dla tych kont jest wzmianka, która sugerowałaby, że nie jest wykluczone, że Apple monitoruje w pewnym sensie instalacje tych aplikacji Enterprise, po to, aby zabezpieczyć się przed sytuacją, gdzie deweloper chciałbym dystrybuować aplikację dla miliona użytkowników poza App Store w swoim sklepie. Założenie jest stricte korporacyjne, takiej dystrybucji Enterprise. Cofając się, wróćmy do dystrybucji testowych. Mamy tutaj TestFlight, o którym wspomnieliśmy. Jest on częścią Apple Connect. Pozwala on na dystrybucje testowe aplikacji jeszcze zanim ją opublikujemy w sklepie. Znowu mamy tu dwie opcje. Możemy dystrybuować tę aplikację do ograniczonego grona, do 25 osób, których Apple ID znamy i jesteśmy w stanie przypisać. Wtedy te osoby dostają tę aplikację tuż po tym jak ją wgramy. Ona się przeprocesuje. Dodajemy Apple ID, udostępniamy na 30 dni i mogą sobie testować. Mogą sobie zainstalować z aplikacji TestFlight na swoim telefonie. Jest jeszcze drugie podejście, czyli zewnętrzna dystrybucja Beta, gdzie możemy dystrybuować aplikację do 10 tysięcy użytkowników testowych. To się często zdarza, kiedy duże aplikacje mają swoje kolejne wersje, to poprzedzają ją dystrybucją Beta, gdzie użytkownicy mogą się zapisać swoim adresem mail. Też mogą przez te 90 dni testować i wracać z feedbackiem do kreatorów tej aplikacji.

Krzysztof: Weźmy może pod lupę tę najbardziej popularną formę dystrybucji, czyli do App Store. Przechodzimy przez etap Review, etap sprawdzania naszej aplikacji, zanim zostanie ona udostępniona i będzie widoczna w App Store. Pamiętam, że jakiś czas temu, był to proces, który trwał dosyć długo. Czasem nawet czekało się do 2 tygodni na zaakceptowanie czy przejrzenie aplikacji. Nadal tyle to trwa? Co właściwie jest sprawdzane?

Marcin: Na szczęście nie. To były fajne czasy, kiedy człowiek miał kolejny pretekst do tego, aby uczyć się cierpliwości, zapisaniu się na jakąś jogę. Gdzie terminy goniły, trzeba było dystrybuować aplikację. Gdzie w tamtym czasach guidelines nie były tak precyzyjne. Tak jak w przypadku Human Interface Guidelines też jest dokument Review Guidelines, który też jest żywym dokumentem, który Apple modyfikuje cały czas. Te wytyczne dla deweloperów nie były tak precyzje. Czasami było tak, że mając gotowy produkt przechodziło się przez 2-3 releasy, które trwały 3-4 tygodnie, tylko po to, aby wypuścić aplikację. Tak na szczęście teraz nie jest. Doszliśmy do takich czasów, gdzie to wszystko odbywa się w miarę normalnie. To nie jest tak wygodne, jak w przypadku Play Store, gdzie godzina-dwie i aplikacja jest już w sklepie. Realny czas w tym momencie to 24 do 48 godzin od momentu zgłoszenia aplikacji do przeglądu, do feedbacku z przeglądu. To jest już bardziej do zaakceptowania. 

 

Oczekiwanie na zaakceptowanie aplikacji trwa do 48 godzin w App Store

 

Krzysztof: Na co zwraca się uwagę podczas tego procesu? Co jest oceniane?

Marcin: Apple jest restrykcyjne, jeśli chodzi o pewne rzeczy, których nie chce mieć w sklepie. Nie chce mieć często rzeczy związanych z hazardem, kontentu dla dorosłych. Kiedyś były wojny o aplikację, które w jakiś sposób to oszukiwały. Nie chce mieć aplikacji, które wnoszą bardzo mało lub nic. Kilka lat temu była akcja, jak hurtowo w krótkim czasu wyrzucili ileś tysięcy czy dziesiątek tysięcy aplikacji, których jedyną funkcjonalnością było pierdzenie lub udawanie, że ktoś pije piwo. Trochę kasy zarabiały, z tego, co słyszałem. Bardzo restrykcyjne jest Apple w kierunku tego, żeby aplikacja dawała jakąś wartość. Apple nie chce aplikacji, które są beta, które są prelive. Chce aplikacji, która działa, daje wartość, jest czytelna i jest w podstawie zgodna z guidelines interfejsu. Zdarzały się przypadki, że pewne ryzykowne zagranie, jeśli chodzi o interfejs niekoniecznie było akceptowane przez Apple. Tak zwany Review Board, czyli grupa ludzi, która zajmuje się ocenianiem aplikacja, zwraca bardzo szczegółową uwagę na kwestię związane z płatnościami. Odnoszę wrażenie, że ich konikiem są subskrypcje, gdzie z roku na roku wytyczne dla deweloperów rosną. Komunikaty, które trzeba dostarczyć użytkownikom rosną. Precyzyjnie to sprawdzają. Niedawno zastanawiałem się i na szybko podliczyłem, to przez parę lat przeszedłem przez Review między 500 a 1000 wersji różnych aplikacji, które utrzymywałem. Na bazie tego doświadczenia działanie Review Board mogę podsumować tak – jeśli nie przeginamy z zasadami typu hazard, kontent dla dorosłych czy kontent, który może być na granicy przyzwoitości lub robimy coś, co jest niezgodne z tym, co przeczytaliśmy tydzień temu w guidelines, to nic nie powinno nam grozić. Może się zdarzyć, że dostaniemy zwrotkę, bo Apple wykryło błąd, którego nie znaleźliśmy. Może dostaniemy zwrotkę, bo nam powie, że zapomnieliśmy wspomnieć o pewnej informacji i trzeba zaktualizować opisówkę. Może dostaniemy inną zwrotkę. Nie jest tak, że powinniśmy się spodziewać nie wiadomo czego. Mała anegdota z mojej przyszłości przyszła mi na myśl. Musimy pamiętać, że w pewnym etapie jest ten Review Board, jest przegląd aplikacji przez Apple, to sam doświadczyłem historii, gdzie przegląd dość mocno zachwiał całym modelem biznesowym startupu. Była taka sytuacja, że rozwijałem aplikację mobilną dla startupu, która dostarczała kontent. Zgodnie z guidelinesami, jeśli kontent cyfrowy dostarczany jest przez aplikację mobilną, to jedyną formą płatności za ten kontent cyfrowy jest zakup w App Store tudzież subskrypcja. Nie może być tak, że kontent cyfrowy bezpośrednio w urządzeniu możemy odblokować w inny sposób. Ten startup dostarczał sprzęt, który był zintegrowany z aplikacją mobilną. Jeśli użytkownik kupił sprzęt, to dostawał kupon na jeden kawałek kontentu. Był voucher, który mógł wprowadzić do aplikacji. Jeden kawałek contentu był w ramach podziękowania za zakup urządzenia. Przez lata ten model się kręcił, aż do momentu, kiedy Apple stwierdził, że ich oszukują. Nie może być tak, żeby użytkownik mógł sobie coś kupić i wprowadzić kod, wprowadzić voucher i dostać kontent za darmo, bo to jest niezgodne guidelinesami. Mamy sytuację taką, że wyprodukowane są dziesiątki tysięcy opakowań z kodami, gdzie cały model biznesowy, cała reklama sprowadza się do tego, żeby zapłacić, za coś można dostać urządzenie, odblokuj, korzystaj. Konkurencja stosowała podobne zagrywki. Zagrywki może jest określeniem pejoratywnym. Ten sam model biznesowy stosowało kilka różnych firm. Kilka tygodni, wiele rozmów, wiele maili, wiele rozmów telefonicznych z Review Board odbyliśmy. Skończyło się na tym, że startup musiał zrobić drobny pivot i przemodelować biznes, tak, aby dało się wypuścić kolejne aktualizacje. 

 

Jeśli nie przeginamy z łamaniem zasad z guidelines, to nasza aplikacja zostanie zaakceptowana

 

Krzysztof: Nie ma sensu walczyć z Apple. Jesteśmy świeżo po WWDC, czyli dorocznej konferencji Apple dotyczącej głównie oprogramowania. Jedną z nowości jest iPad OS, czyli nowa wersja iOS’a przeznaczona dla iPadów. Czy według ciebie jest to znaczący trend, czy kolejny system do utrzymania dla deweloperów? Czy to jest dobry pomysł, według ciebie?

Marcin: Myślałem, że spytasz o stopkę za tysiąc dolców. 

Krzysztof: Wiele memów widziałem o tym.

Marcin: Jest to jakaś forma reklamy – wypuścić coś, o czym będzie głośno przez długi czas. Pamiętajmy o tym, że nie każda aplikacja ma sens na każdym systemie operacyjnym. Raczej aplikacji do rejestrowania treningów biegowych nie importuje się na iPada czy Maca. Mamy możliwość, jako deweloperzy i właściciel aplikacji, dać coś więcej, ale nie musimy z  tego korzystać. To, że ktoś rozdaje darmowe lody, to nie musimy zjeść od razu 8 gałek. Czy utrzymywanie kilku systemów w ramach jednego projektu, bo podejrzewam, że głównie o to ci chodziło, w Xcode to jest dobry pomysł? To zależy od samego interfejsu, od funkcjonalności, od wymagań stawianych przez design względem aplikacji na iOS, jak i aplikacji na iPad OS. Względem też tego na ile ten interfejs odbiega od schematów Apple, które dają pewne automatyczne rozwiązania, które dostosowują się w zależności od systemu. Sprowadzamy się do magicznego „to zależy”. Przychodzi nam trochę z pomocą SwiftUI. Przychodzi z myślą  o nowych projektach, które mielibyśmy zaczynać w przyszłości. Nawet w kwestii refactoringu tych projektów, które mamy obecnie, to SwiftUI przychodzi nam z pomocą. On może nam zapewnić wiele automatyzmu między platformami. Nie zawsze będzie to rozwiązanie, na które możemy sobie pozwolić. Często w praktyce jest tak, że design nam narzuca takie wytyczne, co do interfejsu, co do pixel perfect czy detali, że nie możemy skorzystać z systemowych komponentów, tylko trzeba pisać swoje, które są w 89-90% identyczne jak systemowe, ale mają drobne zmiany, które spełniają wymagania klienta czy designu. To trochę zależy. W przypadku prostszych aplikacji, w przypadku tych aplikacji, które w większości korzystają z natywnych komponentów, które dostosowują się automatycznie do interfejsów zalecanych w danym systemie operacyjnym, to bym się tym nie przejmował. po prostu odhaczymy jeszcze jednego ptaszka w Xcodzie. Nie zaszkodzi. Wprowadzimy kilka ifów i to będzie działało. W przypadku dużego projektu – nie wiem, czy to jest najlepszy pomysł. Nie wiem, czy bym się nie zastanawiał nad tym, żeby core wydzielić do osobnego frameworka i rozwijać kilka niezależnych projektów na każdą platformę, jeśli te różnice między aplikacjami są tak duże.

Krzysztof: Znów wracamy do tego, żeby dobierać rozwiązanie do problemu, który mamy. Nie ma tutaj jednoznacznej odpowiedzi. Podczas konferencji, o której mówiłem słyszeliśmy również o projekcie Catalyst. Mógłbyś krótko powiedzieć co to jest za projekt i jak wpłynie na development aplikacji mobilnych?

Marcin: To, co wspomnieliśmy podczas naszej rozmowy, ale nie nazwaliśmy, ze słynnym, dodatkowym ptaszkiem w Xcodzie, to jest projekt Catalyst, który jest pochodną zeszłorocznego Marcepana, który był średnio odebrany przez pierwszych testerów. Apple wyciągnęło wnioski, podpolerowało, przemianowało nazwę i mamy projekt, który z założenia powinien pozwolić nam w bardzo wygodny sposób przeportować istniejącą aplikację (uniwersalną albo aplikacją dedykowaną dla iPada) pod MacOS. Apple chwalił się na konferencji, że czasami wystarczy kilka godzin, aby dużą, istniejącą aplikację dostosować do MacOS. Podejrzewam, że w praktyce będzie to więcej pracy. Jest to coś dużego dla twórców aplikacji mobilnych. Jest to coś, czym martwią się twórcy aplikacji na MacOS. Nagle pojawia się im duża konkurencja. Nagle ich kompetencje i wieloletnie doświadczenie w projektowaniu interfejsów natywnych pod Maca trochę traci na znaczeniu. Szczególnie w SwiftUI, które zrobi to za nich trochę automatycznie. Aby komuś dać, to trzeba komuś zabrać. 

Krzysztof: Co do konkurencji – zapytam cię o takie projekty jak Xamarin czy React Native, które mają w zamiarze ujednolicić tworzenie aplikacji mobilnych na wiele platform jednocześnie. Czy według ciebie rozwiązania tego typu mogą być jakimś zagrożeniem dla iOS deweloperów?

Marcin: Myślę, że trochę tak. Nie chcę się powtarzać, że zależy. Doszliśmy do etapu, gdzie nowa generacji cross platformowych rozwiązań, jak te, o których wspomniałeś czy Flutter Google, to są rozwiązania, które mają silne wsparcie ze strony silnych graczy. Są to rozwiązania, nie takie, które renderują się w webie jak PhoneGap, tylko one albo się kompilują do systemowych komponentów, albo pomijając ten etap jak Flutter, który renderuje swoje komponenty. To jest pisanie kodu analogicznego do natywnego. To jest pewna alternatywa, która kusi. Piszemy 80% tego samego kodu – drobne dostosowanie pod Android, drobne dostosowanie pod iOS i nagle mamy dwie apki. Taka alternatywa jest kusząca na potrzeby stworzenia MVP dla startupu. Jeśli chce się szybciej, to jest tańsze. Owszem może być problematyczne, jeśli mamy potrzebę zrobienia czegoś Pixel Perfect, mamy potrzebę skorzystania z dedykowanych frameworków, których dana platforma może nie wspierać. Były przygody z Bluetoothem przez jakiś czas czy z innymi frameworkami, których akurat potrzebujemy w aplikacji. Niekoniecznie potrzebuje na początku. Może się okazać, że potrzebujemy po 2-3 latach dodać jakiś framework, czy integrację z bebechami sprzętowymi, które są w telefonie, których ten framework nie wspiera. Jest tak, że dzięki temu, że te projekty cross platformowe są wspierane przez dużych graczy to starają się nadganiać. Kiedyś bawiłem się tym. Ze swojego doświadczenia mogę powiedzieć, że jest to świetna alternatywa właśnie na MVP dla startupu. Jeśli mówimy o projekcie wieloletnim, który może rozwijać się w wielu kierunkach, gdzie nie mamy grubych ograniczeń budżetowych, to stawiałbym na rozwiązania natywne.

Krzysztof: Nie chciałeś powiedzieć, że to zależy, ale wychodzi na to, że jednak to zależy. Marcin, powiedz jak wygląda rynek pracy związany z iOS Development. Ciągle jest takie duże zapotrzebowanie na deweloperów w tej branży?

 

Nadal jest bardzo duże zapotrzebowanie na deweloperów w tej branży

 

Marcin: Tak, jest. Pomimo tego, że kawałek tortu współdzielimy z React Native czy Flutterem, czy Xamarinem, to osobiście nie zauważyłem spadku zapotrzebowania na deweloperów. Trzeba pamiętać, że mamy setki tysięcy stworzonych aplikacji, które są ciągle rozwijane w dużej większości, ciągle powstają nowe. Apple nie pozwala się nudzić deweloperom. Cały czas albo zachęca marchewką do wprowadzania kolejnych modyfikacji, albo czasami kijem jak nie dostosujesz się do nowego notch’a w ciągu pół roku, to żadnego update nie wrzucisz. I cześć! Jest co robić. To, co zauważyłem, to, że jest mniejsze zapotrzebowanie na totalnych Juniorów. Nie wiem, czy to jest związane ogólnie z iOS, czy ogólnie jest taki trend, że firmy potrzebują Juniorów już z doświadczeniem. Coś pomiędzy Juniorem, a Regular’em. Tak, aby opuścić etap inwestycji w totalną niewiadomą, brzydko nazywając. Koszt stanowiska dla iOS developera jest ciut większy niż w przypadku innej technologii.

Krzysztof: Nie da się ukryć. Tak, jak słusznie zauważyłeś, jest to trend, który obserwuję nie tylko w iOS. To jest raczej trend związany z branżą software development. Faktycznie zapotrzebowanie na Juniorów, w przeciągu ostatniego półtora roku spadło. Być może z takich przyczyn, o których powiedziałeś. Na zakończenie powiedz proszę Marcin, gdzie zmierza programowanie na iOS? Jakie są trendy, które widzisz na najbliższą przyszłość?

Marcin: Trochę jest to nie wiadomo, bo zależy od tego, jakie będą trendy rynkowe, jaka technologia przyjmie się bardziej. Jeśli to, co teraz się rozwija, czyli technologie głosowe i wejdą one do codziennego użytku, to pewnie trzeba się spodziewać, że deweloperzy będą mieli swoją przestrzeń do przepracowania, aby wzbogacić swoje aplikacje w rozwiązania, które wspomagają to. Apple też zaczyna nadganiać. Aktualizuje Siri Kit’a. Ponoć ma być bardziej kontekstowy i otwarty. Przekonamy się. Promuje mocno AR, tak jak odpuścił VR zupełnie. Przyszłość deweloperów może zależeć od tego, co rynek łyknie i czego będzie potrzebował. Z perspektywy kierunku rozwoju, jaki Apple nam narzuca jako deweloperom, to wydaje mi się, że wystarczy popatrzeć na to, co Apple nam sugeruje w ostatnich latach. Apple odpowiedziało Swiftem na słaby odbiór przestarzałego Objective-C. Odpowiedziało SwiftUI na deklaratywne podejście do budowania UI, które stało się ostatnio popularne. Ogłosiło Marcepana, przemianowano go na Catalyst, dając sygnał deweloperom aplikacji na MacOS, że ich czas się kończy. To wydaje mi się, że to jest przyszłość programowania na iOS. Jedna aplikacja wywodząca się z iOS, na wszystkie urządzenia z logiem Apple, napisana w Swift z wykorzystaniem SwiftUI. Amen,

 

Przyszłość Apple to jedna aplikacja wywodząca się z iOS, na wszystkie urządzenia z logiem Apple, napisana w Swift z wykorzystaniem SwiftUI

 

Krzysztof: Ciekawa przyszłość się szykuje. Myślę, że to jednoznacznie przemawia za tym, żeby iść w programowanie na iOS. Jeszcze niejedno zostanie powiedziane w tym temacie. Marcin, ja tobie bardzo dziękuję za ciekawą rozmowę. Przekazałeś mnóstwo wiedzy. Dzięki ci za to. Na koniec powiedz, proszę, gdzie można cię znaleźć w internecie?

Marcin: Ja również dziękuję za zaproszenie. Mam nadzieję, że to, co powiedziałem było dla kogoś wartościowe. Można mnie znaleźć na LinkedIn. Mam z okazji mojego nadchodzącego dziesięciolecia kodowania na iOS parę pomysłów, jak prywatnie to uczcić, ale nic nie jest na tyle sformalizowane, żeby coś więcej powiedzieć. Wydaje mi się, że najprościej będzie przez LinkedIn. Jak będę miał się czym pochwalić, to na pewno tam się pochwalę.

Krzysztof: Zapraszamy zatem na LinkedIna Marcina. Jeszcze raz wielkie dzięki i do usłyszenia. Cześć!

Marcin: Do usłyszenia.

 

Krzysztof: I to na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Kilka lat temu popełniłem parę aplikacji na iOS i była to świetna zabawa. Dzisiaj ten ekosystem jest bardziej rozwinięty i do dyspozycji mamy fajne narzędzia. Polecam programowanie mobilne, gdyż jest to przyszłość. A teraz obiecana informacja o kursie Od developera do foundera. Bogusz przygotował kod rabatowy. Ten kod to POROZMAWIAJMYOIT – pisane razem i wielkimi literami. Sprzedaż kursu ruszy bądź ruszyła 8 lipca 2019 roku i potrwa tylko do 12 lipca. Kurs można kupić na stronie akademiasaas.pl. Kod daje 200 złotych zniżki na kurs. Cena finalna to 1137 złotych brutto. Kurs przeprowadza przez ścieżkę od znalezienia i weryfikacji pomysłu poprzez budowę rozwiązania i znalezienia płacących klientów, aż do rezygnacji z etatu i przejścia w 100% na własny produkt. Jest to 12-tygodniowy program online. Prawie 14 godzin materiałów wideo. Prywatna grupa mastermind. Spotkania live z mentorami – Marcinem Osmanem, Andrzejem Krzywdą, Piotrem Buckim, Michałem Bąkiem oraz liczne szablony dokumentów takich jak umowy czy regulaminy. Według mnie nie ma nic porównywalnego i równie dobrego na polskim rynku. Szczerze polecam. 

Zapraszam cię na DynamIT, czyli wybuchową konferencję IT, która odbędzie się 17 sierpnia 2019 roku w Krakowie. Będę na niej występował z prelekcją w ramach ścieżki HARD, czyli technologicznej. Będzie też ścieżka soft. Po więcej informacji zapraszam na stronę www.dynamit.pro. 

Zastanawiam się nad odcinkiem typu Q&A, w którym odpowiedziałbym na twoje pytania. Daj znać czy taki odcinek byłby dla ciebie interesujący. Jak zawsze zapraszam cię na fanpage na Facebooku. Jeśli spodobał ci się ten odcinek, to podziel się nim w social mediach lub oceń w aplikacji, w której słuchasz podcastów. Jeśli masz jakieś pytania, to pisz śmiało na krzysztof@porozmawiajmyoit.pl. Miło mi było gościć w twoich uszach. Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tworzeniu aplikacji na iOS. Zapraszam do kolejnego odcinka już za dwa tygodnie. Cześć!