On the morning of July 13, the iOS 27 public beta announcement showed up, and the first thing I checked was the build number. 24A5380h. The same string already sitting on my test device as developer beta 3.
That settled it. There was no work to do.
It was just a build number matching, but beta season is mostly made of small checks like this one — confirm, then move. Maintaining apps on my own means the devices and hours available for testing are finite. Which is exactly why a few things have to be decided before anything gets installed.
What a matching build number tells you first
The public beta shipping as 24A5380h is the identical build to developer beta 3. Different label, same bits.
The read is simple. If a device is already on the developer beta, moving it to the public beta gains you nothing, because there is nothing new on the other side.
If you have not installed anything yet, though, the public beta is now the shortest path to iOS 27. You reach the same bits without routing through developer account setup.
| Where you are | What to do as of July 13 |
|---|---|
| Developer beta 3 is installed | Nothing. Same build, so switching is a no-op |
| No beta yet, and you own a spare device | Put the public beta on the spare |
| No beta yet, and you own one device | Skip it — reasoning in the next section |
What's inside: new Apple Intelligence capabilities, a stronger Siri, new parental controls, Liquid Glass refinements (there's now a slider for how strong the effect looks), Spotlight improvements, and general performance work.
Of that list, the one that lands directly on your app's appearance is the Liquid Glass intensity slider. I'll come back to why.
Pick the device before you install anything
The hardest thing to undo in beta season isn't the OS. It's the device you chose to put it on.
Signing for older iOS versions eventually closes, and once it does there is no supported route back. On top of that, a backup taken on the newer OS won't restore onto the older one. So "install it, and roll back if it goes badly" tends to be a one-way trip in practice.
Three lines I hold:
- Nothing goes on the device carrying my daily messages and payments
- Nothing goes on the device I use for final on-device purchase-flow checks
- The beta device never signs in with my primary working accounts
| Device role | iOS 27 beta? | Why |
|---|---|---|
| Daily driver | No | With no way back, the personal-life risk is too large |
| Production-equivalent purchase testing | No | It muddies triage for the app that's actually shipping |
| Dedicated older test device | Yes | Damage stays inside something you can wipe and rebuild |
With a single device, I come down on the side of not installing. The pull to try it is real, but when a support message arrives about the live app, a beta phone leaves you unable to separate "app bug" from "beta OS behavior." An environment you can't separate isn't a test environment.
What to archive before it goes on
Once I've decided a device gets the beta, three things get saved first.
A backup taken on the current OS. Anything captured after the beta lands won't restore to where you were. I keep an encrypted backup of the moment before.
The artifacts for the build currently on the App Store. The .ipa and the dSYM for exactly what's live. If you find a crash under the beta, a log you can't symbolicate is barely a lead.
A full set of screenshots on the current OS. This is the one that pays off most this cycle. An intensity slider for Liquid Glass means the same screen can look different on the same device. Without a reference shot, you can't tell whether the beta changed something or whether it always looked that way.
Separately: the requirement that uploads to App Store Connect be built with the iOS 26 SDK or later has been in force since April 28. That's a different thread from beta testing, and keeping them apart saves confusion. Whether your submission pipeline already satisfies it is a check to finish before beta work, not during it.
Where to look in your own app
I don't have the hours to sweep every feature on a beta device. I guess at the likely damage and order the work.
The app I maintain deals in background imagery, and it leans on one structural pattern: a translucent panel over a photo, with text on top of the panel. The Liquid Glass intensity slider lands right there. Turn the intensity down and the photo behind the panel carries more detail; turn it up and it carries less — and the contrast of the text above it moves with it.
So my check starts at the slider's minimum and its maximum, asking only whether the text is still readable. Both ends, not the middle, because if it breaks, it breaks at the ends.
| iOS 27 change | Where to look in your app | How I rank it |
|---|---|---|
| Liquid Glass intensity slider | Any screen with text over a translucent panel | High — a user setting now changes your rendering |
| Spotlight improvements | App Intents and anything you index | Medium — it's the side where exposure can grow |
| New parental controls | Age-related flows and surfaces | Depends on your audience |
| Apple Intelligence and Siri | Intents you expose | Skip it if you expose none |
How far to lean on the OS-side AI inside your own app is a design question rather than a beta-testing one. I worked through that boundary in Delegate to the OS AI or Own It: Drawing the iOS 27 Feature Boundary.
Fold the routine into the same shape every time
Betas keep coming. Improvising the check each round means the set of things you look at drifts, and drifted checks can't be compared later.
I keep the checklist inside the repository — device roles, what to archive, the order of screens to review, in plain text. Each beta, I open it, and when I'm done I add one line about whatever surprised me.
Parts of it automate cleanly. But I keep the delegated scope narrow.
| Task | Delegate to an agent? | Why the line sits there |
|---|---|---|
| Walk every screen and capture screenshots | Yes | Fixed procedure, and the result lands as files |
| Diff those images against the current-OS set | Yes | Listing what moved is machine work |
| Judge whether a diff is acceptable | No | Readability needs a human looking at it |
| Decide which device receives the beta | No | No reason to delegate an irreversible choice |
Anything whose inputs live entirely inside the repository, I hand off. Anything that lives outside it — devices, appearance — stays with me. That's the whole rule.
On distribution, App Store Connect now accepts TestFlight builds made with the Xcode 27 beta, which is the lowest-friction path for getting builds onto a test device. I wrote up automating that pipeline in Automate TestFlight Beta Distribution with Antigravity: A Practical Guide.
Official design kits for Figma and Sketch are also available now for iOS 27, iPadOS 27, and macOS 27. Sizing up the damage in design before touching hardware is a legitimate option.
The next step
If developer beta 3 is already installed, there's nothing to do this round. Same build, so standing still is the correct move.
If you haven't installed yet, the first decision is the device — not the OS. Before it goes on, ask yourself whether you could wipe that phone and rebuild it from scratch. If the answer is no, it isn't a test device.
I once assumed I could roll back, and paid for the assumption. If this saves someone that detour, I'm glad.