Battery life remains a fundamental constraint in mobile application design, directly influencing user experience and system performance. Prior empirical analysis of 1,783 open-source mobile applications shows that energy efficiency is addressed more frequently by Android developers (25% of analyzed apps) than by iOS developers (10%)1, highlighting a relative gap in energy-aware practices within the iOS ecosystem. As modern applications increasingly rely on concurrent execution, concurrency models play a critical role in shaping energy consumption through their impact on CPU scheduling, thread utilization, wakeups, and background activity.
Swift Concurrency introduces structured and unstructured paradigms that improve code safety, readability, and performance. However, while developers typically select concurrency constructs based on correctness and execution speed, the corresponding energy implications of these choices remain insufficiently understood. This gap is particularly important in mobile contexts, where inefficient concurrency patterns can lead to excessive wakeups, unnecessary parallelism, and increased power draw.
To address this issue, this study investigates three research questions: (RQ1) Which Swift Concurrency patterns minimize energy consumption for equivalent workloads? (RQ2) Under what conditions does structured concurrency reduce scheduling overhead compared to detached tasks? (RQ3) What energy and performance trade-offs arise from Actor isolation and @MainActor boundary transitions? By standardizing on Swift 6, which enforces strict concurrency checking by default2, this research isolates the energy characteristics of modern, data-race-safe concurrency mechanisms and provides a systematic foundation for energy-aware decision-making in iOS development.
This section provides the necessary technical background on Swift Concurrency and energy measurement concepts, along with a review of related work relevant to mobile energy efficiency.
Modern Swift adopts a structured concurrency model that emphasizes safety, clarity, and efficient task management. It introduces high-level abstractions such as async/await, Task, and TaskGroup, which enable developers to express asynchronous workflows in a more predictable and maintainable manner. In contrast, unstructured concurrency—primarily through Task.detached—allows tasks to operate independently of a parent context, but at the cost of reduced lifecycle control and potential increases in scheduling overhead.
To enforce memory safety and eliminate data races, Swift incorporates isolation mechanisms such as actor and @MainActor, which ensure controlled access to shared mutable state. With the introduction of Swift 6.0, Region-Based Isolation (SE-0414) further strengthens these guarantees by enabling flow-sensitive analysis, allowing non-Sendable values to be safely transferred across isolation boundaries under well-defined conditions3.
At the runtime level, Swift concurrency is supported by a cooperative thread pool that typically maintains approximately one thread per CPU core, promoting efficient execution without oversubscription. This design mitigates the thread explosion issues historically associated with Grand Central Dispatch (GCD), where excessive thread creation could lead to increased context switching and energy overhead4.
To summarize, the primary concurrency constructs evaluated in this study are outlined below:
Table 1. Summary of Swift concurrency constructs evaluated in this study
Energy consumption in mobile systems is influenced by how efficiently computational work is scheduled and executed. Key contributors include CPU activity, the frequency of thread wakeups, and the overhead introduced by task scheduling. In iOS, excessive wakeups are particularly costly; a process may be terminated if it exceeds 150 thread wakeups per second over a sustained 300-second period5.
To assess energy behavior, Xcode Instruments provides the Energy Impact metric, which serves as a proxy for power usage. This metric aggregates contributions from CPU, GPU, network activity, and system overhead, and classifies overall energy consumption into qualitative levels such as Low, High, and Very High5. While not a direct measurement of energy in joules, it enables consistent relative comparisons across different execution patterns.
Beyond these primary indicators, additional system-level factors influence overall power draw. Background execution can extend resource usage beyond active interaction, while run-loop behavior affects how frequently the system schedules work. Thermal conditions also play a role, as sustained workloads may trigger throttling, thereby altering both performance and observed energy characteristics.
Prior research in mobile energy measurement highlights the challenges of accurately evaluating power consumption due to external sources of overhead. Studies have shown that framework-induced overhead can significantly distort results; for instance, certain automation frameworks have been observed to increase measured energy consumption by over 2,000% compared to baseline human interactions6. These findings emphasize the importance of carefully controlling experimental conditions when assessing energy behavior.
In parallel, performance analysis literature advocates for the use of low-level, OS-derived metrics to improve measurement reliability. Approaches such as GreenScaler demonstrate that energy regressions can be effectively identified by monitoring system-level indicators, including CPU jiffies and system call counts7. Collectively, these works underscore the need for measurement strategies that minimize external interference while leveraging reliable system statistics—principles that inform the methodology adopted in this study.
The study is conducted on an iOS 18+ deployment target using Xcode 16, with all experiments executed on real devices to avoid the limitations of simulators. The application is built in Release mode with optimizations enabled to reflect realistic runtime behavior. To reduce measurement variability, controlled conditions are maintained, including airplane mode, fixed screen brightness, and a consistent thermal starting state prior to each benchmark run.
To represent realistic execution scenarios, three categories of workloads are defined:
The evaluation compares seven concurrency patterns:
To ensure fair comparison, all patterns execute identical workloads under consistent conditions.
This includes:
These controls ensure that any observed differences in energy consumption are attributable to the concurrency model rather than external factors.
This section outlines the benchmarking procedure, including the execution flow, measurement segmentation, and strategies used to ensure reliable and reproducible results.
The benchmarking process follows a structured procedure to ensure consistent and comparable measurements across all concurrency patterns. Each workload is executed under controlled conditions, and both runtime statistics and energy proxies are systematically recorded. However, benchmarking asynchronous execution can introduce challenges, as legacy task interactions may interfere with measurement timing, occasionally requiring workarounds such as detached tasks or dispatch group synchronization to isolate execution phases9.
Algorithm 1: Concurrency energy benchmark
1. Initialize workload input using a fixed seed
2. Perform warm-up runs and discard their measurements
3. For each concurrency pattern (Pi):
4. Aggregate collected metrics (e.g., mean, median, p95)
5. Compare results across patterns to identify performance–energy trade-offs
To ensure precise measurement, execution is segmented using signposts and markers that clearly delineate key phases of the benchmark. These include the start of computation, the end of processing, and the UI handoff stage. This segmentation enables accurate isolation of energy and performance characteristics within each phase.
To improve reproducibility, multiple strategies are applied to minimize external variability. A consistent device state is maintained across runs, including controlled environmental conditions and system configuration. Each benchmark is repeated multiple times, and outliers—particularly those caused by background operating system activity—are identified and excluded based on predefined criteria.
This section defines the metrics and instrumentation methods used to measure and analyze the energy and performance characteristics of each concurrency pattern.
Data collection relies on software-based proxy metrics obtained through Xcode Instruments. These metrics capture the core aspects of energy and performance behavior during execution:
Table 2. Primary metrics used for energy and performance evaluation
In addition to primary indicators, several secondary metrics are observed to provide further context on system behavior. These include thermal state (ProcessInfo.thermalState), thread count, context switching indicators, instances of main-thread blocking, and total background activity duration. While not directly used for primary comparisons, these metrics help explain observed variations in energy and performance.
Instrumentation combines in-code measurement and external profiling tools. Monotonic timestamps are used to capture execution durations, while signposts define precise measurement intervals. Profiling is conducted using Xcode Instruments, including the Energy Log, Time Profiler, System Trace (when needed), and Allocations tool to ensure memory behavior does not confound results.
For each workload and concurrency pattern pair, the benchmarking harness computes aggregate statistics, including average, median, and p95 execution times, as well as average energy impact scores and wakeup rates. Results are then normalized against the baseline configuration (P1), enabling relative comparisons such as percentage increases or reductions in energy consumption.
This section presents and analyzes the experimental results, highlighting the energy and performance characteristics of each concurrency pattern across different workloads.
Energy consumption is compared across all concurrency patterns (P1–P7) for each workload category. Results are presented through tables and charts to highlight relative differences in total energy impact and identify patterns that exhibit higher or lower energy usage under equivalent conditions.
Table 3. Sample energy impact comparison across concurrency patterns
Values represent normalized energy impact relative to the serial baseline (P1).
To analyze the relationship between performance and energy efficiency, a Pareto-based comparison is employed, mapping execution time against energy consumption. This approach enables identification of concurrency patterns that achieve optimal balance, as well as those that trade reduced execution time for increased energy cost.
For example, structured concurrency using Task (P3) demonstrates a favorable balance between execution time and energy consumption, while unstructured concurrency (Task.detached, P4) tends to increase energy usage due to higher scheduling overhead.
The results indicate that actor-based execution within the cooperative thread pool incurs relatively low overhead for isolated operations. However, transitions between the cooperative thread pool and the @MainActor introduce additional cost due to context switching10. Furthermore, improper use of @MainActor, particularly when redundant actor hops occur within already isolated contexts, can lead to unnecessary performance degradation through excessive thread switching11.
Scalability is evaluated by varying task counts (e.g., 10, 100, and 1000 tasks) and workload sizes. While Swift Concurrency maintains a bounded number of threads even with a large number of actors, increased interaction between isolated actors introduces additional overhead. Frequent cross-actor communication results in higher context-switching costs, which can significantly impact both performance and energy efficiency at scale12.
The observed differences in energy consumption can be attributed to several key factors, including excessive thread wakeups, over-parallelization, communication overhead between actors, and the use of detached tasks that escape structured concurrency lifetimes. These behaviors increase scheduling frequency and coordination costs, leading to higher overall power usage.
For simple or low-contention state management, lightweight synchronization mechanisms such as OSAllocatedUnfairLock can provide better performance compared to actor-based isolation or traditional GCD approaches12,13. This suggests that while actors improve safety and abstraction, they may introduce unnecessary overhead in scenarios where fine-grained locking is sufficient.
Based on these findings, several practical guidelines emerge. Batching operations can reduce the number of cross-actor asynchronous calls, thereby lowering coordination overhead10. Structured concurrency constructs such as TaskGroup should be preferred for bounded parallelism, as they maintain lifecycle control and reduce scheduling inefficiencies. In contrast, Task.detached should be used sparingly and only for truly independent work, as excessive use can undermine structured concurrency optimizations and increase energy cost.
This study is subject to several limitations that may affect the interpretation and generalizability of the results. A primary concern is the reliance on Xcode Instruments’ Energy Log, which provides proxy metrics rather than direct hardware-level energy measurements. As a result, the reported values reflect relative energy behavior rather than absolute power consumption.
Additional sources of variability include device state conditions such as thermal levels and background operating system activity, which may introduce noise into the measurements despite controlled experimental settings. If simulators are used in any part of the evaluation, their known limitations in accurately representing real device behavior may further impact validity. Finally, the use of synthetic workloads, while necessary for controlled comparison, may not fully capture the complexity of real-world application scenarios, potentially limiting the generalizability of the findings.
This study presents a systematic evaluation of energy efficiency across multiple Swift Concurrency patterns in iOS applications. By introducing a reproducible benchmarking harness and a taxonomy of concurrency behaviors under Swift 6, the work provides insight into how different execution models influence energy consumption and performance.
Future work will address current limitations by incorporating external hardware-based power measurements to complement software-level proxies. Additionally, expanding the evaluation to a broader range of devices and incorporating more realistic workloads—combining UI, network, and storage components—will further improve the applicability and generalizability of the findings.
