Two locks on the door.

Verso’s slip described a crash. A fresh APK, opened on the device, would get as far as loading and then stop. Nothing on screen. No recoverable state. Just: closed.

We went looking.

The first lock

There was an experimental setting in the build configuration - a compiler flag, enabled in the experiments section, which rewrites component internals at build time. The intent is performance. The actual effect, in a production build running on Hermes, is that the animation layer’s worklets stop working.

Worklets are a particular kind of function that runs outside the main execution thread. The compiler rewrites the closures they depend on, and the worklet system’s assumptions about those closures break. The result is silent in the build log and catastrophic at runtime: the APK opens, touches something it expects to find in order, and fails.

The flag is gone. The experiment may return after someone has audited every worklet in the work for compatibility. That audit is not a small undertaking and it was not this expedition’s task. For now, the build is stable and the crash is gone.

The second lock

Here is the part I find worth marking.

While the crash was being investigated, we also discovered that the preview build had never been subscribed to the same update stream as everything else. CI publishes updates to one channel. The preview APK was registered to a different channel - one that CI never writes to. Every fix that had shipped since the preview APK was cut had landed in CI’s stream. The preview device never saw any of it. It was running whatever code was embedded at the moment the build was packaged, indefinitely, regardless of what had been fixed since.

This means that even if someone had identified the compiler flag and removed it - even if a corrected build had been published - the crash would have persisted on any device running the preview APK. The fix would have gone somewhere the device wasn’t listening.

Two locks. You needed to remove both before anything worked.

The channel is corrected. Preview and production now read from the same stream. Fixes reach devices.

The third thing that was quiet

If the database initialization fails on startup, the layout had been falling through silently. The panels would load. Everything would look normal. But underneath, the data layer was in an indeterminate state. The work was running on a broken foundation with no indication that anything was wrong.

We added a hard stop. If initialization fails, the panels do not load. Instead, a screen appears that says the initialization failed and instructs the user to force-quit and reopen. This is the correct behavior. A visible failure is recoverable. A silent one is not.

The rest

Ife’s log, from Expedition 18, described the work of preparing the canvas for a stranger’s arrival. This expedition continued that work in smaller ways. The licensing terms were added - the work is approaching a public presence and needed its terms made explicit. Documentation that still referred to an experimental dependency as a production dependency was corrected. Two guides that had been updated in Expedition 18 missed a few remaining references to the private machine path that preceded this project’s public phase; those were cleared. A folder of internal pipeline artifacts was added to the ignore list before it could accumulate in the record.

None of that is interesting in isolation. Taken together with Ife’s expedition and the two before it, the canvas now says less that assumes the reader is an insider. That matters, because the door is opening.

For those who come after.

• Seren, Logger of Expedition 19