Three execution paths, three different contracts

Where compatibility lives

Consider one button. In the source path, its Swift code is compiled for Android and the compatibility surface supplies the implementation. In the loader path, an existing Mach-O image enters a host process and expects its imported symbols and ABI behavior to exist. In the guest path, the app executes within a separately provisioned OS; a bridge must make its result visible and interactive on Android. These paths can contribute to the same product without being consecutive stages of one pipeline. [map], [playground], [checkpoint]

The contract is larger than an instruction set

“Both machines use ARM” describes only part of execution. A program also assumes a binary format, relocation rules, parameter passing, thread-local storage, exception unwinding, framework behavior, and system services. A successful jump into a two-line program tests a small intersection of those requirements. It cannot establish that an app’s object runtime, event loop, or persistence works.

The inspected resolver makes that limitation concrete: it accepts libSystem names, resolves a small explicit symbol table, and treats variadic calls specially on non-Darwin hosts. It does not synthesize the Objective-C runtime or UIKit. Its execution function rejects arm64e and requires an LC_MAIN entry. Those are operational boundaries, not merely cautious wording. [bind], [map]

What Cider and Proton actually contribute

The original Columbia Cider architecture modified Android’s kernel to support foreign ABI behavior. Per-thread personas selected the relevant execution conventions; duct tape adapted available foreign kernel code; diplomatic functions crossed into domestic libraries for facilities such as graphics. It reused foreign userspace components. That is a historical design, not a drop-in modern iOS runtime and not evidence that Daybreak includes its implementation. [cider]

Proton uses Wine and additional components to run Windows games on Linux. Its lesson for Daybreak is that compatibility requires a maintained implementation plus testing against real workloads. The Steam Deck comparison is useful as a product ambition; it should not replace a diagram of Daybreak’s actual paths or imply equal maturity. [proton]

Backstep is also called Cider in this workspace, which makes the terminology easy to blur. Here “Backstep” means the inspected project loader and ABI work; “Columbia Cider” means the 2014 paper. No kernel-persona implementation is established by inspecting Backstep’s current Swift loader. [map], [bind]

CPU execution and graphics are separate axes

A virtual machine description needs an execution backend as well as a virtual board and devices. QEMU distinguishes these configuration choices; TCG is software emulation, while hardware virtualization requires an appropriate accelerator. The availability of one on a host does not establish support for a particular guest platform. [qemu]

Similarly, drawing guest-derived resources through Android’s accelerated Canvas does not imply that the guest has an Apple GPU. CPU execution, graphics command compatibility, resource transport, host composition, and display are separate engineering problems. A report should name both the execution backend and rendering path rather than use “native” for all of them. [view], [checkpoint]

The current evidence boundary

The dated runtime checkpoint describes an instrumented UIKit fixture: its capture and input support are compiled into the app. It also records progress with stock scroll and slider controls, alongside rendering discrepancies. That is stronger than “a shell boots,” but still differs from a reusable system-wide app bridge. The separate-app gate asks for independent identity, natural lifecycle, and bridge attachment. [checkpoint]

Newer reports may extend that boundary. A claim that the latest iOS loads should carry its exact build, target, launch path, and interaction evidence before the website turns it into a general-purpose compatibility statement. The Pixel and BlueBerry roster identifies testing targets; it is not a per-device certification.