Własny projekt to większa swoboda, ale to praca w teamie daje dużo możliwości

Jak wygląda praca iOS Developera? Z jakimi problemami mierzy się każdego dnia? I dlaczego każdy developer iOS powinien zainteresować się Swiftem? Na te i wiele innych pytań odpowiedzi znajdziecie w poniższej rozmowie z Bartłomiejem Semańczykiem, iOS Developerem w KISS digital – firmie technologicznej o szerokich kompetencjach związanych z programowaniem aplikacji webowych i mobilnych.

Z jakimi problemami/wyzwaniami mierzysz się każdego dnia?

Przeróżnymi. Czasem są to wyzwania bardzo logiczne, o których nie wolno zapomnieć i trzeba je po prostu obsłużyć. Innym razem mamy problem z wydajnością (aktualnie w swojej aplikacji borykam się z wyświetlaniem na mapie prawie 10 000 labeli, co znacznie ją spowalnia), który wymaga rozwiązania. Często sam Xcode nie do końca działa tak, jak powinien. Continuous integration też nierzadko przysparza trudności, ale jest konieczne do prawidłowego rozwoju i późniejszej dystrybucji aplikacji.

W jaki sposób próbowałeś rozwiązać problem związany z taką liczbą labeli?

Początkowo, gdy sam dodawałem je do mapy, wszystko działało poprawnie. Jednak w momencie, gdy kilkunastu użytkowników zaczęło robić to samo, w dodatku w ogromnej ilości – wyświetlanie znaczników na mapie zaczęło trwać coraz dłużej. Wykorzystana mapa nie jest natywną Apple, tylko Open Street Map, co na samym początku utrudniło mi właściwy clustering, czyli grupowanie obiektów. Po paru dniach udało mi się znaleźć odpowiedni framework, który znacznie usprawnił działanie aplikacji.

Po godzinach piszesz własną aplikację. Opowiedz coś o niej.

Właściwie to pracuję nad kilkoma aplikacjami. Dwie z nich przeznaczone są dla konkretnej grupy osób, dlatego nie są publicznie dostępne w App Store. Mogę za to zdradzić szczegóły dotyczące Tabu. Tabu to prosta gra słowna, przy której świetnie można się bawić. Polega na przekazaniu swojej drużynie danego hasła, bez użycia podanych słów (w żadnej ich formie). Na przykład:

Udało mi się stworzyć już siedem wersji językowych tej aplikacji. Współpracuję z osobami, które dobrze znają konkretny język i mogą przetłumaczyć zestawy takich słówek. Aktualnie dwóch chłopaków z Turcji pomaga mi w stworzeniu wersji tureckiej, a koleżanka z Krakowa zajmuje się tłumaczeniami w języku chińskim. Na tym na pewno nie koniec!

Oferty pracy z

Czego uczy praca nad samodzielnym projektem?

Na co dzień realizuję projekty komercyjne, gdzie nad funkcjonalnością i wyglądem pracuje ktoś inny. Pracując nad własnym projektem, z jednej strony dochodzi więcej obowiązków – oprócz faktycznej realizacji, staram się zrozumieć użytkownika, który oczekuje prostoty, ale jednocześnie funkcjonalności i elegancji. Z drugiej jednak, nie muszę przejmować się dostosowaniem aplikacji do wymagań klienta, innych systemów, czy urządzeń. Pozostanie przy systemie iOS pozwala mi na implementację najnowszych rozwiązań Apple, które mi się podobają… A to naprawdę cieszy.

Jakie są różnice między programowaniem aplikacji na systemy iOS a programowaniem na systemy Android?

Nie programuje na Androida, ale wiem, że w systemach iOS stawia się na prostotę, a Android pozwala na wszystko. Pisząc same aplikacje trzeba być bardzo wyczulonym na restrykcyjne wymagania Apple, które są weryfikowane podczas review. Czasem aplikacje są odrzucane, z różnych powodów. Trzeba faktycznie postawić na szybkość i prostotę – najmniej skomplikowane aplikacje często dostają nagrodę Apple Awards.

Warto instalować także mikropłatności, bo właściciele iPhonów naprawdę bardzo często wydają na to pieniądze.

Jako iOS developer nie musisz za to martwić się o wsparcie dla wszystkich wersji systemu, bo tak naprawdę 98% użytkowników korzysta zawsze z najnowszej i ewentualnie jednej wersji wstecz, czego nie można powiedzieć o Androidzie. Apple produkuje sprzęt i oprogramowanie, co znacznie ułatwia pracę.

Jakie były najczęstsze powody negatywnej weryfikacji aplikacji, którą chciałeś opublikować w App Store?

Na szczęście nie było ich wiele. Pamiętam przypadek, w którym aplikacja była przeznaczona dla dzieci, ale posiadała też panel rodzica, do którego teoretycznie mógł wejść każdy. Należało dodać odpowiednie zabezpieczenie (w tym przypadku – w postaci rozwiązania równania), którego nie mogli obejść najmłodsi użytkownicy. Innym razem, aplikacja wymagała zgody użytkownika na udostępnianie lokalizacji – niestety niedokładnie opisałem przyczynę, dla której udzielenie tej zgody było konieczne. Powody negatywnej weryfikacji bywają przeróżne, ale wszystkie są bardzo dobrze opisane tutaj.

Jakie restrykcyjne wymagania Apple zajmują najwięcej czasu?

Ciężko powiedzieć. Z mojej perspektywy to in-app purchases. Trzeba w prosty i przystępny sposób informować użytkownika za co konkretnie płaci, przeprowadzić go przez proces dokonania płatności, a następnie dać mu to, za co faktycznie zapłacił. To wszystko musi być po prostu czytelne i działać bez zarzutu. Jednakże, rozwiązania proste dla użytkownika nie zawsze są tak łatwe do zaprogramowania przez developera.

Jakie technologie musi znać programista iOS?

Na pewno znajomość Xcode, Swifta, warto jeszcze umieć czytać Objective C. Nie obejdzie się także bez znajomosci Gita. Warto znać architektury programowania aplikacji mobilnych: VIPER, MVVM, MVC. Znajomość zasad SOLID (to pięć podstawowych zasad programowania obiektowego, tj. zasady jednej odpowiedzialności, otwarte-zamknięte, podstawienia Liskov, segregacji interfejsów oraz zasady odwrócenia zależności), OOP (programowanie obiektowe). To pozwoli stworzyć łatwą do utrzymania i czytelną aplikację.

Programista iOS nie musi znać Swifta? Może całą swoją pracę oprzeć na Objective C?

Nie musi znać Swifta, ale jest coraz więcej aplikacji, które są napisane tylko w Swifcie. Jakby nie patrzeć, Objective C to piękny język o niepowtarzalnej składni. Na podstawie własnych doświadczeń widzę, że w Objective C utrzymywane są aplikacje, które zostały napisane przed wydaniem Swifta. Oczywiście, można wciąż pisać aplikacje w Objective C, ale z czasem ten język zostanie zastąpiony przez Swift, który jest zresztą promowany przez Apple.

Dlaczego Apple wybrał właśnie Objective C, niszowy język programowania, zamiast wybrać coś bardziej popularnego?

Chyba Apple przewidziało to pytanie i samo na nie odpowiedziało. Język bardzo spopularyzował Steve Jobs i NextStep. Do dziś w Objective C używamy klas, które zaczynaja się na NS – NSString, NSNumber, NSError… i tak dalej.

Jak wyglądał Twój pierwszy kontakt z programowaniem na iOS?

2014 rok, byłem jeszcze wtedy front-end developerem w jednej z krakowskich firm. Wtedy właśnie Apple wypuścił nowy język, a w moje ręce wpadł iPad. Postanowiłem, że czas na zmianę – przeczytałam książkę o Swifcie dwukrotnie w ciągu paru miesięcy, uzbierałem na MacBooka, wziąłem się za programowanie. Po następnych kilku miesiącach zacząłem pracę na stanowisku Junior iOS Developer w innej firmie.

Czy doświadczenia związane z pracą na stanowisku front-end developera wykorzystałeś w późniejszej pracy?

Poniekąd. Jako frontend developer pisałem dużo w JavaScript. Powiedzmy, że dotknąłem wtedy obiektowego programowania. I to właśnie pozwoliło mi wejść dalej w świat OOP – już w Swifcie, języku kompilowanym.

Jak wyglądała Twoja ścieżka kariery? Ile czasu zajęło Ci przejście od juniora do iOS Developera?

Pamiętam swoją pierwszą rozmowę kwalifikacyjną – dostałem zadanie połączenia się z adresem www, pobrania JSONa i wyświetlenia go na konsoli. To wszystko zajęło mi ponad godzinę. Zostałem zatrudniony na 3 miesiące jako Junior. Razem ze swoim nauczycielem i mentorem miałem okazję faktycznie tworzyć aplikacje dla klienta, chociaż moja praca musiała być sprawdzana i często poprawiana. W firmie zostałem na dłużej, a z czasem, mniej więcej po dwóch latach zdobywania doświadczenia, mogłem sam siebie nazwać iOS developerem. Wciąż jednak nie uważam się za seniora.

Czego przez ten czas się nauczyłeś?

Wielu rzeczy! Tego, że jeśli ja napisałem kod, to nie oznacza to, że ktoś inny nie może go zmienić. Że projekty to nie tylko system iOS, ale też Android, zaplecze backendowe, testerzy, graficy. Tak naprawdę to cała drużyna stoi za jednym projektem, a nie każdy z osobna. Że działanie pod presją czasu wcale nie działa na korzyść projektu. Że jestem w stanie wyszkolić innego juniora, który do dziś pracuje jako świetny developer.

Jakie błędy popełniałeś jako junior?

Myślę, że takie, które każdy z nas popełnia na samym początku. Przede wszystkim, chciałem za dużo rzeczy wiedzieć od razu. Zasadniczo zajmowałem się robieniem funkcjonalności, ale nie zwracałem uwagi na krawędziowe przypadki, które mogły się wydarzyć, a nie zostały obsłużone. Często też chciałem wszystko pisać samemu – pomimo tego, że można było wykorzystać kod, który już został napisany i świetnie działał.

Jak mógłbyś zachęcić do zainteresowania się tym językiem?

Developerzy iOSa to wizjonerzy, oni naprawdę mają szansę zmienić świat. Aplikacje na iOS to nie tylko zwykłe fragmenty kodu, które każdego dnia uruchamiają miliony użytkowników. One faktycznie ułatwiają życie tych, którzy z nich korzystają. Nie chodzi tu o same zarobki, ale o czystą frajdę z programowania na system prosty i prestiżowy, który wciąż się rozwija.

Dlaczego developerzy iOS nazywają się wizjonerami. Czy developerzy Androida nimi nie są?

Nie wiem, kim dokładnie są developerzy Androida. I na pewno nie każdy iOS developer nazywa siebie wizjonerem, ale oglądając jakiekolwiek wydarzenie, na którym Apple prezentuje swoje nowości, ciężko nie być pod wrażeniem. Co by było, gdyby nie Apple? Jakie mielibyśmy dziś telefony i komputery? Steve Jobs był wizjonerem – człowiekiem z pomysłem na to, jak ułatwić codzienne życie. Myślał inaczej (Think different!), dzięki czemu wciąż pozostaje dla nas inspiracją.

Skąd przekonanie, że praca na systemie iOS jest prestiżowa?

iOS jest systemem, który nie pozwoli developerowi zrobić wszystkiego. Dla jednych może być to wadą, bo czują się ograniczeni, ale dla mnie – to zaleta. Pomijając stabilność systemu, wystarczy zwrócić uwagę na wyrazistą markę i wizerunek Apple.

Co najbardziej podoba Ci się w Swiftcie?

Myślę, że jest bardzo intuicyjny i przez to zyskuje coraz większą popularność. Od niedawna jest też dostępny na zasadach open source. Ale mówiąc o samej składni, to chyba najbardziej podobają mi się Optionals.

Czego mu brakuje? Co wziąłbyś z innych języków i przeniósł do Swifta?

Po ostatniej wersji 4.0, na razie nie spotkałem się z brakami. Wiem, że nie ma klas abstrakcyjnych (jak np. w PHP), ale w zupełności wystarczają mi protokoły (odpowiednik interfejsów z Javy).

Co sądzisz o aplikacjach napisanych na iOS, ale w Native React? Swift w każdym wypadku wypada lepiej?

Jestem zwolennikiem natywnych rozwiązań Apple i narzędzi, które udostępnia. Nigdy też nie pracowałem z Native React. Wyznaję zasadę, że producent wie najlepiej, co jest dobre dla jego produktów. Być może na tym polega fenomen Apple: system, narzędzia i urządzenia dostarczane są przez jedną firmę. I to jaką!

---

Bartłomiej Semańczyk. iOS Developer związany z krakowską firmą technologiczną KISS digital, w zawodzie od grudnia 2014 roku. Nie rozstaje się ze Swiftem. W pracy pisze aplikacje dla właścicieli restauracji, banku, kierowców rajdowych, a w czasie wolnym rozwija własne pomysły na aplikacje (jedną z nich w ciągu miesiąca pobiera nawet 10 000 użytkowników!). Jest maniakiem czystego kodu (SOLID, ARCHITECTURE, OOP) i zwolennikiem TDD. Jako moderator, udziela się także na Stackoverflow.