Mobile Computing and Cross-Platform Foundations

Introduction

Mobile application development is not simply desktop software development on a smaller screen. Mobile devices operate under restricted energy, memory and network conditions; contain sensors such as cameras, accelerometers and location receivers; and are governed by platform security policies and application stores. Applications must also tolerate interruptions, orientation changes, process termination and intermittent connectivity.

The two dominant mobile operating systems—Android and iOS—provide different development tools, user-interface conventions, lifecycle mechanisms and distribution processes. Organizations can create separate native applications, deliver browser-based experiences, embed web content in native containers, or use cross-platform frameworks such as React Native and Flutter.

Choosing among these models is an architectural and managerial decision. It affects performance, user experience, maintainability, staffing, testing, security and long-term cost. This chapter establishes the conceptual foundation needed to make that decision responsibly.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the distinctive characteristics and constraints of mobile computing.
2. Describe mobile application and component lifecycles.
3. Distinguish native, mobile web, progressive web, hybrid and cross-platform applications.
4. Explain the architectures of React Native and Flutter.
5. Compare their capabilities, ecosystems, limitations and suitable use cases.
6. Apply performance and decision-analysis methods to framework selection.
7. Identify security, privacy, accessibility and governance responsibilities.

1. The Mobile Computing Environment

Mobile computing combines portable hardware, wireless communication, operating systems, cloud services and context-aware applications. Its defining feature is not merely mobility but changing operational context. A user may move between networks, deny a permission, receive a telephone call, place the application in the background or lose connectivity while completing a transaction.

1.1 Mobile platform layers

A mobile platform usually contains the following layers:

• Hardware: processor, memory, battery, secure hardware and sensors.
• Operating-system kernel: process scheduling, memory management, drivers and security isolation.
• Platform services: notifications, location, media, storage, identity and background execution.
• Application framework: windows, controls, navigation, lifecycle callbacks and accessibility semantics.
• Applications: native or framework-based programs installed or accessed by users.
• Distribution and governance: signing, store review, entitlement management and updates.

Android applications typically use Kotlin or Java with Android SDK and Jetpack libraries. iOS applications commonly use Swift with Apple SDKs such as SwiftUI and UIKit. These native technologies expose platform features directly but require separate implementations when both systems must be supported.

1.2 Resource and interaction constraints

Mobile developers must account for:

• limited battery capacity and thermal headroom;
• memory pressure and possible process reclamation;
• variable bandwidth, latency and connectivity;
• touch, gesture, voice and assistive interaction;
• multiple screen sizes, densities and postures;
• permission-controlled sensors and personal data;
• short, interruption-prone usage sessions;
• store policies and operating-system version fragmentation.

A reliable application therefore saves recoverable state, minimizes unnecessary radio and sensor use, degrades gracefully when offline and requests only permissions that are necessary for a clearly explained purpose.

2. Mobile Application Lifecycles

A lifecycle is the set of states through which an application or component passes from creation to termination. Lifecycle awareness is essential because an application does not control how long its process remains alive.

Figure: Generalized lifecycle with explicit Inactive → Background transition and termination paths from both Background and Suspended states.

The diagram is intentionally platform-neutral. Exact terminology and transitions differ among operating systems, but the main principles are consistent:

• Not running: no application process exists.
• Inactive: the application is visible or transitioning but not accepting normal interaction.
• Foreground active: the user can interact with it.
• Background: the application is not foregrounded but may receive limited execution time.
• Suspended: execution is frozen while state may remain in memory.
• Terminated: the process has ended. Termination may occur without a final callback.

A user interruption can move an active application through an inactive state and into the background. A background process may become suspended. Depending on platform policy and resource pressure, either a background or suspended process may be terminated. Consequently, durable state must be saved before termination becomes possible rather than relying on a shutdown event.

2.1 Android component lifecycles

Android lifecycle behavior is component-oriented. An Activity may receive callbacks such as onCreate, onStart, onResume, onPause, onStop and onDestroy. These callbacks do not guarantee that onDestroy will execute before process death. Developers therefore use saved instance state, persistent storage and lifecycle-aware Jetpack components.

Android also distinguishes services, broadcast receivers and content providers. Background execution is restricted to protect battery life. Deferrable work should generally use mechanisms such as WorkManager rather than an indefinitely running background service.

2.2 iOS application and scene lifecycles

iOS manages application and scene states. A scene may become active, inactive, backgrounded and disconnected. Modern applications can support multiple scenes, so developers should not assume a single global interface instance. Background execution is permitted only for approved modes or bounded tasks, such as location, audio or background refresh under system control.

2.3 Cross-platform lifecycle abstractions

React Native exposes application state through APIs such as AppState, while Flutter supplies lifecycle notifications through AppLifecycleListener and binding observers. These abstractions are useful but do not erase platform rules. Native configuration, permissions and operating-system restrictions still determine what work is allowed.

3. Mobile Application Delivery Models

The word cross-platform is sometimes applied too broadly. The major delivery models differ in where code executes and how interfaces are rendered.

3.1 Native applications

Native development provides direct access to platform APIs, interface controls, diagnostics and release tools. It is often appropriate for applications requiring advanced media processing, low-latency graphics, extensive platform-specific behavior or immediate adoption of new operating-system capabilities.

Its principal cost is duplication. Business rules may be shared through services or multiplatform libraries, but interface and integration code commonly remain platform-specific.

3.2 Mobile web and PWAs

A responsive mobile website runs in a browser and is linked rather than installed through an application store. A PWA adds capabilities such as installability, service-worker caching and web app manifests. PWAs are effective for content, commerce and forms when broad access and rapid deployment are more important than complete device integration.

Support for notifications, background behavior, file access and installation varies by browser and operating system. A PWA should therefore be selected according to verified capability requirements rather than assumed parity with installed applications.

3.3 Hybrid applications

Hybrid applications package HTML, CSS and JavaScript in a native shell containing a WebView. Plugins connect web code to native capabilities. Apache Cordova is a historical example; Ionic can be used with Capacitor for modern hybrid delivery.

Hybrid development can be efficient for web-oriented teams and content-heavy applications. Complex gestures, large animated interfaces and plugin maintenance may present difficulties. Hybrid should not be confused with React Native: React Native does not normally render its interface as HTML in a WebView.

3.4 Cross-platform frameworks

Cross-platform frameworks seek to share application logic and often most interface code while producing installed applications. Shared code does not mean identical behavior. Platform permissions, signing, notifications, deep links and store submissions still require platform-specific understanding.

4. React Native Foundations

React Native applies React's declarative component model to mobile development. Applications are usually written in JavaScript or TypeScript. Components describe the desired interface as a function of properties and state.

4.1 Architecture

Modern React Native's New Architecture includes:

• React renderer: calculates and coordinates interface updates.
• Fabric: renders React component trees into platform host views.
• JavaScript Interface (JSI): enables communication between JavaScript and native or C++ capabilities without depending exclusively on the older serialized bridge.
• TurboModules: provide a modern native-module system with lazy loading and typed specifications.
• Codegen: generates interface code from typed module and component specifications.
• Hermes: an optimized JavaScript engine commonly used for React Native applications.

Earlier React Native versions relied heavily on an asynchronous bridge that serialized messages between JavaScript and native code. The New Architecture reduces associated overhead and enables more direct integration, although execution remains multi-layered and developers must still avoid expensive work on latency-sensitive threads.

React Native ultimately uses native host views for most standard interface elements. This supports familiar platform behavior, although appearance can differ across Android and iOS and may require platform-specific styling.

4.2 Ecosystem and workflow

The ecosystem includes npm packages, React libraries, native modules, Metro bundling and development services such as Expo. Expo can simplify configuration, builds, updates and access to common device APIs. Projects requiring unsupported native functionality can include custom native modules or use development builds.

React Native is particularly attractive when an organization already uses React and TypeScript on the web. Some domain logic, validation rules, API clients and engineering skills can be shared, although web DOM components cannot generally be copied directly into a native interface.

4.3 Strengths and limitations

Strengths include a large JavaScript ecosystem, strong React familiarity, native-view integration and incremental use within existing native applications. Limitations include dependency churn, variation in third-party module quality, occasional native debugging and platform differences in layout or controls. Performance-sensitive animations and computation require careful profiling and may benefit from native, C++ or specialized runtime support.

5. Flutter Foundations

Flutter is a cross-platform UI toolkit centered on the Dart language. It provides a highly integrated framework, rendering engine and development toolchain. In release builds, Dart is generally compiled ahead of time to native machine code on mobile platforms; development mode supports just-in-time execution and hot reload.

5.1 Architecture

Flutter has three broad layers:

• Framework: widgets, gestures, animation, painting and application services written primarily in Dart.
• Engine: text layout, compositing, rasterization and runtime support. Flutter uses engine-managed rendering rather than mapping every widget to a native control.
• Embedder: platform-specific code that connects the engine to operating-system windows, input, lifecycle and services.

Flutter interfaces are composed from widgets. Internally, widget configurations correspond to persistent element structures and render objects where required. This separation allows immutable UI descriptions while preserving state and efficient layout operations.

Flutter typically draws its own controls and pixels, producing strong visual consistency. Platform channels, Dart FFI and plugins provide access to native services. Native platform views can be embedded when necessary, although they may introduce composition, accessibility or performance complexity.

5.2 Ecosystem and workflow

Flutter supplies a cohesive SDK, command-line tools, testing libraries, DevTools and a package repository known as pub.dev. Its hot reload workflow supports rapid interface iteration. Material and Cupertino libraries provide Android-oriented and iOS-oriented design components, but designers must still verify that interactions follow platform expectations.

5.3 Strengths and limitations

Flutter is strong for branded interfaces, custom animation and consistent rendering across platforms. Its integrated toolchain reduces some ecosystem fragmentation. Limitations include the need to learn Dart, potentially larger baseline application artifacts, plugin dependence for platform services and extra work when interfaces must precisely adopt newly introduced native controls.

6. React Native and Flutter Compared

Neither framework is universally superior. A sound choice depends on requirements, team competence, native SDK availability, accessibility targets, expected application lifetime and organizational risk tolerance.

6.1 Performance and frame budgets

Smooth rendering depends on completing necessary work within the display's frame interval. For a refresh frequency f measured in hertz, the theoretical frame interval B in milliseconds is:

Here, B is milliseconds per frame and f is frames per second, numerically equal to hertz for this calculation. The relationship assumes evenly spaced refreshes. It is a deadline, not a guarantee that the application receives the entire interval; the operating system, rendering pipeline and other work consume part of it.

At 60 Hz:

At 120 Hz:

Thus, an operation taking 12 ms may fit within a theoretical 60 Hz interval but cannot fit within a single 120 Hz interval. Actual profiling—not framework reputation—must determine whether decoding, layout, JavaScript or Dart work, native calls, compositing or GPU rasterization is causing missed frames.

6.2 A framework selection model

A weighted decision model can make assumptions explicit. Let w_i be the non-negative weight of criterion i, with ∑w_i = 1, and let s_ij be the score of option j on criterion i. The total score is:

The scores must use the same scale. The model is appropriate for structured comparison, but it does not make ordinal judgments objectively measurable. Results should be tested by changing uncertain weights.

Suppose a TypeScript-oriented organization uses the following 1–5 scores:

For React Native:

For Flutter:

Under these stated assumptions, React Native ranks higher. A design-led organization assigning greater weight to visual consistency and less to existing TypeScript skills could obtain a different result. A proof-of-concept should validate high-risk assumptions before commitment.

7. Applied Case: Offline Field Inspection System

Background

This is an illustrative fictional case. Northstar Utilities employs technicians who inspect remote equipment using Android and iOS devices. Its web team already uses React and TypeScript.

Problem

The proposed application must capture forms, photographs, signatures and GPS coordinates; operate for hours without connectivity; synchronize safely later; and integrate with a vendor's native Bluetooth diagnostic SDK. Inspection records may contain employee identifiers and infrastructure location data.

Analysis

A PWA offers easy deployment but cannot be assumed to provide consistent background synchronization and Bluetooth SDK support on all target devices. A hybrid application would reuse web code but introduces WebView and plugin risks for camera-heavy workflows. Separate native applications offer maximum control but require two interface teams.

React Native and Flutter can both implement offline storage, camera capture and queued synchronization. Flutter offers strong visual consistency. React Native has two contextual advantages: the team already possesses TypeScript and React expertise, and the Bluetooth vendor supplies maintained native Android and iOS SDKs that can be exposed through typed native modules.

Approach

Northstar selects React Native after a proof-of-concept validates Bluetooth communication, accessibility and recovery from process termination. The architecture includes:

1. a local encrypted database as the working source of truth;
2. immutable identifiers for queued inspections;
3. explicit synchronization states such as pending, uploading, confirmed and failed;
4. idempotent server operations so retries do not create duplicate records;
5. native modules wrapping the Bluetooth SDKs;
6. lifecycle handling that persists drafts before backgrounding;
7. least-privilege requests for camera, Bluetooth and location access;
8. automated unit, integration, accessibility and device tests.

Outcome

The pilot demonstrates that technicians can complete and recover inspections after network loss or operating-system process reclamation. The organization retains native specialists for Bluetooth modules, signing and release troubleshooting. The result illustrates that cross-platform development reduces duplication but does not eliminate native engineering.

Learning Points

• Framework choice should follow validated constraints rather than popularity.
• Offline operation requires a data architecture, not merely a connectivity check.
• Lifecycle testing must include forced termination and restoration.
• Sensitive location and workforce data require governance from the design stage.

8. Quality, Security and Governance

8.1 Testing strategy

A professional mobile test strategy combines:

• unit tests for domain logic;
• component or widget tests for interface behavior;
• integration tests for storage and platform plugins;
• end-to-end tests on representative physical devices;
• accessibility testing with screen readers, scaling and alternative input;
• performance profiling under realistic data and thermal conditions;
• lifecycle, network-loss and permission-denial testing.

Emulators and simulators accelerate development but do not fully reproduce camera behavior, radio conditions, thermal throttling or vendor hardware.

8.2 Security and privacy

Mobile security should include secure transport, authenticated APIs, careful token handling, dependency review and protection of sensitive local data. Ordinary preference storage is not suitable for secrets. Platform secure-storage services can protect cryptographic keys, although compromised devices remain a risk.

Permissions should be requested in context and only when needed. Developers should minimize collection, define retention periods and provide meaningful explanations. Logs, crash reports and analytics must not unintentionally expose credentials, precise locations or personal records.

Applications may be subject to privacy and sector-specific regulation, contractual requirements, children's protections or accessibility law. Compliance is not achieved merely by adding a consent dialog; it requires lawful purpose, data minimization, security controls, user rights and accountable processing.

8.3 Supply-chain and update governance

Cross-platform applications depend on packages, plugins, build tools and native SDKs. Teams should pin reviewed versions, monitor vulnerabilities, verify maintainer quality, document licenses and test upgrades. Over-the-air delivery mechanisms must respect platform policies and should not be used to bypass review requirements for prohibited functional changes.

9. Contemporary Developments and Best Practices

React Native continues its transition toward Fabric, TurboModules, JSI and typed code generation. Flutter continues to improve engine performance, rendering consistency and support across mobile, web and desktop targets. Both ecosystems increasingly support on-device machine learning through native libraries, plugins or platform services.

Generative AI can assist with prototypes, tests and documentation, but generated code may contain insecure dependencies, obsolete APIs or incorrect lifecycle assumptions. Human review, testing and license checks remain necessary.

Recommended practices include:

1. Build a proof-of-concept around the riskiest native capability.
2. Keep business rules separate from interface and platform adapters.
3. Treat offline and restoration behavior as architectural requirements.
4. Profile on representative low- and high-end physical devices.
5. Follow platform-specific interaction and accessibility conventions.
6. Minimize dependencies and plan framework upgrades.
7. Preserve native expertise for integration, security and releases.
8. Evaluate total lifecycle cost rather than initial code reuse alone.

Chapter Summary

Mobile applications operate in a constrained, interruption-prone and policy-governed environment. Their processes may move among inactive, foreground, background and suspended states, and the operating system may terminate background or suspended processes. Reliable software therefore persists recoverable state and respects platform limits.

Native, web, PWA, hybrid and cross-platform models provide different combinations of reach, integration, performance and maintainability. React Native uses React with JavaScript or TypeScript, native host views and a modern architecture based on Fabric, JSI and TurboModules. Flutter uses Dart and an engine-managed rendering model that supports consistent, highly customized interfaces.

Framework selection must consider native integration, team skills, user experience, accessibility, performance and long-term maintenance. Quantitative decision models and frame-budget calculations clarify assumptions, but prototypes and device measurements remain essential. Security, privacy, accessibility, dependency governance and lifecycle testing are core engineering responsibilities rather than optional additions.

Key Terms

Application lifecycle: The states and transitions experienced by an application or component during execution.

Background execution: Limited processing performed while an application is not in the foreground.

Cross-platform framework: A framework that shares substantial code across multiple operating systems.

Fabric: React Native's modern rendering system for coordinating React interfaces with native host views.

Flutter: A Dart-based cross-platform UI toolkit using an engine-managed rendering model.

Hermes: A JavaScript engine optimized for applications such as React Native.

Hybrid application: A native container that primarily presents a web interface through a WebView.

Idempotency: The property that repeated execution of an operation has the same intended effect as one execution.

JSI: React Native's JavaScript Interface for communication with native and C++ capabilities.

Mobile web application: An application delivered and executed through a mobile browser.

Native application: Software developed directly with a target platform's languages, SDKs and UI frameworks.

Platform channel: A Flutter mechanism for communication between Dart and platform-specific code.

Progressive web app: A web application enhanced with features such as installability and offline caching.

React Native: A React-based framework for building installed mobile applications with JavaScript or TypeScript.

Rendering engine: Software responsible for layout, compositing and drawing interface output.

Suspension: A lifecycle condition in which application execution is frozen while state may remain in memory.

TurboModule: A React Native native module implemented through the New Architecture.

WebView: A native component that embeds a web-rendering environment inside an application.

Review Questions

Short Answer Questions

1. Why can a mobile application not rely on receiving a termination callback?
2. What distinguishes a hybrid application from a React Native application?
3. What role does JSI perform in modern React Native?
4. Why does Flutter generally provide strong visual consistency across platforms?
5. What is the theoretical frame interval for a 60 Hz display?

Long Answer Questions

1. Explain the mobile application lifecycle and its implications for state persistence.
2. Compare native, PWA, hybrid and cross-platform delivery models.
3. Describe React Native's New Architecture, including Fabric, JSI and TurboModules.
4. Explain Flutter's framework, engine and embedder layers.
5. Evaluate the major technical and organizational factors involved in choosing between React Native and Flutter.

Analytical / Application Questions

1. A banking application requires advanced biometric integration, strict accessibility, offline transaction drafts and rapid adoption of new platform security APIs. Develop and justify a delivery-model recommendation.
2. Construct a weighted decision model for React Native and Flutter using criteria appropriate to a media-streaming application. Explain the limitations of your scoring method.
3. Design a lifecycle and recovery test plan for a mobile form that captures photographs while connectivity is intermittent.

Multiple Choice Questions with Answers

Question 1

Which statement best explains why mobile applications should save recoverable state before termination?

A. Operating systems guarantee a final termination callback only for native applications.

B. A background or suspended process may be terminated without a final callback.

C. Cross-platform frameworks automatically delete all background state.

D. Application stores prohibit saving state during shutdown.

Correct Answer: B. A background or suspended process may be terminated without a final callback.

Question 2

Which delivery model primarily renders HTML, CSS and JavaScript inside a native WebView container?

A. Native application

B. Progressive web app

C. Hybrid application

D. React Native application

Correct Answer: C. Hybrid application

Question 3

What is the principal role of Fabric in modern React Native?

A. It compiles Dart code ahead of time.

B. It coordinates rendering of React interfaces into native host views.

C. It provides browser service-worker caching.

D. It replaces mobile operating-system permission systems.

Correct Answer: B. It coordinates rendering of React interfaces into native host views.

Question 4

Which feature most directly contributes to Flutter's visual consistency across platforms?

A. Every Flutter widget is an HTML element.

B. Flutter delegates all drawing to standard native controls.

C. Flutter's engine renders most interface pixels itself.

D. Flutter requires identical operating-system versions.

Correct Answer: C. Flutter's engine renders most interface pixels itself.

Question 5

What is the theoretical frame interval of a 120 Hz display?

A. 4.17 ms

B. 8.33 ms

C. 16.67 ms

D. 120 ms

Correct Answer: B. 8.33 ms

Question 6

Which mechanism is recommended for deferrable, reliable background work on Android?

A. An indefinitely running foreground Activity

B. A browser service worker in every application

C. WorkManager

D. A Flutter render object

Correct Answer: C. WorkManager

Question 7

In the chapter's weighted framework example, why did React Native receive the higher total score?

A. It is universally faster than Flutter.

B. The stated weights favored native SDK integration and existing TypeScript skills.

C. Flutter cannot access native SDKs.

D. React Native requires no platform-specific engineering.

Correct Answer: B. The stated weights favored native SDK integration and existing TypeScript skills.

Question 8

Which practice best supports reliable offline synchronization?

A. Keeping unsent data only in volatile memory

B. Retrying non-idempotent requests without identifiers

C. Using persistent queues and idempotent server operations

D. Disabling lifecycle state restoration

Correct Answer: C. Using persistent queues and idempotent server operations

Question 9

Which statement about PWAs is most accurate?

A. They provide identical native capabilities on every mobile platform.

B. They cannot operate offline under any circumstances.

C. Their capabilities can vary by browser and operating system.

D. They must always be distributed through a native application store.

Correct Answer: C. Their capabilities can vary by browser and operating system.

Question 10

Which action reflects least-privilege mobile security?

A. Requesting every device permission at first launch

B. Storing authentication secrets in ordinary preference storage

C. Requesting only necessary permissions when their purpose becomes relevant

D. Writing precise location data to diagnostic logs by default

Correct Answer: C. Requesting only necessary permissions when their purpose becomes relevant