Przed Wami trzecia i ostatnia część podsumowania moich wrażeń po tegorocznym keynote’cie na konferencji WWDC. Na koniec zostawiłem temat interesujący mnie najbardziej. Odwlekałem spisanie tych wszystkich myśli, ponieważ każdego dnia teraz pojawiają się kolejne interesujące szczegóły. No ale kiedyś wreszcie to trzeba było zrobić. Miłej lektury – postaram się nie zanudzić za bardzo szczegółami technicznymi.

To trzecia część moich przemyśleń po WWDC 2014. Pierwszą możecie znaleźć tutaj, a drugą tutaj.

Po dwóch godzinach spędzonych na audytorium w Moscone Center lub przed ekranami urządzeń z nadgryzionym jabłuszkiem deweloperzy mogli zdecydowanie poczuć święta. Ilość prezentów jaka została zaprezentowana może jedynie równać się bardzo obfitą gwiazdką. Nowe zabawki muszą starczyć na cały rok. Najbardziej okazałą z nich jest chyba Swift, czyli zupełnie nowy język programowania.

Gwiazda wieczoru – Swift

developer_swift_icon.png

Zacznijmy od największego zaskoczenia tegorocznej konferencji. Nowy język programowania okazał się wielkim zaskoczeniem, którego chyba nikt się nie spodziewał. Powstawał on w tajemnicy od 2010 roku. Jego twórcą jest Chris Lattner. Początkowo pracował on nad tym projektem sam, a po roku otrzymał wsparcie kilku osób. Od lipca 2013 angażował już dużo zasobów zespołu zajmującego się narzędziami deweloperskimi. Niesamowite, że przez cały ten czas udało się cały projekt zachować w tajemnicy.

W ostatnich miesiącach zacząłem uczyć się Objective-C. Pracując codziennie przy tworzeniu oprogramowania w Javie miałem mieszane uczucia dotyczące składni protoplasty Swifta. Widać w nim było naleciałości z C – w końcu stąd ta litera w nazwie ;). Odniosłem wrażenie, że nagromadziło się ich całkiem sporo i to takich, których nie można już przeskoczyć nie zmieniając fundamentów. Nie ma co się dziwić – w końcu Objective-C ma ponad 30-letnią historię. Tak samo brakowało dużej ilości nowoczesnych konstrukcji, które zdążyły zawitać nawet do Javy. Mimo wszystko programiści chyba przyzwyczaili się do korzystania z niego i nikt nie oczekiwał zmiany.

Swift ma wszystko to, czego Objective-C nie ma. Posiada bardzo zwięzłą i jasną składnię, jak np. generic’i, wskaźniki na funkcje, tuple czy elementy języków funkcyjnych. Eliminuje dostęp do wskaźników oraz dzięki ulepszonemu ARC zrzuca z programistów problem zarządzania pamięcią. Bardzo podobało mi się określenie jakie usłyszałem w jednym z odcinków Accidental Tech Podcast:

Swift is low level language with high level syntax.

Do tego wszystkiego Swift jest ponoć diabelnie szybki – szybszy od Objective-C. Zazwyczaj, aby osiągnąć wysoką wydajność skompilowanych programów kompilatory przeprowadzają na kodzie wiele serii optymalizacji. Wydłuża to zdecydowanie cały proces tworzenia pliku wykonywalnego. Dlatego kolejnym już zaskoczeniem było zaprezentowanie Interactive Playgrounds, czyli narzędzia w którym na żywo możemy oglądać efekty jakie ma napisany kod. Jakim cudem udało im się coś takiego osiągnąć?

swift-screenshot.jpg

Swift, tak samo jak Obejctive-C, jest oparty o LLVM (Low Level Virtual Machine). Pozwala to na użycie tych dwóch języków w jednym projekcie. Co więcej – możemy używać klas z Objective-C w kodzie napisanym w Swift. XCode potrafi generować automatycznie pliki nagłówkowe, które stanowią mostki pomiędzy tymi dwoma językami. Powinno to niesamowicie ułatwić migracje na nowy język. Na pewno nie uda się tego przeprowadzić bezboleśnie (nigdy się nie udaje), ale zdejmie dużo pracy z programistów i skłoni ich do szybszej migracji. Słyszałem już o problemach, jakie mieli twórcy AFNetworking w dostosowaniu swojej biblioteki do nowego języka, ale udało się je szybko przewalczyć. W językach takich jak Java, popularyzacja nowych wersji zazwyczaj jest mocno opóźniona. Patrząc na to, że iOS 7 po niecałym roku jest zainstalowany na ponad 80% kompatybilnych urządzeń, to nie wątpię, że asymilacja Swifta nie zajmie długo.

Apple stworzyło swój podręcznik do nauki tego języka, który możecie znaleźć tutaj. Sam nie mogę się doczekać aż go wypróbuję.

SpriteKit i SceneKit

1402644630.375376.png

Apple zdecydowanie również nie zapomniało o twórcach gier. Zaprezentowany w zeszłym roku SpriteKit został rozwinięty o nowe, ułatwiające pracę programistom funkcje. Od tej chwili obiekty w grze powinny się poruszać dużo naturalniej, a wykrywanie kolizji i dodawanie efektów świetlnych łatwiejsze.

SceneKit to natomiast nowość. Jest to framework do tworzenia gier w pełnych trzech wymiarach. Posiada generator cząsteczek, silnik fizyki oraz umożliwia skryptowanie zachowań obiektów 3D. Zgodnie z zapewnieniami Apple bardzo dobrze się integruje ze SpriteKitem i umożliwia osadzanie elementów tego frameworka w scenach tworzonych w SceneKit’cie.

Metal \m/ ;)

developer_gaming_icon_agp5.png

Apple zaprezentowało również nowy framework do tworzenia zaawansowanej grafiki 3D z wykorzystaniem akceleracji chipu graficznego. Ma on pozwolić wycisnąć siódme poty z Applowskiego chipa A7 nie dając takiego narzutu wydajnościowego, jak przykładowo sterowniki do kart graficznych popularnych producentów.

Jest to API niskiego poziomu i zapewne nie będzie masowo wykorzystywane przez programistów, ale stanowi bardzo dobre pole do popisu dla firm, które tworzą silniki do gier. Epic Games już zapowiedziało, że nadchodzący wielkimi krokami Unreal Engine 4 będzie implementował to API.

Wygląda na to, że OpenGL, którego do tej pory promowało Apple powoli będzie odchodzić w niebyt. Nie można powiedzieć, że to już jest zmierzch tej technologii, ponieważ nadal biblioteki Apple nadal umożliwiają wykonywanie kodu OpenGL. Myślę, że programiści szybko przekonają się o zaletach nowego API i będą na nie migrować.

Warto przy tej okazji wspomnieć o zdecydowanej przewadze Apple w tym względzie nad konkurencją. Oferując sprzęt i jednocześnie oprogramowanie do niego można pozwolić sobie na daleko idące optymalizacje. Zauważmy, że Metal tak na prawdę ma obsługiwać 3–4 chipy o bardzo zbliżonej architekturze. Patrząc na ilość urządzeń z Androidem i to jakie chipy są w nich montowane można powiedzieć, że pod względem wydajności będzie bardzo ciężko im dorównać temu co będziemy mogli zobaczyć na iOSie. To też jest jeden z powodów, dla których w urządzeniach z systemem Google’a na pokładzie są montowane teoretycznie wydajniejsze jednostki, a podczas użytkowania tej różnicy nie widać. Część deweloperów może postawić na Metal i tworzyć aplikacje korzystając tylko z platformy Apple pomijając inne systemy.

developer_gaming.png

Zaprezentowane demo pokazujące, co można osiągnąć za pomocą Metala zrobiło na mnie bardzo duże wrażenie. Wszelkie efekty cząsteczkowe powinny być dzięki temu dużo bardziej bogate. Nie mogę się doczekać pierwszych gier, które wykorzystają wszystkie drzemiące w Metalu możliwości.

HealthKit i HomeKit

1402644722.090033.png

Kolejne dwa API o jakich chciałbym napisać związane są z integracją z zewnętrznymi urządzeniami. Już kilka tygodni temu pojawiła się plotka, że Apple wraz z iOS 8 udostępni aplikację Healthbook, która będzie integrować informacje o naszym stanie zdrowia. Możliwe byłoby monitorowanie aktywności fizycznej, wagi, ciśnienia, poziomu cukry we krwi i wielu innych wskaźników, które mówią o naszej kondycji. Teraz Apple zapowiedziało HealthKit, który umożliwiać będzie przekazywanie informacji do tej aplikacji.

Od razu po tym rozgorzała dyskusja o tym, czy w związku z tym Apple planuje stworzenie mitycznego iWatcha, czy produkcję urządzeń pozostawi firmom trzecim. Norbert Cała w swoich przemyśleniach po-konferencyjnych pisze:

Firma otwierając wszelkie możliwości dla producentów zewnętrznych, postawiła by się w złej pozycji wydając po chwili produkt konkurujący z innymi producentami, których zachęcają do współpracy. Jak dla mnie Apple będzie się w najbliższym czasie koncentrowało na swoich „core” produktach – Mac, iPad, iPhone. Cała reszta to będzie wsparcie usług, aplikacji i akcesoriów tworzonych najczęściej przez firmy zewnętrzne.

Nie do końca się z tym zgadzam. Apple może być bardzo pewne swojej pozycji dotyczącej opracowywanego produktu, że może dorzucić swoje 3 grosze do rynku fitness. Poza tym największą zaletą tego urządzenia może być ścisła integracja z iPhonem. W tym momencie mielibyśmy dwa urządzenia w jednym, a zatem coś unikalnego.

Patrząc po tym, co możemy przechowywać w Healthbooku można powiedzieć, że wszystkich wskazanych w nim wskaźników nie będzie można monitorować za pomocą urządzenia naręcznego. Ponadto Apple, dopuszczając innych producentów urządzeń do zasilania aplikacji danymi, wzbogaci swój ekosystem o dodatkowe informacje, z których korzystałby użytkownik posiadając pełniejszy obraz swojego zdrowia w jednym miejscu.

Pozostaje również kwestia patentów jakie Apple ostatnio uzyskało. Na MyApple znalazłem informację dotyczącą uzyskania przez Apple patentu na czujnik umieszczany na sztandze. Sensor ten miałby pokazywać informacje na ekranie, ale nic nie stoi na przeszkodzie, żeby te dane przekazywał gdzie indziej. Inny z kolei patent opisany w tym artykule mówi o czujniku umieszczanym na podeszwie buta. Ten raczej nie będzie posiadał ekranu… Zdecydowanie jest coś na rzeczy.

14204005420_9cda8eb38c_b.jpg

Drugie API pozwalające na komunikowanie się z innymi urządzeniami to HomeKit służący do sterowania elementami inteligentnego domu. Mamy tutaj możliwość komunikacji z żarówkami zmieniającymi barwy, termostatami, bramami garażowymi itd. Ciekawe jest to, że nie poznaliśmy aplikacji jaka miałaby tym zarządzać. Od dłuższego czasu słychać plotki o nowym AppleTV. Czyżby oprócz centrum domowej rozrywki miałoby ono stać się centrum sterowania inteligentnym domem? Nadaje się do tego idealnie – zawsze jest podłączone do prądu i sieci. Nic nie stoi na przeszkodzie, żeby za pośrednictwem iCloud można było się połączyć do niego z iPhone’a, żeby włączyć robienie kawy w inteligentnym ekspresie.

I Tim Cook i Eddie Cue już kilkakrotnie wspominali o nadchodzących na jesieni nowych produktach. Patrząc na to co będzie dostępne od strony software’owej, to nowe produkty mogą przynieść podobną rewolucję do tej, jaka była udziałem iPhone’a czy iPoda.

CloudKit

developer_capabilities_icon_cloudkit.png

API udostępniające usługi serwerowe to kolejna duża rzecz od Apple, ale mam wrażenie, że przez wielu przeceniana. Wydaje mi się, że wiele osób myśli, że będą mogli pisać aplikacje działające po stronie serwera, a w rzeczywistości to co CloudKit udostępnia to możliwość przechowywania danych na serwerze. Ściąga również z barków programisty potrzebę zarządzania użytkownikami, jako że autoryzacja jest obsłużona po stronie systemu.

CloudKit jest darmowy z nałożonymi ograniczeniami. Zaletą jest to, że wraz z napływem nowych użytkowników ilość dostępnego miejsca i transferu rośnie. Górnym limitem jest 1 petabajt przestrzeni dyskowej. Nie macie i jeszcze chwilę nie będziecie mieli takiej przestrzeni w domowym komputerze. ;)

CloudKit świetnie się sprawdzi jeśli chodzi o aplikacje użytkowe, które synchronizują dane między wersjami mobilnymi i desktopowymi. Przy czym gry MMO już na tym nie uruchomimy. Minusem też jest na pewno to, że usługa ta jest ograniczona tylko do iOS i OS X. A zatem jeśli chcielibyśmy stworzyć coś również na Androida to jesteśmy zdani na siebie.

AppStore bundles

Apple zapowiedziało udostępnienie tworzenia pakietów oprogramowania w App Store i Mac App Store. Wiele ludzi czekało na tego typu funkcję. Wśród użytkowników komputerów z nadgryzionym jabłuszkiem bardzo popularne jest kupowanie wielu aplikacji w pakiecie po cenie raptem jednej z nich. Do tej pory można było udostępniać takie aplikacje, które istnieją poza sklepem Apple. Te, które znajdowały się w sklepie nie miały możliwości uczestniczyć w tego typu akcjach. Być może teraz to wszystko przeniesie się tutaj. Mam jedynie obawę, że ceny takich pakietów mogą wzrosnąć o około 30%, czyli de facto o prowizję jaką inkasuje firma z Cupertino.

TestFlight

Jakiś czas temu Apple kupiło Burstly, czyli firmę która tworzyła TestFlight, czyli narzędzie wspomagające beta testy aplikacji i raportowanie błędów. Teraz firma z Cupertino oznajmiła, że zrobiła najlepszą rzecz, jaką mogła zrobić ze swoim nabytkiem, czyli zintegrowała narzędzie ze swoim systemem i ma zamiar udostępnić je deweloperom. Nigdy więcej podawania UDID!

Zrzut%20ekranu%202014-06-13%20o%2009.34.00.png

Od teraz wystarczające będzie podanie identyfikatora iCloud, żeby zapisać kogoś jako beta testera. Wzrośnie również liczba osób jaką, będziemy mogli zaprosić do testów. Nowe wersje będą mogły być automatycznie rozprowadzane, a raporty o błędach będą automatycznie przekazywane autorom aplikacji. Żyć nie umierać!

Tegoroczne WWDC było prawdziwą wizytą świętego Mikołaja dla programistów. Trochę czasu minie zanim zdołają się zapoznać ze wszystkimi nowymi możliwościami, jakie zostały im pokazane. Zresztą widać to po tym, że od początku konferencji codziennie dowiadujemy się jakichś nowych rzeczy. Systematycznie pojawia się jakaś ukryta opcja czy metoda.

W ostatnich miesiącach Apple zarzucano stagnację. Obawiano się, że po śmierci Steve’a Jobsa firma straciła główny motor napędzający kreatywność i innowację. Wielokrotnie wieszczono rychły koniec Apple. Niektórzy posuwali się nawet do określania dat granicznych, do kiedy muszą się pokazać nowe produkty. Teraz widać dlaczego tak było i co się działo w tym okresie. Pracownicy Apple po prostu intensywnie pracowali and tworzeniem tego co zobaczyliśmy teraz. Te rzeczy nie tworzą się z dnia na dzień. W mediach pewnie przeczytamy, jak to Apple powstało jak feniks z popiołów i wróciło do formy. Prawda jest taka, że ono nigdy nie upadło i nie straciło formy. Po prostu przez ten cały czas ciężko pracowało, abyśmy teraz mogli oglądać owoce ich pracy.