Runtime, Hot Reload y compilación en el desarrollo móvil: qué son, conceptos clave y cómo funcionan

Runtime y Reflection: iOS Runtime, Method Swizzling y despacho dinámico

Runtime (entorno de ejecución) es el software que gestiona la ejecución de la aplicación. En el contexto de iOS Runtime, es el sistema dinámico de Objective-C que permite enviar mensajes a objetos, crear clases sobre la marcha y reemplazar métodos durante la ejecución. Esto es posible porque Objective-C es un lenguaje de tipado dinámico sobre C.

Reflection es la capacidad de un programa para examinar y modificar su propia estructura durante la ejecución. En iOS Runtime, esto se implementa mediante funciones como class_getInstanceMethod, method_exchangeImplementations y objc_getAssociatedObject. En Kotlin/Java, la reflexión usa KClass / java.lang.reflect.

En IT Sectr, usamos Runtime muy raramente, solo para tareas específicas donde no hay alternativa. Por ejemplo, Method Swizzling para registro centralizado de analíticas o corrección de errores en bibliotecas. Sin embargo, Runtime es una herramienta potente que requiere un profundo conocimiento y precaución.

Method Swizzling

Method Swizzling es una técnica para reemplazar la implementación de un método de Objective-C por otra durante la ejecución. Es un caso particular de Programación Orientada a Aspectos (AOP) para iOS. Swizzling permite añadir registro, analíticas o caché a métodos existentes sin cambiar su código fuente.

Un ejemplo típico: reemplazar viewWillAppear: en UIViewController para añadir registro automático de pantallas. Importante: el swizzling debe ejecutarse en el método +load o +initialize para garantizar la ejecución antes de usar la clase. Un swizzling incorrecto puede provocar comportamientos indefinidos y errores difíciles de depurar.

// Method Swizzling para registrar 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]; // llamada al método original
    [Analytics logScreen:NSStringFromClass([self class])];
}

@end

Este código reemplaza viewWillAppear: en todos los UIViewController mediante swizzling. Después de method_exchangeImplementations, la llamada al viewWillAppear: original resulta en la llamada a xxx_viewWillAppear:, que llama al método original (mediante llamada recursiva) y añade analíticas. DispatchOnce garantiza la ejecución única del swizzling.

Herramientas web (Transpilation, Polyfill, Bundler, Webpack, Metro)

El desarrollo web moderno y el desarrollo móvil con React Native o Flutter son imposibles sin herramientas de compilación. Transpilation es la conversión de código de un lenguaje a otro. El ejemplo más popular: TypeScript → JavaScript. Un transpilador (Babel, tsc) convierte código moderno en una versión compatible con versiones anteriores.

Polyfill es código que añade funcionalidad faltante a navegadores antiguos. Por ejemplo, Promise.allSettled() no funciona en Internet Explorer, pero un polyfill añade esta capacidad. A diferencia del Runtime nativo, que gestiona la ejecución del código directamente en el dispositivo, los polyfills y transpiladores operan a nivel de abstracción del lenguaje: adaptan la sintaxis y las API, pero no interfieren con el entorno de ejecución.

Webpack es el bundler más popular (usado en el 72% de los proyectos según State of JS 2024). Metro es el bundler de Facebook, usado por defecto en React Native. Reflection en JavaScript existe mediante Object.getPrototypeOf, Proxy y Reflect API — estos mecanismos permiten examinar y modificar objetos durante la ejecución, lo que es fundamentalmente diferente del análisis estático de módulos en los bundlers. Webpack usa un archivo de configuración que describe el punto de entrada, salida, loaders (para procesar diferentes tipos de archivos) y plugins (para funcionalidad adicional).

// webpack.config.js — configuración mínima
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',
};

Esta configuración define el punto de entrada (index.js), el archivo de salida (bundle.js) y una regla para procesar JavaScript mediante Babel. El modo production activa optimizaciones: minificación, tree shaking y detección automática del entorno. En la etapa de Runtime, todas estas optimizaciones ya no afectan la lógica — el navegador ejecuta el bundle minificado como JavaScript normal.

Optimización de código (Minification, Tree Shaking, Obfuscation)

Minification es el proceso de comprimir el código eliminando espacios, comentarios y renombrando variables largas a cortas. Minificadores populares: Terser (JS/TS), CSSNano (CSS), html-minifier-terser. La minificación reduce el tamaño del archivo entre un 50 y un 70%. En producción, Runtime ejecuta el código minificado igual que el original — la diferencia solo está en la legibilidad y el tamaño del archivo, no en la semántica.

Tree Shaking es la eliminación de código muerto que no se utiliza en la aplicación. Funciona mediante análisis estático de módulos ES (import/export). Si una función se exporta pero nunca se importa, Tree Shaking la elimina de la compilación final. Tree Shaking analiza el código estáticamente, a diferencia de Reflection, que funciona dinámicamente y puede acceder a métodos y propiedades invisibles en tiempo de compilación.

Tree Shaking

Tree Shaking en Webpack se activa automáticamente en modo producción. Una condición importante: el código debe usar módulos ES (import/export), no CommonJS (require). Si una biblioteca está escrita en CommonJS, tree shaking no funcionará. Para un tree shaking óptimo, use importaciones precisas: import { merge } from 'lodash-es' en lugar de import _ from 'lodash'. Esto reduce el tamaño del bundle de 500 KB a 10 KB para una sola función.

Hot Reload

Hot Reload es una tecnología que permite actualizar el código de la aplicación sin una recarga completa. En React Native y Flutter, Hot Reload actualiza el archivo modificado sobre la marcha, conservando el estado actual de la aplicación. Esto acelera radicalmente el desarrollo: los cambios son visibles en 1–2 segundos en lugar de 10–30 segundos para una recompilación completa. Hot Reload funciona dentro del Runtime: el módulo modificado se inyecta en la aplicación en ejecución sin reiniciar el entorno de ejecución.

Hot Restart es un reinicio rápido de la aplicación con código actualizado, pero sin conservar el estado. Se usa cuando Hot Reload no es posible (por ejemplo, cuando cambia el código nativo o las variables globales). En IT Sectr, usamos Hot Reload en todas las etapas de desarrollo de UI — ahorra hasta un 50% del tiempo en ajustes visuales.

Tabla 3. Comparación de herramientas de compilación. Webpack es el estándar universal. Metro está especializado para React Native. Vite y esbuild son la nueva generación centrada en la velocidad. Rollup es la mejor opción para publicar bibliotecas.

Recarga en caliente (Hot Reload, Hot Restart)

Hot Reload es una tecnología que se originó en el desarrollo web (React Hot Loader, HMR — Hot Module Replacement) y pasó al desarrollo móvil con Flutter y React Native. La esencia: cuando un archivo cambia, el bundler envía el módulo actualizado a la aplicación en ejecución, que reemplaza el código antiguo sin perder el estado. A diferencia de una recompilación completa, Hot Reload no reinicia el Runtime — el entorno de ejecución sigue funcionando y el módulo modificado se conecta dinámicamente mediante un mecanismo como HMR o una actualización de referencias similar a Reflection.

Hot Reload funciona porque el framework mantiene los widgets (Flutter) o componentes (React) en memoria y actualiza solo las partes modificadas. Hot Restart es un mecanismo más tosco: reinicia completamente la aplicación, pero es más rápido que una recompilación completa porque no recompila el código nativo. En IT Sectr, usamos Hot Reload al desarrollar la UI y Hot Restart al cambiar la navegación o la gestión de estado.