eple overdådig oppmerksomhet på alle plattformene på WWDC i år. Vi fikk til og med en første titt på helt ny Mac Pro. Men en annen kunngjøring, som ikke fanget så mange overskrifter, kan vise seg å være det viktigste å komme ut av årets utviklerkonferanse: SwiftUI.
SwiftUI lover å fundamentalt endre måten utviklere lager apper for Apple -produkter på. Og du trenger ikke å være en tekniker for å sette pris på hvorfor det er så mye.
Med SwiftUI slipper Apple en av Steve Jobs siste arv
Før ble med Apple igjen i 1997, Steve Jobs var administrerende direktør i et selskap kalt NESTE, som produserte et banebrytende operativsystem kalt Neste steg. Søknader for NeXTSTEP ble utviklet i et programmeringsspråk som ble kalt Mål-C.
Apple kjøpte NeXT fordi det trengte et skinnende, neste generasjons operativsystem for å erstatte det aldrende System 7 som Mac-maskiner kjørte på den tiden. Cupertino tilpasset NeXTSTEP til å bli Mac OS X, som senere omformet til macOS, iOS, watchOS og tvOS vi kjenner i dag.
Selv etter alle disse årene, hvis du tar en titt under panseret, er opprinnelsen til Apples plattformer fortsatt tydelig. Navnene på objektklassene Apple bruker i koden starter med bokstavene "NS" for "NeXTSTEP."
Men nå, takk til SwiftUI, Apple begynner å kvitte seg med denne siste NESTE -rest. NSObject og lignende kan snart overføres til historien. Dette er også det første Apple API som ikke er tilgjengelig fra Objective-C siden lanseringen av OS X, noe som kan markere begynnelsen på slutten for dette ærverdige programmeringsspråket.
Fremkomsten av SwiftUI er virkelig slutten på en æra og starten på noe nytt. Men hva handler det om? Og enda viktigere, hva betyr det for Apples sluttbrukere?
Hva er SwiftUI?
Fram til denne uken måtte utviklere bruke AppKit og UIKit for å lage apper for Mac og iOS. Disse API -ene gir verktøyene utviklerne trenger for å produsere brukergrensesnittelementer som knapper, rullelister og inndatafelt. Med sin opprinnelse som går tilbake til NeXTSTEP, begynner disse APIene å vise alderen.
Etter hvert som programvaren blir eldre, får den det teknikere kaller "teknisk gjeld, ”Betyr at selv om det kan være enkelt og kjent å bruke, er det bedre å investere tiden det tar å bytte til en bedre og mer moderne tilnærming. Og den slags bytte er akkurat det SwiftUI handler om.
Da Apple introduserte Swift, etterfølgeren til Objective-C, tilbake i 2014 på WWDC, var det det fakturert som værende "Helt hjemmehørende i både Cocoa [AppKit] og Cocoa Touch [UIKit]." Og takket være Cupertinos tekniske trollmannskap var det det. På en måte.
Apple har alltid vært flink til å gå jevnt over fra en teknologi til en annen. Da selskapet hoppet til OS X, inkluderte det Classic- og Carbon -rammeverkene, slik at gamle apper forble kompatible. På samme måte, med byttet fra PowerPC til Intel -brikker, Rosetta -system sømløst oversatte instruksjoner fra den gamle til den nye brikken.
På samme måte gjorde Cupertino en god jobb med å gjøre AppKit og UIKit kompatible med Swift. Men du kan fortelle at API-ene er gamle og nærmer seg salgsdatoen.
SwiftUI gjør det mulig for Apple å fjerne NeXTSTEP -arven en gang for alle, og erstatte den fra bunnen av med en ny, opprinnelig API for Swift -utvikling.
Hva er så flott med SwiftUI?
Det kan være nytt og annerledes, men hva er egentlig så flott med SwiftUI? Det er mye for utviklere å elske om det. Men for vanlige Apple -kunder som deg og meg er det tre hovedfordeler vi kan forvente: flere apper, bedre apper og bedre støtte for Mac og Apple Watch.
1. Flere apper: tiltrekker seg en ny utviklerras
SwiftUI bringer Apple oppdatert med nåværende trender innen programmering. Den kan skryte av en deklarativ syntaks, en programmeringsstil som allerede er populær blant webutviklere som bruker JavaScript. Det betyr at den umiddelbart blir kjent for et bredt spekter av teknikere som er nye i Apples måte å gjøre ting på. Ved å gjøre det lettere for nye utviklere å komme opp i fart, kan SwiftUI tiltrekke seg en helt ny utviklerras til plattformen.
2. Ekte innfødte apper: Oppfordrer utviklere til å droppe APIer på tvers av plattformer
Facebook tilbyr et appopprettingsverktøy kalt Reager Native. Det har blitt veldig populært fordi det gjør det mulig for utviklere å bygge apper i JavaScript og deretter kompilere dem som native apps for å kjøre på både iOS og Android -enheter. Det er veldig bra, men apper som er bygget med verktøy på tvers av plattformer som dette, fungerer sjelden så godt som ekte native-apper.
Hvorfor? Fordi de krever masse ekstra kode, i form av tredjepartsbiblioteker, for å få dem til å fungere. Som et resultat har de en tendens til å være større, mer trege og mer krevende for systemressurser og batteri enn apper som er bygget med Apples verktøy. De føler seg sjelden som ekte native apps.
Med SwiftUI gir Apple utviklere en mindre grunn til å ty til plattform-APIer. Det er mye raskere og lettere å utvikle seg i, og med sin deklarative syntaks er det lettere for React -utviklere å adoptere.
3. Bedre støtte for Mac og Apple Watch: Gjør det mulig for utviklere å bruke kode på tvers av plattformer
Utviklere kan alltid gjenbruke kode på tvers av Apples plattformer, fordi de alle støtter Objective-C og Swift. Men til denne uken kunne de ikke gjenbruke brukergrensesnittkoden. Det er fordi hver plattform har sine egne rammer for det. Mac bruker AppKit, iOS bruker UIKit, og watchOS bruker WatchKit. For at en app skal fungere på alle tre plattformene, må utvikleren produsere tre separate versjoner av brukergrensesnittkoden.
SwiftUI lover å endre alt dette, fordi det samme rammeverket er innfødt på alle Apple -plattformer. I praksis er det lite sannsynlig at det er så enkelt fordi hver plattform har sine forskjeller. En app som er optimalisert for den ekspansive skjermen på en iPad Pro, ville ikke lett tilpasses de små dimensjonene til en Apple Watch.
Ikke desto mindre kan SwiftUI på lang sikt vise seg å være like viktig som å gjøre det mulig for utviklere å gjenbruke mer brukergrensesnittkode på tvers av plattformer. Project Catalyst for å oppmuntre utviklere til å omfavne alle Apples produkter.
Når kan vi forvente å se apper bygget i SwiftUI?
Akkurat nå, SwiftUI er i beta som en del av Xcode 11. Utviklere vil leke med det og sparke dekkene i noen måneder før de faktisk begynner å bygge ekte apper i det.
Xcode kommer sannsynligvis fra beta i september med lanseringen av iOS 13. Og det er da SwiftUI -utviklingen virkelig kommer i gang. Selv da er det mulig at rammeverket ikke vil være fullstendig, noe som betyr at utviklere kan fortsette å stole på AppKit og UIKit hvis API-ene de trenger ennå ikke er tilgjengelige i SwiftUI.
Det kan også ta lang tid for utviklere av store, komplekse apper som Photoshop å bytte. Så AppKit og UIKit vil henge rundt en stund.
Likevel er det ingen tvil om at SwiftUI er begynnelsen på et viktig nytt kapittel for Apple. På sikt kan vi forvente å se fordeler ikke bare for utviklere, men for alle som bruker Apple -produkter. Denne uken kan gå over i historien som en veldig stor milepæl for Apple. Noe som om 10 år fra nå, vil vår helt egen Luke Dormehl minnes i et "I dag i Apple -historien" post.
