Czy iOS potrzebuje jeszcze Objective-C?

W momencie kiedy zdecydujemy, że chcemy pisać na platformy spod znaku ugryzionego jabłka, bardzo często dochodzimy do momentu zadania sobie pytania, czy warto jeszcze zawracać sobie głowę poznawaniem Objective-C, skoro nawet Apple wszędzie gdzie się da, forsuje Swifta, jako tę słuszniejszą opcję. Niestety, jak w większości takich przypadków, nie ma na to prostej i jednoznacznej odpowiedzi. 

Rozpoczynając od prostego pytania kim jesteśmy, dokąd zmierzamy i po co w ogóle interesować się językiem o tak dziwnej składni?. Apple przygotowując takie SwiftUI czy Combine, jakby zapomniał o ObjC. Nie jest możliwe samo przygotowanie widoków w tym języku, a odwoływanie się do funkcji wcześniej napisanych w ObjC, wymaga stworzenie specjalnego mostu (dodatkowa klasa, która tworzy odwołanie do View Controllera, odwołującego się do funkcji napisanych w starszym języku).

Nie możemy jednak zapominać, że pracując nad aplikacjami, które mają już jakąś swoją historię i po prostu są swoją którąś iteracją, nie rozpoczęły się rok, czy dwa lata temu. 

Trochę historii

Sam Objective-C jest już staruszkiem na aktualne standardy. Powstał w 1984 roku, a najnowsze zmiany w tym aspekcie, w które mieszał się Apple, zostały dołączone już 5 lat temu (już za chwilę szósta rocznica). 

Sam Swift, czyli następca w pisaniu aplikacji na iOS, został po raz pierwszy wydany w roku 2014. czyli ponad 6 lat po powstaniu AppStore. Trzeba pamiętać, że początkowo nie był on częstym wyborem w trakcie pisania aplikacji, ze względu na tak zwane choroby wieku dziecięcego.

Z dużą dozą pewności, mogę przyjąć, że firmy dopiero w roku 2016 zaczęły rozważać przejście na to rozwiązanie, czy jako pierwszy wybór języka w nowych projektach. Zgodnie z danymi zgromadzonymi na Wikipedii, daje nam to ponad dwa miliony aplikacji, które w mniejszym, lub większym stopniu zaczynały swój żywot jeszcze pisane w Objective-C.

Jak to wygląda teraz?

Wiele z tych aplikacji nadal jest rozwijana, a także znaczna ich część nie została w pełni przepisana na nowy język. Nie do końca jestem w stanie wyobrazić sobie sytuację, gdzie Apple nagle by stwierdziło, że wszystkie aplikacje, które są wysyłane do sklepu, muszą być w pełni napisane w Swifcie. Chociaż biorąc pod uwagę niektóre pomysły Apple, nie jest to do końca niemożliwe ;)

Podczas rozwijania i dokładania kolejnych funkcjonalności do swoich aplikacji, bardzo wiele firm (i programistów) wyznaje zasadę działa? nie ruszaj. Z biznesowego i czasowego punktu widzenia, takie podejście ma jak najbardziej sens, ponieważ wykorzystywać czas, po to, aby dana część programu była w danym, a nie innym języku, biorąc pod uwagę pełną kompatybilność Swifta z ObjC, jest w wielu przypadkach nieopłacalne. Ilość czasu związana z przepisaniem aplikacji, nie jest współmierna do korzyści, którą zyskuje użytkownik końcowy.

W tym przypadku, programista iOS, który rozwija istniejący już produkt, powinien kierować się tzw. “zasadą Skouta” i przepisywać dane fragmenty na nowy język w momencie, kiedy dany element jest naprawiany lub zmieniany. To stwierdzenie pasuje do większości przypadków, lecz jak prawie zawsze, są od tej reguły wyjątki. W momencie gdy cały zespół składa się z ekspertów od ObjC, a sam produkt jest złożony, dotyka wielu niskopoziomowych obszarów, lub ma wiele zależności ObjC/C/C++.

Chcąc także rozwijać popularne biblioteki, dość często możemy natknąć się na dużą część lub przewagę ObjC nad Swiftem. Przykładowo:

Gdy nasza biblioteka, czy program, chciałyby wspierać w łatwiejszy sposób frameworki napisane w C lub C++, lepszym wyborem będzie ObjC. Kolejnym powodem może być chęć wspierania bibliotek dla obu języków, ponieważ o ile Objective-C bez żadnego problemu przeportujemy na Swifta, w drugą stronę sytuacja nie wygląda już tak różowo. Starszy brat nie wspiera chociażby przekazywania zmiennych w enumie (ang. associated values). Można oczywiście takich rzeczy po prostu nie używać, lecz wtedy musimy być dużo ostrożniejsi.

Pomijając przypadek wymieniony przed chwilą, a także rozwój istniejących już rozwiązań, sensowność wyboru Obj-C nad Swiftem coraz bardziej się zmniejsza. Także ze względu na to, że coraz więcej aplikacji jest pisanych w nowszym języku, korzystając z jego dobrodziejstw i mniej aplikacji odcinamy od naszych użytkowników końcowych biblioteki. 

Każda nowa funkcjonalność na WWDC jest prezentowana w Swficie. Apple też bardzo mocno wspiera swoje dziecko i daje tak przydatne narzędzia jak np. Playground, umożliwiający szybko testować fragmenty kodu, właśnie pod ten język. 

Mniej lub bardziej odległa przyszłość

Od momentu premiery Swifta w 2014 roku widać wyraźne działania Apple, aby właśnie ten język był promowany na platformach. Pojedyncze fragmenty dokumentacji, jakie możemy znaleźć w ObjC, są zwykłym błędem przy pracy (mam tutaj oczywiście na myśli fragmenty dokumentacji tylko w Objc). Mimo tego, że nadal słychać opinie, że przy projektowaniu dużej aplikacji, warto rozważyć pisanie w stabilnym już Objective-C, zamiast na dynamicznie zmieniającym się Swifcie.

Aby zapobiec dużym problemom, podczas aktualizacji języka do wersji 5, zostało wprowadzone ABI Stability, które w skrócie zapewnia możliwość kompilacji starszego kodu w nowszej wersji.

Czy wchodząc w świat iOSa czy ogólnie programowania na systemy Apple, warto uczyć się ObjC? To mocno zależy. W momencie gdy dopiero rozpoczynamy swoją przygodę z pisaniem aplikacji na telefony z jabłkiem, warto w pełni skupić się na języku Swift. Istnieje pewna szansa, że w momencie poznania już dobrze platformy, jak i API które udostępnia Apple, Objective-C niw będzie nam już potrzebny.

ObjC może być przydatny, kiedy już od 2-3 lat piszemy aplikacje na iOS i chcemy lepiej poznać platformę. Warto poznać jego podstawy, jak i elementy, które wpłynęły na wygląd języka Swift, jak chociażby cały czas funkcjonujące ObjC runtime i realizowana przez niego obiektowość. Objective-C przydaje się także do zrozumienia, w jaki sposób działają zewnętrzne biblioteki, niektóre biblioteki od Apple, które nie zostały jeszcze w pełni przeniesione na Swifta, czy praca nad programami napisanymi w ObjC.

Na pewno jest to język który warto znać w stopniu umożliwiającym zrozumienie logiki danej funkcji. Jeśli chodzi o sam start, warto skupić się na Swifcie, a po poznaniu w dobrym stopniu ekosystemu, jak i samego języka, warto poświęcić swój czas, na zapoznanie się także z tym, co potrafi i jak wygląda ObjC. 

Przeglądając oferty pracy, w większości przypadków głównym językiem jest Swift, a jego starszy brat czasem pojawia się na podobnej pozycji, ale często po prostu, że “dobrze znać”, lub “mile widziane”. Co nie oznacza, że oferty pracy się nie pojawiają, lub nie będą pojawiać. WIele SDK nadal jest pisane w ObjC, nie tylko tych otwarto źródłowych.

Patrząc na aktualne trendy, a także na to, w jaki sposób Apple traktuje oba języki, warto, podobnie jak oni, bardziej skupić się na rozwoju w Swifcie, wiedzieć co potrafi, czego nie potrafi i jakie mogą być problemy podczas przepisywania kodu z jednego, na drugi, mimo ich pełnej kompatybilności w równoległym używaniu obu języków. Z uwzględnieniem wspomnianych ograniczeń z przepisywania z nowszego, na starszy język. 

Wiele rozwiązań dostępnych na iOS, takich jak np. Automatic Reference Counting, powstało z myślą o ObjC i zostało także przeniesione na Swifta. Pisząc, czy modyfikując bardziej skomplikowane zagadnienia, jak chociażby poszukiwanie zombie w kodzie, taka wiedza jest jak najbardziej przydatna i pomocna. 

Jest też wiele źródeł, lecz niestety nie udało mnie się znaleźć żadnego oficjalnego potwierdzenia, że takie aplikacje jak XCode, czy Applowskie biblioteki do wykorzystania podczas pisania (takie jak UIKIt, Foundation itd.), są cały czas pisane w ObjC. Widać to podczas wykorzystania także w Swifcie, chociażby w niektórych miejscach poprzez prefix NS. Lecz te same źródła mówią, że wraz z dalszym rozwojem, kolejne elementy są także przepisywane na Swifta. 

Pisząc aplikacje, tak czy inaczej spotykamy się z odwołaniem do Objective-C runtime, poprzez znacznik @objc, widoczny bardzo dobrze podczas korzystania z UIKIt. Nie bez powodu Apple coraz mocniej rozwija i reklamuje SwiftUI, którego już w ObjC napisać nie jesteśmy w stanie. 

Podsumowanie

Czy iOS potrzebuje jeszcze Obj-C? Tak, ale w coraz mniejszym stopniu i to będzie postępować, o ile Apple nie zmieni swojej strategii. 

Czy warto się uczyć Objective-C? Tak, ponieważ nadal jest on używany w wielu zastosowaniach i raczej nie zapowiada się, aby Apple planowało go zupełnie odsunąć od swojego ekosystemu.

Jaki język wybrać rozpoczynając naukę programowania na iOS? Moim zdaniem Swift, lecz w przyszłości warto także poznać szczegóły i zastosowanie Objective-C.

Wsparcie merytoryczne - Paweł Wojtkowiak