Mobile App Development (eBook)

Software Development (2025 Edition) An Academic Course Textbook

Azhar Ul Haque Sario (Autor)

eBook Download: EPUB

2025
228 Seiten
Azhar Sario Hungary (Verlag)
978-3-384-75894-1 (ISBN)

Infos

Master Mobile App Development in 2025 - The Only Textbook That Actually Prepares You for Real Jobs

This is the mobile development book I wish existed when I started teaching. It's built exactly like the courses at Stanford, MIT, Berkeley, and CMU - but updated to November 2025 reality. You get native iOS with Swift 6 + SwiftUI, native Android with Kotlin 2.0 + Jetpack Compose, cross-platform React Native (new architecture) and Flutter 3.24+, plus modern PWAs that finally feel like real apps. Every chapter starts with 2025 market data (actual App Store made -$102B, Play Store -$48B, iOS still owns premium revenue). You learn strategic platform decisions before writing a single line of code. Then you go deep: Clean Architecture, MVI/MVVM, modularization, gRPC + GraphQL, Core ML + Gemini Nano on-device AI, ARKit/ARCore, Vision Pro development, offline-first patterns, biometric security, CI/CD with Fastlane + GitHub Actions, and proper testing pyramids that big companies actually use. Every section ends with real case studies (Airbnb's KMP migration, Google Play Store's Compose rewrite, Duolingo's 200+ A/B tests, Be My Eyes AI integration) and explicit 'Job Skill' boxes that tell you exactly what recruiters want when they say 'Senior Mobile Engineer' or 'Mobile Solutions Architect' in 2025.

Most mobile books are either five years out of date or just shallow tutorials. This one is different because it's brutally current, ruthlessly practical, and academically honest. I wrote it after noticing every existing textbook was missing the same things: real 2025 economics, proper decision frameworks, enterprise architecture patterns, on-device AI, spatial computing, and direct mapping to six-figure job requirements. So I built the missing book myself. Short, dense modules you can teach or learn in any order. No filler. No recycled 2020 content. Just the stuff that actually gets you hired at FAANG-tier companies or lets you ship serious apps as an indie.

Copyright © 2025 Azhar ul Haque Sario - Independently produced textbook. No affiliation with Stanford, MIT, Berkeley, CMU, Apple, Google, or any referenced organization. All company/course references are nominative fair use for educational purposes.

Textauszug

Part 2: Native Platform Development: iOS (Academic Basis: Stanford CS193p)

 

iOS Development Fundamentals with Swift 6 and SwiftUI

 

4.1 The Swift 6 Language: Data-Race Safety and the New Concurrency Model

 

The Reality of the "Sea of Concurrency" If you have been coding for iOS since the Objective-C days, you know the terror of a "Heisenbug"—a crash that happens only when the stars align, usually because two threads tried to write to the same variable at the exact same microsecond. Swift 6 isn't just an update; it is a fundamental philosophical shift in how we handle this chaos. It moves us from "trusting the developer" to "trusting the compiler."

 

In the 2024/2025 ecosystem, Swift 6 has effectively solved the "shared mutable state" problem, but it demands you learn a new vocabulary. The headline feature here is Data-Race Safety, which is no longer a suggestion but a mandate if you are running in the new language mode.

 

The "Strict Concurrency" Enforcement Before Swift 6, we relied on documentation and hope. We would write comments like // Only access this on the main thread. Now, the compiler acts as a strict gatekeeper. It uses a concept called Isolation Domains. Think of these as secure rooms.

 

 

The Main Actor (@MainActor): This is the VIP room (the UI thread).

 

Actors: These are private rooms where data is locked up. Only one person (thread) enters at a time.

 

Non-Isolated: The public hallway.

 

The mechanism enforcing this is the Sendable protocol. This is the biggest hurdle I see developers trip over in 2025. A type is Sendable if it is safe to pass from one isolation domain to another. Value types (structs, enums) are usually implicitly Sendable because they are copied. Reference types (classes) are the danger zone.

 

The Compiler as Your Pair Programmer In Swift 5.10, we had the -strict-concurrency=complete flag, which was like a gentle warning light. in Swift 6, that light turns into a roadblock. For example, consider a classic singleton pattern used for caching user data.

 

The Old Way (Pre-Swift 6): You might have a class UserCache with a dictionary inside. If a background thread updates the cache while the main thread reads it for the UI, you get a crash.

 

The Swift 6 Way: The compiler statically analyzes this flow. If you try to pass a non-Sendable closure or object between threads, the build fails. You are forced to refactor that class into an actor.

 

Technical Insight: An actor automatically serializes access to its mutable state. It’s like a bank teller; no matter how many people get in line (threads), the teller only handles one transaction at a time.

 

Migration Pain Points From my fieldwork migrating mid-sized codebases, the transition to Swift 6 isn't free. You will encounter "viral" concurrency requirements. If you mark a function async, its caller must be async, and so on. The nonisolated keyword becomes your escape hatch. It allows you to tell the compiler, "I know this function is inside an actor, but it doesn't touch any internal state, so let it run freely on the thread pool."

 

4.2 The Declarative UI Paradigm: SwiftUI vs. UIKit and the 2025 Job Market

 

The bifurcated Market: "Greenfield" vs. "Brownfield" Let’s cut through the hype. If you go to Twitter (X) or Reddit, you’ll hear that "UIKit is dead." If you go to a job interview at a Fortune 500 bank in London or New York in 2025, you will find UIKit is very much alive.

 

The market has split into two distinct realities:

 

The 90% Greenfield Reality: If you are building a new app (Greenfield) for a startup or a personal project, you are using SwiftUI. It is roughly 3x faster to write. A list view that took 50 lines of UITableViewDataSource boilerplate in UIKit is now 5 lines in SwiftUI.

 

The 80% Enterprise Reality: Large, legacy apps (Brownfield)—think banking, airlines, healthcare—are still 60-80% UIKit. They cannot afford to rewrite 500,000 lines of code just to be "modern."

 

The "Hybrid" Developer is King The most lucrative skill in 2025 is Interoperability. Companies are desperate for developers who can maintain the old UIKit "diesel engine" while bolting on new SwiftUI "electric motors."

 

The Glue: UIHostingController and UIViewRepresentable You need to master the bridge.

 

Embedding New in Old: You are asked to build a new "Credit Score" card. You build it in SwiftUI because it’s pretty and interactive. You then wrap it in a UIHostingController to display it inside the existing UIKit navigation stack.

 

Embedding Old in New: You are building a SwiftUI app, but you need a complex specific Map feature that SwiftUI’s Map view doesn't support yet. You wrap the UIKit MKMapView in a UIViewRepresentable struct.

 

Performance Nuances SwiftUI is "Declarative"—you tell the system what you want (e.g., "I want a red text"). The system figures out how to render it. This is great until it isn't. I have seen performance "hitches" in SwiftUI when handling massive datasets because the diffing algorithm (computing what changed) gets overwhelmed. UIKit is "Imperative"—you manually control the views. For ultra-high-performance scrolling (like a social media feed with autoplaying video), heavily optimized UIKit UICollectionView setups still often beat SwiftUI in raw frame-rate stability.

 

Market Stat: In 2025, job postings for "Senior iOS Engineer" often list SwiftUI as a requirement but UIKit as a "dealbreaker." If you don't know the view lifecycle (viewDidLoad, viewDidAppear), you are a liability to a mature team.

 

4.3 Native Tooling: The Xcode 16 Developer Workflow, Previews, and Instruments

 

The Tight Feedback Loop The biggest productivity killer in iOS development used to be the "Build and Run" cycle. You change a color, wait 15 seconds for the simulator to launch, navigate to the screen, and check. In Xcode 16, the workflow centers on SwiftUI Previews. With the new #Preview macro (introduced in Swift 5.9 and perfected in Xcode 16), you get an interactive canvas. You can simulate different states (Light Mode, Dark Mode, Large Text, German language) simultaneously side-by-side without running the full app.

 

Profiling with Instruments Writing code is easy; writing fast code is hard. Instruments is the X-ray machine for your app. In 2025, memory leaks are still a plague. The "Leaks" instrument is standard, but the SwiftUI View Body profiler is critical. It tells you how often your views are redrawing. A common mistake is accidentally causing a view to redraw 60 times a second because of a changing timestamp, killing battery life.

 

The AI Era: Core ML Performance Reports This is the cutting edge. As we move into the "AI Phone" era, developers are shipping models on-device. Xcode 16 integrates directly with the Apple Neural Engine (ANE). When you drag a Core ML model into Xcode, you now get a Performance Report.

 

Latency: How many milliseconds does inference take?

 

Compute Unit: Is it running on the CPU (slow), GPU (fast but hungry), or ANE (fast and efficient)?

 

Quantization: Xcode 16 helps you compress models. You might see a report saying, "Converting this model from Float32 to Int8 reduced size by 75% with only 1% loss in accuracy."

 

 

Case Study in Workflow Imagine you are building a photo filter app.

 

Code: You write the UI in SwiftUI using the #Preview canvas to tweak the slider layout instantly.

 

Profile: You feel a stutter when the slider moves. You open Instruments and see the "Hang" trace.

 

Diagnose: The Core ML report shows your filter model is running on the GPU, blocking the main thread.

 

Fix: You configure the model to use the ANE (Neural Engine) and dispatch it to a background actor. The stutter vanishes.

 

4.4 Case Study: Migrating a Large-Scale App (Airbnb, Asana) to a Modern SwiftUI Stack

 

The "Ship of Theseus" Problem You cannot simply "rewrite" an app like Airbnb or Asana. These apps have millions of lines of code and generate billions in revenue. Stopping for six months to rewrite in SwiftUI is business suicide. The strategy is Brownfield Modernization.

 

Airbnb: The "Native" Pivot Airbnb is famous for trying React Native and then abandoning it for native Swift. Their migration wasn't a "Big Bang." It was a slow, methodical takeover.

 

Module-by-Module: They broke their monolithic app into over 1,500 modules. This allowed them to compile smaller chunks of code independently.

 

The Stats: When moving to Swift, they initially saw a 2.2MB increase in their app bundle size (IPA) due to Swift libraries (back when Swift wasn't ABI stable). They also saw a 16-second increase in debug build times. This is the reality of migration—it often gets worse before it gets better.

 

The Strategy: They built new features (like "Experiences") in Swift while leaving the core "Booking" flow in Objective-C/UIKit, slowly strangling the old code out over...

Produkt-Details

• Erscheint lt. Verlag: 19.11.2025
• Reihe/Serie: Software Development
• Sprache: englisch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Flutter React Native • iOS Android Cross Platform PWA • Jetpack Compose Kotlin • Mobile App Development 2025 • Mobile Architecture MVVM MVI • On Device AI Core ML Gemini Nano • SwiftUI Swift 6
• ISBN-10: 3-384-75894-3 / 3384758943
• ISBN-13: 978-3-384-75894-1 / 9783384758941