Moving apps onto fastframe

An index by app, then one section per crate: what each app deletes, and what it calls instead. Each move is its own change in the app’s repository, made after the crate lands here. Paths are relative to the app’s repository root; line counts are estimates taken when the crate was extracted.

Depend on a pinned revision:

fastframe-<name> = { git = "https://github.com/crmne/fastframe", rev = "<commit>" }

Keep behaviour: each section lists where the crate differs from what an app did, so the app either accepts the change on purpose or keeps its own code for that part.

Before you start

fastframe needs Rust 1.98 (rust-version in every crate). An app pinned to an older toolchain in rust-toolchain.toml fails to resolve on macOS and Windows with “rustc 1.97.1 is not supported by fastframe-*”; bump the app’s toolchain and rust-version to 1.98 first. Keep the app’s [patch.crates-io] block for the egui and winit forks: patches only apply at the app’s root.

By app

Which crates each app adopts, and which it leaves for later. Each crate’s section below has a subsection per app with the details.

Shared widgets have not moved; see Not moved yet: widgets.

fastframe-text

Follows the desktop’s font rendering. Every app replaces its hand-set hinting and color_transfer_function with it:

let rendering = fastframe_text::detect(); // once per process, outside a tokio runtime
rendering.apply_to(&mut fonts); // before `ctx.set_fonts`
ctx.all_styles_mut(|style| rendering.apply_to_visuals(&mut style.visuals));

• Linux reads the desktop portal, then fontconfig. With the usual slight hinting this is egui’s default hinting with sub-pixel positions, and linear coverage in both themes, which matches GTK’s weight.
• macOS is unhinted and Windows slightly hinted; both keep egui’s coverage per theme, so dark text there is a little heavier than on Linux.
• Apps that shift a galley by hand (ZapFast’s selectable bubbles, Spotifast’s right-to-left runs) round both ends with snap_to_pixels.
• The watch feature follows portal changes live; call apply_to and ctx.set_fonts again from its callback.

Adopted by all five apps: ZapFast, Spotifast, Solco, TonePush and Chat with Work (58da999, which applies it to the system UI font it uses).

fastframe-fonts

Bundled Inter at the app’s weights, the monospace choice, companions such as a bundled emoji face, and the system fallback faces with their baseline and Arabic adjustments. Each app keeps its sizes and text styles, its own extra faces (ZapFast’s colour emoji overlay, Spotifast’s skin font and playlist face, TonePush’s Plex Mono file), and when it installs fonts.

Everywhere, the helpers become one-liners or go away:

pub fn regular(size: f32) -> egui::FontId { fastframe_fonts::Weight::Regular.font_id(size) }
pub fn medium(size: f32) -> egui::FontId { fastframe_fonts::Weight::Medium.font_id(size) }
pub fn semibold(size: f32) -> egui::FontId { fastframe_fonts::Weight::SemiBold.font_id(size) }
pub fn bold(size: f32) -> egui::FontId { fastframe_fonts::Weight::Bold.font_id(size) }

The family names inter-medium, inter-semibold and inter-bold and the regular key inter are the ones ZapFast and Spotifast already use.

ZapFast

About 540 lines. Demo and screenshot builds call .system_fallbacks(false) if they want output independent of the machine’s fonts (the current code always adds them).

Behaviour that changes, all from Spotifast’s newer copy: fallbacks are moved onto Inter’s baseline (y_offset_factor); macOS asks CoreText instead of scanning /System/Library/Fonts (which never finds PingFang); on Linux the directories fontconfig’s configuration names are probed too (NixOS); a Japanese face no longer serves Han on a Chinese desktop when a Chinese one exists; Windows reads its display language for the Han cut; Yi and the ★ probe are added. The ♡ probe ZapFast called symbols is now suits, so its font data key becomes fallback-suits when a different face than the one for ★ covers it.

Spotifast

Keep memmap2: the playlist face lookup that stays in Spotifast maps font files with it. About 1,500 lines. milkdrop/overlay.rs and ui/winamp/pixel_text.rs read fastframe_fonts::system::fallbacks() instead; Fallback gains scale and y_offset_factor, which they may ignore. Code that looked up system_fonts::FALLBACK_SCRIPTS for a probe character uses the fallback’s own face instead (the list is internal to the crate now).

Behaviour that changes, from ZapFast’s copy: a small Arabic face is enlarged up to 25% to match Inter’s x-height, and Javanese, mathematical alphanumerics, enclosed alphanumerics and ♡ get fallbacks too.

Solco

About 40 lines. Solco has no system fallbacks today: the default adds them, so track names in CJK, Arabic or Indic scripts stop drawing as boxes. Pass .system_fallbacks(false) to keep today’s behaviour. The font data keys change from solco-inter to inter.

TonePush

About 45 lines. The SEMIBOLD family name changes from semibold to inter-semibold (use Weight::SemiBold.family()). Inter’s figures become tabular in labels too, and system fallbacks are added unless turned off.

Chat with Work

It draws with the platform’s UI font and bundles none; nothing to move.

fastframe-icons

The icons! macro, the icon enum it now generates, the bytes loader, and the 43 Lucide files ZapFast and Spotifast ship byte for byte alike. Each app keeps its own SVG files, its icon widgets (icon, paint_icon, icon_button), and its sizes and tints.

Every app does the same:

1. Replace the macro_rules! icons, the pub enum Icon { .. } list, the const ICONS: &[(Icon, &str, &[u8])] = icons! { .. } table, impl Icon (uri, image) and register_icons with one block:

   fastframe_icons::icons! {
       pub enum Icon {
           prefix: "zapfast-icon-",          // the app's current bytes:// prefix
           directory: "../assets/icons/",
           Archive => "archive",             // the old table's entries, unchanged
           Check => lucide "check",          // a shared icon: see step 3
           // ...
       }
   }
   

2. Call fastframe_icons::install::<Icon>(ctx) where register_icons(ctx) was called (after egui_extras::install_image_loaders).
3. For each of the 43 shared names (fastframe_icons::lucide::ALL), write lucide "name" and delete assets/icons/<name>.svg. Keep assets/icons/LICENSE.txt: the app still ships its own Lucide files.
4. Code that iterated ICONS uses Icon::ALL with icon.uri() and icon.bytes().

ZapFast

About 180 lines of Rust and 43 files. The ICONS table becomes the icons! block (the same length).

Spotifast

About 120 lines and 43 files. Behaviour change: icons are served by the never-forget loader instead of ctx.include_bytes, which fixes the red placeholder if Spotifast ever turns on reduce_texture_memory.

Solco

About 80 lines. Its SVGs are minified lucide-static files that differ from the shared ones byte for byte, so it keeps all of them. Its draw-time helpers keep their shape: icon_image(icon, color, size) becomes icon.image(color, size) (the same egui::Image, tinted and sized), and icon(ui, ..), icon_button and transport_button keep calling icon.uri().

TonePush

Its UI and category icons use their own macros and file layout. It can move to icons! later; nothing is shared with it yet.

fastframe-theme

Palette files, the background catalogue, the shared palettes, Omarchy following and file watching. Each app keeps its Palette struct and its dark and light defaults, theme::apply (the mapping onto egui::Visuals and widget styling), the Settings picker and its wording, the reload-themes command on its single-instance channel, and the packaging files in contrib/omarchy/.

Every app does the same:

1. impl fastframe_theme::Palette for Palette: base returns Palette::dark() or Palette::light(); set is the old match name from parse_palette, returning false for unknown names; ZapFast’s derive holds its “Spotifast palettes share the sixteen interface colours” block.
2. theme::custom::CustomTheme becomes fastframe_theme::CustomTheme<Palette> and theme::custom::Catalog becomes fastframe_theme::Catalog<Palette>. The serialized cache (custom_theme_cache, system_theme_cache) keeps its shape, so existing settings.json files read as before; point deserialize_with at "fastframe_theme::read_cached_theme".
3. theme::custom::label becomes fastframe_theme::display_name.
4. Catalog::start(directory, selected, &waker) takes a fastframe_theme::Waker: build one once with fastframe_theme::Waker::new({ let waker = self.waker.clone(); move || waker.wake() }).
5. The status line: catalog.status(selected) returns Status::Loading, Status::SelectedUnavailable or Status::Problem(..); the app maps each to its (translated) sentence. The sentences both apps use today: “Loading local themes…”, “The selected theme is unavailable. Keeping the last usable appearance. See the log for details.”, and per Problem: Unreadable “The themes folder could not be read. See the log for details.”, TooManyEntries “The themes folder has more than 512 entries. Keep fewer files there to list the custom palettes.”, TooManyThemes “Only 128 custom palettes can be listed. Keep fewer JSON files in the themes folder to see the rest.”, LoaderFailed “Custom themes could not be loaded. Run reload-themes to try again.", `OmarchyUnreadable` "The Omarchy palette could not be loaded. Keeping the last usable appearance. See the log for details."
6. Add a test that the shipped hook has not drifted: assert_eq!(include_str!("../contrib/omarchy/<slug>-theme"), fastframe_theme::omarchy::hook_script("<slug>"));

ZapFast

About 1,300 lines, less the 45-line Palette impl and a 25-line status mapping. In App::new: app.custom_themes.enable_desktop_themes(DesktopThemes { slug: "zapfast", omarchy_template: include_str!("../contrib/omarchy/zapfast.json.tpl"), omarchy_previous_templates: &[], presets: true }). Behaviour is unchanged.

Spotifast

About 950 lines. entrypoint.rs calls app.custom_themes.enable_desktop_themes(DesktopThemes { slug: "spotifast", omarchy_template: include_str!("../contrib/omarchy/spotifast.json.tpl"), omarchy_previous_templates: &[], presets: true }) (presets: true adds the eight shared palettes to its picker, which it does not show today). Keep in the app, run before that call on Linux:

• the upgrade of an installed hook that still says /fastpotify/themes (the block at the top of Setup::install, about 20 lines), and
• skipping enable_desktop_themes when the themes directory is the legacy fastpotify one during an updater trial.

tests/omarchy.rs (which runs the shipped hook with bash) can stay, or give way to the hook_script equality test.

Behaviour that changes, from ZapFast’s newer copy: Omarchy is followed whenever it is set up, not only when a package installed the assets, and its palette is read from Omarchy’s rendering (or rendered from its colours) rather than from themes/omarchy.json alone; the themes folder and the current Omarchy theme are watched, so palettes reload without the hook or a restart.

Solco, TonePush, Chat with Work

Solco and TonePush draw one fixed dark palette, and Chat with Work follows the platform’s light or dark setting; none reads palette files. They can adopt the crate by implementing Palette when they add custom themes or Omarchy support.

fastframe-i18n

The PO compiler, the lookup functions, language tag parsing, and the template update script. Each app keeps its Locale enum, its tags, native names, language picker, settings.json format, and its own phrase helpers (Spotifast’s song_count and friends).

ZapFast

About 130 lines. Call sites (crate::i18n::gettext(app.locale, ..)) stay as they are because crate::i18n re-exports the functions. The tests that check real catalogs (german_catalog_translates_the_pilot and the plural tests) stay in the app.

Spotifast

About 200 lines. Locale::from_tag keeps using clap::ValueEnum.

Solco, TonePush, Chat with Work

No translations yet. Start with the crate when they add one.

fastframe-log

The logger (stderr plus a per-run file), the panic hook, and redaction helpers. Each app keeps its default filter strings (and their tests), its paths (log_file, panic_log), and its own redactors.

ZapFast

Keep src/diagnostics.rs; add a three-line adapter for .redact:

fn redact_protocol(record: &log::Record<'_>, message: &str) -> Option<Cow<'static, str>> {
    (is_protocol_target(record.target())
        || is_protocol_target(record.module_path().unwrap_or_default()))
    .then(|| protocol_summary(message).into())
}

About 90 lines. Keep default_log_filter and its two tests.

Differences: init also logs Starting zapfast <version> on <os> (<arch>) at info, which the file keeps at the default filter. A log file that cannot be created is reported through the logger (on stderr) instead of eprintln!.

Spotifast

About 60 lines. http.rs keeps error.without_url() (reqwest does it better on its own errors); redact::links is for errors that are already strings.

Differences, all deliberate:

• The panic log keeps the payload, with links removed (PanicMessage::Redacted(redact::links)), on one line after the location. Spotifast wrote {info} with the raw payload; a payload can quote the data being handled, such as a URL with a token. The default hook is no longer chained, so the raw payload is not printed to stderr either. (ZapFast keeps PanicMessage::Omit, the default.)
• Log lines use [time LEVEL target] message with the level unpadded (env_logger’s default pads it and colours it on a terminal).
• The start line says spotifast (the name passed to Logging::new, which the panic line also uses) where it said Spotifast.

Solco, TonePush, Chat with Work

Not moving the logger now. Solco logs through tracing-subscriber (an EnvFilter in main.rs, stderr only) and records panics as structured session evidence (src/diagnostics/sessions.rs), which chains the previous hook and already never captures the payload. It can take the facade-free parts with default-features = false: redact::links/words for error strings, and, if it wants a human-readable panic line next to its session records, log_panics installed before Session::install_panic_hook (so the session hook chains it). Its logger stays as it is; the crate has no tracing subscriber until a second app logs through tracing.

TonePush uses eprintln!. Chat with Work logs to stderr only and reads CWW_APP_LOG, not RUST_LOG; it can adopt the crate once it wants a log file, which would change its variable.

fastframe-tray

The tray item on all three platforms, with the menu supplied by the app. Each app keeps its menu labels (and translations), its icon drawing (util::app_icon_rgba, util::tray_template_rgba), and the mapping from tray events to its own actions.

ZapFast

About 540 lines. The dock_reopen_requests_a_window_only_when_none_is_visible test moves with the code (the crate’s macOS test covers the new behaviour).

Differences, all taken from Spotifast on purpose:

• Windows: a left click on the icon now always shows the window (Event::Show) and no longer opens the menu; the menu opens on right click (Spotifast #310, 5eb054e).
• macOS: a Dock click now brings back a minimized window too, and wakes the app so the request is read (Spotifast ec75951). ZapFast only asked when AppKit reported no visible window, which a minimized window is not.
• Flatpak: the item registers the unique bus name (Spotifast 1c03c21).
• On Windows, dropping the tray now ends its thread and removes the icon (before, it lived until the process ended).

Spotifast

About 800 lines, of which 140 are the Flatpak private-bus test in tray.rs. fastframe tests do not start dbus-daemon, so that test is not in the crate; to keep it, rewrite it in Spotifast’s tests/ against fastframe_tray::Tray::spawn and events(), without the “previous registration method must fail” half (which needs ksni’s own builder).

Differences:

• macOS: the headless pump now runs -[NSApplication run] in slices (ZapFast 655509b). Spotifast’s nextEventMatchingMask:/sendEvent: loop can let an Objective-C exception unwind into Rust and abort (ZapFast #199). Media keys and the menu bar keep working, since AppKit’s own loop serves them.
• The labels are the app’s; Spotifast’s untranslated "Play", "Next"… can now go through its gettext.

Chat with Work

Not moving now: its tray shares one winit loop with the window (pump_app_events) and uses tray-icon 0.25. Its menu also needs what the crate doesn’t have yet: disabled status lines, a tooltip that changes, a dimmed icon while paused, and an item that relabels itself. It can adopt the crate once the crate grows those and moves to tray-icon 0.25, and if the app moves to the run-native loop.

fastframe-shell

The keep-running loop around eframe::run_native, the Waker, start hidden, and off-screen window recovery. Each app keeps its eframe::App wrapper (demo shots, tours, thumb bar, menus), its native options, and its decisions about when to hide, show, reopen and quit. Single instance stays in each app (see the crate README for why).

ZapFast

The Resident impl (about 25 lines in app.rs):

impl fastframe_shell::Resident for App {
    fn closed(&self) -> Closed {
        if !self.quit_requested && self.hide_intent { Closed::Hide } else { Closed::Quit }
    }
    fn window_gone(&mut self) { App::window_gone(self) }
    fn headless_frame(&mut self, ctx: &egui::Context) -> Headless {
        self.background_frame(ctx);
        if self.quit_requested { Headless::Quit }
        else if self.wants_show { Headless::Show }
        else { Headless::Wait }
    }
    fn start_hidden(&mut self) -> bool {
        if !self.hides_to_tray() { return false; }
        App::start_hidden(self); // sets hide_intent, releases the backend
        true
    }
    fn shutdown(&mut self) { App::shutdown(self) }
}

About 270 lines out, 25 in. Keep a_hidden_start_starts_the_backend_without_a_frame in app.rs: the crate tests that the shell calls start_hidden before any window, the app test that it releases the backend.

No behaviour changes. Moving the hide-to-tray check into start_hidden keeps the rule “without a tray there is no way back, so show the window”.

Spotifast

About 95 lines out, 25 in. The per-window option building (MiniWindow, native_options, profile_options, the thumb bar) moves into the run closure unchanged, since the closure runs once per window.

Off-screen recovery: Spotifast checks its own saved session positions before applying them (window::can_restore, the Windows work-area test of the title bar), which stays. It can add recover_offscreen on the main window’s first frame as a net for positions eframe restored itself; that is new behaviour on X11 and Windows, so it is optional.

No other behaviour changes.

Solco, TonePush, Chat with Work

Not moving: Solco and TonePush have no tray or background mode. Chat with Work keeps its window alive with pump_app_events on one winit loop, a different design.

fastframe-macos

Traffic lights in the app’s own title bar, the inset that clears them, and the title-bar double-click setting. Each app keeps its header heights, its double-click handling (which viewport command or AppKit selector it sends), and its application menus.

ZapFast

About 55 lines. The menu code in macos.rs stays. No behaviour change.

Solco

About 115 lines. Differences: a double-click setting the crate does not know (a future macOS value) now does nothing, where Solco zoomed.

Spotifast

About 35 lines. Difference: Spotifast now also honours the older AppleMiniaturizeOnDoubleClick switch when the newer key is unset. Spotifast keeps AppKit’s own traffic-light positions (its top bar is laid out around them), so align_traffic_lights is not needed there.

fastframe-update

Self-update from GitHub releases. Each app keeps its UpdateConfig (names, legacy names, macOS identity, publisher key), its HTTP client settings, and its update interface. The move below targets ZapFast 0.16.x and Spotifast 0.10.x. Take the reqwest feature:

fastframe-update = { git = "https://github.com/crmne/fastframe", rev = "<commit>", features = ["reqwest"] }

Both apps already build reqwest 0.12 with blocking, so the reqwest feature adds nothing to their trees; ring, sha2 0.11, url, serde and anyhow are already there too.

The first release built on the crate is installed by the previous release’s own updater, which is unchanged. What that old helper needs from the new binary stays the same: --version prints <slug> <version>, the new app accepts --update-receipt <job> and --update-error <message> (now through intercept), and it writes started next to the receipt. The crate’s compat tests cover the receipts of both apps’ current releases.

ZapFast

Delete

The 19 updater tests in those files move into the crate. Keep assets/update-public-key.hex, packaging/zapfast-portable.txt, packaging/windows/zapfast-installer.txt and packaging/UPDATE_SIGNING.md (point its verification paragraph at this crate).

Add

A new src/updates.rs of about 35 lines:

pub use fastframe_update::{
    CHECK_INTERVAL, DownloadState, Installation, Kind, Prepared, Release, Source, Unsupported,
    Updater,
};
use fastframe_update::{MacConfig, ReqwestTransport, UpdateConfig};

pub const CONFIG: UpdateConfig = UpdateConfig {
    // Cask and bundle names from before the rename. This also accepts
    // fastsapp-* marker files and `fastsapp <version>` answers, which no
    // release produces.
    legacy_names: &["fastsapp"],
    macos: MacConfig {
        bundle_ids: &["me.paolino.fastsapp"],
        executable_names: &[],
        legacy_bundle_names: &["FastsApp.app"],
    },
    publisher_key: Some(include_str!("../assets/update-public-key.hex")),
    ..UpdateConfig::new("crmne/zapfast", "ZapFast", "zapfast", env!("CARGO_PKG_VERSION"))
};

/// An updater on the proxy-aware reqwest client.
pub fn updater() -> anyhow::Result<Updater> {
    let mut builder = reqwest::blocking::Client::builder();
    if let Some(proxy) = crate::proxy::reqwest_proxy() {
        builder = builder.proxy(proxy);
    }
    Ok(Updater::new(CONFIG, ReqwestTransport::new(builder)?))
}

#[test]
fn update_config_is_valid() {
    CONFIG.validate().unwrap();
}

Replace

Command::InstallUpdate already moves the Prepared out of DownloadState::Ready with mem::replace, which suits the non-Clone Prepared.

Net: about 1,944 lines deleted and 60 added or changed, so roughly 1,880 fewer lines.

What changes for users

• The helper’s standard error goes to helper.log in the staging folder (as Spotifast does), and handoff names that file when the helper dies.
• A Nix install says “Update this installation with Nix.” instead of “with Nix or Homebrew”.
• A handoff into a staging folder that already holds a marker is refused (none can today, since each download gets a new folder).
• result.txt is written before the rolled-back app restarts, not after.

Spotifast

Delete

The 21 updater tests move into the crate. Keep the marker files in packaging/ (spotifast- and fastpotify-portable.txt, spotifast- and fastpotify-installer.txt) and the CI step that runs --apply-update on a missing job inside a real bundle: intercept prints the error to standard error and exits with 1, as today.

examples/updater-inspect.rs (11 lines) becomes a call to Updater::installation_at(&path).

Add

A new src/updates.rs of about 40 lines:

pub use fastframe_update::{
    CHECK_INTERVAL, DownloadState, Installation, Kind, Prepared, Release, Source, Unsupported,
    Updater,
};
use fastframe_update::{MacConfig, ReqwestTransport, UpdateConfig};

pub const CONFIG: UpdateConfig = UpdateConfig {
    legacy_names: &["fastpotify"],
    legacy_windows_installs: &["Programs/Fastpotify/fastpotify.exe"],
    macos: MacConfig {
        bundle_ids: &["rocks.spotifast.Spotifast", "me.paolino.fastpotify"],
        // 0.9.1 kept "fastpotify" for older clients' validation; later
        // releases may rename it to "Spotifast" (#538).
        executable_names: &["fastpotify", "Spotifast"],
        legacy_bundle_names: &["Fastpotify.app"],
    },
    // Checksums only until releases are signed; see below.
    publisher_key: None,
    ..UpdateConfig::new("crmne/spotifast", "Spotifast", "spotifast", env!("CARGO_PKG_VERSION"))
};

pub fn updater(proxy: &crate::settings::ProxyConfig) -> anyhow::Result<Updater> {
    let builder = crate::http::blocking_builder(proxy).map_err(anyhow::Error::msg)?;
    Ok(Updater::new(CONFIG, ReqwestTransport::new(builder)?))
}

Replace

Net: about 2,003 lines deleted and 70 added or changed, so roughly 1,930 fewer lines.

What changes for users

• The macOS helper runs from a copy of the whole bundle (ZapFast’s fix), not from the installed bundle. The installed bundle can then be moved and restored without touching the helper’s own code.
• portable_entry’s special case for the 0.8.0 and 0.9.0 archive layout is gone. Those versions are older than 0.10, so no app built on the crate can be offered them.
• The pre-marker Windows location now also checks the setup program’s current default, Programs/Spotifast/spotifast.exe, as well as Programs/Fastpotify/fastpotify.exe.
• A Nix install says “Update this installation with Nix.”

Turning on publisher signatures

Spotifast releases are not signed yet, so publisher_key stays None and the update is verified against checksums.txt alone. To sign:

1. Add native-packages’ sign-release step and a release-signing environment with the private key to the release workflow, as ZapFast has, and publish a release that carries checksums.txt.sig.
2. Only then ship a version with publisher_key: Some(include_str!(..)). From that version on, a release without a valid signature is refused, so every later release must be signed.

Older installs keep updating on checksums until they reach a version that embeds the key.

TonePush

TonePush has no updater of its own to delete: 0.6.1 only asks GitHub for the newest tag and links to it. It adopts the crate over its own ureq client, implementing Transport with redirects turned off, and without the reqwest feature.

Its archives hold two programs, the tonepush command-line tool and the tonepush-gui editor, beside one marker, so it sets portable_executable:

pub const CONFIG: UpdateConfig = UpdateConfig {
    portable_executable: Some("tonepush-gui"),
    macos: MacConfig {
        bundle_ids: &["rocks.tonepush.editor"],
        executable_names: &[],
        legacy_bundle_names: &[],
    },
    publisher_key: Some(include_str!("../../../assets/update-public-key.hex")),
    ..UpdateConfig::new("crmne/tonepush", "TonePush", "tonepush", env!("CARGO_PKG_VERSION"))
};

The editor answers --version with tonepush <version>, the slug, and the release workflow puts tonepush-portable.txt (tonepush-portable-v1) into the Linux and Windows archives. Only a running tonepush-gui beside that marker updates itself; the tonepush tool next to it never matches. Inside the macOS bundle the editor’s executable is tonepush, so the bundle needs no executable names. ZapFast and Spotifast leave portable_executable at None and nothing changes for them.

Solco

Solco has no updater yet, and every release so far is a GitHub pre-release (v0.5.0-alpha.2), so releases/latest answers 404. It turns on the pre-release channel:

pub const CONFIG: UpdateConfig = UpdateConfig {
    prereleases: Prereleases::WhenRunningPrerelease,
    mac_target: MacTarget::Arm64Only,
    publisher_key: Some(include_str!("../assets/update-public-key.hex")),
    ..UpdateConfig::new("crmne/solco-releases", "Solco", "solco", env!("CARGO_PKG_VERSION"))
};

An alpha is offered the highest newer release, alpha or stable; a stable build never sees an alpha. Its macOS build is Apple silicon only, so MacTarget::Arm64Only looks for solco-v<version>-macos-arm64.dmg, the name its release workflow already uses, and refuses an x86_64 copy with Unsupported::Platform. Before it ships:

• An expired alpha must still reach the update check, the download, the handoff and Receipt::acknowledge. Put the expiry gate after intercept and keep the update banner usable when the alpha has expired, or an expired copy can only be replaced by hand.
• --version prints solco 0.5.0-alpha.2, the full version. The macOS bundle’s CFBundleShortVersionString may stay the numeric 0.5.0 that packaging/macos/bundle.sh writes.
• The Linux and Windows archives need solco-portable.txt (solco-portable-v1), or those copies report NotPortable.
• A portable update replaces only the executable. The models folder, bundled libraries and alpha-release.json in the archive are not updated; a release that changes them needs the app to cope with the old ones, or a manual download.
• Once a stable release exists, publish it as a normal (latest) release: a stable build reads only releases/latest.
• The stable Windows installer is published as solco-v<version>-windows-x86_64-setup.exe; the updater expects solco-v<version>-x86_64-pc-windows-msvc-setup.exe. Rename it in the release workflow before installer copies are meant to update.

Deleted lines, both apps

About 3,950 lines of updater code and tests leave the two apps, replaced by about 75 lines of configuration and 130 of changed call sites. The crate is about 6,000 lines as formatted: about 2,900 of code and documentation and 3,100 of tests and test fakes.

Not moved yet: widgets

Widgets stay in the apps for now. These exist in two or more apps and are the candidates for a later fastframe-widgets, once the look crates above have settled:

Their sizes and colours differ by app, so a shared crate would take the palette through a small trait (or the BASE_COLORS names) rather than fix any app’s look.