NOTO v1.1.3

Noto for Android, published as an APK you can install from the download page.

This is the release 1.1.2 was meant to be. That version was tagged but never
published: one packaging job stopped responding, and the run was cancelled
before it could attach a single file. Nothing was ever downloadable under
1.1.2, and everything it promised is here.

Android

The download page now offers an Android build for phones running Android 7.0
or later. The recommended download is the 64-bit APK, which every phone made
since roughly 2016 wants; a 32-bit build is published alongside it for older
hardware.

It is a 16 MB download. The generated Android project would have made it 104
MB for an application whose JavaScript is 2.2 MB: one APK carrying native code
for four processor architectures, stored uncompressed, three of which no
single phone can run. Each APK now carries one architecture, unreachable code
is stripped from the release build, and the native libraries are compressed.

Noto is not on Google Play yet, so Android asks you to permit the install once
— that prompt is expected for anything from outside the store. Open the file
after it downloads and confirm.

Documents on the phone are stored in on-device SQLite, the same local-first
arrangement as every other platform. There is no account, and no sync: notes
written on the phone stay on the phone for now.

Signed with a real upload key

Expo's generated Android project signs release builds with debug.keystore —
the well-known Android debug key that ships with the SDK and is byte-identical
on every machine. An APK signed with it is not merely unverified: anyone can
sign their own APK with the same key and Android will accept it as a
legitimate update to Noto.

The release pipeline was already passing an upload keystore through the
environment, and nothing was reading it. apps/mobile/android is regenerated by
expo prebuild on every build, so the signing configuration had been reverting
to the template's on each run, silently. It is now applied by a config plugin
that runs as part of that regeneration, and a release fails outright rather than
publishing an APK carrying the shared debug key.

The download page only links files that exist

Not every release publishes every platform — Android is built only when the
mobile job runs. The page now checks each file name against the assets the
release actually carries, and shows the platform as unavailable when the file
was never uploaded. Previously a package could be listed for a release that had
no such file, which meant a download button pointing at a 404.

A hung build no longer costs a release

Packaging is the one release step that hangs rather than fails. hdiutil,
which builds the macOS disk image, intermittently stops responding on the
hosted build machines — no output, no error, nothing in the log. That is what
happened to 1.1.2: macOS on Apple Silicon sat in that step for the full
45-minute limit while the other four platforms finished in under three, and
the timeout cancelled the whole run. Four working installers were built and
discarded.

Each attempt now has a deadline of its own and is retried, so a stall that
clears on a second try costs a few minutes instead of the release. A build
that is genuinely broken now fails, loudly, rather than being reported as
cancelled — which reads like somebody pressed stop.

Re-running a release by hand was also unsound: the jobs that build the
packages checked out whichever branch the run was started from, while the
version stamped into them came from the tag. The two could disagree, and
nothing would have said so. Every job now builds the tag it was asked for.

Also in this release

• The Android Studio guide covers the JDK 17 requirement, which matters more
  than it sounds: building on the JetBrains Runtime bundled with Android Studio
  fails the native build with a message that names neither the JDK nor the
  cause.
• Code signing documentation gains an Android section, including what happens
  if the upload keystore is ever lost.

Known limitations

Unchanged from 1.1.1: the desktop installers are unsigned, so Windows
SmartScreen and macOS Gatekeeper warn on first launch — verify your download
against SHA256SUMS.txt. macOS auto-update needs a signed build, and Windows
ARM64 is installer-only. iOS is not published. Cloud sync is not enabled on any
platform.

---

Downloads

Windows

Package	File
Installer (x64)	Noto-1.1.3-win-x64.exe
Installer (ARM64)	Noto-1.1.3-win-arm64.exe

macOS

Package	File
Disk image (Apple Silicon)	Noto-1.1.3-mac-arm64.dmg
Disk image (Intel)	Noto-1.1.3-mac-x64.dmg
Archive (Apple Silicon)	Noto-1.1.3-mac-arm64.zip
Archive (Intel)	Noto-1.1.3-mac-x64.zip

Linux

Package	File
AppImage (x64)	Noto-1.1.3-linux-x64.AppImage
Debian package (x64)	Noto-1.1.3-linux-x64.deb
RPM package (x64)	Noto-1.1.3-linux-x64.rpm

The web application needs no download and is always at the latest version.

---

Verifying a download

Checksums for every asset are published as SHA256SUMS.txt.

sha256sum --check --ignore-missing SHA256SUMS.txt

---

Updating

Windows and macOS installations update themselves: Noto checks for a new version on startup, downloads it in the background, and applies it on the next restart.

On Linux, replace the AppImage or install the new .deb/.rpm through your package manager.

---

System requirements

Platform	Requirements
Windows	Windows 10 or later, x64 or ARM64, 4 GB RAM, 500 MB storage
macOS	A supported modern macOS version, Apple Silicon or Intel, 4 GB RAM, 500 MB storage
Linux	x64, 4 GB RAM, 500 MB storage
Web	A current version of Chrome, Edge, Firefox or Safari

Full details: System requirements

Full Changelog: v1.1.2...v1.1.3