--- title: "AutoBrew v2.5.4: Xcode 27, Pipeline Hardening" description: "Two AutoBrew releases in one week: v2.5.3 fixed auto-retry and pre-snapshot hooks, v2.5.4 moved the entire build to Xcode 27. Here is what that actually took." url: https://theapparchitect.com/blog/2026-10-19-weekly-update/ language: en --- Article # AutoBrew v2.5.4: Xcode 27, Pipeline Hardening Two AutoBrew releases in one week: v2.5.3 fixed auto-retry and pre-snapshot hooks, v2.5.4 moved the entire build to Xcode 27. Here is what that actually took. October 19, 2026, Marcel R. G. Berger, 6 min read - macos app development - autobrew - swift - sparkle - build-in-public - ios development AutoBrew shipped twice this week. Version 2.5.3 landed first, carrying a batch of fixes that had been piling up: auto-retry logic, pre-snapshot hook behaviour, free-space checking, and a translated legal hub. Version 2.5.4 followed the same day, built entirely with Xcode 27.0. No new features in that second release, just the toolchain upgrade and a hardened release pipeline. Small on the surface, more work underneath than I would like to admit. ## Two Releases, Three Things Worth Explaining ### Auto-Retry and Approval Persistence The most user-visible fix in v2.5.3 was in the upgrade approval flow. AutoBrew lets you require explicit approval before it installs an update. That approval should stay valid until the upgrade actually succeeds. It was not doing that. If an upgrade attempt failed partway through, the approval was being discarded, which meant the app would not retry automatically even if you had told it to. You had to go back into the queue and approve again manually. The fix was straightforward once I found it: approvals now persist in the queue entry until the upgrade reports a clean success. Auto-retry selection also had a related problem where the wrong queue item was being acted on after a failure. Both are fixed in v2.5.3. The commit message says “fix auto-retry selection and keep approvals until the upgrade succeeds”, and that is exactly what it does. Not glamorous work, but the kind of thing that makes an automated tool feel trustworthy instead of flaky. ### Pre-Snapshot Hook Timeout AutoBrew can run a shell hook before it takes an AppSnapshot. Useful if you want to flush a database, close a file, or run your own backup script before the snapshot captures application data. The problem: if that hook hung or ran too long, AutoBrew would just wait. No timeout, no cancellation, no feedback to the user. I added a hard timeout enforcement in v2.5.3. The hook now gets a defined window to complete. If it does not finish in time, AutoBrew cancels it and proceeds, logging the fact that the hook timed out. There was also a separate build error with the hook target under Xcode 26 that I had to untangle before I could even test the timeout logic. That took longer than the timeout feature itself. Fixing a compile error in a pre-snapshot hook target is the kind of yak-shaving that does not show up in release notes but absolutely shows up in commit history. ### Moving the Build to Xcode 27 This is the one that looked simple and was not. The plan was straightforward: build everything with Xcode 27.0, pin Sparkle to 2.9.0, update the appcast, done. The actual sequence involved several intermediate steps I had not anticipated. For a while I kept beta and release builds on Xcode 26.6 while running CI against Xcode 27 on a separate runner. That was a deliberate hedge while I verified that nothing broke at the toolchain level. Once CI came back clean, I merged the Xcode 27 build into test, then beta, then main. The release pipeline itself got hardened in the same batch of commits: it now guards against supply-chain changes that could silently affect the build environment. I am not going into full detail on what that means here, but the short version is that a dependency update in the runner should no longer be able to alter a release build without me noticing. The thing I am still not fully happy with is the number of merge commits this produced. Four branches, three channels, multiple merges in a single day. The history is correct but noisy. I will look at whether I can consolidate the channel pipeline next time I touch the CI configuration. ## Side Notes: theapparchitect.com The other active repo this week was this site. Several things moved at once. The biggest was IndexNow. After every deploy, the site now compares page hashes against the live version, identifies new, changed, and removed URLs, and submits them directly to Bing and the other IndexNow-compatible search engines. I added a wait step before the submission so the key file is actually reachable on the live domain before the ping goes out, and a retry loop for 403 responses. Without the wait, the first deploy after a cold start would fail the key verification and the submission would be silently dropped. I also replaced an AI-generated portrait with a real photo, rewrote the regional service pages to get similarity scores below 55 percent (two pages that are too close to each other are a problem for search ranking, not just aesthetics), and fixed three old URLs that Google was still crawling as 404s by adding proper redirects. Mobile performance got a pass too: critical CSS is now inlined rather than loaded as a blocking stylesheet, and Latin character subsets use `unicode-range` so the full font file only loads when it is actually needed. None of this is as satisfying to write about as shipping a macOS feature. But it is the work that determines whether anyone finds the site in the first place. ## What This Looks Like from the Outside If you are thinking about having a custom macOS app built, weeks like this one are worth paying attention to. Not because of the specific features, but because of what the commit sequence shows: two releases in one day, each with a clear scope, both moving through test and beta before hitting main. That kind of structured release process is not something you get from a freelancer who ships to a single branch and calls it done. It matters especially for apps that run in the background and update themselves automatically. Users have to trust that an update will not break something. That trust is built in the pipeline, not in the UI. If you are considering a similar project, [take a look at what I build and how I work](https://theapparchitect.com/work/). If it looks like a fit, [get in touch](https://theapparchitect.com/contact/). The AutoBrew source and full release history are on [GitHub](https://github.com/marcelrgberger/auto-brew). ## More on this topic - macos app development ### [AutoBrew v2.4: Snapshots, CLI, and a Signing Fight](https://theapparchitect.com/blog/2026-05-25-weekly-update/) AutoBrew v2.4 landed this week with pre-upgrade snapshots, a URL-scheme CLI, and a brew doctor health view. Also: an Apple signing rabbit hole I didn't see coming. Read more - macos app development ### [Civo Cloud Manager: 16 Languages, a New Icon, and a Paywall](https://theapparchitect.com/blog/2026-09-14-weekly-update/) This week I shipped a seven-day free trial, localized Civo Cloud Manager into 16 languages, and rebuilt the marketing site from scratch. Here is what that actually involved. Read more - macos app development ### [Civo Cloud Manager: Guide Pages, Keyword Cannibalism, and a Slow Week](https://theapparchitect.com/blog/2026-09-21-weekly-update/) Six guide pages across 16 locales and a keyword cannibalism fix. This is what a thin week looks like when you work alone. Read more