Case Studies of Popular Operating Systems

Learning Objectives

By the end of this page, you should be able to:

• Identify the kernel architecture (monolithic, hybrid, XNU/Mach-based) used by Windows, macOS, and Linux, and explain what that architecture implies.
• Explain why Android and iOS are not "new" operating systems from scratch, but built on existing kernels (Linux and XNU respectively).
• Compare how each OS approaches process/app lifecycle management, especially around background execution on mobile.
• Explain the tradeoffs of open-source (Linux) vs. proprietary (Windows, macOS, iOS) development models.
• Relate concepts from earlier OS topics (scheduling, virtual memory, process states) to concrete behavior in a real OS.

Quick Answer

Every general-purpose OS solves the same core problems — process scheduling, memory management, file systems, security — but the five dominant operating systems (Windows, macOS, Linux, Android, iOS) make different architectural choices shaped by their history and target hardware. Windows uses a hybrid kernel built for broad hardware compatibility; macOS and iOS share the XNU hybrid kernel (Mach + BSD) built for Apple's controlled hardware ecosystem; Linux is a monolithic, open-source kernel that scales from embedded devices to supercomputers; Android runs on the Linux kernel but adds its own runtime (ART) and app lifecycle model on top. This matters because these aren't just trivia — the kernel architecture and design philosophy behind each OS explains real, observable behavior: why Android apps get killed in the background, why macOS security models differ from Windows, and why Linux dominates servers while remaining niche on desktops.

Kernel Architecture: The Foundational Choice

An OS's kernel is the core software that manages hardware, memory, and processes with the highest privilege level. The architectural choice made decades ago still shapes each OS today.

Linux uses a monolithic kernel: the scheduler, memory manager, file systems, and device drivers all run together in kernel space (privileged mode) for performance, though loadable kernel modules let you add drivers without recompiling the whole kernel. This is a direct descendant of the design principles covered in the CPU scheduling and memory management chapters — Linux's CFS scheduler and virtual memory subsystem are textbook examples running in production.

Windows uses a hybrid kernel: most core services run in kernel mode for performance, but it's structured in layers (the Hardware Abstraction Layer, kernel, executive services) that isolate hardware-specific code and provide some structure closer to a microkernel design without the full performance cost of message-passing between fully separated servers.

macOS and iOS both build on XNU, Apple's hybrid kernel combining a Mach microkernel core (message-passing, memory management, scheduling) with BSD components (Unix process model, POSIX APIs, networking stack) layered on top. This is why macOS supports standard Unix tools and behaves like a Unix system in a terminal, while still having Mach-level abstractions underneath.

Android runs directly on the Linux kernel — Google didn't write a new kernel; they adapted Linux and added the Android Runtime (ART) (which compiles app bytecode ahead-of-time/just-in-time) plus Android-specific subsystems for app lifecycle, permissions, and hardware abstraction (the Hardware Abstraction Layer, or HAL) suited to mobile constraints like battery life.

Process and App Lifecycle: Desktop vs. Mobile

Desktop OSes (Windows, macOS, Linux) generally let user-facing processes run until the user or the process itself decides to quit — the five-state process model (New/Ready/Running/Waiting/Terminated) applies fairly directly, and background apps mostly just... keep running, competing for CPU via the normal scheduler.

Mobile OSes (Android, iOS) impose a much stricter app lifecycle on top of the underlying process model, because battery life and limited RAM are first-class constraints:

• Android apps move through lifecycle states (Created, Started, Resumed, Paused, Stopped, Destroyed) managed by the Activity Manager, and the OS aggressively kills backgrounded apps' processes under memory pressure using an "OOM killer"-like priority scheme — but preserves enough state (via onSaveInstanceState) that the app can appear to "resume" seamlessly when relaunched.
• iOS is even stricter: apps typically get only a few seconds to finish work after being backgrounded (with limited exceptions for background audio, location, or explicitly requested background tasks) before being suspended, and can be terminated by the OS at any time without warning if memory is needed elsewhere.

Why it matters: This is a direct, practical consequence of the process/memory-management tradeoffs from earlier chapters — mobile OSes bias heavily toward aggressive resource reclamation because unlike a desktop with a power supply and expandable RAM, a phone has a fixed battery and fixed RAM that must serve many apps.

Common misunderstanding: Students often assume a "closed" mobile app that gets reopened later resumes because it was still "running in the background" the whole time. In most cases the process was actually killed by the OS, and what looks like resuming is the app restoring saved state on a fresh process launch — the lifecycle callbacks exist precisely to make this reconstruction seamless to the user.

Memory Management Choices in Practice

All five OSes use virtual memory and paging (concepts covered in Memory Management), but differ in specifics:

• Windows uses a working-set-based approach with a systemwide page file, and historically has been criticized for heavier baseline memory usage due to background services.
• Linux uses demand paging with an aggressive page cache (using "free" RAM to cache disk data, reclaimed instantly when applications need it) — this is why Linux systems often show almost all RAM "used" even when idle; it's mostly reclaimable cache, not a memory problem.
• macOS uses a similar demand-paging model with compressed memory (compressing inactive pages in RAM instead of writing them to disk swap when possible) to reduce disk I/O and improve responsiveness on SSD-constrained devices.
• Android and iOS, given constrained RAM, rely much more heavily on process termination (killing a backgrounded app entirely) rather than swapping pages to slow storage, since flash storage wear and battery cost make disk-based swapping less attractive than on desktops (though Android has since added zram-based compressed swap).

Security and Permission Models

• Windows relies on User Account Control (UAC), NTFS permissions, and Windows Defender integrated at the OS level, historically the biggest target for malware given its desktop market dominance.
• macOS uses System Integrity Protection (SIP), sandboxing for App Store apps, and Gatekeeper (code-signing verification) to restrict what unsigned/unverified software can do.
• Linux relies on discretionary Unix permissions (user/group/other) plus optional mandatory access control frameworks (SELinux, AppArmor) — flexible but requiring deliberate configuration to be maximally secure.
• Android enforces per-app sandboxing (each app runs as its own Linux user ID) plus a runtime permission model (introduced from Android 6.0 onward) where users grant sensitive permissions (camera, location) individually.
• iOS takes the strictest approach: mandatory App Store review, strong app sandboxing, and no user-facing root access on production devices, trading flexibility for tighter control over what any app can do.

Real-world example: A Linux server administrator can grant a program elevated capabilities without full root access using fine-grained Linux capabilities, something neither iOS nor default Android configurations expose to end users at all — reflecting Linux's server/power-user heritage versus mobile OSes' consumer-safety-first design.

Key Terms

Term	Definition	Context/Related
Kernel	Core OS software managing hardware, memory, and processes at the highest privilege level	Monolithic (Linux), hybrid (Windows, XNU)
Monolithic Kernel	Kernel where scheduler, memory manager, drivers, and file systems all run together in kernel space	Used by Linux; performance-favoring design
Hybrid Kernel	Kernel blending monolithic performance with some microkernel-style separation	Used by Windows and XNU (macOS/iOS)
XNU	Apple's hybrid kernel combining a Mach microkernel core with BSD Unix components	Powers both macOS and iOS
Android Runtime (ART)	Android's application runtime that compiles app bytecode ahead-of-time/just-in-time	Replaced the earlier Dalvik VM
App Lifecycle	The set of states (created, resumed, paused, stopped, destroyed) mobile OSes impose on apps	Distinct from the general process-state model; adds OS-driven termination
Page Cache	RAM used to cache recently accessed disk data, reclaimed on demand	Explains why Linux often shows "high" memory usage while idle
Memory Compression	Compressing inactive memory pages in RAM instead of swapping to disk	Used by macOS (and Android via zram) to reduce disk I/O
Sandboxing	Restricting an app's access to system resources and other apps' data	Central to Android and iOS security models
SELinux/AppArmor	Mandatory access control frameworks that supplement Linux's default discretionary permissions	Optional hardening layer on top of standard Unix permissions

Common Mistakes

1. Misconception: "Android and Linux are basically the same operating system." Why it's wrong: While Android uses the Linux kernel, it does not include the GNU userland tools, standard Linux init system, or X11/Wayland display stack that define a typical Linux distribution — Android replaces nearly the entire userspace with its own runtime (ART), app framework, and UI stack. Correct explanation: Android is best described as "built on the Linux kernel" rather than "a Linux distribution" in the traditional sense (like Ubuntu or Fedora) — it shares the kernel's process/memory management and drivers model but diverges completely above that layer.

2. Misconception: "A backgrounded mobile app that reopens instantly must have been running the whole time." Why it's wrong: Both Android and iOS routinely terminate backgrounded app processes entirely to reclaim memory; what feels like "resuming" is frequently the app being relaunched fresh and restoring previously saved UI state. Correct explanation: Mobile app lifecycle frameworks provide explicit save/restore callbacks (e.g., onSaveInstanceState on Android) precisely because the OS assumes it may need to kill the process at any time — the illusion of continuity is a deliberate design feature, not evidence the process survived.

3. Misconception: "Open-source (Linux) means less secure than proprietary systems (Windows, macOS) because anyone can see the code and find vulnerabilities." Why it's wrong: Open-source visibility cuts both ways — attackers can read the code, but so can a much larger pool of independent security researchers, and vulnerabilities can be patched without waiting on a single vendor's release schedule. Correct explanation: Security depends far more on how quickly vulnerabilities are found and patched, how the software is configured, and its attack surface/exposure than on whether the source is open — Linux dominates security-critical infrastructure like servers and supercomputers precisely because of its transparency and rapid community patching, not despite it.

Comparison and Connections

OS	Kernel Type	Primary Domain	Key Design Principle
Windows	Hybrid	Desktop/Laptop, gaming, enterprise	Broad hardware compatibility, backward compatibility
macOS	Hybrid (XNU: Mach + BSD)	Desktop/Laptop (Apple hardware only)	Integrated hardware/software experience
Linux	Monolithic	Servers, supercomputers, embedded, cloud	Open-source flexibility and customizability
Android	Modified Linux kernel + ART	Smartphones/tablets	Mobile-optimized lifecycle and battery management
iOS	XNU (shared with macOS)	Apple smartphones/tablets	Strict sandboxing and curated app ecosystem

Dimension	Desktop OSes (Windows/macOS/Linux)	Mobile OSes (Android/iOS)
App lifecycle	Runs until user/process quits	OS actively suspends/kills backgrounded apps
Memory strategy	Paging to disk/swap, page cache	Prefers process termination over swap (though Android added zram)
Root/admin access	Generally available to the user	Restricted or unavailable in production configurations
Update model	User/IT-controlled, staggered	Centralized app stores, OS-vendor-controlled rollout

Practice Questions

Recall

1. What kernel architecture does Linux use, and what does that imply about where device drivers run? Answer guidance: Linux uses a monolithic kernel, so device drivers (along with the scheduler, memory manager, and file systems) run in kernel space at the highest privilege level, though they can be loaded/unloaded as kernel modules without recompiling the whole kernel.

2. What kernel do both macOS and iOS share, and what two components make it up? Answer guidance: Both share XNU, which combines a Mach microkernel core (message-passing, memory management, scheduling) with BSD components (Unix process model, POSIX APIs, networking).

Understanding

3. Why do mobile OSes (Android, iOS) impose a stricter app lifecycle than desktop OSes? Answer guidance: Phones have fixed, limited battery life and RAM shared across many apps a user might switch between constantly, so the OS must aggressively reclaim resources from backgrounded apps to keep the foreground app responsive and preserve battery — a tradeoff desktops with continuous power and expandable RAM don't need to make as aggressively.

4. Why is it inaccurate to call Android "a Linux distribution" in the same sense as Ubuntu? Answer guidance: Android only shares the Linux kernel; it replaces the standard GNU userland, init system, and display server stack with entirely different components (ART runtime, its own app framework and UI stack), whereas a traditional Linux distribution keeps the conventional Unix/GNU userland on top of the same kernel.

Application

5. A developer notices their Linux server reports 95% RAM "used" even though no heavy applications are running. Should they be worried? Why or why not? Answer guidance: Generally not — Linux aggressively uses otherwise-idle RAM as page cache to speed up disk access, and this cached memory is instantly reclaimable the moment an application actually needs it. The relevant number to check is "available" memory (which accounts for reclaimable cache), not raw "used" memory.

6. A user complains that their iOS podcast app stops downloading episodes a minute after they switch to another app, while their Android phone continues downloading for longer. Explain this difference using app lifecycle concepts. Answer guidance: iOS enforces a strict background execution model — apps get only a short grace period after backgrounding before being suspended unless they use a specific background mode API (e.g., background audio/download tasks) that the OS explicitly grants continued execution for. Android's process/lifecycle model has historically been comparatively more permissive about background execution (though it has tightened over versions with Doze mode and background limits), which is why background tasks can persist longer by default before the OS intervenes.

Analysis

7. Compare the security philosophies of Linux and iOS, explaining why each is appropriate for its primary use case rather than one being objectively "more secure." Answer guidance: Linux favors flexible, discretionary Unix permissions with optional mandatory access control (SELinux/AppArmor) that a knowledgeable administrator can configure precisely — appropriate for servers/experts who need fine-grained control and are responsible for their own configuration. iOS favors mandatory, inflexible sandboxing with curated App Store review and no root access — appropriate for a mass consumer audience who cannot be expected to configure security themselves and benefits more from an OS-enforced baseline. Neither is "more secure" in the abstract; each matches its threat model and user population.

8. A company deciding on server infrastructure is choosing between Linux and Windows Server. Using the kernel architecture and licensing model differences discussed, what tradeoffs should they weigh beyond pure feature checklists? Answer guidance: Linux offers no licensing fees, a monolithic kernel with mature, highly tunable performance characteristics for server workloads, an enormous open-source ecosystem, and rapid community-driven security patching — but requires more in-house expertise to configure and secure well. Windows Server offers tighter integration with Microsoft's enterprise ecosystem (Active Directory, .NET), a hybrid kernel with vendor support contracts, and often better compatibility with proprietary enterprise software — at the cost of licensing fees and being tied to a single vendor's release/patch cadence. The right choice depends on in-house expertise, existing software dependencies, and budget for licensing vs. staffing.

FAQ

Q: Why doesn't Apple let macOS run on non-Apple hardware the way Windows and Linux run on almost any PC? A: Apple's business model and XNU's design both assume tight integration between hardware and software (custom silicon, drivers, security chips like the T2/Apple Silicon Secure Enclave), which lets them optimize performance and security in ways that are much harder to guarantee across arbitrary third-party hardware configurations — the opposite tradeoff from Windows, which prioritizes running on the widest possible range of hardware.

Q: If Linux powers most of the internet's servers, why doesn't it have more desktop market share? A: Server workloads value stability, configurability, and cost (no licensing fees), which favors Linux; desktop adoption is driven heavily by application/software compatibility (commercial software, games), hardware driver support out-of-the-box, and switching costs for average users already familiar with Windows/macOS — factors where Linux desktop distributions have historically lagged despite technical merit.

Q: Is Android's use of the Linux kernel why Android has so many different versions running on different phones (fragmentation)? A: Not directly because of the kernel itself, but because phone manufacturers customize the Android layers above the kernel and are responsible for pushing updates to their specific hardware, so update timelines vary by manufacturer and even by carrier — a very different model from iOS, where Apple controls both hardware and software and can push updates to all supported devices simultaneously.

Q: Why do iOS apps feel more "consistent" across different apps than Android apps sometimes do? A: Apple's stricter App Store review process, tighter Human Interface Guidelines enforcement, and singular hardware target (Apple-designed devices only) create more consistency pressure than Android's more open app distribution model and vastly more diverse hardware/manufacturer ecosystem, where OEMs often add their own UI customizations on top of stock Android.

Q: Does using the same kernel (XNU) mean macOS and iOS apps can just run on each other's OS unmodified? A: No — while they share the underlying kernel, the frameworks, UI toolkits (AppKit vs. UIKit, though increasingly unified via Catalyst/SwiftUI), and app packaging formats differ, so an app generally needs to be built or adapted specifically for each platform, even though the shared kernel foundation makes cross-compiling and code-sharing easier than porting to a completely unrelated OS.

Quick Revision

• Windows: hybrid kernel, broad hardware compatibility, dominant desktop/enterprise OS.
• macOS and iOS share XNU: a hybrid kernel combining Mach (microkernel core) + BSD (Unix userland/networking).
• Linux: monolithic kernel, open-source, dominates servers/cloud/supercomputers/embedded; loadable kernel modules avoid full recompiles.
• Android: built on the Linux kernel but replaces the userland with its own runtime (ART) and app framework — not a traditional Linux distribution.
• Mobile OSes (Android, iOS) impose strict app lifecycle management and aggressively kill backgrounded apps to save battery/RAM; desktops don't.
• What looks like an app "resuming instantly" on mobile is often a fresh process restoring saved state, not a surviving background process.
• Linux's high "used" RAM at idle is mostly reclaimable page cache, not a memory shortage.
• macOS uses memory compression; mobile OSes favor process termination over disk-based swap due to flash wear/battery cost.
• Security models differ by audience: Linux offers flexible discretionary + optional mandatory access control for experts; iOS enforces mandatory sandboxing/App Store review for mass consumers.
• Open-source visibility (Linux) is not inherently less secure — faster patching and broader scrutiny often offset the "attackers can read the code" concern.
• Kernel architecture (monolithic vs. hybrid) is a direct application of the scheduling/memory-management concepts from earlier OS chapters.
• No single OS is "best" — each optimizes for a different primary use case (broad compatibility, integrated experience, server flexibility, mobile battery/RAM constraints).

Related Topics

Prerequisites: Introduction to Operating Systems, Process Management and Scheduling, Memory Management

Related Topics: Virtualization, Deadlocks and Synchronization

Next Topics: Computer Networks