0.8.0 came out on 25 october, seven weeks after 0.7.8. the release notes are the short version. this is the long one: what changed on the phone and why, every fix on the desktop and the phone, and the build machinery that took more of those seven weeks than i expected.

the phone has its own app

until 0.8.0, shizumu on a phone was the desktop app made narrow. every phone fix went inside a desktop component as one more branch for small screens. by august the history showed what that cost. about fifty-five of the last eighty commits were mobile fixes, and the editor component alone carried nine phone branches in three and a half thousand lines. the bugs kept coming back in the same shapes: the keyboard and the viewport disagreeing about how much screen was left, controls drawn over the writing, a bar that hid itself and stayed hidden.

so on 22 august i wrote a different plan. the phone gets its own set of screens, and the desktop stays exactly as it was. the phone shell owns everything you see and touch, and borrows everything underneath it: the editor, the database, sync, search. it was built alongside the desktop for two months and merged on 23 october.

the page is home. its header holds the date, the trail and the pages of the day, and folds to one line while you scroll or type. three tabs sit at the bottom: page, memory and settings.

the editing controls live in one place, a single strip above the keyboard, and nothing floats over the text. with the caret in a block, the strip holds six things: turn into, bold, italic, insert, pin and undo. select some words and it changes to what a selection can do. type / or @ and the suggestions show as chips to tap. a control that cannot apply to the block you are in is left out rather than greyed. in a list, indent and outdent join it.

each block has one handle beside it. tap it for the block’s actions. hold it for about a third of a second and the block lifts and follows your finger, with a thin line showing where it will land.

pins, memory, trails and sync each got screens of their own. you can read a pin, edit it in place, or move it to another trail. memory filters by date from a month calendar and narrows to one trail. a living document’s date opens a list of its days. sync can be set up, paired by camera and switched off from the phone. sheets come up from the bottom and fit what they hold: renaming a pin is one field, so it opens halfway, and a note with a body opens full height so its field is not hidden under the keyboard.

the keyboard took longest. android 15 draws every app edge to edge, and for an app built against a recent android it no longer shrinks the window when the keyboard opens. on the galaxy a16 i test with, the page measured 832 pixels tall with the keyboard down, and 832 with a 310 pixel keyboard up. the editing strip was behind the keyboard. the fix was to stop asking the web page. the android side of the app now measures the keyboard itself, and the page shrinks by that much.

one samsung webview taught the hardest lesson. it froze every height reading at the keyboard-up value, so the app believed a keyboard was open for the rest of the session, and the editing strip took the place of the tabs, and with them every way off the page. since then the tabs and the editing strip are two rows, and nothing the keyboard does can take the tabs away.

the layout is chosen by the shape of the screen and the kind of pointer, not the operating system. so the browser demo opens it on a phone, with a few weeks of writing already in it. a linux phone gets it too: under phosh or plasma mobile a touch-only screen counts as a phone, and flathub now builds for arm64. i have not run it on a linux phone myself yet. if you have one, i would like to hear how it goes.

tested on two devices at once

a feature that works on one device and breaks on the second is not done. so most of september and october went into runs with a laptop and a real phone side by side, paired, writing on both, deleting, going offline, starting over, moving to another relay. i test on two phones, a galaxy a16 and a galaxy a06, driven over wifi from the laptop. the runs found most of the sync fixes below, and the a06 found one nobody would have guessed: with out of date time zone data, today’s page would not take typing for an hour around midnight.

everything that was fixed

two of these started as github issues, and i am grateful to the two people who wrote them up so clearly. the rest came from testing and from using it.

writing and the editor

sync between devices

sync is still optional and end-to-end encrypted. the relay holds what it cannot read, and neither can i.

the lock, encryption at rest and backups

the phone and installing

five platforms, and no mac

a fair share of the seven weeks was not the app. it was the machinery that turns one version tag into installers for linux, windows, android, iphone and mac, run by one person who does not own a mac.

a tag starts one pipeline, and its first real job is the test suite. at release time that was 3424 unit tests. until the middle of october, the windows and android builds ran beside the tests rather than after them, so a tag could ship whatever it built. now every build waits, and a tag with one failing test produces no installers at all.

windows builds on a machine i own and is signed by a cloud signing service that never hands over the key. the job checks the signature itself before it uploads anything, because an earlier run printed success while the signing had failed. android signs with one upload key. an early version of the job generated a fresh key on every run, and play refused every bundle after the first, because play ties an app to the certificate it saw first.

the public repository at github.com/shizumu-app/shizumu is built on each tag by copying only the paths on an allowlist into a fresh tree, then checking that tree for private paths, credential-shaped text and key files before it is pushed. copying what is allowed, instead of deleting what is not, means a new private folder cannot leak by being forgotten. during this release i found a hole in that check: the container’s small version of find did not understand one option, so the key-file check errored, matched nothing, and passed. it uses the full findutils now. on release day the push itself was refused twice, first by an expired token and then by one that was not allowed to update workflow files, until both were replaced.

flathub builds from that mirror, pinned to the tag and the exact commit behind it. for 0.8.0 the deb, rpm and tarball went away and flathub became the only linux build, on x86_64 and aarch64. flathub builds offline, so every npm package has to be listed ahead of time, and two new packages since 0.7.8 meant regenerating that list. flathub’s bot opens its own update request on a new tag, but it changes only the tag and commit and its build would have failed, so i closed it and opened one with all three files.

the website’s download section is built last. it fetches the installers that actually arrived, names only those, and fails the deploy if a link points at a file that is not there. that rule came from 0.7.1, which went out with no android download because the site deployed before the apk landed.

iphone and mac build on github’s macos runners, from the same allowlisted snapshot. the iphone build took ten runs in september before apple would take it: the project wanted automatic signing the runner cannot do, the large icon carried an alpha channel, the sdk was too old, and the newer xcode failed in the linker until the minimum ios version went to 17. the day before release, app store connect asked for a privacy manifest declaring the system calls the rust code makes, and the build writes one now.

the mac build makes one dmg for apple silicon and one for intel. each is signed, notarized, checked by gatekeeper and launched for twenty seconds before it is uploaded. on release day the mac keychain refused the signing certificate until it was exported again in an older format, and then the upload refused to go because it was waiting for the linux deb that 0.8.0 had just stopped making. it waits for the android bundle now. the mac version ships as a beta, and the people who run it are its testers.

getting it

on linux, flathub updates it for you, on x86_64 and arm64. on windows, get the installer from the download section. on android, the play closed test updates itself: join from the android page in two steps, or install the apk directly. on iphone, open the testflight link on the phone. on a mac, the beta download is signed and notarized for both chips.

if something is still wrong for you, open an issue and say which version you are on. a screenshot helps more than anything.