Nightly Builds & Safari Extension Beta Builds?

XIII Thanks for the correction. 😅

I had misinterpreted the WWDC session.

It supports native Mac apps and iOS apps on Apple Silicon Mac.

I now realize they meant that you can use TestFlight to test Mac apps on Intel hardware running Monterey, and you can test both Mac apps and iOS apps on Apple Silicon.

Currently Mac App Store TestFlights are limited to Apple Silicon hardware running the macOS Monterey Preview

Are you sure about that?

I'm running several TestFlight beta's in my macOS Monterey VM in Parallels Desktop on my (Intel) MacBook Pro (16-inch, 2019).

Hi nimvio ,

The short version nightly builds are "more beta than beta", and we don't have plans to offer beta 1Password for Safari releases in the near future.

Nightly builds

Most users would be better served on the PRODUCTION or BETA channels. You'll get to see new features sooner on NIGHTLY, but it can be a bumpy ride.

We built the NIGHTLY channel for us, but kept it visible to allow curious users to explore. We use a git workflow that is based on Merge Requests (MRs). When we're building a new feature, or working to solve a bug we branch from main. A gitlab MR is required to bring those changes back into main. This review requires at least one other developer to approve. Particularly sensitive areas of the code (like cryptography) are further protected with gitlab's Code Owner feature. Changing those areas requires reviews and approvals from specific teams.

The merge request runs a variety of automated tests before merging into main. These range from static analysis tools like lint or clippy to more traditional unit tests and Build Verification Tests (BVTs).

Typically once per day, a NIGHTLY release is automatically built from the current state of main, and is automatically tested and published. Sometimes a NIGHTLY release will be skipped because something broke in the pipeline. Sometimes we'll be working on the updater, and we may trigger a dozen NIGHTLY releases in a single day.

We branch from main when we're ready to create a new BETA. Our QA team runs though Release Candidate Tests (RCT). If an important issue is found, we'll create a MR to fix it, review and merge the fix into main, and then git cherry-pick the change into our release branch and create a new build. Once we're satisfied with the release, we manually start the jobs to publish the beta.

The process for PRODUCTION is similar to BETA. Instead of basing the release freeze branch on main, we base it on the previous BETA release. We'll cherry-pick fixes into the release freeze branch, make a new build, and QA will run tests on it.

1Password for Safari beta releases

Distributing Safari Web Extensions is complex. Either users would need to allow unsigned extensions or the beta extension would need to be distributed in TestFlight via the Mac App Store. Allowing unsigned extensions is dangerous, and there are very few legitimate reasons to do so. We're not going to encourage our users to disable that safety feature, which means our only option for beta distribution is TestFlight.

TestFlights for the Mac App Store are very new. If you look at https://testflight.apple.com/, it still says "TestFlight is not available for Mac apps." Apple started to role out the ability to run Mac TestFlights this summer. Currently Mac App Store TestFlights are limited to the macOS Monterey Preview.

I wouldn't say we'll never do public TestFlights for the browser extension, but we don't have any plans to do so.

Edit: I was incorrect about the Apple Silicon requirement for TestFlight on macOS.