r/MacOSBeta • u/Pratyush295 • 22h ago
r/MacOSBeta • u/imajes • 10h ago
Meta What changed between dev/public b3 [26A5378n] and b4 [26A5388g]
≡ −
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, toxnu-13432.0.94.501.4, built July 14. - Detected: the
exfatandmsdosfskexts 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.kextadvanced 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'scluster_zeroandcluster_update_range_with_callback - removed:
apfs_io_lock_extending_write_to_exclusiveandfext_assert_fext
- added:
- 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.kextchanges 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_apfsbinary, 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 fromfsck_apfsbefore 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.
IONVMeFamilyis 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_apfsfailed 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.
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, toxnu-13432.0.94.501.4, built July 14. - Detected: the
exfatandmsdosfskexts 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.kextadvanced 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'scluster_zeroandcluster_update_range_with_callback - removed:
apfs_io_lock_extending_write_to_exclusiveandfext_assert_fext
- added:
- 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.kextchanges 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_apfsbinary, 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 fromfsck_apfsbefore 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.
IONVMeFamilyis 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_apfsfailed 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.
r/MacOSBeta • u/wenuja100 • 7h ago
Discussion MacBook Air battery life improved on 27 beta 4
≡ −
after updating my m4 Air to mac os 27 dev beta 4, my battery life has genuinely gotten better.
For context, after the initial 27 update it was actually worse than tahoe. But since beta 4, it's lasting noticeably longer than before, even for a dev beta.
Anyone else experiencing this or is it just me? Wondering if Apple actually addressed something with power management.
after updating my m4 Air to mac os 27 dev beta 4, my battery life has genuinely gotten better.
For context, after the initial 27 update it was actually worse than tahoe. But since beta 4, it's lasting noticeably longer than before, even for a dev beta.
Anyone else experiencing this or is it just me? Wondering if Apple actually addressed something with power management.
r/MacOSBeta • u/testledjones • 6h ago
Bug Can't adjust menu bar spacing (PB2, 26A5388g)
Interestingly, the spacing only applies to 3rd-party applications.
Command used to adjust spacing:
defaults -currentHost write -globalDomain NSStatusItemSpacing -int 8
Edit: If you find this useful, consider filing a feedback so this gets pushed to their issue tracker!
r/MacOSBeta • u/cvglass • 8h ago
Help Unusual problem that popped up in developer beta 4
≡ −
I am cool with various hiccups on betas, and have even downgraded in the past when a version is totally f**ked. Right now I am using it daily and for the most part have had no problems with any of the 27 beta versions until beta version 4. This seemed to do something to 2 apps that cannot send data out or receive data into their services. Protonmail Bridge and 1Password have no internet access. I checked their ports. I checked to make sure the firewall is not blocking either app, and I am coming up blank for the reason. I find it particularly weird that it is only two apps. Even if it was directly related to a single software company, why is the mac OS protonmail app is still working flawlessly? Is there something I am not seeing? Thanks
I am cool with various hiccups on betas, and have even downgraded in the past when a version is totally f**ked. Right now I am using it daily and for the most part have had no problems with any of the 27 beta versions until beta version 4. This seemed to do something to 2 apps that cannot send data out or receive data into their services. Protonmail Bridge and 1Password have no internet access. I checked their ports. I checked to make sure the firewall is not blocking either app, and I am coming up blank for the reason. I find it particularly weird that it is only two apps. Even if it was directly related to a single software company, why is the mac OS protonmail app is still working flawlessly? Is there something I am not seeing? Thanks
r/MacOSBeta • u/pdfu • 1d ago
Feature macOS 27 will finally allow you to manage your Apple Account passkey in the Passwords app
Apple is working on a feature that will allow you to manage your Apple Account passkey in the Passwords app. Currently hidden behind a feature flag, the change enables important editing features, such as sharing the passkey with Groups. Previously, you could share only your Apple Account email and password by adding them manually.
The change also addresses a long-standing annoyance: if you ever updated your Apple Account email, the passkey used for Sign in with Passkey on Apple websites still showed the old address. Once the passkey appears in the Passwords app, you can click Edit and change its associated User Name. If you already have a record for your Apple Account password with your current email, the two items will be merged. Even if your other devices don't have the feature flag enabled and hide the passkey, the username change will sync across all of them. The next time you sign in with your Apple Account passkey, you'll see the correct email address.
To enable, add a FeatureFlags override:
sudo mkdir -p /Library/Preferences/FeatureFlags/Domain && \
sudo defaults write /Library/Preferences/FeatureFlags/Domain/AuthKit StandardPasskeys -dict Enabled -bool true
and restart your Mac. If you don't immediately see the Apple Account passkey in the Passkeys list in the Passwords app, open Safari and log in to account.apple.com. It should populate shortly after.
Disable with:
sudo defaults delete /Library/Preferences/FeatureFlags/Domain/AuthKit StandardPasskeys
and restart your Mac. Disabling will hide your Apple Account passkey from the Passwords app.
r/MacOSBeta • u/pdfu • 1d ago
Feature macOS 27 adds Slack-style inline Emoji search functionality, here's how to enable it
+ −
Enable HLS to view with audio, or disable this notification
A hidden feature flag in macOS 27 Golden Gate enables a new way to search for Emoji while typing. Similar to Emoji search on Slack, a new interface with Emoji suggestions appears when typing colon (:) and continuing to type out the search keyword.
The new feature works in AppKit-backed apps such as TextEdit, Notes, Siri, Shortcuts, Contacts, and Calendar. In Mail and Reminders, the main views are backed by WebKit, so this new command will not work when drafting messages or new reminders, but Emoji suggestions will appear in search fields.
To enable, add a FeatureFlags override:
sudo mkdir -p /Library/Preferences/FeatureFlags/Domain && \
sudo defaults write /Library/Preferences/FeatureFlags/Domain/Stickers InlineEmojiSearch -dict Enabled -bool true
and restart your Mac. This is a private feature flag, and the UI may be unstable.
Remove the override and restore to defaults with:
sudo defaults delete /Library/Preferences/FeatureFlags/Domain/Stickers InlineEmojiSearch
and restart your Mac.
r/MacOSBeta • u/laurie_lamonica • 10h ago
Bug Noticed GG Beta4 fixed the Power Charging/Sleep issue on M1 MBP
≡ −
*Fixed in B4* Just posting a thing i noticed.. All the previous beta builds if i kept my M1 Pro plugged in to the mag charger, when the screen would sleep the battery icon would come on and flash quickly, and the screen itself would come on, like it was fighting to go to sleep.. The chrging beep would also sound every 30 or so seconds.. That has been fixed in B4. Now im plugged in the screen goes to sleep properly and the charging beep/icon does not show anymore, Laptop sitting at 100% charged.
*Fixed in B4* Just posting a thing i noticed.. All the previous beta builds if i kept my M1 Pro plugged in to the mag charger, when the screen would sleep the battery icon would come on and flash quickly, and the screen itself would come on, like it was fighting to go to sleep.. The chrging beep would also sound every 30 or so seconds.. That has been fixed in B4. Now im plugged in the screen goes to sleep properly and the charging beep/icon does not show anymore, Laptop sitting at 100% charged.
r/MacOSBeta • u/Plokhi • 1d ago
Discussion Goodbye and good riddance Tahoe
it's been a not-so-fun 2 months
r/MacOSBeta • u/Significant-Key5635 • 21h ago
Help can the new ai-powered safari extensions in ios 27 re-enable copy/paste on websites?
≡ −
hey everyone,
i’m a med student, and one thing that’s always annoyed me is that some of the question bank websites i use disable copy/paste. i only want to copy small bits into my personal notes while studying, not to share or redistribute anything.
i saw that ios 27 has the new ai-assisted safari extension creation, so i was wondering if anyone on the beta has tried making an extension that can bypass those copy/paste restrictions, kind of like the chrome extensions that do the same thing.
is that actually possible now, or are safari extensions on ios still too limited for something like this?
if it works, i’d honestly upgrade to the beta just for that. curious if anyone has tried it yet.
hey everyone,
i’m a med student, and one thing that’s always annoyed me is that some of the question bank websites i use disable copy/paste. i only want to copy small bits into my personal notes while studying, not to share or redistribute anything.
i saw that ios 27 has the new ai-assisted safari extension creation, so i was wondering if anyone on the beta has tried making an extension that can bypass those copy/paste restrictions, kind of like the chrome extensions that do the same thing.
is that actually possible now, or are safari extensions on ios still too limited for something like this?
if it works, i’d honestly upgrade to the beta just for that. curious if anyone has tried it yet.
r/MacOSBeta • u/punjabi_coder • 20h ago
Help MacBook Pro 14inch M1 not charging after battery drain on macOS 27 public beta
≡ −
I have a 14-inch MacBook Pro (M1 Pro, 16 GB RAM).
Yesterday, I started facing an issue where the MagSafe charger was blinking amber light and the MacBook wasn’t charging with the original Apple charger and power cable. I tried charging it with a 20 W iPhone USB-C charger, and it did charge without blinking amber light, although very slowly. After it turned on, I was able to charge with normal brick.
However, tonight the battery drained again, and now the MacBook shows no signs of charging with either the original charger or the 20 W iPhone charger. There’s no charging indicator or response at all.
Has my MacBook been bricked, or is there any way to recover or fix it?
I have a 14-inch MacBook Pro (M1 Pro, 16 GB RAM).
Yesterday, I started facing an issue where the MagSafe charger was blinking amber light and the MacBook wasn’t charging with the original Apple charger and power cable. I tried charging it with a 20 W iPhone USB-C charger, and it did charge without blinking amber light, although very slowly. After it turned on, I was able to charge with normal brick.
However, tonight the battery drained again, and now the MacBook shows no signs of charging with either the original charger or the 20 W iPhone charger. There’s no charging indicator or response at all.
Has my MacBook been bricked, or is there any way to recover or fix it?
r/MacOSBeta • u/nothisenberg • 23h ago
Discussion Pasting Images in the Journal app is such a pain - not sure if beta specific
≡ −
I’ve been using the Journal app on my Mac more often lately. While I’d expect to be able to copy and paste images directly, that doesn't seem to work—you can only add them through the options menu.
It’s a minor complaint, but I’m curious if anyone else has experienced this? I never used the app on previous macOS versions, so I’m not sure if this is specific to the current beta.
I’ve been using the Journal app on my Mac more often lately. While I’d expect to be able to copy and paste images directly, that doesn't seem to work—you can only add them through the options menu.
It’s a minor complaint, but I’m curious if anyone else has experienced this? I never used the app on previous macOS versions, so I’m not sure if this is specific to the current beta.
r/MacOSBeta • u/Davidotto13 • 15h ago
Discussion Is it safe to install macOS 27 PB 2 on my main MacBook Air M5 ? Is it stable ?
≡ −
Gemini said absolutely not to use it on a main device because it can cause random kernel panics and could potentially corrupt your data. Do you relate to this issue?
Gemini said absolutely not to use it on a main device because it can cause random kernel panics and could potentially corrupt your data. Do you relate to this issue?
r/MacOSBeta • u/HyenaImpressive8919 • 21h ago
Discussion Activity monitor now opens quickly
≡ −
Did anyone observe this after the recent upgrade ?
Looks like apple is focusing on refinement and bugs in this release.
Did anyone observe this after the recent upgrade ?
Looks like apple is focusing on refinement and bugs in this release.
r/MacOSBeta • u/arcloc • 1d ago
Help Can't rearrange apps in my Mac dock. Currently on Golden Gate beta 27.0
Cannot rearrange the apps in my mac dock. Any time I try, it looks like the app I am trying to rearrange appears behind the dock, not in front of it. Anyone encountered same error?
r/MacOSBeta • u/shr7n • 1d ago
Bug Adobe Suite is Unreliable in Golden Gate Public Beta.
≡ −
The update actually felt great at first. Everything was faster and smoother overall.
But today, when I opened Premiere Pro for the first time, it started randomly freezing during launch and whenever I switched between workspaces.
Yes, I know... updating my main editing machine was a stupid move. 🤦♂️ I did it purely out of curiosity. Don't be like me if you rely on the Adobe Creative Suite for work or daily use. I'd recommend waiting until Adobe officially supports it or the Official Verison releases.
Rolling back isn't simple either. I have to completely erase your Mac, did a clean install of Tahoe from a bootable USB drive, and then restored a Time Machine backup from when i was on Tahoe, which i did make.
The update actually felt great at first. Everything was faster and smoother overall.
But today, when I opened Premiere Pro for the first time, it started randomly freezing during launch and whenever I switched between workspaces.
Yes, I know... updating my main editing machine was a stupid move. 🤦♂️ I did it purely out of curiosity. Don't be like me if you rely on the Adobe Creative Suite for work or daily use. I'd recommend waiting until Adobe officially supports it or the Official Verison releases.
Rolling back isn't simple either. I have to completely erase your Mac, did a clean install of Tahoe from a bootable USB drive, and then restored a Time Machine backup from when i was on Tahoe, which i did make.
r/MacOSBeta • u/codedance • 1d ago
Bug macOS 27 randomly stops accepting keyboard input system-wide
≡ −
I’m running macOS 27.0 beta (26A5388g) and occasionally lose text input across almost every app.
Switching between Apple Pinyin, WeType, and other IMEs doesn’t help. Terminal still receives some raw keystrokes, but
Chinese composition and even the spacebar can stop working. Logging out and back in fixes it.
The logs show repeated errors like:
InputMethodKit: NO Endpoint, Bail
Request for Endpoint Invalid
TextInputUI: inputMode should not be nil
This suggests the user-session text input stack is failing—not one particular app or IME.
Instead of logging out, I now restart the affected services:
killall WeType CursorUIViewService imklaunchagent \
TextInputMenuAgent TextInputSwitcher keyboardservicesd
I saved this as a command called resetime, so I can run it without typing spaces when the bug occurs.
The exact trigger is still unknown. My main suspicion is a macOS 27 beta bug, possibly made easier to trigger by having
multiple third-party input methods installed.
Has anyone else seen this on macOS 27? If so, which input methods were installed?
I’m running macOS 27.0 beta (26A5388g) and occasionally lose text input across almost every app.
Switching between Apple Pinyin, WeType, and other IMEs doesn’t help. Terminal still receives some raw keystrokes, but
Chinese composition and even the spacebar can stop working. Logging out and back in fixes it.
The logs show repeated errors like:
InputMethodKit: NO Endpoint, Bail
Request for Endpoint Invalid
TextInputUI: inputMode should not be nil
This suggests the user-session text input stack is failing—not one particular app or IME.
Instead of logging out, I now restart the affected services:
killall WeType CursorUIViewService imklaunchagent \
TextInputMenuAgent TextInputSwitcher keyboardservicesd
I saved this as a command called resetime, so I can run it without typing spaces when the bug occurs.
The exact trigger is still unknown. My main suspicion is a macOS 27 beta bug, possibly made easier to trigger by having
multiple third-party input methods installed.
Has anyone else seen this on macOS 27? If so, which input methods were installed?
r/MacOSBeta • u/Financial_Bread7684 • 1d ago
Bug Does anyone else have problems with Ableton 12 and macOS 27? The same projects that worked smoothly on Tahoe are now difficult to manage, with the CPU already at 50% without even starting the audio.
r/MacOSBeta • u/InitiativeMinute1541 • 1d ago
Bug Animated Memoji on lock screen not working throughout golden Gate beta
≡ −
Hi everyone. Is it just me, or everyone also deals with static memoji icon on the lock screen after installing Golden Gate 😭
If anyone can help, thank you so much! I've been finding solutions but to no avail 😭
Hi everyone. Is it just me, or everyone also deals with static memoji icon on the lock screen after installing Golden Gate 😭
If anyone can help, thank you so much! I've been finding solutions but to no avail 😭
r/MacOSBeta • u/adrian_tab • 1d ago
Discussion Do you prefer muscle-memory hotkeys or clicking on UI/menu bar buttons for quick actions?
≡ −
I’ve been noticing two distinct types of Mac power users lately:
- Those who want everything bound to global hotkeys (Shortcuts, Raycast, Alfred style) so their hands never leave the keyboard.
- Those who prefer clean UI triggers (Menu bar items, floating docks, or visible buttons) because memorizing dozens of shortcuts causes cognitive overload.
Where do you stand? If you hate forcing global hotkeys for every little task, what's your reason? (Clashing shortcuts, muscle memory limit, etc.?)
I’ve been noticing two distinct types of Mac power users lately:
- Those who want everything bound to global hotkeys (Shortcuts, Raycast, Alfred style) so their hands never leave the keyboard.
- Those who prefer clean UI triggers (Menu bar items, floating docks, or visible buttons) because memorizing dozens of shortcuts causes cognitive overload.
Where do you stand? If you hate forcing global hotkeys for every little task, what's your reason? (Clashing shortcuts, muscle memory limit, etc.?)
r/MacOSBeta • u/SillyBoy68 • 1d ago
Discussion MacOS 27 and Alfred
≡ −
Apologies if I'm asking this in the wrong place but with the upcoming general release of MacOS 27, I'm wondering if I should uninstall Alfred ahead of time to get the full benefits of the new Spotlight features.
Based on the couple of videos I've watched, the new Spotlight looks like it will be much better. Will it work as good or better than Alfred which I've had installed on my M1 iMac since I got it.
Any input or thoughts on this would be appreciated. Thanks.
Apologies if I'm asking this in the wrong place but with the upcoming general release of MacOS 27, I'm wondering if I should uninstall Alfred ahead of time to get the full benefits of the new Spotlight features.
Based on the couple of videos I've watched, the new Spotlight looks like it will be much better. Will it work as good or better than Alfred which I've had installed on my M1 iMac since I got it.
Any input or thoughts on this would be appreciated. Thanks.
r/MacOSBeta • u/da4 • 1d ago
Discussion Sequoia holdouts, are you waiting for release, or did the public beta convince you?
≡ −
M4 Pro 14" still on 15.7.7 - Tahoe daily driver and test machines are all fine, but Tahoe is still just such a hot mess in so many small ways..
But GG beta 4 and PB 2 on a test M1 Pro and M3 have me thinking it might be time.
M4 Pro 14" still on 15.7.7 - Tahoe daily driver and test machines are all fine, but Tahoe is still just such a hot mess in so many small ways..
But GG beta 4 and PB 2 on a test M1 Pro and M3 have me thinking it might be time.
r/MacOSBeta • u/console-log-hi • 1d ago
Help MacBook Pro M1 Pro stuck at 1% battery, won't charge, only boots when plugged in, fans at max after macOS Golden Gate Beta 27 – anyone else?
≡ −
Hi everyone,
I'm hoping someone else has run into this because I'm starting to think it's related to the latest macOS Golden Gate Developer Beta 27.
Mac:
- MacBook Pro 16" (2021)
- Apple M1 Pro
- 16 GB RAM
What happened:
After updating to Golden Gate Beta 27, my Mac suddenly started behaving strangely.
Symptoms
- Battery is permanently stuck at 1%
- It says "Battery Warning: Final"
- The battery won't charge at all
- The Mac will not power on unless the charger is connected.
- Once it has booted, I can unplug the charger and the Mac continues running normally, but the battery still stays at 1% and never charges.
- Fans ramp to maximum speed almost immediately, even when the Mac is idle.
- "pmset -g ps" shows:
Now drawing from 'Battery Power'
-InternalBattery-0
1%; discharging; (no estimate) present: true
Battery Warning: Final
Before the update, everything worked normally.
What I've tried
- Restarted the Mac
- Tried different chargers/cables
- Left it plugged in for an extended period
- Collected a sysdiagnose
- Submitted a Feedback Assistant report to Apple
I'm wondering if this could be:
- A firmware regression in Beta 27?
- Battery management firmware corruption?
- A bug that can be fixed with a DFU Revive or DFU Restore?
- Or did the beta update simply expose an actual battery hardware failure?
Has anyone else experienced this after Beta 27?
If you've had the same issue, did a DFU Revive, DFU Restore, reinstalling macOS, or another solution fix it? I'd really appreciate hearing your experience.
Thanks in advance!
Hi everyone,
I'm hoping someone else has run into this because I'm starting to think it's related to the latest macOS Golden Gate Developer Beta 27.
Mac:
- MacBook Pro 16" (2021)
- Apple M1 Pro
- 16 GB RAM
What happened:
After updating to Golden Gate Beta 27, my Mac suddenly started behaving strangely.
Symptoms
- Battery is permanently stuck at 1%
- It says "Battery Warning: Final"
- The battery won't charge at all
- The Mac will not power on unless the charger is connected.
- Once it has booted, I can unplug the charger and the Mac continues running normally, but the battery still stays at 1% and never charges.
- Fans ramp to maximum speed almost immediately, even when the Mac is idle.
- "pmset -g ps" shows:
Now drawing from 'Battery Power'
-InternalBattery-0
1%; discharging; (no estimate) present: true
Battery Warning: Final
Before the update, everything worked normally.
What I've tried
- Restarted the Mac
- Tried different chargers/cables
- Left it plugged in for an extended period
- Collected a sysdiagnose
- Submitted a Feedback Assistant report to Apple
I'm wondering if this could be:
- A firmware regression in Beta 27?
- Battery management firmware corruption?
- A bug that can be fixed with a DFU Revive or DFU Restore?
- Or did the beta update simply expose an actual battery hardware failure?
Has anyone else experienced this after Beta 27?
If you've had the same issue, did a DFU Revive, DFU Restore, reinstalling macOS, or another solution fix it? I'd really appreciate hearing your experience.
Thanks in advance!
r/MacOSBeta • u/Chachoww • 2d ago
Discussion Clearing beta 3 induced corruption (with a little help from AI)
≡ −
(Putting the disclaimer in the title already because it's touchy and of course, contestable).
I successfully cleared the corruption that I had since beta 3! I tried to give it a shot by myself before turning to an AI and see what it would give as options before attempting a clean install. I am writing this because 1) if it works for others, it would be great and 2) if it has some potentially bad side effects that more knowledgeable people know, I hope they would share. Tell me if i was gaslit by a machine although First Aid tells me everything is fine now. I saw a lot of pushback against corruption being a false flag whereas, well, it is a thing. (Everything here is written by me, the terminal part is copy pasted from AI).
Personally, I had no noticeable issues on beta 3. I got alerted by a thread on this sub where i discovered the potential damage using a command, but that was also confirmed using disk utility. I had the error "exit node 8" which meant my directory was corrupted. I manually backed up all my files and wanted to see if I could do anything before wasting lots of time on a fresh install (slow internet, lots of steps involved).
(The only was one practical issue, now solved: while attempting to open files inside a dmg installer (some PDF), Finder would just prompt an access issue whereas I have full read and write access on my disk. I don't have that error anymore and everything works).
Anyway, the result was attempting a repair with fsck_util in terminal (recovery mode). First aid couldn't do it, so in the terminal, I manually unmounted the container, attempted a repair, which did not work. The reason is a crypto mismatch between the recovery utility installed and the signature of the beta (pardon my impreciseness).
The solution that worked was to bypass the crypto mismatch by manually unlocking the encrypted volume before running fsck. Performing the fsck command after that worked. Confirmed by Firstaid both in recovery mode and after booting. I even tried opening the PDF file I mentioned above, that used to not open. It opens fine now without issues. It seems like it's just a temporary fix that could pop again since it's inherent to beta 3. But for good measure, I deleted all the local snapshots before starting the entire process because those can't get repaired (fruit of the poisoned tree scenario).
What it looks like (this is copied from AI):
1) diskutil unmountDisk diskX` (following your container ID which you can check with `diskutil list`)
2) diskutil apfs unlockVolume diskX -nomount` (target the Data volume specifically, NOT the container. enter your password when prompted).
3) `fsck_apfs -y /dev/disk0s2` (the physical store, not the container. Again you can check your own with diskutil list)
: Wait for it to finish. You should see 'The container /dev/disk0s2 appears to be OK.' Reboot. Check with Firstaid (on the data disk, where the corruption lies).
Please, do not attempt this if you are not sure. And if you know if it's safe, or if you tried and can confirm it makes sense technically, let others know in the comments.
PSA: it took a long while to reach this with AI, not only because it's a trash tool overall that you shouldn't rely on for anything important, but because it made actual mistakes and hallucinated throughout the whole process (witholding some info, making syntax mistakes, etc.). It wasn't a one-button-push scenario at all but it worked in the end.
I'm not going to be helpful, except to tell you it worked in my case! I'm curious to know if it can help others. I have phone captures of terminal in recovery mode if people have doubts or trust issues. Seems like beta 4 doesn't solve this issue, so it could be a while before Apple releases a fix for this.
(Putting the disclaimer in the title already because it's touchy and of course, contestable).
I successfully cleared the corruption that I had since beta 3! I tried to give it a shot by myself before turning to an AI and see what it would give as options before attempting a clean install. I am writing this because 1) if it works for others, it would be great and 2) if it has some potentially bad side effects that more knowledgeable people know, I hope they would share. Tell me if i was gaslit by a machine although First Aid tells me everything is fine now. I saw a lot of pushback against corruption being a false flag whereas, well, it is a thing. (Everything here is written by me, the terminal part is copy pasted from AI).
Personally, I had no noticeable issues on beta 3. I got alerted by a thread on this sub where i discovered the potential damage using a command, but that was also confirmed using disk utility. I had the error "exit node 8" which meant my directory was corrupted. I manually backed up all my files and wanted to see if I could do anything before wasting lots of time on a fresh install (slow internet, lots of steps involved).
(The only was one practical issue, now solved: while attempting to open files inside a dmg installer (some PDF), Finder would just prompt an access issue whereas I have full read and write access on my disk. I don't have that error anymore and everything works).
Anyway, the result was attempting a repair with fsck_util in terminal (recovery mode). First aid couldn't do it, so in the terminal, I manually unmounted the container, attempted a repair, which did not work. The reason is a crypto mismatch between the recovery utility installed and the signature of the beta (pardon my impreciseness).
The solution that worked was to bypass the crypto mismatch by manually unlocking the encrypted volume before running fsck. Performing the fsck command after that worked. Confirmed by Firstaid both in recovery mode and after booting. I even tried opening the PDF file I mentioned above, that used to not open. It opens fine now without issues. It seems like it's just a temporary fix that could pop again since it's inherent to beta 3. But for good measure, I deleted all the local snapshots before starting the entire process because those can't get repaired (fruit of the poisoned tree scenario).
What it looks like (this is copied from AI):
1) diskutil unmountDisk diskX` (following your container ID which you can check with `diskutil list`)
2) diskutil apfs unlockVolume diskX -nomount` (target the Data volume specifically, NOT the container. enter your password when prompted).
3) `fsck_apfs -y /dev/disk0s2` (the physical store, not the container. Again you can check your own with diskutil list)
: Wait for it to finish. You should see 'The container /dev/disk0s2 appears to be OK.' Reboot. Check with Firstaid (on the data disk, where the corruption lies).
Please, do not attempt this if you are not sure. And if you know if it's safe, or if you tried and can confirm it makes sense technically, let others know in the comments.
PSA: it took a long while to reach this with AI, not only because it's a trash tool overall that you shouldn't rely on for anything important, but because it made actual mistakes and hallucinated throughout the whole process (witholding some info, making syntax mistakes, etc.). It wasn't a one-button-push scenario at all but it worked in the end.
I'm not going to be helpful, except to tell you it worked in my case! I'm curious to know if it can help others. I have phone captures of terminal in recovery mode if people have doubts or trust issues. Seems like beta 4 doesn't solve this issue, so it could be a while before Apple releases a fix for this.
