Bitcode: wat is het, tussentijdse bytecode en compilatie

Wat is Bitcode in iOS-ontwikkeling

Bitcode is een tussentijdse representatie van een programma (Intermediate Representation, IR) gegenereerd door de LLVM-compilerinfrastructuur. Apple introduceerde ondersteuning voor Bitcode vanaf Xcode 7 en iOS 9 als een verplichte vereiste voor watchOS-apps en optioneel voor iOS en tvOS. Vanaf Xcode 14 is de verplichting voor alle platforms behalve watchOS opgeheven.

Geschiedenis van Bitcode

Het concept van tussentijdse coderepresentatie bestaat sinds de jaren 2000 binnen het LLVM-project, opgericht door Chris Lattner aan de Universiteit van Illinois. Apple paste LLVM aan voor Xcode in 2011 en introduceerde in 2015 Bitcode als een manier om apps te updaten zonder ze opnieuw naar de App Store te sturen. De technologie werd aangekondigd op WWDC 2015 in de sessie „What’s New in Xcode”.

Verschil tussen Bitcode en machinecode

Machinecode — zijn binaire instructies voor een specifieke processor: arm64, armv7 of x86_64. Bitcode wordt opgeslagen in een hardware-onafhankelijk formaat, waardoor de App Store geoptimaliseerde binaire bestanden voor verschillende architecturen kan genereren vanuit één bronrepresentatie. Dit is het belangrijkste verschil dat alle voordelen van de technologie bepaalt.

Bitcode is geen uitvoerbaar bestand. Het is LLVM IR in binair formaat dat de ontwikkelaar samen met projectmetadata naar de App Store stuurt. De app-winkel start het hercompilatieproces en past de code aan voor elk doelplatform en elke versie van het besturingssysteem.

Hoe werkt Bitcode in iOS-compilatie

Het generatieproces van Bitcode begint met de frontend van de compiler, die Swift- of Objective-C-broncode omzet in LLVM IR. In de linkfase verpakt Xcode IR in bestanden met de .bc-indeling (Bitcode), die vervolgens samen met het .xcarchive-archief naar de App Store worden gestuurd. De App Store start op zijn beurt het hercompilatieproces aan zijn kant.

LLVM-fase en generatie van tussentijdse code

De LLVM-infrastructuur bestaat uit drie delen: frontend (Clang voor C/ObjC, Swift Frontend voor Swift), Middle-End optimizer en backend (machinecodegenerator). Bitcode is het resultaat van de eerste twee fasen zonder over te gaan naar het genereren van assembleerinstructies. Middle-End voert platformonafhankelijke optimalisaties uit: dode code verwijderen, inlining en constant folding.

// Voorbeeld van Swift-broncode
func calculateSum(a: Int, b: Int) -> Int {
    return a + b
}

// LLVM IR na compilatie (vereenvoudigd)
; define i32 @calculateSum(i32 %a, i32 %b)
; %result = add i32 %a, %b
; ret i32 %result

Na het genereren van IR voert de compiler een reeks optimalisaties uit op representatieniveau: dode code verwijderen, functies inlinen en constant folding. Deze optimalisaties zijn niet architectuurafhankelijk en worden in Bitcode bewaard. Bij hercompilatie in de App Store worden architectuurafhankelijke optimalisaties toegevoegd, zoals het herschikken van instructies voor de specifieke processor.

Hercompilatie in de App Store

App Store Connect ontvangt het archief met Bitcode en start zijn eigen compilatie-infrastructuur. Het systeem bepaalt de doelarchitectuur van het apparaat van de gebruiker en genereert machinecode, waarbij het verder wordt geoptimaliseerd voor de specifieke kenmerken van de processor. Voor arm64e (A12+- en M-serie processors) worden extra beveiligingsoptimalisaties toegepast.

Dit proces wordt App Thinning genoemd — een technologie die ervoor zorgt dat alleen de bronnen en code die nodig zijn voor de architectuur van het apparaat worden geleverd. Een iPhone-gebruiker met een A17 Pro-processor krijgt een binair bestand dat is geoptimaliseerd voor arm64e, zonder overbodige instructies voor verouderde architecturen. Dit verkort de laadtijd en bespaart ruimte op het apparaat.

Voordelen van het gebruik van Bitcode

Bitcode biedt verschillende belangrijke voordelen voor iOS-app-ontwikkelaars. De belangrijkste is automatische optimalisatie voor nieuwe Apple-processors zonder dat de update opnieuw in de App Store hoeft te worden gepubliceerd. Dit is vooral relevant bij de overgang naar nieuwe architecturen, zoals de overgang van armv7 naar arm64.

Optimalisatie voor nieuwe architecturen

Wanneer Apple een processor met een nieuwe architectuur uitbrengt, worden apps die met Bitcode zijn verzonden er automatisch voor gehercompileerd. De ontwikkelaar hoeft het project niet opnieuw te bouwen en een update te publiceren — de App Store doet dit aan zijn kant bij de eerste download door de gebruiker. Dit is vooral belangrijk voor langlevende apps die jarenlang worden ondersteund.

Verkleinen van de binaire bestandsgrootte

App Thinning in combinatie met Bitcode kan de grootte van de geïnstalleerde app met 15–40% verminderen. De App Store genereert alleen de machine-instructies die nodig zijn voor het specifieke apparaat, waarbij code voor andere architecturen en varianten voor verschillende iOS-versies worden uitgesloten. In de praktijk betekent dit dat een gebruiker met een nieuwe iPhone een compact binair bestand ontvangt.

Volgens gegevens van Apple WWDC 2015 Session 102 kan het gebruik van Bitcode en App Thinning de grootte van de gedownloade app gemiddeld met 25% verminderen in vergelijking met een universeel binair bestand dat alle architecturen bevat. Voor een app van 100 MB kan de besparing oplopen tot 40 MB op het apparaat van de gebruiker.

• Automatische aanpassing aan nieuwe processors zonder herbouw van het project door de ontwikkelaar
• Verkorte laadtijd van de app op het apparaat van de gebruiker
• Vereenvoudigde distributie — één archief voor alle architecturen, één set metadata
• Toekomstbestendigheid — de app werkt op nog niet uitgebrachte Apple-processors

Bitcode inschakelen in een Xcode-project

Bitcode configureren gebeurt in de buildconfiguratie van Xcode. De parameter Enable Bitcode staat in de Build Settings en is standaard ingeschakeld voor nieuwe projecten, maar ontwikkelaars kunnen deze uitschakelen voor debuggen of bij gebruik van bibliotheken van derden zonder Bitcode-ondersteuning.

Configureren via Build Settings

// Build Settings -> Apple Clang - Code Generation
// Enable Bitcode = YES

// Of via Info.plist voor individuele targets
@property (nonatomic, assign) BOOL enableBitcode;
- (void)configureBuildSettings {
    // Bitcode-status controleren in configuratie
    if (self.enableBitcode) {
        NSLog(@"Bitcode is enabled for this target");
    } else {
        NSLog(@"Bitcode is disabled");
    }
}

Om te controleren of het archief Bitcode bevat, opent u het .xcarchive-bestand via Xcode Organizer of voert u de opdracht otool -l uit in de Terminal. De aanwezigheid van de sectie __LLVM in het binaire bestand bevestigt dat Bitcode is ingeschakeld en correct is verpakt. Als de sectie ontbreekt — is Bitcode niet gegenereerd tijdens de build.

Controleren via terminal

# Controleren op aanwezigheid van Bitcode in archief
otool -l YourApp.app/YourApp | grep __LLVM

# Resultaat: als er een __LLVM-sectie is — Bitcode is aanwezig
# Als het resultaat leeg is — Bitcode is niet ingeschakeld of niet gegenereerd

# Kan ook worden gecontroleerd via de size-opdracht
size -m -l YourApp.app/YourApp | grep __LLVM

Bij gebruik van bibliotheken van derden via CocoaPods of SPM, zorg ervoor dat alle afhankelijkheden zijn gebouwd met Bitcode. Als ten minste één bibliotheek Bitcode niet ondersteunt, genereert Xcode een linkfout tijdens de archieffase. Voor CocoaPods controleert u de vlag bitcode_enabled in podspecs of gebruikt u use_frameworks! met enable_bitcode.

Beperkingen en valkuilen van Bitcode

Bitcode is geen universele oplossing voor alle soorten iOS-projecten. De technologie heeft beperkingen waarmee de ontwikkelaar rekening moet houden voordat hij de optie in de buildconfiguratie inschakelt. Inzicht in deze beperkingen helpt problemen in de archief- en publicatiefase te voorkomen.

Compatibiliteit met bibliotheken

Niet alle bibliotheken van derden worden geleverd met Bitcode-ondersteuning. Als een bibliotheek alleen wordt gedistribueerd als een gecompileerd binair bestand zonder Bitcode, zal het project met de ingeschakelde optie niet worden gebouwd. In dit geval moet de ontwikkelaar Bitcode uitschakelen of de leverancier om een versie met Bitcode vragen. Dit is vooral relevant voor oude bibliotheken die niet meer worden bijgewerkt.

Debuggen en crashrapporten

Crashrapporten van apps die met Bitcode zijn gebouwd, vereisen extra verwerking. Symbolen (dSYM) voor gehercompileerde code worden gegenereerd door de App Store en zijn beschikbaar om te downloaden via Xcode Organizer. Zonder het downloaden van de bijbehorende dSYM-bestanden is de call-stack in crashrapporten onleesbaar, wat het diagnosticeren van problemen bemoeilijkt.

• dSYM downloaden — verplicht voor het decoderen van crashlogs uit de App Store na hercompilatie
• Archiefgrootte — .xcarchive met Bitcode neemt meer schijfruimte in beslag bij de ontwikkelaar
• Compilatietijd — het genereren van Bitcode verlengt de compilatiefase van het project met ongeveer 10–15%
• macOS — Bitcode wordt niet ondersteund voor macOS- en watchOS-apps
• Verouderde projecten — migratie van grote projecten kan het bijwerken van alle afhankelijkheden vereisen

Vanaf iOS 17 en Xcode 15 vereist Apple niet dat Bitcode verplicht wordt ingeschakeld voor publicatie in de App Store. Voor watchOS-apps blijft Bitcode echter een verplichte voorwaarde op het niveau van de App Store Connect-regels. Ontwikkelaars wordt aangeraden Bitcode in te schakelen voor nieuwe projecten als alle afhankelijkheden dit ondersteunen.