Narzędzia programisty iOS cz. 1: Xcode

Tym razem opiszę najpopularniejsze narzędzia wśród programistów iOS. W pierwszej części skupię się na Xcode, ponieważ to w nim spędza się najwięcej czasu.

Opis przyda się szczególnie początkującym programistom, którzy nie wiedzą gdzie i czego szukać lub wręcz zaczynają przygodę z macOS. Doświadczeni też mogą znaleźć coś ciekawego, ponieważ z pewnością nie każdy się ze wszystkim zetknął. Mnie też to dotyczy, więc jeśli pominąłem coś ważnego, bardzo proszę o komentarz! :-)

Xcode

O nim już chyba każdy słyszał. Co można jeszcze dodać? Całkiem sporo, rzecz jasna. Oczywiście nie będzie tutaj wszystkiego, bo narzędzie to jest tak rozbudowane, że zasługiwałoby na całą książkę.

Pierwsza i najważniejsza rzecz to wersja Xcode, z jakiej chcemy korzystać. Aktualnie wersja Xcode jest równoznaczna z wersją SDK iOS, tvOS, watchOS i macOS. Dla przykładu Xcode 9.3 to SDK iOS 11.3, a Xcode 9.2 to SDK iOS 11.2. Używając starszego Xcode nie możemy korzystać z dobrodziejstw nowego systemu. Użytkownicy iOS aktualizują system bardzo szybko, więc często implementuje się nowe funkcjonalności jeszcze gdy SDK jest w wersji beta aby być gotowym na premierę systemu.

Jeśli projekt nie wymaga używania konkretnej wersji Xcode (co zwykle trwa krótko, aż kod i zależności nie zostaną zaktualizowane) polecam korzystać z najnowszej dostępnej. Rzadko kiedy powoduje to problemy, a często je rozwiązuje. Apple często narzuca konieczność uploadu aplikacji skompilowanych z najnowszym SDK.

Dla przykładu aktualnie Apple wymaga aby od kwietnia tego roku wszystkie aplikacje wysyłane do App store były zbudowane z SDK iOS 11, a nowe aplikacje wspierały w pełni rozdzielczość iPhone X. Tutaj można zauważyć jeden z plusów niekorzystania z nowego Xcode – jeśli projekt jest duży i skomplikowany, poprawienie wszystkich ekranów pod kątem wsparcia dla iPhone X może być problematyczne, a aplikacje skompilowane z SDK iOS 10 będą działały w trybie kompatybilności, wyświetlając czarne paski na górze i na dole. Jest na to jednak pewien sposób. Wystarczy użyć LaunchImage i nie załączyć wersji dla iPhone X. W ten sposób możemy używać nowego SDK i nadal otrzymać tryb kompatybilności.

Tutaj mała dygresja. LaunchImage, choć powszechnie nazywany “splash screenem“, nie jest nim w rozumieniu Apple od początków iOS 10 lat temu. Gdy przyjrzymy się dokumentacji oraz aplikacjom Apple, możemy zauważyć, że ten ekran powinien być zaprojektowany w taki sposób, aby sprawiać wrażenie, że aplikacja otwiera się szybciej niż w rzeczywistości. W jaki sposób? Prezentując główny interfejs aplikacji ale jeszcze bez danych. Niestety “splash screeny” nadal są w modzie. Niektórzy wręcz przedłużają start aplikacji aby użytkownik na pewno zdążył zapamiętać logo producenta… ale to lepiej pomińmy milczeniem.

W jaki sposób zainstalować Xcode? Standardowo pobiera się go z Mac App Store. Osobiście polecam jednak użyć [xcode-install], o którym wspominałem poprzednio.

Budowanie z linii komend

Xcode zawiera też narzędzia linii komend, które są instalowane podczas pierwszego uruchomienia Xcode. Jeśli jest zainstalowane kilka wersji, można wybierać pomiędzy nimi w ustawieniach Xcode (Xcode -> Preferences -> Locations -> Command Line Tools). Można to zrobić również poprzez wywołanie komendy xcode-select lub przez xcode-installprzy użyciu komendy np. xcversion select 9.2.

Ich dokumentację można standardowo odnaleźć przy użyciu systemowych “manual pages” np. man xcodebuild lub man xcrun albo poprzez wewnętrznego helpa, czyli np. xcodebuild -h lub xcrun -h.

Dokumentacja

Xcode posiada wbudowaną przeglądarkę dokumentacji (Window -> Developer Documentation), którą można też otworzyć, klikając w kodzie na symbol trzymając klawisz Command. Nie trzeba jej dodatkowo ściągać i zawiera się wewnątrz Xcode.

Są też inne przeglądarki dokumentacji na macOS. Osobiście polecam Dash. Jest on co prawda płatny ($25) ale przydaje się podczas programowania iOS. Źródeł dokumentacji jest całkiem sporo.

Symulator iOS

Wraz z Xcode dostajemy też kilka innych aplikacji, w tym symulator iOS. Wbrew nazwie jest to również symulator watchOS oraz tvOS. Jak poprzednio wspominałem, działa on bardzo szybko i sprawnie (z wyjątkiem OpenGL), więc warto z niego korzystać. Symulatorami zarządza się w dwóch miejscach.

Pierwsze to ustawienia Xcode. Wchodząc do Xcode -> Preferences -> Components możemy zauważyć listę symulatorów starszych wersji iOS. Najnowszej (dla danego Xcode) nie ma na liście, ponieważ zawsze zawiera się on w paczce z Xcode. Jeśli chodzi o usuwanie symulatorów to musimy to zrobić sami znajdując je w systemie plików (/Library/Developer/CoreSimulator/Profiles/Runtimes)

Drugie to okno Devices and Simulators. Możemy z tego miejsca np. instalować aplikacje, podglądać konsolę urządzeń (fizycznych oraz symulatorów). W tym momencie bardziej nas jednak interesuje możliwość zarządzania instancjami symulatorów. Każda instancja ma swoje zapisane dane, zainstalowane aplikacje itp. Xcode domyślnie stworzy ich wiele, ale dobrze wiedzieć gdzie nimi zarządzać.

Warto też wspomnieć o narzędziu fastlane snapshot. Zostało ono stworzone do hurtowego wykonywania zrzutów ekranu aplikacji do celów publikacji w App Store, ale ma też inną przydatną komendę: fastlane snapshot reset_simulators. Komenda ta skasuje wszystkie instancje i utworzy je na nowo. Przydaje się to szczególnie wtedy, gdy zajmujemy się UI testami lub znudziło nam się bycie zaskakiwanymi, że np. po odpaleniu aplikacji na iPhone 6s z iOS 10.2 mamy już jakieś dane, ponieważ uruchamialiśmy ją tam rok wcześniej…

Dobrze jest też znać kilka podstawowych skrótów klawiaturowych symulatora, a szczególnie “magiczne” działanie przycisków Shift oraz Option – pozwalają one na symulowanie multitouch.

Instruments

Aplikacja Instruments służy do profilowania aplikacji. Uruchamia się ona również podczas wywołania w Xcode opcji Product -> Profile (wtedy też projekt skompiluje się odpowiednio). Jest to zbiór wielu różnych narzędzi służących do dynamicznej analizy kodu. Przykładowe narzędzia to:

• Time Profiler – sprawdza, które wywołania metod zajmują najwięcej czasu i jak bardzo obciążony jest procesor.
• Leaks – analizowanie alokacji i szukanie wycieków pamięci.
• Energy Diagnostics – sprawdzanie jak dużo energii zużywa nasza aplikacja

Osobiście najlepiej trafiały do mnie materiały na temat tej aplikacji z filmów z WWDC. Nic tak dobrze nie nauczy dynamicznego analizowania jak film, który przedstawia działającą aplikację i osobę przy pracy.

Poza dynamiczną analizą kodu jest też Static Analyzer, który jak nazwa wskazuje służy do statycznej analizy kodu. Nie występuje on jednak jako osobna aplikacja, a uruchamia się go poprzez wywołanie w Xcode Product -> Analyze. Zajmuje to trochę więcej czasu niż budowanie projektu ale potrafi wychwycić sporo głupich błędów jak np. kod, który zupełnie nic nie robi.

Ważne foldery

Wspominałem już o tym, że symulatory trzeba usuwać ręcznie. Nie jest to jedyny folder, który warto znać. Najważniejsze moim zdaniem to:

• DerivedData (~/Library/Developer/Xcode/DerivedData) – tam Xcode domyślnie trzyma obiekty pośrednie budowania itp. Jeśli projekt wywala dziwne błędy (choć nie powinien), to najczęściej pomaga usunięcie zawartości tego folderu.
• Simulators (/Library/Developer/CoreSimulator/Profiles/Runtimes) – folder, o którym już wspominałem. Tam są symulatory. Ważą po kilka GB, więc warto usuwać niepotrzebne.
• Device Support (~/Library/Developer/Xcode/iOS DeviceSupport) – symbole oraz biblioteki pozwalające debugować aplikacje na danej wersji systemu. Niestety nie kasują się samoczynnie, więc jeśli brakuje nam miejsca na dysku, to jest pierwsze miejsce, w którym należy go szukać.
• Provisioning Profiles (~/Library/MobileDevice/Provisioning Profiles) – są one potrzebne przy podpisywaniu aplikacji. Nie zajmują dużo miejsca ale czasem ich usunięcie i pobranie ponownie (Xcode -> Preferences -> Accounts -> Download Manual Profiles) potrafi pomóc w problemach z podpisywaniem.

Poza tym dobrą wskazówką jest dodanie katalogu całego ~/Library/Developer do wykluczeń Spotlight. Ktoś z was potrzebuje wyszukiwać przez Spotlight pliki pośrednie budowania? A może symbole debugowania? Jeśli tak, to możecie zignorować tę radę. Pozostali pewnie się ucieszą ze zwiększenia szybkości działania Xcode.

Chisel

Koniecznie trzeba wspomnieć o jeszcze jednym narzędziu, które nie wchodzi w skład Xcode. Jest to chisel.

Dzięki niemu używanie LLDB jest o wiele prostsze. Pozwala np. łatwo znaleźć w hierarchii widok spełniający zadany warunek albo zlokalizować go na ekranie czy też otworzyć podgląd obrazu ukrytego w zmiennej.

Ma o wiele więcej możliwości i naprawdę warto się z nim zapoznać.

AppCode

Jeśli ktoś lubi narzędzia IntelliJ, a bariera finansowa nie jest problemem, polecam skorzystać z AppCode… lub chociaż spróbować. Mi osobiście nie odpowiada skakanie pomiędzy nim a Xcode, ale wiele osób bardzo sobie chwali dodatkowe możliwości.

Prawie wszystkie z wyżej wymienionych porad odnoszą się również do AppCode, ponieważ korzysta ono pod spodem dokładnie z tego samego co Xcode, czyli xcodebuild, xcrun itd. Różnice dotyczą jedynie warstwy GUI, edytora tekstu i pluginów.

Inne narzędzia

W następnej części opiszę krótko kilka innych, mniejszych narzędzi, które na co dzień wykorzystuję w pracy.

A może jest coś innego o czym chcielibyście przeczytać? Dajcie znać!