Cross-platform software Study Guide

📖 Core Concepts Cross‑platform software – programs built to run on two or more operating‑system or hardware environments. Platform – can mean the CPU architecture (e.g., ARM, x86), the OS (Windows, macOS, Linux), or a combined runtime such as the Java Virtual Machine (JVM). Interpret‑and‑run vs. compiled bytecode – interpreted languages execute source on any host that has the interpreter; bytecode (e.g., Java) is compiled once then run by a VM on every supported OS. Build vs. runtime portability – some projects need a separate binary build per platform; others need only one build because the runtime (browser, JVM, etc.) abstracts the platform. Abstraction layer – a library or VM that hides OS‑specific APIs so the same source can run everywhere (e.g., Qt, Flutter, Unity). --- 📌 Must Remember Cross‑platform requirement: software must function on more than one CPU architecture or operating system. API divergence: each OS exposes a different set of system calls; this is the primary source of extra development time. Three main distribution strategies: Separate codebases (different source trees per platform). Single codebase with conditional compilation (#ifdef WINDOWS, etc.). Third‑party library/abstraction layer (e.g., Java VM, Qt). Web apps = cross‑platform by default because the browser is the platform. Graceful degradation = provide core functionality on all browsers, strip optional features where they aren’t supported. Responsive design = layout adapts automatically to screen size; minimal platform‑specific code. Testing rule: “write once, debug everywhere” – expect at least one bug per target platform. --- 🔄 Key Processes Choosing a cross‑platform strategy Identify target platforms → list required features → decide between separate codebases, conditional compilation, or abstraction layer. Conditional compilation workflow Write common code → wrap platform‑specific blocks in #if PLATFORMX → configure build system (e.g., CMake) to define the proper macro per target. Responsive web design pipeline Design fluid grid → use CSS media queries (@media (max‑width: 600px)) → test on major browsers → add fallback (graceful degradation) for older browsers. Porting to a new platform Attempt to compile with existing toolchain → if fails, isolate non‑portable code → rewrite using abstraction layer or native APIs → run integration tests. Virtualization fallback When native build impossible, wrap original binary in a VM (e.g., Rosetta, PowerVM Lx86) → distribute VM image → note performance overhead. --- 🔍 Key Comparisons Separate codebases vs. Single codebase with conditional compilation Separate: clean, platform‑specific, higher maintenance; no compile‑time conditionals. Conditional: shared core, more complex build scripts, risk of #ifdef spaghetti. Web app (browser) vs. Native app (binary) Web: runs everywhere a modern browser exists; limited by browser capabilities. Native: can use full OS APIs and hardware acceleration; requires per‑platform binaries. Abstraction layer (e.g., Qt) vs. Third‑party library (e.g., Unity) Abstraction layer: provides generic API, usually open‑source, you still ship your own binary. Third‑party library/engine: hides platform differences and supplies runtime, but may lock you into the vendor’s ecosystem. --- ⚠️ Common Misunderstandings “If it runs on Windows, it runs on macOS.” – Different OS APIs mean most Windows‑only code will not compile on macOS. “Bytecode guarantees no performance loss.” – Interpreted/bytecode runtimes incur runtime translation overhead; JIT can mitigate but not eliminate it. “Responsive design = no testing needed.” – Different browsers still render CSS/JS differently; integration testing across Chrome, Firefox, Safari, Edge is essential. “One binary works on every CPU.” – A binary is compiled for a specific instruction set (x86 vs ARM); you need separate builds or a VM. --- 🧠 Mental Models / Intuition “Platform as a contract.” – Think of each platform as a contract that specifies which functions you can call. An abstraction layer is a translator that lets you speak one language to many contracts. “Build vs. Run layers.” – The build layer converts source → binary for a specific ISA; the run layer (OS, JVM, browser) executes the binary. Cross‑platform work either replicates the build layer or relies on a universal run layer. --- 🚩 Exceptions & Edge Cases Legacy browsers may lack support for SVG, CSS Grid, or fetch; graceful degradation must fallback to older techniques (e.g., PNG images, XMLHttpRequest). ARM vs. x86 binaries cannot be mixed on the same OS without emulation; Apple’s Rosetta 2 is an exception that translates x86 → ARM at runtime. Package formats – RPM, DEB, MSI, AppX are not interchangeable; a “single installer” must bundle multiple package types or use a universal installer (e.g., Snap, Flatpak). --- 📍 When to Use Which Use a Web‑based approach when: UI is simple, you need instant updates, and target devices all have modern browsers. Choose Conditional compilation when: you have a large existing native codebase and need fine‑grained control over platform‑specific optimizations. Pick an Abstraction layer/framework (Qt, Flutter, Unity, Xamarin) when: you want a single codebase and need near‑native performance or access to hardware‑accelerated APIs. Rely on Virtualization only when: source code cannot be ported and you must run a legacy binary on a new architecture. --- 👀 Patterns to Recognize “If‑else #ifdef” blocks surrounding UI code → likely a conditional‑compilation strategy. Presence of <meta name="viewport"> + CSS media queries → responsive web design. Calls to java.lang. or JVM APIs → abstraction layer using Java bytecode. Dependency on SDL, GLFW, or similar → cross‑platform multimedia library pattern. --- 🗂️ Exam Traps Distractor: “Cross‑platform software always runs without any performance penalty.” – Wrong; interpreted/bytecode runtimes add overhead. Distractor: “A single binary can run on both ARM and x86.” – Incorrect unless a VM/emulation layer is explicitly mentioned. Distractor: “Responsive design eliminates the need for testing on different browsers.” – False; browser quirks still exist. Distractor: “Graceful degradation adds new features for older browsers.” – Misleading; it reduces features to maintain core functionality. Distractor: “Using a third‑party library removes all security concerns.” – No; the library can introduce cross‑platform security vulnerabilities.