arXiv:2609.21544v1 [cs.SE] 18 Sep 2026
Native and Cross-Platform Mobile Development
Cross-Platform vs Native Mobile Development: An Empirical Study of Software Quality Trade-offs Alexandru Ilovan
Abstract—Cross-platform mobile frameworks promise code reuse, shorter delivery cycles, and lower implementation effort, but their trade-offs relative to native development remain difficult to assess objectively. Many comparisons rely on simplified applications, inconsistent feature sets, or a narrow set of metrics. This paper compares five implementations of the same plant-management application: native iOS, native Android, Flutter, React Native, and Kotlin Multiplatform. The shared approaches target both Android and iOS, yielding eight executable variants. Guided by ISO/IEC 25010, the study examines time behavior, implementation footprint, source-code organization, and observable rendering responsiveness. All implementations share the same domain, backend services, functional requirements, and benchmark contract. The supplied dataset contains 2,000 completed runs per variant and covers authenticated and cached retrieval, image transfer and decoding, list rendering and scrolling, local synchronization, and media upload. Backend preparation and framework-specific UI drivers are analyzed separately from the primary client workflow. Native records the lowest non-UI client subtotal on both operating systems, with Kotlin Multiplatform the closest cross-platform implementation, while operation and UI-wrapper rankings vary by task. The shared approaches contain less authored mobile source than the native applications combined, and the source inventory shows different patterns of file size, organization, and dependency use. Rather than identifying a universally superior technology, the study shows that each approach’s advantages and costs depend on the quality attribute, workload, platform, and measurement boundary. Keywords: Cross-platform mobile development, native mobile development, Kotlin Multiplatform, empirical software engineering, performance measurement, source-code metrics
1
I NTRODUCTION Mobile software teams frequently need to deliver the same product on Android and iOS while preserving acceptable runtime behavior, interface responsiveness, maintainability, and engineering cost. Native development provides direct access to platform APIs, vendor tooling, and platform-specific conventions, but separate native codebases can duplicate implementation and maintenance work. Cross-platform frameworks reduce some of that duplication through shared source code and common development workflows, while introducing their own runtimes, rendering models, dependencies, and platform-integration boundaries. The resulting choice cannot be reduced to a universal framework ranking because the relevant quality dimensions measure different properties. Fast execution does not imply low energy use, a compact source tree does not establish short development time, and static-analysis grades do not directly demonstrate longterm maintainability. Observable rendering timings also cannot substitute for subjective user-experience evidence. A rigorous comparison must therefore define each construct, apply equivalent workloads, and limit conclusions to the quantities that are actually measured. Comparability is the central methodological challenge. Differences attributed to a framework may instead arise from application scope, backend behavior, hardware, operating system, framework version, optimization choices, or measurement technique. This study responds with a non-trivial application, a shared backend, repeated execution, and a common telemetry contract. It compares Flutter, React Native, and Kotlin Multiplatform with native Android and native iOS baselines. Runtime observations are compared within each operating system, while source properties are treated at codebase level rather than duplicated for every executable target. The main contribution is a common evaluation framework that replaces informal comparisons with measurable, bounded evidence.
Scope and Contributions The present study addresses gaps associated with simplified benchmark applications, inconsistent feature sets, and narrow metric coverage through five implemented codebases and eight measured runtime variants of a common mobile application. It compares native and cross-platform approaches on Android
and iOS using a shared benchmark contract, runtime telemetry, and source-code analysis. The scope combines within-platform runtime comparisons with structural assessments, covering time behavior, renderingresponsiveness proxies, implementation footprint, filelevel source concentration, and declared dependency surfaces. The experimental artifact used for this comparison is ChloroByte, a plant management app created for this study. It comprises native iOS with Swift and SwiftUI, native Android with Kotlin and Jetpack Compose, Flutter with Dart, React Native with TypeScript and Expo, and Kotlin Multiplatform with shared Kotlin services and native interfaces. Flutter, React Native, and Kotlin Multiplatform each target Android and iOS, yielding eight runtime variants. The common application contract includes login and session restoration, remote API communication, plant list and detail flows, search, filtering and sorting, image loading and upload, local persistence, settings management, and an integrated benchmark interface. The complete repositories retain some platform-specific differences, so runtime claims are bounded to the scripted benchmark path rather than assuming whole-product equivalence. Each implementation contains a benchmark runner that executes the same nominal 12-step scenario and records structured telemetry. Backend reset and dataset seeding are instrumented preparation steps. They contribute to whole-run elapsed time but are interpreted separately from operations that exercise authentication, plant retrieval, cache validation, image transfer and decoding, list rendering, automated scrolling, local synchronization, and upload. The supplied exports provide all wrapper totals and aggregate operation summaries for 2,000 runs per variant. They retain complete nested telemetry only for the last run, which limits distributional and inferential operation-level analysis. The ISO/IEC 25010 product quality model informs the placement of the measured runtime and structural properties within a broader software-quality context.1 The empirical questions are deliberately narrower than the full quality model. They concern measured time behavior, observable rendering-responsiveness proxies, implementation footprint, file-level source concentration, and declared dependency surfaces. This boundary keeps the conclusions aligned with the quantities recorded in the runtime exports and source inventory. 1 ISO/IEC 25010 product quality model: https://iso25000.com/
index.php/en/iso-25000-standards/iso-25010.
2
The contribution is threefold. First, the study documents five implementations and eight platform-specific runtime variants of the same application, including a Kotlin Multiplatform design that shares non-UI application layers while retaining native UIs. Second, it provides a repeated telemetry workflow and a 16,000run dataset for comparing native, Flutter, React Native, and Kotlin Multiplatform within the same operating system. Third, it reports client-operation timing, rendering wrappers, authored source footprint, filelevel source concentration, and declared dependency surfaces as distinct measures. This separation supports bounded framework selection without assuming that one technology must dominate every quality attribute.
Organization of the Paper The remainder of the paper is organized as follows. Background Work synthesizes prior research on framework selection, runtime behavior, energy, maintainability, and code reuse, leading to the Research Questions. Methodology defines the study design, units of analysis, operational measures, inclusion rules, and analysis boundaries. Artifact and Implementation Design describes the five codebases, benchmark instrumentation, and parity limitations. Experimental Setup and Protocol records the backend, workload, supplied run organization, repository-measurement rules, and reproducibility gaps. Results present dataset validity and findings by research question. Discussion relates the findings to prior work and practical framework selection, followed by Limitations and Conclusions and Future Work.
Background work Prior research approaches mobile-framework choice through architecture taxonomies, selection criteria, practitioner and ecosystem evidence, controlled runtime experiments, energy measurements, source-code analysis, and application case studies. These forms of evidence address related but distinct questions. Their conclusions can be compared only within the applications, platforms, metrics, and procedures from which they were obtained. Ecosystem, runtime, and source-quality studies illustrate the separation among forms of evidence. Jošt and Taneski combine surveys, repository activity, search interest, online discussion, and job postings for Flutter, React Native, and .NET MAUI [1]. Flutter leads some admired or loved indicators, while React Native is more visible in one employment dataset, yet
several direct popularity differences are not statistically significant. Bedogni et al. instead measure latency in six operating-system, framework, and mappingSDK combinations [2]. Native responds faster for inapplication alerts, but Flutter with Mapbox is faster than Kotlin with Mapbox for some Android map operations. Ugli et al. move from runtime to source quality by applying SonarQube and Code Climate to controlled and repository applications [3]. Java produces more raw smells in most controlled comparisons and Dart receives strong maintainability grades. Together, these studies show that adoption, latency, and analyzer findings cannot be combined into one framework score. Selection-oriented comparisons make criteria explicit but provide less direct experimental evidence. Zou and Darus compare five frameworks across seven qualitative dimensions, while Adnane et al. convert nine equally weighted binary criteria into a developer recommendation tool [4], [5]. Their explicit criteria help reveal what a decision model values, but binary scoring and equal weighting obscure context and interaction among criteria. Their categories also differ from other surveys, and Adnane et al. include SwiftUI, a native Apple UI technology, among alternatives framed for the same decision. Compared with the preceding empirical studies, these papers are better suited to eliciting requirements than to establishing runtime or maintainability rankings. Controlled runtime and energy experiments provide the broadest range of empirical designs. Oliveira et al. use computational benchmarks and interactionoriented applications and find native Android generally the most consistently resource efficient, with Flutter often the strongest cross-platform option for CPUintensive work [6]. React Native improves when animation is delegated to its native driver, whereas Ionic performs poorly in several animation and scrolling cases. Frattaroli et al. compare complete movie applications built with native Swift, native Kotlin, Kotlin Multiplatform Mobile, Flutter, and React Native [7]. Native produces the smallest packages, while network and energy results vary by operating system and some iOS quantities, including Kotlin Multiplatform energy, are unavailable. Huber et al. obtain stronger energy isolation by measuring 14 Android UI-component implementations with external hardware [8]. Native components are consistently most efficient, but the ordering among wrapped web components and Capacitor changes across dialogs, sheets, drawers, and scrolling.
3
Oliveira et al. provide workload breadth, Frattaroli et al. provide cross-OS application breadth, and Huber et al. provide component-level instrumentation. Their different winners reinforce that the unit of work and measurement boundary determine the conclusion. Other studies from the same period examine source quality, organizational priorities, and implementation feasibility. Karami et al. combine a systematic review of 75 studies with 3,566 native Android and React Native repositories and report fewer detected smells for React Native in small and medium project groups [9]. This breadth complements Ugli et al.’s tighter controlled comparison, but unrelated repositories and language-specific rule sets prevent a causal claim about framework maintainability. Mahmoud et al. survey 85 practitioners and report strong Flutter adoption together with memory and speed concerns; the convenience sample is concentrated among young developers, Egyptian respondents, and small organizations [10]. El Tom et al. apply 33 criteria, expanded into as many as 162 checklist items, to React Native and Xamarin.Forms in one organization and score React Native higher, although package size is the principal directly measured performance quantity [11]. These studies expose real decision criteria but do not measure functionally equivalent applications under common controls. Application case studies clarify where reuse creates integration work. De Almeida et al. report that adapting the Flutter-based IscteSpots application to the web changes 27 of 155 Dart files and 2,115 of 14,309 lines, partly because mobile packages lack web support [12]. Seo embeds Unity3D in a React Native storybook application and records 825 completed tasks after preliminary fixes, demonstrating feasibility while introducing communication, permission, state, and memory-management complexity [13]. Zarichuk provides a broader comparison of native, hybrid, and cross-platform approaches, but classifies React Native differently from studies that distinguish nativeUI runtimes from WebView-based hybrids [14]. These papers show that shared source moves effort toward packages, adapters, and platform integration rather than eliminating platform-specific work. Architecture and reuse research continues the contrast between classification and measured sharing. Stanojević et al. survey modern cross-platform architectures and selection considerations, providing a useful map of approaches but no controlled application comparison [15]. Wheeler and Olszewska report
4
69.16% shared code in a custom C++ framework for smart services, but exclude boilerplate and UI layout from the denominator [16]. The first study broadens the design space, while the second quantifies reuse within one particular sharing boundary. Neither percentage nor architecture category directly establishes runtime quality or development effort. Broader framework evaluations likewise depend on scope. Nawrocki et al. compare native Android, native iOS, Xamarin.Forms, React Native, and Flutter, finding native advantages in package size and startup and identifying Flutter as the strongest overall crossplatform compromise in their workload [17]. One device per operating system, synthetic applications, partly manual measurements, and no inferential analysis limit that ordering. Blanco and Lucrédio reduce the counted implementation from 3,719 native lines to 885 model-language and native lines through a holistic model-driven approach, but exclude view code and do not evaluate runtime behavior [18]. Shetty and Padmashree compare development approaches and framework characteristics at a broader level without an equivalent repeated artifact [19]. Their results are useful for package size, startup, and potential reuse, but those constructs cannot stand in for overall software quality. Controlled device and list-render experiments also show unstable rankings. Biørn-Hansen et al. conduct an Android experiment across six physical devices and 16,290 observations [20]. Native Android performs best overall, yet NativeScript leads parts of the completion-time and CPU comparisons, and Flutter combines low incremental memory use with high idle memory. Işıtan and Köklü test a 1,000-item list on one Android emulator without a native baseline or reported repetitions and observe the shortest render time for NativeScript [21]. The larger study offers stronger device and observation coverage, while the narrower study demonstrates how virtualization and a single task can change the apparent leader. Across the literature, native implementations frequently lead package-size, startup, device-feature, and component-level energy measures, but cross-platform approaches remain competitive for operations aligned with their compilation, rendering, or native-delegation mechanisms. Popularity, code sharing, latency, memory, energy, and source-quality measures answer different questions. Four gaps remain especially relevant. Few studies combine feature-aligned native, Flutter, React Native, and Kotlin Multiplatform applications
on both operating systems. Repeated application workflows with operation-level telemetry are uncommon. Rendering-wrapper times are often discussed without common frame traces or subjective evaluation. Source volume and code-sharing percentages are also prone to interpretation without an explicit counting scope. The present study addresses these gaps with five implemented codebases and eight measured variants. Its shared workflow exercises authentication, remote access, cache validation, image handling, local persistence, list rendering, scrolling, and upload. Runtime comparisons remain within operating system, while the source inventory applies one stated counting scope to all five codebases. The research questions therefore distinguish time behavior, observable rendering evidence, total implementation footprint, and file-level source and dependency structure.
Research Questions The literature shows that broad framework rankings conceal workload effects, operating-system differences, and measurement limitations. Accordingly, this study does not seek a universally superior technology. It asks four bounded questions across the five implemented codebases. RQ1. Within each target operating system, how do native, Flutter, React Native, and Kotlin Multiplatform builds differ in client-workflow elapsed time and operation-level time behavior under the common repeated benchmark workflow? RQ1 compares eight runtime variants: native iOS, Flutter iOS, React Native iOS, Kotlin Multiplatform iOS, native Android, Flutter Android, React Native Android, and Kotlin Multiplatform Android. Its primary aggregate is the sum of seven measured nonUI client operations: authentication, list retrieval, conditional retrieval, image transfer, image decoding, local synchronization, and upload. Full-scenario elapsed time is retained as contextual telemetry. Backend reset and seeding are excluded from the client subtotal because they primarily measure shared server and object-storage preparation. RQ2. Within each target operating system, how do native, Flutter, React Native, and Kotlin Multiplatform builds differ in the recorded list-render wrapper, and how comparable are their automatedscroll wrapper durations? RQ2 uses the available render and scroll wrapper summaries as descriptive evidence. The render wrapper
measures completion of each framework’s scripted synthetic-list task. The scroll wrapper is analyzed as a property of the realized test driver because the implementations use different animation and completion rules. Neither quantity is interpreted as a direct measure of frame quality, perceived smoothness, or subjective user experience. RQ3. How does authored mobile-source footprint differ among the native iOS, native Android, Flutter, React Native, and Kotlin Multiplatform codebases in the inspected snapshot, and how does each shared codebase compare with the combined native footprint required for both operating systems? Implementation footprint is evaluated through authored file counts, physical lines, nonblank lines, and source lines of code. Native iOS and native Android are presented separately and as a combined twoplatform strategy. The same inclusion and exclusion rules are applied to each inspected source tree. RQ4. How do the five codebases differ in the organization of their authored source files and in their use of direct production dependencies? RQ4 compares all five codebases using median SLOC per authored file, maximum authored-file SLOC, and direct production dependency declarations. These measures describe how source is distributed across files and how many external dependencies are declared by each inspected implementation under the stated counting rules.
Methodology The study is a comparative case study of native and cross-platform mobile development. It contains five source codebases and eight executable variants. Native iOS and native Android each contribute one platformspecific build, while Flutter, React Native, and Kotlin Multiplatform each contribute Android and iOS builds. The runtime phase is a high-repetition observational benchmark of the supplied artifacts.
Related-Work Identification The Background Work synthesis was assembled through a structured qualitative search whose identification and screening counts are documented using PRISMA 2020 as reporting guidance [22]. Searches in Web of Science and IEEE Xplore were supplemented with Connected Papers, Perplexity.ai, and Consensus as discovery tools. The seed query was mobile cross platform native. Screening yielded 61 candidate publications, of which 21 were retained for
5
full-text qualitative synthesis because they directly examined native or cross-platform mobile development. The synthesis motivates and delimits the research questions; it does not pool effect estimates across incompatible experiments. Figure 1 presents the identification, screening, eligibility, and inclusion flow for the literature review.
FIGURE 1: PRISMA 2020 flow diagram for identification and selection of studies included in the qualitative literature review. The diagram documents the reported review flow.
Study Design and Units of Analysis The study uses two units of analysis because runtime behavior and source-code properties belong to different artifacts. A runtime observation is one completed execution of a specific build on a specific operating system. RQ1 and RQ2 compare four build conditions within Android and four within iOS. Native Android is not compared directly with native iOS because that contrast would combine framework, operating-system, device, and toolchain effects. A codebase observation is one inspected mobile source tree. RQ3 and RQ4 therefore concern five codebases rather than eight executable targets, with an additional
6
combined-native view for RQ3. Table 1 summarizes the implemented conditions. The mobile applications use a common plantmanagement domain and expose aligned benchmark entry points. All benchmark clients authenticate against the same Node.js backend, use the same logical benchmark account and API contract, request the same configured dataset, and execute the same nominal sequence. Idiomatic framework choices are permitted. A measured difference is interpreted as a frameworklevel comparison only to the extent that inputs, outputs, and timing boundaries are equivalent.
Functional Equivalence and Experimental Controls Functional equivalence is assessed at two levels. The first level is the user-visible application contract, including authentication, plant retrieval, caching, image handling, local persistence, and list interaction. The second level is the benchmark contract, which specifies the ordered logical operations, input sizes, telemetry names, outputs, and success conditions. Equivalence therefore concerns observable behavior and workload rather than an identical sequence of internal calls. Requiring identical internals would be impractical because each platform and framework exposes different APIs, execution models, and integration mechanisms. Platform-specific product features outside the common benchmark path are excluded from runtime comparisons and are considered separately in the repository inventory. Many internal differences follow directly from platform constraints and framework-specific APIs. Native applications use operating-system networking, security, persistence, and image-decoding facilities. Flutter reaches corresponding services through its engine and plugin abstractions, while React Native and Expo delegate work through JavaScript-to-native interfaces and native-backed library objects. Kotlin Multiplatform shares application logic but supplies platform-specific implementations for networking, secure storage, databases, image decoding, and UI. Consequently, the same logical operation can involve different bridges, object representations, scheduling behavior, and library calls. Same-operating-system comparisons reduce operating-system confounding, but they cannot separate the effects of the framework, supporting libraries, platform APIs, architecture, and implementation boundaries. The recorded durations
TABLE 1: Implemented study units. Approach
Primary source and UI
Android build
iOS build
Native Android Native iOS Flutter React Native Kotlin Multiplatform
Kotlin and Jetpack Compose Swift and SwiftUI Dart and Flutter TypeScript and Expo Shared Kotlin and native UI shells
Available N/A Available Available Available
N/A Available Available Available Available
therefore characterize the complete realized implementations under a common logical workflow. They do not estimate an isolated causal effect of framework overhead. Backend reset and seed operations are treated separately because they measure shared server and object-storage preparation rather than client-framework behavior.
Operationalization of the Research Questions Table 2 maps each research question to its unit, measures, and interpretation boundary. For RQ1, the primary non-UI client subtotal is the sum of the exported means for step_login, step_fetch_plants, step_fetch_plants_304, step_download_images, step_decode_image, step_sqlite_sync, and step_upload_image. The subtotal excludes the runtime-origin marker, backend reset and seed, rendering and scrolling, and uninstrumented orchestration gaps. For RQ2, the runners emit list-render and automated-scroll wrappers, with some nested firstvisible and frame-related events. The exports retain those detailed nested events only for the final run, and their semantics differ across frameworks. Flutter and iOS use fixed-duration animations, Android Compose uses framework-controlled movement with fallback behavior, and React Native completes its driver substantially sooner. The available aggregate wrappers are reported as implementation and harness profiles. For RQ3, the inspected-source inventory includes authored production-language files in each mobile source tree and excludes tests, dependencies, generated output, assets, caches, and exported telemetry. Benchmark and telemetry source remains included because it is intertwined with application shells in some implementations. Kotlin Multiplatform is separated into commonMain, androidMain, iosMain, and native UI shells. The shared-source ratio does not duplicate commonMain. Native iOS and native Android are reported separately and as their sum. The
backend is shared infrastructure and is excluded from client totals. For RQ4, SLOC is aggregated per included authored file using the same lexical counting rules as RQ3. The median describes the central file size; for an even number of files, it is the mean of the two central values. The maximum identifies the largest included source file in each codebase. Direct production dependencies are counted from the maintained project manifests. Internal project edges, test dependencies, development-only tools, build-time processors, framework-managed SDK entries, and platform bill-of-materials constraints are excluded.
Data Inclusion and Analysis Plan The wrapper-level inclusion rule requires succeeded=true and completedSteps=totalSteps=12. All 16,000 supplied wrapper rows meet that rule. The operationsummary tables also report 2,000 samples for every step. For full-scenario elapsed time, the analysis reports sample size, mean, sample standard deviation, median, 95th percentile, minimum, and maximum from the 2,000 wrapper rows. Percentiles use the linearly interpolated Type-7 sample-quantile estimator. Operationlevel reporting uses the exported mean and sample standard deviation. Relative differences are calculated within operating system as 100(x̄candidate /x̄native − 1).
Artifact and Implementation Design The experimental artifact comprises five mobile clients, the shared backend, and embedded benchmark and telemetry subsystems. The design goal is functional alignment at the experimental boundary while allowing each application to use frameworkappropriate architecture internally. This section describes the inspected working trees and the boundaries that affect interpretation.
7
TABLE 2: Operationalization of the research questions. RQ
Unit of analysis
Measures
Interpretation boundary
RQ1
One completed execution; eight build conditions One wrapper observation; eight build conditions One inspected source tree; five codebases Five inspected source trees
Non-UI client subtotal, operation means, and contextual full-scenario duration Synthetic-list render and automatedscroll wrapper durations Authored files, PLOC, nonblank lines, SLOC, and combined-native total Median and maximum file SLOC; direct production dependency declarations
Same-OS comparison; reset and seed are backend preparation Drivers differ; no frame-quality or subjective UX claim Common counting scope across the inspected snapshot File structure and package granularity differ
RQ2 RQ3 RQ4
Shared Functional Contract and Architecture The common experimental path includes authentication, bearer-token refresh, plant retrieval, HTTP cache validation, signed image access, image upload, synthetic list rendering, local write and read operations, telemetry storage, and CSV export. Each client uses a central dependency container or equivalent composition root and separates API, authentication, persistence, feature, benchmark, and telemetry responsibilities. The clients use platform-specific mechanisms to route or rewrite loopback image URLs to a configured backend host.
Flutter The Flutter implementation uses Dart, Material widgets, a central application container, and ChangeNotifier-based feature controllers. It uses the http package for networking, sqflite for local database operations, and flutter_secure_storage for credentials. Android and iOS runner projects are present. The repository declares Flutter and Dart constraints and includes platform wrappers generated by Flutter tooling; generated wrappers will not be counted as authored product source.
Native Baselines Native iOS The current iOS application uses SwiftUI with Observation-based view models and a central AppContainer. A shared API client supports the normal product and benchmark paths. The product repository performs authenticated REST retrieval, CRUD operations, signed-image access, and image upload, and it persists a GRDB plant cache. GRDB also stores telemetry and benchmark records, Keychain stores access and refresh credentials, and an ephemeral URLSession configuration disables URL caching and cookie storage for the benchmark network client. The project uses NukeUI for image presentation.
React Native The React Native implementation uses TypeScript, Expo, React hooks, and a central service container. Manual route state is used instead of an external navigation package. Expo Secure Store persists credentials, while plant and telemetry data are stored in JSON files under the application document directory. The benchmark storage step therefore measures file serialization rather than SQLite, despite its legacy telemetry operation name. Expo File System, Image Picker, and Sharing support media and result-export workflows. The checked-in configuration uses Expo 55, React Native 0.83, React 19, TypeScript 5.9, Hermes, and the React Native new architecture.
Native Android The Android application uses Kotlin, Jetpack Compose, ViewModel, StateFlow, and Navigation Compose. Room provides SQLite persistence; credentials are stored with encrypted shared preferences; OkHttp performs authenticated API communication; and Coil handles remote images. The project targets SDK 35, uses Java 17, and leaves release minification disabled in the inspected configuration. The benchmark is part of the main source set and can be launched from the normal application route or a benchmark-only intent. The current network-security configuration permits the configured local benchmark hosts.
8
Kotlin Multiplatform The Kotlin Multiplatform implementation shares application services rather than UI code. commonMain contains models and data transfer objects, sorting, authentication and refresh handling, the plant repository, Ktor API access, ETag and JSON caching, SQLDelight persistence, image transfer, telemetry, CSV export, and the 12-step benchmark runner. androidMain supplies the Ktor OkHttp engine, Android SQLDelight driver, AES-GCM credential protection backed by Android Keystore, a monotonic clock, and bitmap decoding. Its application
shell uses Jetpack Compose. iosMain supplies the Ktor Darwin engine, native SQLDelight driver, Keychain storage, a monotonic clock, and UIKit image decoding. Shared Kotlin is exposed as a static framework to a SwiftUI shell for device and simulator architectures. The inspected project uses Kotlin 2.0.0, Android Gradle Plugin 8.10.0, Ktor 2.3.12, SQLDelight 2.0.2, coroutines 1.8.1, serialization 1.7.1, datetime 0.6.0, Compose UI 1.5.4, and Material 3 1.1.2. Android targets SDK 35 with minimum SDK 33 and Java 17. The iOS target has deployment version 16.0 and a Swift 5.0 project setting. Both shells implement authentication, cache-backed plant lists, local and server search, sorting and filtering, pagination, detail and CRUD flows, image selection and upload, settings, logout, and benchmark export.
Benchmark and Telemetry Instrumentation All five clients implement the same nominal sequence of 12 steps: a runtime-origin marker, login, backend reset, backend seed, plant fetch, ETag-based fetch expecting HTTP 304, image download, image decode, list rendering, automated scrolling, local persistence synchronization, and image upload. Default controls expose a short verification run and configurable repeated batches. The supplied configuration contains 2,000 executions per build. Full-scenario elapsed time is recorded by an outer wrapper and is not reconstructed by summing step means because orchestration gaps and instrumentation also contribute. Telemetry events share a logical schema containing run identifier, timestamp, scenario, operation, duration, success, optional HTTP status, byte counts, and contextual attributes. Each implementation produces a detailed-event table, a per-run wrapper table, and a per-operation aggregate table. Persistence mechanisms and synchronization costs differ among GRDB, Room, sqflite, JSON files, and SQLDelight. Functional Parity and Known Implementation Deviations The repository audit identified the following deviations that bound the results: • Image wrappers independently acquire their inputs rather than passing the preceding download bytes directly to decoding. Platform decoders differ. React Native times Expo Image’s complete loadAsync call and receives a native-backed image reference,
rather than performing the same explicit platformcodec operation as the other clients. Upload wrappers also differ in temporary-file and multipart handling. • Synthetic list containers, virtualization, scrolling animation, timeout behavior, and visibility callbacks differ across UI frameworks. • The post-first-row rendering proxies use either a fixed 16 ms delay or one additional rendered frame rather than a measured quiescence condition. • Telemetry persistence cost differs, and raw exports cover only the final run even though aggregate tables cover all 2,000 executions. • Runtime-origin markers begin at different lifecycle points and are reused or accumulated throughout an in-process batch, so they do not represent repeated cold starts. • Whole-product scope remains unequal in some media acquisition and platform UI flows. KMP uses native UI shells and therefore represents a different sharing boundary from Flutter and React Native shared-UI approaches. These deviations are properties of the realized artifacts. Results are reported by operation and operating system, and claims are limited to the work performed inside each recorded boundary.
Experimental Setup and Protocol The repositories encode a common workload and the supplied CSVs preserve its wrapper and aggregate results. They do not preserve every element needed to reconstruct the execution environment. This section distinguishes verified artifact properties from missing run metadata.
Hardware and Software Environment The experiments were designed for execution on physical mobile devices. The following mobile devices were used: • iOS device: iPhone 15, iOS version 26.3.1; • Android device: Pixel 6 Pro, Android version 16; The experiments were run on Android version 16 for native Android and iOS version 26.3.1 for native iOS; Flutter packages including http, sqflite, and secure storage; Expo 55, React Native 0.83, React 19, TypeScript 5.9, Hermes, and the new architecture for React Native; SwiftUI, GRDB, and NukeUI for native iOS; and the KMP versions reported above.
9
Backend, Network, and Dataset Conditions The shared backend is a Fastify and TypeScript service backed by PostgreSQL and S3-compatible object storage. Benchmark routes are available only outside backend production mode and require an authenticated user. POST /benchmark/reset first requests deletion of the authenticated user’s distinct image objects. If the storage request throws, the route returns HTTP 503 before deleting database rows. It then deletes the user’s plants. POST /benchmark/seed uploads deterministic shared image objects and creates the requested plant and image records sequentially without a transaction or rollback, so a later failure can leave partial state. The common client configuration requests 200 plants, original and generated images, the medium image variant, a page size of 50, offset zero, and strict failure handling. The medium seed image is a deterministic 256 by 256 noise PNG. In the inspected backend snapshot it is 224,668 bytes. The route uploads one shared original object and one shared generated object, approximately 0.43 MiB in total, then creates 200 plants and associated image records that reference those keys. This work belongs to environment preparation rather than client-framework performance. Seed is omitted from all operation charts and from the primary client subtotal. Benchmark Configuration and Scenario The shared workload uses the following values: • benchmark account shared across builds; • 200 seeded plants; • original and generated images enabled; • deterministic medium image variant at 256 by 256 pixels; • page size 50 and offset zero; • strict mode enabled; • a synthetic 50-row render task, a 200-row scroll task, and a 200-record local synchronization task. The 12 wrapper steps execute in this order: 1) record the runtime-origin marker; 2) authenticate the benchmark account; 3) reset server-side benchmark plants and image objects; 4) seed the 200-plant dataset; 5) retrieve one page of plants; 6) validate ETag behavior with an HTTP 304 response;
10
7) download one image; 8) independently acquire and decode one benchmark image; 9) render a synthetic 50-row list; 10) scroll a synthetic 200-row list; 11) write and read 200 local records or their aligned representation; 12) upload the deterministic benchmark image. The ETag wrapper performs a preparatory HTTP 200 retrieval before the conditional request that returns HTTP 304. It therefore measures a two-request validation workflow. The outer full-scenario duration includes every wrapper, backend preparation, UI-driver time, and orchestration between wrappers.
Run Protocol and Runtime Data Quality Each generated CSV contains 2,000 sequential wrapper observations from one in-process execution session. Native Android, native iOS, Flutter Android, Flutter iOS, React Native Android and iOS, KMP Android, and KMP iOS label them as ten batches of 200. Repository-Metric Configuration The source snapshot used for RQ3 and RQ4 includes authored mobile-language files from the following roots: • native iOS: Swift under the application source tree; • native Android: Kotlin under app/src/main; • Flutter: Dart under lib plus maintained Android Kotlin and iOS Swift host source; • React Native: App.tsx, TypeScript under src, and maintained Android Kotlin and iOS Swift host source; • Kotlin Multiplatform: Kotlin and SQLDelight source in commonMain, androidMain, and iosMain, plus the Android Compose and iOS SwiftUI shells. Tests, build scripts, generated and build output, dependencies, lockfiles, assets, resources, caches, and exported telemetry are excluded. Physical lines of code (PLOC) count every file-line record; nonblank lines exclude whitespace-only records; the reported source lines of code (SLOC) apply a lexical filter for line and block comments, counting mixed code-andcomment lines as source. Handwritten platform host code and benchmark and telemetry code are included. The latter cannot be removed consistently because KMP intertwines benchmark UI and application-shell
behavior. The counts therefore characterize the current whole client, not an instrumentation-free product. Dependency declarations are read from each platform’s maintained manifest or project configuration. Counts are reported as declared package products or runtime artifacts according to the native package manager, pub, npm, or Gradle source-set model. They describe the visible dependency surface under each ecosystem’s declaration model.
Reproducibility Materials The supplied result bundle contains one CSV for each of the eight runtime variants. Every file concatenates three tables: detailed nested telemetry for the last run, wrapper summaries for all 2,000 runs, and aggregate summaries for 12 operations.
Results The results combine the eight supplied runtime exports with a structural inventory of the five current mobile source trees. Runtime findings are descriptive because collection was sequential.
Dataset and Run Validity Table 3 reports the observed run structure. Every variant contains 2,000 unique wrapper identifiers, every row is marked successful with 12 of 12 completed steps, and every operation aggregate reports 2,000 samples. The dataset therefore contains 16,000 completed wrapper runs. RQ1: Time Behavior Figure 2 and Table 4 report full-scenario elapsed time. This total is contextual because it includes backend reset and seed, UI-driver time, and orchestration. Seed is not plotted as an operation in any result figure. On Android, full-scenario ordering is Native, KMP, React Native, then Flutter. Relative to native, the means are 21.7%, 25.0%, and 186.3% higher. On iOS, ordering is React Native, KMP, Native, then Flutter; relative to native, React Native is 33.5% lower, KMP is 1.1% lower, and Flutter is 16.6% higher. The React Native iOS total is strongly affected by its 61.706 ms scroll wrapper, compared with 871.525 ms for native and 876.012 ms for KMP, so this ordering is not evidence of a general React Native advantage. Table 5 and Figure 3 give the primary sevenoperation subtotal. It excludes the runtime marker, reset, seed, render, and scroll. Because it is calculated as a sum of aggregate means, no subtotal SD or
confidence interval is reported. Figures 4 and 5 show the component means. Reset and seed are intentionally absent because they are backend preparation, and the runtime marker and UI wrappers are analyzed separately. The component profile is operation dependent. On iOS, KMP has the shortest login and decode means, native has the shortest fetch, conditional-fetch, download, and upload means, and React Native has the shortest local-sync mean. On Android, native has the shortest login, fetch, conditional-fetch, download, and decode means, while KMP has the shortest localsync and upload means. KMP Android is within 1.2% of native for download and 1.0% for decode. These observations describe the timed wrappers and retain the semantic caveats identified in the artifact audit. Answer to RQ1. For the seven-operation client subtotal, native is lowest on both operating systems and KMP is the closest cross-platform implementation, at 6.1% above native on iOS and 11.4% above native on Android. React Native and Flutter have larger subtotals, but no implementation leads every component. Full-scenario ordering is different because backend and UI-driver work dominate parts of that total.
RQ2: Observable Rendering Responsiveness Table 6 reports the available list-render and scroll wrapper summaries. Each value contains 2,000 samples. The shortest recorded render wrapper is Flutter on iOS and KMP on Android. KMP is 26.5% below native iOS and 39.6% below native Android for this wrapper. Its scroll duration is close to the native shell on both platforms: 0.5% above native on iOS and 0.1% above native on Android. This proximity is expected because KMP uses the same native UI families and closely matched platform-specific drivers. React Native’s much shorter scroll wrappers and Flutter Android’s much longer value reveal different prescribed paths and completion rules rather than measured smoothness. Answer to RQ2. The render wrapper distinguishes the realized implementations, with Flutter lowest on iOS and KMP lowest on Android. The scroll wrappers are not cross-framework responsiveness measures because the driver is part of the timed work. The current exports cannot answer which interface has better frame pacing, fewer missed frames, or better perceived responsiveness.
11
Mean full-scenario elapsed time (ms)
TABLE 3: Wrapper-level validity and batching in the supplied runtime exports. OS
Approach
iOS iOS iOS iOS Android Android Android Android
Native Kotlin Multiplatform React Native Flutter Native Kotlin Multiplatform React Native Flutter
Attempted
Completed
Included
Exported batch layout
2,000 2,000 2,000 2,000 2,000 2,000 2,000 2,000
2,000 2,000 2,000 2,000 2,000 2,000 2,000 2,000
2,000 2,000 2,000 2,000 2,000 2,000 2,000 2,000
10 × 200 10 × 200 10 × 200 10 × 200 10 × 200 10 × 200 10 × 200 10 × 200
3,000
2,000
1,000
0
e tiv
S
iO
a -N
P
KM S-
iO
RN
OS
i
tte
iO
lu -F
S
r
e tiv
i
dro An
P
a d-N
K iddro
An
RN
M
tte
droi
r
i
d
An
lu d-F
dro
An
FIGURE 2: Full-scenario elapsed time for 2,000 wrapper runs per variant. Error bars show sample standard deviation. The total includes backend reset and seed and framework-specific UI-driver time, so it is contextual rather than the primary client-framework outcome. TABLE 4: Full-scenario elapsed-time distribution for each variant, in milliseconds. OS
Approach
iOS iOS iOS iOS Android Android Android Android
Native Kotlin Multiplatform React Native Flutter Native Kotlin Multiplatform React Native Flutter
Mean ± SD
Median
P95
Range
1606.078 ± 93.014 1589.136 ± 101.181 1068.165 ± 142.592 1872.157 ± 343.031 1074.042 ± 125.781 1306.726 ± 375.725 1342.155 ± 194.826 3075.470 ± 349.366
1585.0 1571.0 1055.0 1698.0 1048.0 1204.0 1333.5 3022.0
1769.00 1757.00 1338.00 2529.20 1280.05 1915.45 1699.00 3670.00
1456–2498 1415–2696 739–2387 1428–4129 826–2214 919–5056 976–3244 2261–9059
RQ3: Implementation Footprint Table 7 reports the rule-based whole-client inventory defined in the methodology. SLOC is used for relative comparisons; PLOC and nonblank lines expose sensitivity to comments and whitespace. The combined-native row represents the two source trees required to deliver both operating systems. KMP’s 4,195 SLOC consists of 1,624 shared SLOC, 1,291 Android-specific SLOC, and 1,280 iOSspecific SLOC. Shared Kotlin therefore accounts for
12
38.7% of unique KMP source. Viewed per target, common code forms 55.7% of the Android deliverable and 55.9% of the iOS deliverable. When common source is counted once for each target in the twodeliverable source incidence, the shared proportion is 55.8%. These values reflect KMP’s architecture of shared application services with separate Compose and SwiftUI interfaces. Answer to RQ3. In this whole-client snapshot, the combined native implementation contains 9,105
Sum of operation means (ms)
TABLE 5: Seven-operation non-UI client subtotal and difference from the same-OS native subtotal. OS
Approach
iOS iOS iOS iOS Android Android Android Android
Native Kotlin Multiplatform Flutter React Native Native Kotlin Multiplatform React Native Flutter
Sum of operation means (ms)
Difference from native
353.120 374.677 518.638 594.855 452.755 504.592 771.907 1547.144
Reference +6.1% +46.9% +68.5% Reference +11.4% +70.5% +241.7%
1,500
1,000
500
0 Na S-
iO
e tiv
P
RN
M
K S-
iO
i
OS
r
e tiv
tte
Flu S-
a d-N
roi
iO
d An
P
RN
M
K id-
dro An
tte
droi
r
i
d
An
lu d-F
dro
An
FIGURE 3: Primary non-UI client subtotal. Bars sum aggregate means for login, fetch, conditional fetch, image download, image decode, local synchronization, and upload. Backend reset and seed and UI wrappers are excluded. TABLE 6: Synthetic UI wrapper durations, mean ± sample SD in milliseconds. OS
Approach
Render 50 rows
Scroll 200 rows
iOS iOS iOS iOS Android Android Android Android
Native Kotlin Multiplatform React Native Flutter Native Kotlin Multiplatform React Native Flutter
49.708 ± 3.108 36.517 ± 1.460 61.368 ± 6.396 33.989 ± 6.014 45.338 ± 5.646 27.404 ± 6.011 63.748 ± 21.333 95.379 ± 18.814
871.525 ± 6.199 876.012 ± 4.958 61.706 ± 2.063 890.003 ± 3.844 316.170 ± 15.054 316.347 ± 9.723 111.814 ± 11.069 912.652 ± 11.036
SLOC. Flutter contains 5,466 SLOC, 40.0% less than combined native; React Native contains 4,209 SLOC, 53.8% less; and KMP contains 4,195 SLOC, 53.9% less. KMP has the smallest measured total, 14 SLOC below React Native. The corresponding file, PLOC, and nonblank-line counts are reported in Table 7 under the same inventory rules.
RQ4: Source-File Organization and Dependency Use Table 8 compares all five codebases using the median and maximum SLOC among included authored files and the direct production dependencies declared by each project. The file statistics use the same inventory and lexical SLOC rules as RQ3. KMP has the highest median included-file size at 157.5 SLOC, followed by Flutter at 130.0 and native Android at 98.0. Flutter has the largest individual file
13
KMP
Native
React Native
Flutter
Mean client-operation duration (ms)
350 300 250 200 150 100 50
oa d
yn c ca
U
pl
lS
od e ec
D
Lo
D
ow
nl
oa d
tc h3 04 Fe
Fe
Lo
tc
gi
h
n
0
FIGURE 4: iOS aggregate means for the seven client operations, each based on 2,000 summary samples. Error bars show sample standard deviation. Backend reset and seed are excluded. TABLE 7: Authored mobile-source footprint in the inspected working-tree snapshot. Approach Native iOS Native Android Combined native Flutter React Native Kotlin Multiplatform
Files
PLOC
Nonblank
SLOC
Versus combined native
63 26 89 16 39 16
5,754 5,030 10,784 6,062 4,681 4,516
4,964 4,583 9,547 5,467 4,245 4,196
4,522 4,583 9,105 5,466 4,209 4,195
N/A N/A Reference −40.0% −53.8% −53.9%
TABLE 8: File-level source concentration and declared direct dependency surface. Approach Native iOS Native Android Flutter React Native Kotlin Multiplatform
Median SLOC per file
Maximum file SLOC
Direct dependencies
43.0 98.0 130.0 54.0 157.5
363 1,127 1,989 498 1,116
2 19 10 10 19
at 1,989 SLOC. The largest native Android and KMP files contain 1,127 and 1,116 SLOC, respectively, while the React Native and native iOS maxima are 498 and 363 SLOC. The maintained declarations contain 2 external package products for native iOS, 19 native Android runtime artifacts, 10 third-party pub packages for Flutter, 10 runtime npm packages for React Native, and 19 KMP implementation declarations across common and platform source sets. Answer to RQ4. The five codebases exhibit different file-level concentration profiles and declared
14
dependency surfaces. KMP has the highest median file SLOC, Flutter has the largest included source file, and native iOS has the lowest median, maximum, and dependency count. Native Android and KMP each declare 19 direct dependencies, Flutter and React Native each declare 10, and native iOS declares 2. These are declaration counts within each ecosystem’s package model.
Native
KMP
React Native
Flutter
Mean client-operation duration (ms)
400
300
200
100
ad pl o U
nc Sy al Lo c
D
ec
od e
oa d nl ow D
Fe t
ch 30 4
ch Fe t
Lo
gi
n
0
FIGURE 5: Android aggregate means for the seven client operations, each based on 2,000 summary samples. Error bars show sample standard deviation. Backend reset and seed are excluded.
Discussion Status of the Empirical Evidence The 16,000 completed wrapper runs provide a high-repetition descriptive basis. The central result is the same-OS seven-operation profile. Native has the lowest client subtotal on both systems and KMP is consistently the closest shared approach. The leader still changes for individual operations, showing why one total cannot describe every part of an application. Full-scenario time tells a different story. React Native appears fastest on iOS because its scroll driver completes about 810 ms sooner than the native and KMP drivers. Android KMP is 21.7% above native in the full scenario and has the largest full-run coefficient of variation, 28.8%, while iOS KMP is 1.1% below native and has similar variability. Runtime and Rendering Trade-offs KMP’s client subtotal is 6.1% above native on iOS and 11.4% above native on Android. On Android, its image download and decode means are within about 1% of native, and its local-sync and upload wrappers are lower. On iOS it has the lowest login and decode means. These results are compatible with an architecture that shares service code but delegates HTTP engines, storage drivers, security, decoding, and UI behavior to platform implementations. They do not
show that KMP itself causes the difference because implementations, libraries, and timed boundaries vary together. The UI wrappers demonstrate a different tradeoff. KMP’s native shells produce scroll timings nearly identical to the corresponding native applications under closely matched drivers. Flutter and React Native use different driver durations, so their scroll totals cannot rank smoothness. The render wrapper favors Flutter on iOS and KMP on Android. Frame pacing, jank, and subjective responsiveness remain unmeasured.
Implementation Footprint and Source-Structure Trade-offs All three shared approaches contain less authored mobile source than the sum of the two native clients in the current manifest. KMP and React Native are nearly equal in total SLOC, while Flutter is larger. File-level concentration differs: KMP has the highest median file SLOC, whereas Flutter contains the largest individual file. The counts describe the inspected implementations and include their benchmark and telemetry code. Dependency ecosystems also package functionality at different granularities, so declaration totals are interpreted within each ecosystem. KMP’s sharing boundary is especially important. Shared Kotlin is 38.7% of unique KMP SLOC, while
15
approximately 55.8% of two-target source incidence is shared. The rest includes two native UIs and platform adapters. Flutter and React Native share their primary UI-language source, so a direct sharing-ratio comparison would conflate architectural strategy with reuse efficiency.
Comparison with Prior Work The native lead in the primary client subtotal is consistent with the overall tendencies reported by Biørn-Hansen et al., Nawrocki et al., and Oliveira et al., while the operation-specific exceptions agree with their finding that rankings depend on workload [20], [17], [6]. Bedogni et al. likewise show that framework and SDK combinations can reverse the ordering for individual mapping operations [2]. The present results extend this type of comparison with KMP on both systems but remain bounded to one application and its wrappers. Frattaroli et al. provide the closest prior fiveapproach application comparison, although their outcomes are package size, network traffic, and aggregate energy rather than operation timing [7]. The current KMP footprint also supports the reuse pattern reported by De Almeida et al., Wheeler and Olszewska, and Blanco and Lucrédio: sharing reduces duplicated source but leaves adapters, UIs, and integration work [12], [16], [18]. Implications for Framework Selection Technology selection cannot be reduced to one end-to-end timing bar. Teams whose priority is the measured service workflow should examine the sameOS native and KMP profiles closely, while teams prioritizing maximum UI sharing may accept different runtime and integration characteristics from Flutter or React Native. KMP offers a distinct compromise: native interfaces and platform adapters combined with shared domain and data services. Source footprint, file-level organization, sharing boundaries, declared dependencies, runtime behavior, ecosystem maturity, and team expertise remain separate decision inputs.
Limitations Construct Validity Time measurements cover only time behavior, not the full ISO/IEC 25010 performance-efficiency characteristic. CPU use, memory, capacity, energy, package size, and startup are outside the current runtime
16
dataset. The render and scroll wrappers do not measure frame time, dropped frames, jank, or subjective UX. The seven-operation subtotal excludes backend and UI work, but its components still contain unequal parsing, storage, image, multipart, and instrumentation behavior. It is a sum of exported operation means rather than a per-run aggregate. Full-scenario elapsed time includes reset, seed, and prescribed UI drivers. The RQ3 and RQ4 source measures characterize authored footprint, KMP’s sharing boundary, file-level source concentration, and declared dependency surfaces under the stated counting rules.
Internal Validity Implementation expertise, framework idioms, library selection, cache state, asynchronous work, and telemetry persistence can influence timings. Image decoders, HTTP engines, security stores, and UI drivers also differ. Backend seed is sequential and non-transactional, and reset can leave partial state if database deletion fails after successful object deletion.
Conclusion Validity Each build has 2,000 wrapper totals, but those observations are sequential and sometimes autocorrelated. The collections are not randomized or interleaved. Treating all rows as independent would therefore overstate precision.
External Validity The study uses one plant-management application and one realized implementation per approach. Results may not generalize to games, real-time collaboration, media-intensive applications, offline-first systems, or background-processing workloads. Frameworks, operating systems, compilers, libraries, and backend dependencies evolve quickly. KMP findings are specific to shared domain and data layers with native Compose and SwiftUI shells, not to every Kotlin Multiplatform design or a shared Compose UI. Flutter and React Native results are likewise tied to their selected packages and architectures. Despite these limitations, the application workflow, common backend, 16,000 wrapper executions, operation summaries, and separate runtime and codebase units provide a useful descriptive case study.
Conclusions & Future Work This paper compares five ChloroByte codebases and eight Android and iOS runtime variants, including a Kotlin Multiplatform implementation with shared application services and native interfaces. The supplied exports contain 2,000 completed runs per variant, or 16,000 wrapper-level runs. Separating backend preparation and UI-driver time from the primary non-UI client subtotal changes the interpretation of the results. Native has the lowest seven-operation client subtotal on both operating systems. KMP is the closest cross-platform result at 6.1% above native on iOS and 11.4% above native on Android. Flutter is 46.9% above native on iOS and 241.7% on Android, while React Native is 68.5% and 70.5% above native. Individual operations have different leaders. The render wrappers favor Flutter on iOS and KMP on Android. The whole-client source snapshot contains 9,105 SLOC for the two native applications together, compared with 5,466 for Flutter, 4,209 for React Native, and 4,195 for KMP. Shared Kotlin accounts for 38.7% of unique KMP source and about 55.8% of two-target source incidence. Across the five codebases, median file SLOC ranges from 43.0 for native iOS to 157.5 for KMP, while Flutter contains the largest included file at 1,989 SLOC. The inspected manifests declare 2 direct package products for native iOS, 19 runtime artifacts for native Android, 10 third-party packages for Flutter, 10 for React Native, and 19 implementation dependencies for KMP. These values describe the source organization and dependency structure of the implemented clients. Future work can extend the workload to more devices and application domains and measure CPU, memory, energy, subjective experience, recorded development effort, and longitudinal maintenance.
comparative study of market and developer trends,” INFORMATICS-BASEL, vol. 12, no. 2, APR 28 2025. 2. L. Bedogni, C. A. Grazia, and R. Scalise, “On the latency performance of mobile mapping services: towards vulnerable road users safety,” in 2025 IEEE 22ND CONSUMER COMMUNICATIONS & NETWORKING CONFERENCE, CCNC, ser. IEEE Consumer Communications and Networking Conference.
Institute of Electrical and Electronics
Engineers Inc, 2025, 22nd Consumer Communications and Networking Conference-CCNC-Annual, Las Vegas, NV, JAN 10-13, 2025. 3. I. S. R. Ugli, J. Cheon, and G. Woo, “Code smells and development efficiency in native and cross-platform mobile applications: A study of java, kotlin, and flutter,” JOURNAL OF INFORMATION PROCESSING SYSTEMS, vol. 21, no. 4, pp. 401–412, AUG 2025. 4. D. Zou and M. Y. Darus, “A comparative analysis of cross-platform mobile development frameworks,” in 2024 IEEE 6th Symposium on Computers & Informatics (ISCI), 2024, pp. 84–90. 5. A. Souha, L. Benaddi, C. Ouaddi, and A. Jakimi, “Comparative analysis of mobile application frameworks: A developer’s guide for choosing the right tool,” Procedia Computer Science, vol. 236, pp. 597–604, 2024, international Symposium on Green Technologies and Applications (ISGTA’2023). [Online]. Available: https://www.sciencedirect.com/science/ article/pii/S1877050924010871 6. W. Oliveira, B. Moraes, F. Castor, and J. P. Fernandes, “Analyzing the resource usage overhead of mobile app development frameworks,” in 27TH INTERNATIONAL CONFERENCE ON EVALUATION AND ASSESSMENT IN SOFTWARE ENGINEERING, EASE 2023, 2023, pp. 152–161, 27th International Conference on Evaluation and Assessment in Software Engineering (EASE), Oulu, FINLAND, JUN
Acknowledgment The author acknowledges the use of generative AI tools, including Connected Papers, NotebookLM, Perplexity AI, and ChatGPT, in the preparation of this work. These tools were employed to assist in the refinement, rewriting, and organization of the manuscript. All ideas, analyses, and original contributions presented remain the author’s own.
14-16, 2023. 7. V. Frattaroli, O. Le Goaer, and O. Philippot, “Ecological impact of native versus cross-platform mobile apps: a preliminary study,” in 2023 38TH IEEE/ACM INTERNATIONAL CONFERENCE ON AUTOMATED SOFTWARE ENGINEERING WORKSHOPS, ASEW, ser. IEEE ACM International Conference on Automated Software Engineering.
IEEE; Assoc Comp
Machinery; IEEE Comp Soc, 2023, pp. 3–8, 38th IEEE/ACM International Conference on Automated
REFERENCES 1. G. Jost and V. Taneski, “State-of-the-art cross-platform mobile application development frameworks: A
Software Engineering (ASE), Echternach, LUXEMBOURG, SEP 11-15, 2023. 8. S. Huber, M. Doeller, and M. Felderer, “On the
17
energy-efficiency of hybrid ui components for mobile cross-platform development,” in WEB ENGINEERING,
14. O. Zarichuk, “Comparative analysis of frameworks for
ICWE 2023, ser. Lecture Notes in Computer Science,
mobile application development: Native, hybrid, or
I. Garrigos, J. Rodriguez, and M. Wimmer, Eds., vol.
cross-platform solutions,” vol. 28, no. 4, p. 19–27, Nov.
13893, 2023, pp. 247–261, 23rd International
2023. [Online]. Available:
Conference on Web Engineering (ICWE), Alicante, SPAIN, JUN 06-09, 2023. 9. P. Karami, I. Darif, C. Politowski, G. El Boussaidi,
http://dx.doi.org/10.62660/2306-4412.4.2023.19-27 15. J. Stanojevic, U. Sosevic, M. Minovic, and M. Milovanovic, “An overview of modern cross-platform
S. Kpodjedo, and I. Benzarti, “On the impact of
mobile development frameworks,” in CENTRAL
development frameworks on mobile apps,” in
EUROPEAN CONFERENCE ON INFORMATION AND
PROCEEDINGS OF THE 2023 30TH ASIA-PACIFIC
INTELLIGENT SYSTEMS, CECIIS 2022, ser. Central
SOFTWARE ENGINEERING CONFERENCE, APSEC
European Conference on Information and Intelligent
2023, ser. Asia-Pacific Software Engineering
Systems, N. Vrcek, L. Guardia, and P. Grd, Eds.
Conference, 2023, pp. 131–140, 30th Asia-Pacific
Zagreb, Fac Org & Informat; Infodom; Mobilisis;
Software Engineering Conference (APSEC), Seoul,
Oracle; Dignet Software; FactoryX; IGEA; In2 Grupa;
SOUTH KOREA, DEC 04-07, 2023.
Republ Croatia, Minist Sci & Educ, 2022, pp. 489–497,
10. A. T. Mahmoud, A. A. Muhammad, A. H. Yousef, H. H.
Univ
33rd Annual International Scientific Central European
Zayed, W. Medhat, and S. Selim, “Industrial
Conference on Information and Intelligent Systems
practitioner perspective of mobile applications
(CECIIS), Univ Dubrovnik, Dubrovnik, CROATIA, SEP
programming languages and systems,”
21-23, 2022.
INTERNATIONAL JOURNAL OF ADVANCED
16. D. Wheeler and J. I. Olszewska, “Cross-platform
COMPUTER SCIENCE AND APPLICATIONS, vol. 14,
mobile application development for smart services,” in
no. 5, pp. 275–285, MAY 2023.
2022 IEEE 22ND INTERNATIONAL SYMPOSIUM ON
11. A. El Tom, C. Bogdan, T. A. Majchrzak, and T.-M.
COMPUTATIONAL INTELLIGENCE AND
Gronli, “Criteria based evaluation of cross-platform
INFORMATICS AND 8TH IEEE INTERNATIONAL
development frameworks,” in PROCEEDINGS OF THE
CONFERENCE ON RECENT ACHIEVEMENTS IN
56TH ANNUAL HAWAII INTERNATIONAL
MECHATRONICS, AUTOMATION, COMPUTER
CONFERENCE ON SYSTEM SCIENCES, ser. Hawaii
SCIENCE AND ROBOTICS (CINTI-MACRO), ser.
International Conference on System Sciences, T. Bui,
International Symposium on Computational
Ed.
Intelligence and Informatics.
Univ Hawaii Manoa, Coll Business; Assoc
IEEE; Hungarian Fuzzy
Informat Syst; Univ Redlands, Sch Business & Soc;
Assoc, 2022, pp. 203–208, iEEE Joint 22nd
ESRI; Univ Arkansas, Sam M Walton Coll Business
International Symposium on Computational
Informat Syst, 2023, pp. 6944–6953, 56th Annual
Intelligence and Informatics / 8th IEEE International
Hawaii International Conference on System Sciences
Conference on Recent Achievements in Mechatronics,
(HICSS), Maui, HI, JAN 03-06, 2023.
Automation, Computer Science and Robotics
12. J. C. de Almeida, F. Brito e Abreu, and D. S. de Almeida, “Cross-platform mobile app development: the isctespots experience,” in 2023 38TH IEEE/ACM
(CINTI-MACRo), Budapest, HUNGARY, NOV 21-22, 2022. 17. P. Nawrocki, K. Wrona, M. Marczak, and B. Sniezynski,
INTERNATIONAL CONFERENCE ON AUTOMATED
“A comparison of native and cross-platform
SOFTWARE ENGINEERING WORKSHOPS, ASEW,
frameworks for mobile applications,” COMPUTER,
ser. IEEE ACM International Conference on Automated
vol. 54, no. 3, pp. 18–27, MAR 2021.
Software Engineering.
IEEE; Assoc Comp
18. J. Z. Blanco and D. Lucredio, “A holistic approach for
Machinery; IEEE Comp Soc, 2023, pp. 11–16, 38th
cross-platform software development,” JOURNAL OF
IEEE/ACM International Conference on Automated
SYSTEMS AND SOFTWARE, vol. 179, SEP 2021.
Software Engineering (ASE), Echternach, LUXEMBOURG, SEP 11-15, 2023. 13. B. Seo, “A case study of combining two cross-platform development frameworks for storybook mobile app,”
18
3345–3363, DEC 31 2023.
19. S. A. Shetty, “Evaluation of cross-platform application development frameworks,” 2021. [Online]. Available: https://api.semanticscholar.org/CorpusID:235416321 20. A. Biørn-Hansen, C. Rieger, T.-M. Grønli, T. A.
KSII TRANSACTIONS ON INTERNET AND
Majchrzak, and G. Ghinea, “An empirical investigation
INFORMATION SYSTEMS, vol. 17, no. 12, pp.
of performance overhead in cross-platform mobile
development frameworks,” Empirical Software Engineering, vol. 25, no. 4, pp. 2997–3040, Jul 2020. [Online]. Available: https://doi.org/10.1007/s10664-020-09827-6 21. M. Işıtan and M. Koklu, “Comparison and evaluation of cross platform mobile application development tools,” International Journal of Applied Mathematics Electronics and Computers, vol. 8, no. 4, p. 273–281, 2020. [Online]. Available: https://izlik.org/JA76JX82ZK 22. M. J. Page, J. E. McKenzie, P. M. Bossuyt, I. Boutron, T. C. Hoffmann, C. D. Mulrow, L. Shamseer, J. M. Tetzlaff, E. A. Akl, S. E. Brennan, R. Chou, J. Glanville, J. M. Grimshaw, A. Hróbjartsson, M. M. Lalu, T. Li, E. W. Loder, E. Mayo-Wilson, S. McDonald, L. A. McGuinness, L. A. Stewart, J. Thomas, A. C. Tricco, V. A. Welch, P. Whiting, and D. Moher, “The prisma 2020 statement: an updated guideline for reporting systematic reviews,” BMJ, vol. 372, 2021. [Online]. Available: https://www.bmj.com/content/372/bmj.n71
19