iPad Split-Screen Resource Allocation in iOS 12

When running multitasking features such as Split View and Slide Over on an iPad, iOS 12 dynamically balances system resources to ensure smooth performance, battery efficiency, and system stability. This article examines the core mechanisms iOS 12 uses to allocate memory, process cycles, and graphics power between two concurrently running applications, detailing how the operating system handles execution states, priorities, and hardware constraints.

Foreground Execution States and RAM Allocation

In standard single-app usage, only one application occupies the foreground execution state, while other apps are suspended or limited to background tasks. Under iOS 12, running apps side-by-side in Split View (either in a 50/50 or 70/30 spatial split) places both applications into an active foreground state simultaneously.

Because two distinct app processes require physical RAM at the same time, iOS 12 enforces strict memory footprint management using its low-memory daemon, jetsam. When Split View is engaged, the operating system aggressively clears caches and terminates suspended background processes to free up system memory for the visible applications. If the system faces memory exhaustion, jetsam evaluates the footprint of both active apps. The app exceeding its expected per-process memory budget receives memory warnings first; if it fails to purge non-critical data, it is terminated to preserve system stability and keep the companion app running.

CPU Scheduling and Thread Prioritization

iOS 12 relies on the Darwin kernel and Grand Central Dispatch (GCD) to schedule processor time across the iPad's multi-core A-series chips. The operating system utilizes Quality of Service (QoS) classes to determine thread execution priority:

  • User Interactive and User Initiated: Threads handling UI rendering, touches, and immediate user responses from both apps receive the highest priority on the CPU's high-performance cores.
  • Utility and Background: Lower-priority maintenance threads from both apps are assigned to high-efficiency cores or scheduled during idle cycles.

When touch events occur in one partition (e.g., actively scrolling a webpage in Safari), iOS 12 dynamically elevates the thread priority of the focused application to prevent dropped frames, temporarily demoting lower-priority threads in the adjacent window without suspending its main execution loop.

Graphics Rendering and Metal Compositing

To maintain a consistent 60 frames per second (or up to 120 FPS on iPad Pro models with ProMotion), iOS 12 delegates split-screen compositing directly to the GPU via the Metal framework and Core Animation:

  1. Independent Framebuffers: Each active application renders its visual elements to its own off-screen buffer.
  2. WindowServer Compositing: The system’s backboardd and WindowServer daemons intercept these surfaces and composite them into a single frame buffer corresponding to the physical display resolution.
  3. Dynamic Resolution Handling: During partition resizing via the central divider, the system provides real-time resize events to both apps. Apps are expected to quickly adapt their view hierarchies using Auto Layout, while the GPU scales intermediate textures to hide frame drops until the UI settles.

Thermal and Power Throttling

Running two hardware-intensive applications simultaneously (such as a video editing timeline next to a complex vector canvas) rapidly increases power consumption and thermal output. iOS 12 monitors real-time SoC temperatures and applies dynamic frequency scaling to the CPU and GPU. If thermal thresholds are reached, the OS throttles overall clock speeds uniformly across both processes, signaling apps to reduce frame rates or defer non-critical background jobs to maintain device stability and battery health.