A 2014. évi Worldwide Developers Conference ez alkalommal valóban a fejlesztőkről szólt. Az iOS megjelenése óta megrendezett WWDC-k közül szerintem az idei lett a legszínvonalasabb; nekem személyes kedvencemmé vált. A 2012-es és 2013-as keynote-ok után sokan elégedetlenkedve vagy kissé csalódottan távoztak a képernyők elől, mert az Apple az előző két évben nem foganatosított olyan radikális változtatásokat, amelyeket egyesek elvártak volna. Idén viszont nem érheti szó a ház elejét: sok jelentős újítást és innovatív technológiát kaptunk, a cég mérnökei pedig számtalan apró kényelmi funkcióval is kellemesebbé tették a szoftveresek életét.

Nagyszerű hír, hogy a WWDC anyaga (az ott nyilvánosan bejelentett fejlesztések), az iOS 8 SDK és az OS X Yosemite dokumentációját is beleértve, idén nincs NDA (titoktartási kötelezettség) alatt, tehát a fejlesztők legálisan beszélhetnek, írhatnak róla nyilvánosan, sőt, a dokumentációt az Apple fel is tette a fejlesztői oldalára. Magukra a bétaverziós operációs rendszerekre illetve a keynote során be nem mutatott API-kra viszont továbbra is vonatkozik a titoktartási kötelezettség.

Ezzel a lehetőséggel élve szeretnék az alábbiakban egy rövid betekintést nyújtani az érdeklődők számára. Természetesen a felsorolás nem teljes; aki tüzetesen meg szeretné ismerni az új lehetőségeket, annak mindenképpen rá kell szánnia néhány napot a dokumentáció fontosabb részeinek áttanulmányozására. Ehhez nincs más dolgotok, mint az iOS Developer Library “Pre-release” oldalára navigálni.

Tim Cook — jó vezérigazgató módjára — legelőször természetesen az App Store legújabb statisztikáit vette számba. 1,2 millió alkalmazás, heti 300 millió felhasználó, aki megnyitja az App Store-t, 75 milliárdos letöltésszám — a gigászi adatok felsorolása után Tim azt mondta: “De mi még ennél is jobbá akarjuk tenni az App Store-t”.

Az elsőként bemutatott feature-ök még nem igazán a fejlesztőket, sokkal inkább a felhasználókat célozzák meg. Gyakorlatilag az iOS-es App Store alkalmazás felhasználói élményén és a keresések pontosságán, relevanciáján javítottak. Mostantól a Store felajánl nekünk kapcsolódó keresési kulcsszavakat is, valamint beépítettek egy “Trending Searches” menüpontot is, amelyben a legnépszerűbb keresések vannak felsorolva.

Nagy népszerűségnek örvendett az előnézeti videók feltöltésének lehetősége is — de ez is még inkább a felhasználók számára érdekes, a fejlesztőknek inkább csak egy pluszfeladat lesz a videók elkészítése… 😛 Bár az App Store-ban megjelent leírások eddig is tartalmaztak az adott alkalmazásról készült képernyőképeket, egy olyan videó, ami élőben mutatja be az app működését, sokkal valósághűbb képet nyújthat a felhasználói élményről és az egyes funckiók működéséről.

Az első, ténylegesen a fejlesztőknek szóló újdonság az alkalmazáscsomagok, “App Bundle”-ök megjelentetésének a lehetősége. (Ezt nem szabad összetévesztenünk a fejlesztők által már eddig is jól ismert app bundle-ökkel, ami nem több program összességét jelenti, hanem azt a könyvtárszerkezetet, amiben egy adott alkalmazás telepítve lesz a készülékre.) Az új szolgáltatás segítségével a fejlesztők megengedhetik a felhasználóknak, hogy több alkalmazásukat egyszerre, mintegy “csomagban” töltsék le, méghozzá kedvezményesen.

Az Apple még februárban jelentette be a népszerű bétateszt-program, a TestFlight mögött álló Burstly felvásárlását. Azoknak, akik esetleg nem ismernék a TestFlight-ot, elmondjuk, hogy ez egy olyan szolgáltatás, aminek segítségével a fejlesztők kényelmesen tudják tesztelésre kiadni a megjelenés előtt álló alkalmazásaikat. A bétateszternek jelentkező felhasználóknak csak regisztrálniuk kell a TestFlight honlapján, ahonnan a készülékükre letölthetnek egy úgynevezett Provisioning Profile-t. Ez teszi lehetővé, hogy a még ki nem adott alkalmazásokat is engedje telepíteni az iOS. (E sorok írója a jailbreakelést még mindig kényelmesebbnek találja, mint a titkosítási kulcsokkal való szenvedést, node a jailbreakelés nyilván nem mindenkinek opció, és nem is minden esetben lehetséges.) A fejlesztők pedig a TestFlight SDK használatával könnyen és gyorsan tudnak információkat szerezni a programjuk működéséről, az esetleges hibákról, belassulásokról, memóriaszivárgásokról, stb.

Nos, a TestFlight ezentúl az iOS-be lesz integrálva, és meglepő módon ingyenes marad. A fejlesztők meghívhatják az egyes felhasználókat bétatesztelésre, és a már megszokott formában kapják meg az eredményeket.

Az App Store után végre-valahára az iOS SDK-ra került a sor a keynote-ban. Az új API-kat a legkompetensebb személy, Craig Federighi, az Apple szoftverfejlesztésért felelős igazgatóhelyettese mutatta be.

Tim Cook szerint az iOS SDK-ban véghezvitt fejlesztések az iOS 8-at az utóbbi idők legnagyszerűbb iOS-verziójává teszik. Azt is mondta, hogy a fejlesztők számára olyan dolgokat tettek lehetővé az iOS 8-ban, amiről eddig még csak álmodni sem mertek. Ez azért kicsit túlzás, itt halkan megjegyezném, hogy például az új, Extensibility névre hallgató rendszerszolgáltatás a jailbreak és a MobileSubstrate által nyújtott bővíthetőségnek és flexibilitásnak a közelébe sem ér, de erről majd később.

A keynote-on elhangzott, hogy “több, mint 4000 új API” került bele az új rendszerbe. Az, hogy pontosan mit értettek API alatt, a kicsit business speak szagú beszédből nem derült ki, azonban az Apple oldalán megjelentetett API diff-ből, aminek valóban kb. 4000 bejegyzése van, arra lehet következtetni, hogy valószínűleg az egyes metódusokra, osztályokra, függvényekre és makrókra gondoltak.

Node mi is az az Extensibility API? Az iOS és OS X egyes komponensei specifikusan támogatják majd a bővíthetőséget. Ennek eredményeként például az Értesítési központban, a megosztást végző paneleken (e-mail, Twitter, Facebook), OS X-en pedig a Finder bizonyos részeiben is egy App Store-os alkalmazás is elhelyezheti a saját widgetjeit. A widgetek interaktívak, így bizonyos — egyszerűbb — feladatokat akár az alkalmazás megnyitása nélkül is elvégezhetünk, közvetlenül az extension segítségével.

A “Share” és “Action” típusú kiegészítők Safariban való futtatása esetén a kiegészítők az aktuális weboldalhoz is hozzáférhetnek JavaScript kódon keresztül. A hivatalos dokumentáció a JavaScript futtatására is hoz példát, érdemes beleolvasni.

Ugyan a fejlesztés menetét nem befolyásolja, de technológiai szempontból érdekes tény, hogy az app extensionök nem dinamikus könyvtárak (dylib), hanem rendes, önállóan futtatható fájl formájában kerülnek lefordításra. (Ezt csupán onnan szűrtem le, hogy az Xcode bétaverziójában az iOS szimulátor számára lefordított fájlok között böngésztem egy kicsit, de amint tudjuk, a szimulátornak néha jóformán köze sincs a valódi készüléken történtekhez, így tehát nem merem teljes biztonsággal állítani, hogy egy tényleges iPhone-on vagy iPaden is ugyanez a helyzet.)

Az Extensions API másik legfontosabb része a személyre szabott billentyűzetek telepítése. Az alkalmazások saját, rendszerszintű billenytűzeteket is feltehetnek a készülékre (természetesen a felhasználó engedélyével), így lehetségessé válik például saját készítésű emotikonok használata, vagy akár az automatikus javítás működésének módosítása is.

Érdekes módon az Extensibility API nem kapott saját frameworköt; osztályait (NSExtensionItem, stb.) a Foundation könyvtáron belül találjuk meg. Ez alól kivétel a NotificationCenter framework, amely — értelemszerűen — az Értesítési központban megjelenő widgetek készítését elősegítő osztályokat és protokollokat tartalmaz.

Egy évnyi várakozás után végre a külsős alkalmazások is kapnak Touch ID API-t. A fejlesztők a Keychainben tárolt adatokat védethetik le biometrikusan. Magához az ujjlenyomat-információhoz az alkalmazások természetesen továbbra sem férnek hozzá, tehát az adataink biztonságban vannak. (A Touch ID amúgy sem tárolja az ujjlenyomatunk képét, csak egy abból számított hash-t, tehát ha még hozzá is férne egy alkalmazás, akkor sem tudna sokmindent kezdeni vele, hiszen az eredeti ujjlenyomatot a hashből nem lehet visszafejteni.)

A Touch ID használatához szükséges osztályokat a LocalAuthentication frameworkben találhatjuk meg.

A fényképező finomhangolását is megkapjuk végre. Az AVCaptureDevice és AVCaptureOutput osztályok olyan új property-kkel és metódusokkal egészültek ki, amelyek lehetővé teszik az exponálás hosszának, az ISO értéknek, a fehéregyensúlynak és a fókusztávolságnak a manuális beállítását illetve az aktuális értékek lekérdezését. Az új Photos framework pedig lehetőséget ad a fejlesztőknek a PhotoLibrary-ből való olvasásra, az oda történő írásra, a felhasználó engedélyével pedig képek törlését is megoldhatjuk kódból.

Az iOS 8 a mindennapi élet megkönnyítésére is nagy hangsúlyt fektet. Az egészségügyi adatokat, statisztikákat szolgáltató HealthKit, valamint az otthonautomatizálást (home automation) egységes és biztonságos protokollon keresztül megvalósító HomeKit framework nem holmi Sci-Fi-ből pottyantak ide, hanem ezentúl az iOS-felhasználók mindennapjainak részét fogják képezni. A HomeKit egyébként különösen jól lett kitalálva, ugyanis nemcsak külön-külön irányíthatjuk az automatizált készülékeket, hanem csoportokba is szervezhetjük őket. A HomeKitben helyet kapott a Siri-integráció is, így a rendszeresen ismétlődő feladatok (ilyen például lefekvés előtt a lámpák lekapcsolása vagy munkába menet az ajtók és ablakok bezárása) elvégzése ténylegesen “csak egy szavunkba kerül”.

Igazi, programozóknak való csemege a szintén új CloudKit framework. Ennek a használatát (vagy nem használatát…) az átlagfelhasználó aligha fogja észrevenni, ugyanis ez az API a webalkalmazások logikájának könnyű, gyors és egységesített implementálását tűzte ki célul. A CloudKit használatával — bizonyos, az adatmennyiségre és sávszélességre vonatkozó határokon belül — gyakorlatilag ingyen webhostingot kapunk az Apple-től, valamint osztályokat a fájltároláshoz, le- és feltöltéshez és nem utolsó sorban a felhőalapú adatbázis-kezeléshez.

Nemcsak a kényelem, hanem a teljesítmény és a sebesség terén is nagyot alkotott a cupertinói iOS-fejlesztőcsapat. A Metal framework az eddig de facto szabványként 3D renderelésre használt OpenGL-t hivatott lecserélni. Az új technológia megalkotására azért volt szükség, mert az OpenGL egy elég vastag réteget képezett a hardver és az alkalmazások között, annak ellenére is, hogy iOS-en a kifejezetten beágyazott rendszerekre készült, kisebb, “ES” változata futott. A Metal library egy sokkal vékonyabb réteget alkot (itt vajon kevesebb ragasztókódra kell gondolni?), valamint támogatja az előre leforított (precompiled) shaderek használatát. Ez a shaderrutinok betöltését bizonyosan meggyorsítja; az, hogy a futásidőt mennyiben befolyásolja, nem tudom (nem vagyok 3D grafikai szakértő — sajnos), de lehetséges, hogy ott is javít a teljesítményen.

Egy biztos: Craig Federighi állítása szerint a Metal használatával akár tízszeresére is nőhet a renderelés sebessége. Ez azt jelenti, hogy másodpercenként akár 4000 draw call-t (háromszögek bizonyos csoportjának kirajzolását) is el lehet végezni.

Az Apple a Metal kifejlesztése során együtt dolgozott néhány nagy játékkiadó céggel. Az EA például a Metal segítségével portolni tudta iOS-re az — amúgy konzolokra és asztali gépekre írt — Frostbite játékmotort. Az engine eddig csak Windows-on, Xbox-on és PlayStation-ön működött, és az EA állítása szerint nem is gondolták volna, hogy valaha is el fog futni egy mobilkészüléken.

Az “Apple által megalkotott új buzzword” cím idei nyertese valószínűleg a “console-level game” kifejezés lesz…

A teljes 3D-s játékok mellett a kisebb grafikai teljesítmény igénylő, egyszerűbb játékok készítőire is gondolt az Apple. A tavaly kiadott SpriteKit frameworkbe sok újítást tettek az idén (ezek főleg fizikai, mechanikai vonatkozásúak), illetve iOS-en megkaptuk az OS X-ről már ismerős SceneKit API-kat.

A keynote során bemutatott “zászlóshajó” feature-ökön kívül még természetesen rengeteg más, kisebb változás is található az új SDK-ban. Ezek némelyike viszont szinte ugyanolyan fontos — legalábbis a programozói kényelem szempontjából —, mint egy-egy külön kiemelt új API. Az én személyes kedvencem ezek közül a CoreLocation framework CLFloor osztálya. Ismerjük az Apple azirányú törekvéseit, hogy bizonyos nagyobb és fontosabb épületeken belül részletes helymeghatározási szolgáltatást nyújtson. A CLFloor ennek egy előfutára: az iOS-készülékeinkben található GPS mostmár tudni fogja azt is, hogy hányadik emeleten tartózkodunk.

A kisebb, kevésbé kiemelt, de mégis hasznos API-król az NSHipster összeállított egy csinos kis gyűjteményt. Erre tessék.

Ha itt vége lett volna a WWDC-nek, én már akkor sem elégedetlenkedtem volna, sőt. Az Apple viszont, úgy látszik, a “ha már lúd, legyen kövér” stratégiát folytatta 2014-ben. Megírtak ugyanis egy teljesen új programozási nyelvet, a Swiftet. A Swift fejlesztése még 2010-ben kezdődött; minden elismerésem a dolgozóknak, hogy semmi sem szivárgott ki belőle. Mégcsak pletykák vagy találgatások sem születtek e téren.

A Swift egy natív, LLVM által optimalizálva fordított, többparadigmás (objektum-orientált, funkcionális és imperatív), C-szerű szintaxissal rendelkező, magasszintű, statikusan típusos, objektum-orientáltságában mégis dinamikus nyelv. A nyelv a teljesítményt, sebességet és a biztonságot ötvözi egyben — a “swift” szó jelentése: “gyors”, “sebes”. Objektum- és osztályrendszere az Objective-C runtime-jára alapul, azonban alapvetően nincsenek benne explicit pointerek (bár, ha nagyon akarunk, akkor használhatunk pointereket, de az egy elég haladó téma Swiftben). Memóriakezelése automatikus, az Objective-C-ből már jól ismert ARC technológiát használja. A tömbök indexelése előtt a tömb méretét ellenőrzi a nyelv (bounds checking), ezzel megelőzve a buffertúlcsordulásos hibák nagy részét.

A Swifthez tartozó fő fejlesztőeszköz (sajnos) továbbra is az Xcode. A nyelv egyik legfőbb érdemeként emlegetett interaktivitás tulajdonképpen nem is magának a Swiftnek a tulajdonsága. A gépeléskor a kódot azonnal kiértékelő REPL, a programvégrehajtásban visszafelé is lépetni képes interaktív debugger és a többi kényelmi funkció igazából többé-kevésbé az Xcode és/vagy az LLVM toolchain részét képezi.

A nyelv nemcsak az Objective-C objektumrendszerével, hanem egyszerű C függvényekkel is képes együttműködni. Emellett pedig az Objective-C-ből olyannyira hiányzó névterek is belekerültek a Swiftbe. Végre nem kell egyedi két- és hárombetűs osztálynév-prefixumokon törni a fejünket!

A hozzám hasonló “readability freak”-ek számára tartogat pár kellemes meglepetést az új nyelv szintaktikája. Először is, a pontosvesszők nem kötelezőek. (Erre mondjuk én személy szerint nem vagyok allergiás, sőt, én szebbnek találom a pontosvesszőkkel tagolt Swift kódot, dehát ízlések és pofonok, ugye…) Szintén opcionálisak a zárójelek az if statement, a while, do-while és for ciklusok feltételét képező kifejezések körül. (Khm, khm…)

A nyelv teljeskörű Unicode-támogatással is rendelkezik, tehát sajnos már tudunk például ékezetes karaktereket vagy emotikonokat használni változónévként. Kérlek benneteket, hogy ne tegyétek!

Az igazi csemege viszont a switch statement szemantikája. A switch statement feltétele nemcsak egész szám lehet, mint C-ben. Megengedettek például a stringek is. Sok-sok hibalahetőség  kiküszöbölésére lesz pedig jó az, hogy az egyes esetek (case) végén nincs “fallthrough”, nem szükséges az explicit “break”. Ez valószínűleg programozók tízezreinek az életét fogja szebbé varázsolni.

Amint említettem, a Swift többek között a funkcionális programozást is támogatja. A closure-ök (hívja valaki ezeket egyáltalán a magyar nevükön “lezártaknak?”), a mintaillesztés (pattern matching) és a típus-kikövetkeztetés (type inference) a kód olvashatóságát javítják, a konstansok használata pedig az optimalizálást segíti. A Haskellből ismert Maybe típus és az Objective-C “silent nil”-jének frigyéből született opcionális típuskvalifikátor (“?”) a null pointerek által okozott hibák egy részét teszi fordítási időben észlelhetővé.

Craig állítása szerint a Swift általában gyorsabb, mint az Objective-C — ez a kijelentés azonban még elég gyenge lábakon áll. Keith Gugliotto készített néhány benchmarkot, amelynek során tipikus programkonstrukciókban — üres ciklus, értékadás változónak, elem hozzáadása tömbhöz, stringek összefűzése (konkatenációja) — hasonlította össze a két nyelv sebességét. Az eredmények elég elkeserítőek — az Objective-C általában legalább egy nagyságrendet rávert a Swiftre. Én személy szerint nem merek semmilyen hosszútávú következtetést levonni ebből. Lehetséges, hogy a “gyorsabb” az csak amolyan reklámszöveg volt (a Safari JavaScript-motorjának, a JavaScriptCore-nak a sebességével kapcsolatban már rajtakapták némi csúsztatáson az Apple-t), de az is lehet, hogy a tesztek nem voltak jók (az olvasók egy részének ez a véleménye).

A Swift compilernek/interpreternek és az Xcode-ba épített Swift-támogatásnak is vannak még hiányosságai és hibái. Még béta szoftverhez képest is sok bennük a bug. Mind az Xcode-ot, mind a parancssoros Swift REPL-t ki lehet akasztani egy egészen triviális rekurzív típusdefinícióval:

struct Foo { var bar: Foo }

Ahelyett, hogy az értelmetlen (végtelen rekurziót okozó) típusra hibaüzenetet adna a fordító, inkább végrehajtja a végtelen rekurziót, és a stack elfogyásakor természetesen elszáll “bus error”-ral.

Egyszóval az Apple-nek van még mit javítania az implementáción, a nyelv alapfilozófiája, designja, koncepciója viszont kifejezetten modern és üdítő. Biztos vagyok benne, hogy a hibákat időben ki fogják javítani, és egy nagyszerű élmény lesz a programozás Swiftben.

Egyetlen dolog maradt hátra, amit a sok dicséret között nem tudok szó nélkül hagyni. Az Apple, úgy látszik, idén az egységesítés, “szabványosítás” felé indult el. A CloudKit a webalkalmazásokat egységesíti, a HomeKit a lakásautomatizálás protokolljait fogja össze, az OS X és az iOS működésének és felhasználói felületének konvergenciája pedig nyilvánvaló. Ez egyrészt jó hír, mert az egységes felületek, API-k és protokollok egyszerűbbé és kényelmesebbé teszik mind a fejlesztők, mind a felhasználók életét, valamint a biztonságot is javítják.

Az érmének azonban két oldala van. Az Apple eddig is szerette megmondani az embereknek, hogy mit csináljanak, és nem vagyok benne biztos, hogy az “egységesítés” helyett nem kellett volna-e inkább “központosítást” írnom. Vegyük észre, hogy a cég nagyon sok nyílt szabványt lecserélt saját, zárt, proprietary technológiákra. Az OpenGL helyett megkaptuk a Metalt, a javarészt C-re alapuló Objective-C vetélytársa pedig a Swift lett. Igen, úgy tűnik, hogy a Swift egy proprietary nyelv, a forráskódja nem elérhető. Nem tudni egyelőre, hogy a bétaverzió lejárata után, az iOS 8 nyilvános kiadásakor ez meg fog-e változni. Ez kicsit aggasztó lehet, legalábbis én annak érzem. Hogy ez hosszú távon milyen következményekkel fog járni, azt nem látjuk előre, mindenesetre a nyílt szabványok és szoftverek használata nekem mindig is rokonszenvesebb volt.

És nektek, magyar fejlesztőknek, mi a véleményetek az idei WWDC-ről? Tetszik a Swift? Aki felhasználói szemszögből követte a keynote-ot, mit szól az új technológiákhoz? Írjátok meg hozzászólásban!