What a Forced Eviction After Sixty-Four Kilobytes of Generated GPU Instructions Reveals About Portability You Are Granted Rather Than Achieve
In 2019 we shipped a product on Apple's platforms that generated GPU instructions at runtime. It was not rejected and it did not fail review. It ran, and it kept running until roughly 64K of generated instructions had accumulated, at which point the platform forced eviction. Apple is the substrate where compiling in advance stops being an industry habit and becomes a platform rule, and the rule is enforced with a number.
Paper 1 argued that a compiled binary is a prediction about a machine the builder never saw, and that thirty years of Linux packaging answered that by carrying more of the assumed machine along rather than by making the assumption unnecessary. On Linux that is a convention. The industry chose it, and could choose otherwise. Apple is where the same commitment stops being a convention and becomes a property of the platform: executable code is signed before it runs, and on the more restricted Apple operating systems the ability to write and then execute the same memory is withheld except under an entitlement granted to very little. For nearly all software this costs nothing, because nearly all software was compiled in advance regardless. It bites exactly one kind of system: one that decides instructions at execution.
This paper's anchor is not an argument, it is a receipt. In 2019 MindAptiv shipped illumin8 on Apple platforms, generating GPU instructions at runtime. The product was not rejected and did not fail review. It ran, and continued running until roughly 64K of generated GPU instructions had accumulated, at which point the platform forced eviction. That distinction, between a prohibition and a quota, is what this paper is about, and it is the harder of the two to design against: a prohibition is a constraint you architect around from the first day, while a quota lets the prototype succeed and the product fail at the point where the architecture finally starts to matter. The paper states what resolution can still do under a signed runtime, what it costs, and it states plainly that Essence has no current Apple deliverable. The illumin8 account is MindAptiv's own recollection of a 2019 event and is not independently verified; Apple's platform rules have changed materially since, and the specific behavior described may not reproduce today.
The familiar complaint about Apple's platforms concerns curation: what is allowed into the store, what share is taken, whose business model survives review. That is a real debate and it is not this one. It is a debate about distribution, and distribution is not where this series' argument lives.
The relevant fact is narrower, more technical, and much less discussed. Apple's platforms are built on the premise that executable code is known and signed before it runs. Code signing is enforced throughout. On the more restricted operating systems, memory that can be written cannot also be executed, and the entitlement that lifts that restriction has historically been granted to almost nothing outside the browser engine. macOS is considerably more permissive than iOS; tvOS and watchOS are tighter still. The details differ by operating system, by version, and now by jurisdiction, and any specific rule cited here should be checked against Apple's current documentation before being relied on.
This premise has a real security rationale and this paper is not going to pretend otherwise. A platform that knows what code will run can make guarantees that a platform permitting arbitrary runtime code generation cannot. The cost of that guarantee is invisible to almost every developer, because almost every developer ships a binary that was compiled in advance anyway. The premise only becomes visible, and only becomes expensive, for a system whose entire architecture is that instructions are decided when the machine is finally in front of it.
In 2019 MindAptiv launched illumin8 on Apple platforms. Underneath it did what this series argues software should do: rather than shipping a fixed set of precompiled GPU programs, it generated GPU instructions during execution, against the hardware actually present.
It worked. That is the part worth sitting with before the rest of the paragraph. The architecture was not theoretical, it was not rejected at review, and it did not fall over on first contact with the platform. It shipped and it ran.
What it ran into was a ceiling. Past roughly 64K of generated GPU instructions, the platform forced eviction of what had been generated. Not a crash, not a rejection, not a policy notice. The generated instructions were reclaimed, and everything the product had resolved against the live machine went with them.
A prohibition is a design input. If a platform states that instructions may not be generated at execution, an architect knows that on day one, designs for it, and either serves that platform differently or does not serve it. The constraint is expensive but it is honest, and it is visible before anything is built.
A quota behaves differently, and worse. Under a quota the architecture is permitted. It compiles, it ships, it passes review, it demonstrates well, and it does all of that because early workloads generate few enough instructions to stay under the line. The failure surfaces later, in proportion to success: the more work the system resolves against the real machine, the more instructions it generates, and the closer it moves to the threshold that reclaims them. A ceiling denominated in generated instructions is a ceiling on exactly the property the architecture exists to provide.
This is the same fixed-commitment mechanism the series has traced elsewhere, arriving by a different route. On Linux, in Paper 1, the commitment is a convention: the industry compiles in advance because it always has, and every generation of packaging has made that convention cheaper to keep rather than unnecessary. On Apple the commitment is closer to a requirement, and the quota is where the requirement is enforced. The platform does not need to forbid resolution. It only needs to meter it below the volume at which resolution would matter.
The useful question is not whether Apple should change. It is what remains architecturally available on a platform that meters generated code, and the answer turns on a distinction Paper 1 did not need to draw: resolving and emitting are separate acts.
Resolution is the decision. It is the work of examining the components actually present, the driver stack, the accelerator generation, the available instruction extensions, what else is contending for those components, and determining what should be done given that. None of that requires writing a single new executable page. Emission is the separate act of turning that determination into instructions the hardware will run, and emission is the only part the platform meters.
That separation is what makes Apple tractable at all. Essence's approach on these platforms is to resolve on the device and emit through a path the platform already sanctions rather than through general-purpose runtime code generation. The determination is made against the live machine, as everywhere else in this series. What changes is the channel through which the determination becomes execution, which is chosen from what the platform permits rather than from what would be optimal.
The cost of that arrangement should be stated rather than glossed. An approved emission path carries its own ceiling, its own latency, and its own supported feature set, and none of the three is under the architecture's control. Portability obtained this way is granted, in the precise sense that it is extended by a party who can narrow it later without notice and without appeal. On Linux the architecture's reach is bounded by what the hardware can do. Here it is bounded by what the vendor currently permits, and those are different kinds of limit.
There is no current Essence deliverable for any Apple platform. illumin8 is history, not a product line, and nothing in this paper should be read as an announcement. Paper 1 could point at a Linux binary and a distribution channel. This paper points at a 2019 precedent and an architectural analysis, and the substrate strip at the top of the page says so.
Stating that is not a formality. A series arguing that vendors overclaim platform coverage cannot itself claim a platform it does not ship on, and the temptation to soften this into "Apple support is on the roadmap" is exactly the temptation the register of this series exists to refuse. The honest position is that Apple is the substrate where the architecture has been tested against a hard platform limit, found the limit, and has not yet returned with a shipped answer.
What would have to be true to change that is specific rather than aspirational: an emission path whose own ceiling sits above what real workloads generate, on the specific Apple operating systems being targeted, verified against current platform rules rather than against 2019 ones. That is an engineering question with a determinate answer, and when there is one this series will publish it with the conditions attached, the same way Paper 1 published the Linux figures with theirs.
The illumin8 account is not independently verified. It is MindAptiv's own recollection of a 2019 product experience. No correspondence with Apple is cited, no ticket or determination is reproduced, and the numeric threshold has not been re-tested. The unit behind "roughly 64K," and the precise platform mechanism that performed the eviction, are flagged in Section 02 as open.
No claim that Apple acted improperly. Signing executable code before it runs, and constraining runtime code generation, are defensible security decisions with real benefits to users. A limit being costly to one architecture is not evidence that the limit is wrong. This paper describes a structural tension, not misconduct.
No claim about current Apple behavior. Apple's rules have changed materially since 2019, including regulatory changes affecting alternative engines and distribution in some jurisdictions. Nothing here should be treated as a description of what these platforms do in 2026 without fresh testing.
No current Apple deliverable, and no date for one. Section 05 states this at length because it is the claim a reader is most likely to assume was implied.
No claim that the Apple operating systems behave alike. macOS, iOS, iPadOS, tvOS, watchOS and visionOS differ substantially in what runtime code generation they permit. This paper treats them as one substrate for the purpose of one argument, which is a simplification, and a paper claiming a specific technical result on one of them would need to name which one.
Two substrates in, the series has both of the shapes the fixed commitment takes. On Linux it is a convention, kept because it is cheaper to keep than to question. On Apple it is a rule, enforced by a quota denominated in the very thing the architecture produces. Every remaining substrate is a variation on one of those two.
Paper 3 takes up Windows, where the commitment appears in its third and strangest form: not a convention and not a quota, but a debt. Thirty years of binaries shipped against preserved interfaces have produced an operating system that carries the accumulated weight of every prediction ever made against it, and cannot put any of it down. Papers IV and V then split what is usually treated as one subject, the fleet Google controls and the Android that ships on hardware it does not, because a vendor that already moved half the compile decision onto the device is a different argument from a market structure that no runtime abstracts away.
That sentence is the whole paper. A platform that forbids runtime instruction generation tells you so on day one and you design accordingly. A platform that rations it lets the architecture ship, demonstrate, and succeed, and then reclaims what it generated at the point where the generation had started to be worth something. Resolution survives that meter, because deciding what a machine should do is not the same act as writing new executable pages. Unrestricted emission does not. Apple is the hardest substrate in this series, Essence does not ship on it today, and this paper would be worth less if it pretended otherwise.
← Paper 1 · The Distribution Problem The Common Substrate