Back to the dev blog Engineering update

After 1.0.0: what is in development

Read this article in: English · 中文 · 日本語 · Español · Français · 한국어 · Українська

SyncTrans 1.0.0 shipped in mid-August. The final tag (build 13, August 19) carries one last change on top of the build the download button serves, and it is bookkeeping rather than a feature: the Mac App Store build no longer offers in-app updates that the store already delivers, which review asked for. Since then, nothing newer has shipped. If you want to know what a given build does, the release notes remain the only page that counts.

The repository, however, has not been idle. Two lines of work landed on development branches in the week after the tag. This post describes them honestly, which means starting with the disclaimer: everything below is in development, unreleased, and not promised for any date. We are writing about it because the alternative is a changelog-shaped silence that reads as inactivity.

A hybrid engine: three slots instead of one plan

In 1.0.0 the engine mode is a single choice: on-device, managed cloud, or custom service, and the choice applies to recognition, translation and speech together. That is the right shape for a first release, and it is also too coarse for the requests we actually receive — people who want cloud translation quality but on-device recognition, or local translation with a better hosted voice.

The work in development replaces the single plan with three independent slots — recognition, translation, speech — each filled from its own allowed sources. The design went through paper before code: the first draft was reviewed, rejected with a list of blockers, and revised until the reviewers converged. The rules that survived that process say a lot about where 1.0.0's sharp edges were:

  • No silent fallbacks. If a slot fails mid-session, the turn fails visibly in the timeline and names the slot at fault. The session waits for the next sentence rather than quietly switching to a different source — after repeated failures a banner suggests changing that slot, and switching is always the user's explicit choice.
  • The plan is frozen when a session starts. Changing settings mid-conversation cannot reshape a running session; the next start picks it up. That removes a whole class of half-applied states.
  • Billing cannot charge twice for one call. When a cloud slot is involved, each logical operation carries a stable idempotency key that the server de-duplicates on, so a retried request is answered from the record of the first attempt rather than billed again.
  • Languages are checked against the combination, not the plan. Which pairs a session can offer is computed as the intersection of what the three chosen sources can each do, validated before the session starts — so a mixed setup cannot promise a language that only two of its three stages support.

None of this changes what shipped: the three 1.0.0 engine modes remain exactly what they are, and a mixed configuration is an addition, not a replacement.

Local-mode hardening

The second line of work is smaller and more tactical: three fixes aimed at the on-device experience, developed together on a hardening branch.

Model downloads now pick up where they left off instead of restarting, and a failed download shows its failure on the model card rather than disappearing. Cancellation got the same treatment — stopping a download reaches every in-flight piece of it, and a cancelled download says that it was cancelled instead of looking like an error. The third fix is about honesty in the UI: the app now says up front where the macOS system voice is what you will actually get (the GGUF model sets ship no speech package, so they use the system voice), and languages the system voice cannot speak — Indonesian is the concrete case — are labelled as such before you build a configuration around them.

Each of these is the kind of thing that only bothers you once, and then every time. They are merged among themselves but not into any release.

What we are deliberately not saying

No version number and no date attach to any of this, because neither exists yet. The hybrid engine in particular is a large change to the part of the app that handles money and privacy at the same time, and it ships when its own bar is met, not on a schedule. When any of it does ship, it will appear in What's New with a version number attached — that page, not this blog, is the source of truth for what a build contains.

If one of these directions matters to you — or a different one does — the feedback board genuinely influences what gets finished first.