Runtime, Hot Reload en bouwen in mobiele ontwikkeling: wat het is, belangrijkste concepten en hoe het werkt

Runtime en Reflection: iOS Runtime, Method Swizzling en dynamische verzending

Runtime (uitvoeringsomgeving) is de software die de uitvoering van de applicatie beheert. In de context van iOS Runtime is dit het dynamische systeem van Objective-C waarmee berichten naar objecten kunnen worden verzonden, klassen ter plekke kunnen worden gemaakt en methoden tijdens runtime kunnen worden vervangen. Dit is mogelijk omdat Objective-C een dynamisch getypeerde taal is die op C is gebouwd.

Reflection is het vermogen van een programma om zijn eigen structuur tijdens runtime te onderzoeken en te wijzigen. In iOS Runtime wordt dit geïmplementeerd via functies zoals class_getInstanceMethod, method_exchangeImplementations en objc_getAssociatedObject. In Kotlin/Java gebruikt reflectie KClass / java.lang.reflect.

Bij IT Sectr gebruiken we Runtime zeer zelden — alleen voor specifieke taken waarvoor geen alternatief is. Bijvoorbeeld Method Swizzling voor gecentraliseerde analytics-logging of het repareren van bugs in bibliotheken. Runtime is echter een krachtig hulpmiddel dat diepgaand begrip en voorzichtigheid vereist.

Method Swizzling

Method Swizzling is een techniek om een Objective-C-methode-implementatie tijdens runtime te vervangen door een andere. Dit is een speciaal geval van Aspect-Oriented Programming (AOP) voor iOS. Swizzling maakt het mogelijk om logging, analytics of caching toe te voegen aan bestaande methoden zonder hun broncode te wijzigen.

Een typisch voorbeeld: het vervangen van viewWillAppear: in UIViewController om automatische scherm-logging toe te voegen. Belangrijk: swizzling moet worden uitgevoerd in de +load- of +initialize-methode om uitvoering vóór gebruik van de klasse te garanderen. Onjuiste swizzling kan leiden tot ongedefinieerd gedrag en bugs die moeilijk te debuggen zijn.

// Method Swizzling voor logging van viewWillAppear:
@implementation UIViewController (Tracking)

+ (void)load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class class = [self class];
        SEL originalSelector = @selector(viewWillAppear:);
        SEL swizzledSelector = @selector(xxx_viewWillAppear:);
        
        Method originalMethod = class_getInstanceMethod(class, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
        method_exchangeImplementations(originalMethod, swizzledMethod);
    });
}

- (void)xxx_viewWillAppear:(BOOL)animated {
    [self xxx_viewWillAppear:animated]; // aanroep van de originele methode
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Deze code vervangt viewWillAppear: op alle UIViewController via swizzling. Na method_exchangeImplementations leidt het aanroepen van de originele viewWillAppear: tot het aanroepen van xxx_viewWillAppear:, die de originele methode aanroept (via recursieve aanroep) en analytics toevoegt. DispatchOnce garandeert eenmalige uitvoering van swizzling.

Webtools (Transpilation, Polyfill, Bundler, Webpack, Metro)

Moderne webontwikkeling en mobiele ontwikkeling met React Native of Flutter zijn onmogelijk zonder bouwtools. Transpilation is het converteren van code van de ene taal naar de andere. Het populairste voorbeeld: TypeScript → JavaScript. Een transpiler (Babel, tsc) converteert moderne code naar een achterwaarts compatibele versie.

Polyfill is code die ontbrekende functionaliteit toevoegt aan oude browsers. Promise.allSettled() werkt bijvoorbeeld niet in Internet Explorer, maar een polyfill voegt deze mogelijkheid toe. In tegenstelling tot native Runtime, die de code-uitvoering direct op het apparaat beheert, werken polyfills en transpilers op het niveau van taalabstractie — ze passen syntaxis en API's aan, maar bemoeien zich niet met de uitvoeringsomgeving.

Webpack is de populairste bundler (gebruikt in 72% van de projecten volgens State of JS 2024). Metro is Facebooks bundler, standaard gebruikt in React Native. Reflection in JavaScript bestaat via Object.getPrototypeOf, Proxy en Reflect API — deze mechanismen maken het mogelijk objecten tijdens runtime te onderzoeken en te wijzigen, wat fundamenteel verschilt van statische module-analyse in bundlers. Webpack gebruikt een configuratiebestand dat het ingangspunt, de uitvoer, loaders (voor het verwerken van verschillende bestandstypen) en plug-ins (voor extra functionaliteit) beschrijft.

// webpack.config.js — minimale configuratie
const path = require('path');

module.exports = {
    entry: './src/index.js',
    output: {
        filename: 'bundle.js',
        path: path.resolve(__dirname, 'dist'),
    },
    module: {
        rules: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: 'babel-loader',
            },
        ],
    },
    mode: 'production',
};

Deze configuratie definieert het ingangspunt (index.js), het uitvoerbestand (bundle.js) en een regel voor het verwerken van JavaScript via Babel. De production-modus activeert optimalisaties: minificatie, tree shaking en automatische omgevingsdetectie. In de Runtime-fase hebben al deze optimalisaties geen invloed meer op de logica — de browser voert de geminifieerde bundle uit als gewoon JavaScript.

Code-optimalisatie (Minification, Tree Shaking, Obfuscation)

Minification is het proces van het comprimeren van code door het verwijderen van spaties, opmerkingen en het hernoemen van lange variabelen naar korte. Populaire minifiers: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. Minificatie vermindert de bestandsgrootte met 50–70%. In productie voert Runtime geminifieerde code op dezelfde manier uit als de originele code — het verschil zit alleen in leesbaarheid en bestandsgrootte, niet in semantiek.

Tree Shaking is het verwijderen van dode code die niet wordt gebruikt in de applicatie. Het werkt op basis van statische analyse van ES-modules (import/export). Als een functie wordt geëxporteerd maar nooit geïmporteerd, verwijdert Tree Shaking deze uit de uiteindelijke build. Tree Shaking analyseert code statisch — in tegenstelling tot Reflection, dat dynamisch werkt en toegang kan krijgen tot methoden en eigenschappen die tijdens het compileren onzichtbaar zijn.

Tree Shaking

Tree Shaking in Webpack wordt automatisch ingeschakeld in de productiemodus. Een belangrijke voorwaarde: de code moet ES-modules (import/export) gebruiken, niet CommonJS (require). Als een bibliotheek in CommonJS is geschreven, werkt tree shaking niet. Gebruik voor optimale tree shaking precieze imports: import { merge } from 'lodash-es' in plaats van import _ from 'lodash'. Dit vermindert de bundelgrootte van 500 KB naar 10 KB voor één functie.

Hot Reload

Hot Reload is een technologie waarmee applicatiecode kan worden bijgewerkt zonder volledige herlading. In React Native en Flutter werkt Hot Reload het gewijzigde bestand ter plekke bij, met behoud van de huidige applicatiestatus. Dit versnelt de ontwikkeling radicaal: wijzigingen zijn zichtbaar in 1–2 seconden in plaats van 10–30 seconden voor een volledige herbouw. Hot Reload werkt binnen Runtime: de gewijzigde module wordt geïnjecteerd in de actieve applicatie zonder de uitvoeringsomgeving opnieuw te starten.

Hot Restart is een snelle herstart van de applicatie met bijgewerkte code, maar zonder behoud van status. Het wordt gebruikt wanneer Hot Reload niet mogelijk is (bijvoorbeeld wanneer native code of globale variabelen zijn gewijzigd). Bij IT Sectr gebruiken we Hot Reload in alle fasen van UI-ontwikkeling — het bespaart tot 50% tijd op visuele aanpassingen.

Tabel 3. Vergelijking van bouwtools. Webpack is de universele standaard. Metro is gespecialiseerd voor React Native. Vite en esbuild zijn de nieuwe generatie gericht op snelheid. Rollup is de beste keuze voor het publiceren van bibliotheken.

Hot Reload (Hot Reload, Hot Restart)

Hot Reload is een technologie die is ontstaan in webontwikkeling (React Hot Loader, HMR — Hot Module Replacement) en is overgegaan naar mobiele ontwikkeling met Flutter en React Native. De essentie: wanneer een bestand verandert, stuurt de bundler de bijgewerkte module naar de actieve applicatie, die de oude code vervangt zonder statusverlies. In tegenstelling tot een volledige herbouw start Hot Reload de Runtime niet opnieuw — de uitvoeringsomgeving blijft draaien en de gewijzigde module wordt dynamisch verbonden via een mechanisme zoals HMR of een Reflection-achtige referentie-update.

Hot Reload werkt omdat het framework widgets (Flutter) of componenten (React) in het geheugen houdt en alleen de gewijzigde delen bijwerkt. Hot Restart is een grover mechanisme: het herstart de applicatie volledig, maar is sneller dan een volledige herbouw omdat het geen native code opnieuw compileert. Bij IT Sectr gebruiken we Hot Reload bij UI-ontwikkeling en Hot Restart bij het wijzigen van navigatie of statusbeheer.