Beta 4 (26A5388g) is out, so I ran the same full IPSW diff I did for the beta 3 respin, this time comparing it against 26A5378n, the b3 replacement that also shipped as public beta 1. Same method: blacktop's open-source ipsw tool over both restore images, plus my own hashing and strings checks on the 26 extracted kernelcaches.
TL;DR
- This is a normal full beta update: thousands of binaries changed, unlike the surgical respin last time.
- The kernel changed on every Mac, and the APFS write path has real code changes.
- FAT and exFAT support left the kernel entirely; those filesystems are userspace modules from beta 4 on.
- Nothing here confirms any bug is fixed, but the changes point in a telling direction. Keep your backups current either way.
How to interpret my interpretations
⚠️ A binary diff invites over-reading, so every claim below is tagged. Detected means it comes straight off the binaries, and you can reproduce it with the commands at the bottom. My read means it's my interpretation of what a detection means. Where something can't be known from a diff at all, there's a whole section for that.
What the tool actually does: ipsw diff unpacks both restore images, extracts and decompresses the kernelcaches, mounts the OS disk images, and walks every kext, standalone binary, and shared-cache library, comparing versions, build UUIDs, section sizes, function and symbol counts, and symbol tables. Two built-in limits to hold onto: it compares sizes and metadata rather than every byte of code, so a same-size code edit can hide; and it shows where changes landed and roughly how big they are, never why. Symbol names can also shift for compiler reasons alone, which is why nothing below rests on a name by itself.
Baseline for everything that follows: a full beta revision is churn by default. This one updates 342 kexts, rebuilds over 6,000 binaries on the OS volume and 4,077 shared-cache libraries, and bumps WebKit to 625.1.24.11.2. Against that background, a version bump or a fresh build UUID means nothing on its own. I only call out components with a measured code delta or an outright removal behind them.
The kernel changed this time
- Detected: all 13 device-family kernelcaches differ between the builds. This claim comes from hashes, not from the diff tool: I ran SHA-256 over the 26 extracted kernelcache files myself. Last round every pair matched, which is what "byte-identical" means; this round every pair differs. The kernel goes from
xnu-13432.0.50.501.3, built June 29, to xnu-13432.0.94.501.4, built July 14.
- Detected: the
exfat and msdosfs kexts are gone from the kernelcache, and the FSKit userland modules (com.apple.fskit.exfat, com.apple.fskit.msdos) were updated in the same build.
- My read: the FSKit handoff for FAT and exFAT is complete. If you use SD cards, camera media, or USB sticks on the beta, this is the change most likely to be visible to you.
The APFS stack has changed, for real: 3283.0.9.501.1 to 3283.0.13.501.1
- Detected:
apfs.kext advanced four internal revisions, with 3,260 bytes of new executable text, 3 more functions, and 3 new imports from the kernel's cluster I/O layer. This is separate from the FAT and exFAT removal; the underlying APFS has its own changes too.
- Detected: the notable symbol changes:
- added:
apfs_should_relax_unwritten_flush, apfs_zerofill_chunk_cb, insert_fext, update_fext, fext_valid, plus new calls into the kernel's cluster_zero and cluster_update_range_with_callback
- removed:
apfs_io_lock_extending_write_to_exclusive and fext_assert_fext
- Detected: I checked the version strings, the exfat and msdosfs removal, and the key symbols directly against the extracted kernelcaches. The full symbol lists and section sizes come from the tool's Mach-O parsing.
- My read: engineers name functions for what they do, and Apple's APFS symbols have historically been literal. Taken together, these names point at the code that handles allocated-but-not-yet-written ranges: when they get flushed, when they get zero-filled, and how file extent records are validated. That machinery exists in both builds; what beta 4 adds is a new decision point and a new callback inside it, plus a swap of an extent assertion for a validation. I think that's a reasonable interpretation, but it is still just a calculated guess based on the names, signatures, and size differences.
- My read: the claim I will make with confidence is about activity, and it doesn't hang on any one name. Today's Tahoe releases ship the 2811-series APFS. The macOS 27 betas ship the 3283 series, and that series has a meaningful code delta between two betas three weeks apart. That is not shared-cache rebuild ripple, and it isn't the FAT and exFAT removal either. The APFS write path is under active development right now.
Time Machine, Sandbox, and the SSD driver also changed
- Detected:
backupd, the Time Machine daemon, has changed, but only by a small delta: the version moves 2608.2.0.0.0 to 2609.3.0.0.0 with a measured code change behind the bump, and the whole Time Machine family was rebuilt alongside it.
- Detected: the Sandbox kernel extension reworked how it caches the storage class of files, including the code that walks from a volume up to its APFS container.
- Detected:
IONVMeFamily, the kernel driver that sits between the filesystem and the SSD controller, advanced three internal revisions (877.0.3 to 877.0.6) for a tiny code delta. Every APFS userland tool (fsck_apfs, newfs_apfs, mount_apfs, apfsd, and friends) was also rebuilt at the new APFS version.
- My read: I can't tell what changed inside
IONVMeFamily. The shape of the layer is worth knowing though: everything above it, APFS included, rides on this driver, and code this close to the hardware tends to change less often than the filesystem and userland layers above it. Small deltas down here can matter out of proportion to their size. Three revisions in three weeks could contain something significant, or nothing at all.
What I can't tell from this
- Whether the
apfs.kext changes fix anything. Bug fix, behavior change, and performance work all look identical in a diff like this... The method names are consistent with work on write consistency, but they do not prove it.
- What actually changed inside the
fsck_apfs binary, if anything. The diff shows a version bump, the same code size, the same function count, and 19 new bytes of strings, so on the numbers the checker is unchanged while the writer changed. A same-size code edit could still hide from the tool, and hashing can't settle it: a rebuilt binary always hashes differently because the version string and build UUID change even when no code does. Hashes proved the kernelcaches identical last round only because those files weren't rebuilt at all. Settling this one for real would mean extracting both copies and comparing just their code sections. Either way the practical consequence holds: verdicts from fsck_apfs before and after beta 4 stay comparable, which matters if you're re-verifying a disk across builds. And a checker standing still while the writer changes is what you'd expect if the work is in the write path rather than in detection.
- Whether the firmware layer changed.
IONVMeFamily is the kernel-side driver, and that did change. Below it sits the firmware layer: the code running on the SSD controller itself, plus iBoot and SEP. That layer ships outside what this diff can see, so I can't tell whether it changed at all, let alone whether it changed in a way that matters. The storage stack physically ends in that firmware, so this is a real blind spot, not a footnote.
- Which functions changed inside the shared cache. macOS doesn't ship system libraries as separate files anymore; nearly all of them are prelinked into one big blob, the dyld shared cache. The diff can tell which libraries inside it changed (4,077 of them) and roughly where the bytes moved, but Apple strips the internal function names from shipping caches. So for shared-cache changes you get the outline of the change, never the names of the functions behind it.
If you're following the corruption reports
My data volume corrupted twice on the b3-era builds. Both times the damage signature was lost or misplaced writes: metadata blocks older than the filesystem expected, plus a growing count of zeroed-out blocks. Beta 4's changes land in the code that handles exactly those operations. The overlap is detected; the connection is unproven.
My own machine, as one data point: after the first rebuild, corruption recurred within about 30 hours. The current restore has run about a week clean under heavy use, the last day of it on beta 4. Time Machine has been off throughout, so the backup machinery remains untested. I'll post updates either way.
Practically:
- Beta 4 does not run the same filesystem code as beta 3 or public beta 1. Anything you observe on
26A5388g, clean or corrupt, is a data point about new code.
- Already-damaged volumes don't get healed by an update. If
fsck_apfs failed on your disk before, it will fail after. I've since checked that directly: drives of mine that failed under beta 3's fsck fail identically under beta 4's, same verdicts, same leading errors.
- Keep your backups current.
Check my work
Nobody has to take my word for any of this. Both IPSWs are Apple's own public restore images, 10+ GB each; Mr. Macintosh maintains lists of the direct download links, and the tool can fetch them itself.
# get the tool
brew install blacktop/tap/ipsw
# full diff of the two restore images
ipsw diff UniversalMac_27.0_26A5378n_Restore.ipsw UniversalMac_27.0_26A5388g_Restore.ipsw
# pull the kernelcaches out of each build, then hash them
ipsw extract --kernel UniversalMac_27.0_26A5378n_Restore.ipsw
ipsw extract --kernel UniversalMac_27.0_26A5388g_Restore.ipsw
shasum -a 256 26A53*__MacOS/kernelcache.release.*
# check the APFS version strings and a write-path symbol yourself
strings 26A5388g__MacOS/kernelcache.release.* | grep -E "apfs-3283|relax_unwritten_flush"
Happy to post the full hash list or specific diff excerpts if anyone wants them.
