First of all, Fast User Switching works fine. Thanks for confirming this. It was not properly showing up in the configuration where I originally reported the problem. I reproduced the same problem in an existing UTM VM with a single volume after adding a second admin user. In the original admin account, the Fast User Switching option wasn't available in the UI referenced by Kevin above. However, after logging out of that account and logging in to the new admin account, the Fast User Switching button was available in the Control Center's "Edit Controls" UI. So there may be a minor bug there. This is not the same behavior that I saw with the installation on a separate APFS volume. However, I went through a more complex setup flow with that installation, as I initially migrated over my primary admin account settings from the primary volume, and then added a second admin account after I ended up with the wrong UID, which necessitated going through Recovery mode and disabling SIP to get the file ownership straightened out so that I could access my source files on the primary volume. I imagine something in that process caused the system to fail to recognize that a second account had been added, causing the feature to remain hidden. I'm not sure what you mean by "secondary volume". I assume he's testing on a secondary volume instead of replacing his primary boot volume. Correct. I don't recommend trying to test with any kind of unusual boot configuration. I previously worked in Core OS for 12 years, so I'm pretty well aware that this is a supported and not extremely unusual boot configuration. Anyway, as mentioned above, I expect the problem was not directly related to the boot configuration, but rather the account manipulations that I performed post-install. the more unusual a boot configuration is the MORE important it is to test that boot configuration, since that gives us the most time to fix things if/when something is broken. This. Fast User switching is an operating system feature. I'm unaware of any 3rd party developer API that might affect its behaviour. Therefore, it's not relevant to this developer forum. I am a developer and encountered this problem in my development workflow while trying to bring my apps to macOS 26, so I had reason to believe it might be relevant for others. Perhaps I'm wrong, but my understanding has always been that this forum is for developers to seek help with any issues they encounter while testing the betas. I've never known that the discussion should be limited strictly to APIs. In macOS 26 the entire Control Center settings pane has been removed and is now managed through an "Edit Controls" button at the bottom of control center itself. Right, I saw this, but as described above, the option wasn't showing up.

what's confusing users I understand your confusion. I feel that "confusion" is a mischaracterization of my state. I understood from the outset where to look for the Fast User Switching settings. The fact is that the option is hidden in the failing configurations, as described previously. I think this is a bug (or possibly multiple bugs) in macOS, though admittedly probably a corner case, based on my current understanding. Back when Apple last re-launched these forums, they explicitly described them as "meant for code-level questions". I see, thanks for the reference. This still seems like the best place to discuss such issues with a beta, in order to raise the problem to the attention of Apple and other developers who may encounter it. prefer to run betas, and often the current version, on a dedicated test machine. Presently, a dedicated test machine is not financially justifiable for me, and it's also not very efficient. I would prefer the VM option if Apple Intelligence worked in a VM (but it doesn't).

Problem persists in macOS 26.0 Beta (25A5279m).

Problem persists in macOS 26.0 Beta 4 (25A5316i). Apple had sent this back to me claiming that it was fixed, when all it seems they really did was changed the default document context menu so it was impossible to access the Share... option from there without selecting some text (in which case the Save option disappears). I updated my sample project to add a File > Share menu item, as found in my actual app, which requires adding a UIApplication subclass as follows: @implementation Application - (void)buildMenuWithBuilder:(id<UIMenuBuilder>)builder { // Add Share menu // // Reference: // • <https://developer.apple.com/documentation/uikit/uicommandtagshare?language=objc> // • <https://www.mattmoriarity.com/2019-10-18-share-menus-with-mac-catalyst/> // Note: "When you use this tag, the command’s action, though still required, will be ignored." // • https://developer.apple.com/forums/thread/742532 // Note: "Starting in Ventura, this submenu no longer appears ..., and instead ... the menu now just displays "Share" with no submenu.... [builder insertSiblingMenu:[UIMenu menuWithTitle:@"" image:nil identifier:nil options:UIMenuOptionsDisplayInline children:@[[UICommand commandWithTitle:@"Share" image:nil action:@selector(share:) propertyList:UICommandTagShare] ]] afterMenuForIdentifier:UIMenuDocument]; } @end It seems nothing else has changed, the exception is occurring in the same place as before (nil passed to -[NSSavePanel setNameFieldStringValue:]).

I have noticed the same behavior with just having a UILabel as an indirect descendant of a UIVisualEffectView configured with UIGlassEffect (note that this is all within an inputAccessoryView in my app). If I don't create the UIVisualEffectView with UIGlassEffect, then the label text color updates correctly. If I use UIGlassEffect, then the label text remains black in dark mode. I was amused to see that if I add an emoji to the label text, as you've shown here, then the label's text color correctly updates to white in dark mode. The workaround I'm presently using is to set the label's textColor to: [UIColor colorWithDynamicProvider:^UIColor * _Nonnull(UITraitCollection * _Nonnull traitCollection) { return UIColor.labelColor; }]; Note: I'm presently working on beta 4. I didn't test betas 2 and 3, but beta 1 behavior was correct.

NOT fixed as of iOS 26 Beta 9 (23A5336a). Placeholder icon (blank with gradient background on iOS 26) is still displayed.