Swift 5 en ABI Stability - de beste tijd om te migreren

Swift is een snelle, veilige en leuke taal om in te coderen met volledig stapelpotentieel en geweldige community-ondersteuning. Volgens Apple is het ongeveer 2,6 keer sneller dan Objective-C, maar sommige onderzoeken geven aan dat het verschil niet zo dramatisch is. Swift-code is gemakkelijker te onderhouden omdat er geen afzonderlijke interface- en implementatiebestanden zijn, de syntaxis korter is en de taal dynamische frameworks ondersteunt.

De taal is aanzienlijk gegroeid en is overgenomen door een groot aantal ontwikkelaars. Het is de 6e meest geliefde taal volgens StackOverflow Developer Survey 2018. Voor een taal die pas in 2014 is uitgebracht, is de acceptatiegraad fenomenaal.

Dit zijn enkele voordelen van Swift, laten we nu eens kijken naar de nadelen vanuit het perspectief van een ontwikkelaar. Swift is nog steeds niet volwassen en is als een bewegend doelwit met grote veranderingen die bij elke nieuwe release worden geïntroduceerd. Een van de belangrijkste problemen van veel ontwikkelaars is het gebrek aan achterwaartse compatibiliteit met oudere taalversies en de versie-lock, wat betekent dat er slechts één versie van Swift in het hele project en de externe afhankelijkheden kan zijn. Bijgevolg worden ontwikkelaars gedwongen hun projecten volledig te herschrijven als ze willen overschakelen naar de nieuwste Swift-versie en hun externe afhankelijkheden willen bijwerken. Voor ontwikkelaars die frameworks maken, moeten ze hun framework bijwerken voor elke nieuwe Swift-versie en ze kunnen het niet distribueren als een binair vooraf gecompileerd framework.

Gelukkig werken het Swift-team en de Open-Source-gemeenschap aan dit probleem en zullen ze dit naar verwachting aanpakken in de volgende grote release van Swift, dat wil zeggen Swift 5.0, die naar voren is geschoven sinds Swift 3.0. Het ABI Stability Manifesto stelt dat ze het doel hebben:

  1. Broncompatibiliteit, wat betekent dat nieuwere compilers code kunnen compileren die in een oudere versie van Swift is geschreven. Dit verwijdert de versie-lock die momenteel in Swift zit.
  2. Binaire framework & runtime-compatibiliteit, waarmee kaders kunnen worden gedistribueerd in een binaire vorm die over meerdere Swift-versies werkt. Binaire framework-compatibiliteit wordt bereikt door module-formaatstabiliteit die het modulebestand stabiliseert, wat de compiler is die de openbare interfaces van een framework weergeeft en ABI-stabiliteit maakt binaire compatibiliteit mogelijk tussen applicaties en bibliotheken die zijn gecompileerd met verschillende Swift-versies.

Wat is ABI?

Tijdens runtime werken de binaire programma's van Swift samen met andere bibliotheken en componenten. Application Binary Interface is de specificatie waaraan onafhankelijk gecompileerde binaire entiteiten moeten voldoen om te worden gekoppeld en uitgevoerd. Deze binaire entiteiten moeten het eens zijn over veel details op laag niveau, zoals hoe functies worden opgeroepen, gegevensrepresentatie in het geheugen, en zelfs waar hun metadata zijn en hoe ze toegang kunnen krijgen.

Wat is ABI-stabiliteit?

ABI-stabiliteit betekent dat de ABI zodanig moet worden vergrendeld dat toekomstige compilerversies binaire bestanden kunnen produceren die voldoen aan de stabiele ABI. Zodra een ABI stabiel is, blijft deze de rest van de levensduur van het platform bestaan.

ABI-stabiliteit heeft alleen invloed op invarianten van extern zichtbare openbare interfaces en symbolen. Toekomstige compilers kunnen bijvoorbeeld de oproepconventies voor interne functieaanroepen wijzigen zolang de openbare interfaces behouden blijven.

Voorwaarden voor ABI-stabiliteit

  1. Typen, zoals structs en klassen, moeten een gedefinieerde indeling in het geheugen hebben voor instanties van dat type en dezelfde lay-outconventies delen.
  2. Type metadata wordt veelvuldig gebruikt door Swift-programma's. Deze metagegevens moeten een gedefinieerde geheugenindeling hebben of een set gedefinieerde API's hebben voor het opvragen van de metagegevens van een type.
  3. Elk geëxporteerd of extern symbool in een bibliotheek heeft een unieke naam nodig waarover binaire entiteiten kunnen overeenkomen. Swift biedt functieoverbelasting en contextuele naamruimten (zoals modules en typen), wat betekent dat elke naam in de broncode mogelijk niet wereldwijd uniek is. Een unieke naam wordt geproduceerd via een techniek die naammangeling wordt genoemd.
  4. Functies moeten zich houden aan aanroepconventies, zoals zaken als de lay-out van de call-stack, welke registers worden bewaard en eigendomsconventies.
  5. Swift wordt geleverd met een runtime-bibliotheek die zaken als dynamische casting, referentietelling, reflectie, enz. Afhandelt. Gecompileerde Swift-programma's voeren deze runtime externe oproepen uit. Swift runtime API is dus Swift ABI.
  6. Swift-schepen met een standaardbibliotheek die veel voorkomende typen, structuren en bewerkingen hierop definieert. Een standaardbibliotheek die wordt verzonden met toepassingen die in verschillende versies van Swift zijn geschreven, moet een stabiele API hebben. Swift Standard Library API is dus Swift ABI, evenals de lay-out van veel van de typen die het definieert.
Al deze taken zijn uitgevoerd door het Swift-kernteam, maar ze zijn nog niet vrijgegeven op GitHub. Als we naar de status van de taken kijken, kunnen we veilig verwachten dat de volgende grote release van Swift ABI-stabiel zal zijn.

Voordelen van ABI-stabiliteit

  1. Dus zodra Swift ABI-stabiel is verklaard, zou de vanaf dit moment geschreven code compatibel zijn met de nieuwere versies van de taal en hoeft de ontwikkelaar niet alle externe afhankelijkheden van het project bij te werken tijdens het migreren naar een nieuwe versie van Snel.
  2. De bibliotheekauteur kan zijn framework als een binair framework leveren zodra de stabiliteit van het moduleformaat is bereikt.
  3. De grootte van de toepassingsbundel zou afnemen omdat de stabiele Swift-runtime vervolgens in het besturingssysteem zou kunnen worden opgenomen.
  4. De taal zou blijven evolueren, maar de wijzigingen in de ABI vanaf dat moment zouden additief zijn. De ABI-additieve wijzigingen kunnen worden benut wanneer de minimale gerichte Swift-versie deze ondersteunt, omdat ABI-stabiliteit alleen de extern zichtbare openbare interfaces en symbolen vergrendelt. De nieuwere compilers kunnen interne wijzigingen aanbrengen die de efficiëntie kunnen verbeteren.

Gevolgtrekking

Swift is duidelijk de toekomst voor ontwikkeling in het Apple-ecosysteem en als het eenmaal ABI-stabiel en module-formaat stabiel is, zou de taal geen grote nadelen meer hebben. Lees dit artikel voor een gedetailleerde vergelijking tussen Swift en Objective-C in 2019.

Als u uw Objective-C-codebase naar Swift wilt converteren, is dit de beste tijd om te beginnen. Ik heb een artikel geschreven over de conversie van SVProgressHUD naar IHProgressHUD, dat volledig in Swift is geschreven en veilig is met hetzelfde API-ontwerp als SVProgressHUD met Swiftify voor Xcode.

Referenties

  1. https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
  2. https://swift.org/abi-stability/
  3. https://www.altexsoft.com/blog/engineering/the-good-and-the-bad-of-swift-programming-language/
  4. https://www.altexsoft.com/blog/engineering/swift-vs-objective-c-out-with-the-old-in-with-the-new/
  5. https://medium.com/swift-india/swift-5-abi-stability-769ccb986d79
  6. https://www.ca.com/en/blog-developers/dynamic-versus-static-framework-in-ios.html
  7. https://www.youtube.com/watch?v=GzP2oaZRi7Q

U kunt contact met ons opnemen op Twitter, Linkedin, Facebook en Github.