Runtime in Mobile Development: What It Is, Runtime System and How It Works

What is Runtime in Mobile Development?

Runtime is the infrastructure that ensures program execution after it is launched. In the context of mobile development, runtime includes the class loader, memory allocator, garbage collector, method dispatcher and exception handler. Without this interlayer, the operating system cannot execute Dalvik bytecode or Objective-C messages.

Mobile platforms use different runtime implementations. Android uses ART (Android Runtime) with hybrid AOT/JIT compilation. iOS uses Objective-C Runtime — a dynamic system based on message passing and SEL identifiers. Both approaches solve the same problem: execute the developer's code on a specific device with maximum performance.

According to Google I/O 2024, Android Runtime processes over 10 billion methods per day on devices worldwide. Runtime performance directly affects application launch speed, animation smoothness and battery consumption. Every method call, every memory allocation and every garbage collection cycle goes through the runtime layer.

Runtime System: What Components Does It Consist Of

Runtime system includes five key components: class loader, memory manager, interpreter or compiler, method dispatcher and security system. Each component performs a strictly defined function in the code execution process.

Class Loader and Verification

When a user launches an application, the ClassLoader loads DEX files (Android) or Mach-O binaries (iOS) into RAM. In Android, this stage includes bytecode verification: the runtime checks that the code contains no unsafe instructions, does not go out of array bounds and respects types. Verification is a critical security step that prevents malicious code execution.

Memory Manager and Garbage Collector

Memory Manager allocates and frees memory for objects. In Android ART, a concurrent garbage collector with generational collection is used: young objects are checked more often, old ones less often. Objective-C Runtime uses Automatic Reference Counting (ARC), where the compiler inserts retain/release calls automatically.

Method Dispatcher and Virtual Table

Method dispatcher determines which method implementation will be called. In static languages (Kotlin, Swift), dispatch is performed via vtable — a virtual method table. In dynamic languages (Objective-C), the message passes through objc_msgSend, which looks up the implementation in the class and its superclasses. The result is cached in the method cache to speed up repeated calls.

How ART Works on Android

Android Runtime (ART) is a virtual machine that executes DEX bytecode of Android applications. ART replaced Dalvik in Android 5.0 Lollipop, introducing AOT compilation: the application is compiled into machine code once during installation. This eliminated the overhead of JIT compilation on every launch.

Starting from Android 7.0 Nougat, ART uses a hybrid approach. During installation, JIT compilation is performed only for frequently used methods (hot methods), the rest of the code is interpreted. A background process (profile-guided optimization) analyzes which methods are called most often and compiles them AOT during device idle time. This reduces installation time while ensuring high performance.

ART also includes an AOT compiler (dex2oat) that converts DEX files into ELF binaries with ARM64 machine code. Compilation is performed with three optimization levels: quicken (fast), optimize (medium) and everything (full). By default, Android uses optimize, balancing between compilation speed and code performance.

class RuntimeExample {
    fun measureExecutionTime() {
        val start = System.nanoTime()
        // Method call compiled by ART
        processData()
        val end = System.nanoTime()
        println("Execution time: ${end - start} ns")
    }
}

In the example above, System.nanoTime() is a native method whose call is dispatched through the ART runtime into the Linux kernel. ART converts Kotlin bytecode into ARM64 instructions that are executed by the device's processor. This process happens transparently to the developer, but its optimization is a key task of the Android Platform team.

Profile-Guided Optimization (PGO)

Profile-guided optimization is an ART mechanism that collects method usage profiles. The file profiles/.primary.prof contains a list of hot methods that are compiled AOT. According to Android Performance Team, PGO speeds up application launch by 15–30% after several days of use, once the profile is accumulated.

Developers can enable baseline profiles in their Gradle project. These are manual annotations that tell ART which methods to compile AOT immediately after installation. Baseline profiles reduce first launch by 40% without waiting for background profiling.

How Objective-C Runtime Works on iOS

Objective-C Runtime is a dynamic library that provides execution of Objective-C code on iOS and macOS. Its core is the objc_msgSend function, which implements message passing: instead of a direct method call, the object sends a message with a selector, and the runtime determines which implementation should execute.

Each Objective-C object contains an isa pointer to its class, and the class has a dispatch table that maps selectors (SEL) to implementations (IMP). When a method is called, objc_msgSend traverses the chain: class → superclass → NSObject, until it finds the IMP. If no implementation is found, the runtime invokes the forwarding mechanism, which can intercept the message or generate an exception.

Objective-C Runtime also supports method swizzling — replacing the IMP of an existing selector at runtime. This is a powerful mechanism used in AOP libraries and monitoring tools, but requires caution due to its impact on the entire application.

@interface RuntimeDemo : NSObject
- (void)printClassInfo;
@end

@implementation RuntimeDemo
- (void)printClassInfo {
    // objc_getClass — runtime function
    Class cls = objc_getClass("RuntimeDemo");
    unsigned int count;
    Method *methods = class_copyMethodList(cls, &count);
    NSLog("Number of methods: %d", count);
}
@end

The code demonstrates direct access to Objective-C Runtime API: objc_getClass obtains the class object by name, class_copyMethodList retrieves the list of all methods. This is reflection in action — access to class metadata at runtime. This approach is used in XCTest for dynamic test registration.

isa Pointer and Tagged Pointers

isa pointer is a pointer to the object's class, stored in the first 8 bytes of each object. Starting from iOS 12, Apple introduced isa-swizzling for optimization: the lower bits of isa encode additional information about the object's state. Tagged pointers are another optimization where values up to 60 bits (NSNumber, NSDate) are stored directly in the pointer, without allocating an object on the heap. This reduces memory manager load by 30%.

JIT vs AOT Compilation: Comparing Approaches

JIT (Just-In-Time) and AOT (Ahead-Of-Time) are two approaches to compiling bytecode into machine code. JIT compiles code during application execution, analyzing hot spots and optimizing them on the fly. AOT compiles all code in advance — during application installation or on the developer side.

ART hybrid approach (Android 7+) is considered optimal: the application uses an interpreter for rarely called methods, JIT for hot methods and AOT for methods from profile-guided optimization. iOS, by contrast, uses strict AOT via LLVM: Swift and Objective-C are compiled into machine code at the build stage in Xcode.

According to Apple Developer Documentation, 2024, Swift runtime adds about 15 MB to the application size. Flutter uses its own Dart VM, where JIT compilation works in debug mode for hot reload, and AOT in release mode for maximum performance. React Native uses Hermes — a JavaScript engine with AOT compilation that reduces launch time by 50%.

ARM64 Runtime and Machine Code

ARM64 Runtime is the level at which machine code interacts with the device's processor. Most modern mobile devices run on ARM64 (aarch64) processors. Runtime translates bytecode or native calls into ARM64 instructions that the CPU executes.

Key ARM64 registers used by runtime: x0–x7 (function parameters), x8 (indirect result), x30 (return address), sp (stack pointer), fp (frame pointer). ART generates code that follows the ARM64 Procedure Call Standard: all method calls go through the protocol defined by the processor architecture.

Understanding ARM64 ABI is important for performance optimization: inline caching, branch prediction and code alignment in memory directly affect runtime speed. Profiling tools (Android Studio Profiler, Instruments) show which code sections spend the most time in runtime — optimizing these yields the greatest improvement.

// Example of ARM64 assembly generated by ART
// Method call with two parameters

mov    x0, x23            // self (this)
mov    x1, x24            // param1
mov    x2, x25            // param2
bl     methodEntryPoint   // call via runtime
str    x0, [sp, #8]      // save result

In this example, ARM64 instructions mov pass arguments to registers x0–x2, bl calls the method entry point, and str saves the return value. Runtime generates such instructions for every method call, optimizing the sequence through devirtualization and inlining.

Impact of Runtime on Performance

Runtime overhead is the inevitable cost of dynamic dispatch. Each method call through runtime requires: looking up the implementation in the dispatch table, type checking, calling IMP and returning the result. Measurements show that runtime adds 10–50 ns per call in Objective-C and 5–20 ns in ART.

To reduce overhead, developers use monomorphic inlining (ART) and method caching (Objective-C). Kotlin/Native and Swift compile directly to ARM64, completely eliminating the runtime layer, but losing dynamic capabilities — reflection, swizzling, dynamic class loading.