Share
I løpet av WWDC gir Apple tradisjonelt utviklere en snakk av neste store utgivelse av IDE, Xcode. Med alle store utgivelser forbedrer selskapet sine utviklerverktøy og legger til en rekke overbevisende nye funksjoner. Og i år var ikke annerledes.
Frem til Xcode 8 var hver versjon av Xcode knyttet til en bestemt versjon av Swift programmeringsspråket. Det er ikke lenger sant fra Xcode 8. Swift 3 introduserer en rekke endringer, og et betydelig antall av disse endringene bryter.
Prosjekter opprettet med Xcode 8 bruker Swift 3 som standard. Heldigvis inneholder Xcode 8 en bygginnstilling som gir utviklere muligheten til å holde fast med Swift 2, Swift 2.3 for å være presis.
Dette betyr at du kan velge når du vil overføre et prosjekt til Swift 3. For å konfigurere et mål for Swift 2.3, åpne målets bygginnstillinger og sett Bruk Legacy Swift Language Version til Ja.
Xcode 8 inneholder også et migreringsverktøy som hjelper deg med å migrere et prosjekt til Swift 3. Jeg har hatt blandede resultater med migreringsverktøyet til Xcode 7. Swift 3 introduserer mange, mange endringer, og jeg håper at migreringsverktøyet har forbedret seg betydelig når Xcode 8 er klar for utgivelse.
En av de mest overraskende funksjonene var introduksjonen av kilde redaktørutvidelser. Utviklere har bedt om en innfødt pluginarkitektur i mange år. Kilderedaktørutvidelser er et første godt skritt i den retningen.
Det er mye å like om utvidelser for Xcode, men Apple understreker at utvidelser for tiden er fokusert på å manipulere og navigere innholdet i kildeditoren, derav kildeditorutvidelser. Xcode 8 inneholder selv en mal for å hjelpe deg med å komme opp til fart.
Det jeg spesielt liker om utvidelsesarkitekturen er at hver utvidelse går i en egen prosess. Dette betyr at en crashing-utvidelse ikke forårsaker at Xcode slutter uventet. Dette forårsaket ofte problemer med hjemmelagde plugins, spesielt hvis Apple sendte en ny stor utgave av Xcode.
En annen fordel utvidelser har over plugins er sikkerhet. Du kan signere og distribuere utvidelser ved hjelp av utviklerkontoen din. Apple nevnte også at du kan bruke Mac App Store til å distribuere utvidelser. Dette er et flott alternativ hvis du er interessert i å tjene penger med utvidelsene du lager.
Jeg er veldig spent på kildedirektørutvidelser. Mens jeg er en stor fan av Alcatraz, ser Apples opprinnelige implementering av utvidelser veien fremover. Jeg kan ikke vente å se hva slags utvidelser utviklere skal bygge. Det er allerede noen tilgjengelige på GitHub.
Selv de beste utviklerne bruker en betydelig del av tidenes feilsøking, og Apple forstår behovet for bedre verktøy for å gjøre denne oppgaven enklere. Xcode 8 introduserer en rekke betydelige forbedringer relatert til feilsøking.
Vis feilsøking er mye kraftigere i Xcode 8. Pålitelighet har forbedret og feilsøking av tvetydige eller usatisfiable oppsett er mye lettere takket være en forbedret visning av feilsøking som viser kjøretidsproblemer.
Runtime problemer? Det er riktig. Xcode 8 introduserer runtime problemer i tillegg til buildtime problemer. Hvis du kjører inn i Auto Layout-problemer ved kjøring, viser Xcode problemet ditt som et kjøretidsproblem i Issues Navigator til venstre. Dette er et veldig velkommen tillegg.
Xcode 8 har også en ganske imponerende minnefeil for å spore opp minnelekkasjer og beholde sykluser. Jeg er ikke sikker på hvor nyttig det skal være i praksis, men det ser veldig bra ut.
Kodesignering er et nødvendig onde for utviklere som er interessert i Apples plattformer. Heldigvis begraver Apple ikke hodet i sanden. Det forstår smerteutviklerne har. Selv veteraner sliter med kodesigneringsproblemer fra tid til annen. I løpet av årets plattformer Statens Union, gjorde Apple til og med gøy av seg selv Løs utgave knapp som sjelden løste problemet og noen ganger gjorde ting enda verre.
Kodesigneringsproblemer bør være en ting fra fortiden med Xcode 8. For hvert mål kan du sjekke en avkrysningsboks som forteller Xcode å administrere kodesignering på dine vegne. Dette alternativet er aktivert som standard for nye prosjekter. Når du kontrollerer, administrerer Xcode sertifikater, provisjonsprofiler og programidentifikatorer for deg.
Jeg håper Apple har det riktig denne gangen. Og med meg titusenvis av andre utviklere.
Hvis du liker å jobbe med nydelig utformet programvare, kan du nyte Apples nye San Francisco Mono skrift som leveres med Xcode 8. Det er en monospaced variant av San Francisco og blander seg pent inn i systemfonten til macOS.
Visste du at den nåværende linjen er uthevet i bildet ovenfor? Det er en annen velkommen forbedring som Apple har lagt til Xcode 8. Jeg bruker for øyeblikket Backlight for Xcode for å oppnå samme effekt i Xcode 7. Jeg antar at jeg ikke lenger trenger pluginet i Xcode 8.
Når jeg snakker om datching av tredjepartsplugger, bruker jeg for øyeblikket Kent Sutherlands utmerkede KSImageNamed-plugin for å aktivere kodeavslutning for bilder i Xcode. Jeg vil ikke trenge det pluginet når jeg bytter til Xcode 8 da denne funksjonen nå er innebygd i Xcode.
Utviklere bruker en uvanlig mengde tid på å surfe og lese dokumentasjon. God dokumentasjon går langt, og Apples dokumentasjon er utmerket. Bla gjennom dokumentasjonen er en annen historie.
Denne smerten er nå løst i Xcode 8. Det nye dokumentasjonsformatet ser nydelig ut og dokumentasjonsleseren er rask og enkel å bruke. Apple konsoliderte også dokumentasjonen for plattformene, noe som resulterte i et mye mindre minneopptak.
Og ja, dokumentasjon kan se nydelig ut. Ta en titt på disse skjermbildene hvis du ikke tror på meg.
Det sier seg selv at jeg bare dekket en delmengde av det som er nytt i Xcode 8. Den neste store utgivelsen av Xcode er alltid noe jeg ser frem til. Utviklere bruker så mye tid i kodeditoren, og det er derfor forståelig at de bryr seg om evolusjonen, både godt og dårlig. Hva er din favorittfunksjon i Xcode 8? Del det i kommentarene.
Accentsconagua