Thank you, Albert! One more question: If I disable liquid glass on a UIBarButtonItem by setting hidesSharedBackground to true, the liquid glass effect disappears but the bar button titles are spaced differently from where they are when liquid glass is disabled globally in the app. I think the spacing difference is the framework allocating space as if the bar button title would be inset on a liquid glass background. Is there a good way to make the bar button item appear without adding this margin? John

Thank you, Ed! I will experiment with the -destination specifier. I filed FB19691776 about the change in behavior. John

Investigating further, it appears that Carthage does not specify the -sdk when compiling for macOS. It does for other platforms. Carthage has good documented reasons for this. It looks Xcode 26 beta 4 and earlier assumed the platform was macOS when it was ambiguous, and Xcode 26 beta 5 does not. I described the issue in more detail in a Carthage ticket: https://github.com/Carthage/Carthage/issues/3399 Would a an FB also make sense? John

Thank you for the reply. I am still working my way through this, but I have figured out at least one Xcode behavior change that appears to trigger the issue. Take RSParser: https://github.com/Ranchero-Software/RSParser It moved away from Xcode projects entirely, but at this commit it had an Xcode project I could build with Carthage: fcbd9a34ecd8c080c6f26798a4b22ea0c98d8e74 Carthage runs this command to get a list of build settings: xcodebuild -project RSParser.xcodeproj -scheme RSParser -configuration Release archive -showBuildSettings -skipUnavailableActions With Xcode 26 beta 4, the output had: LLVM_TARGET_TRIPLE_OS_VERSION = macos10.13 With Xcode 26 beta 5, the output has: LLVM_TARGET_TRIPLE_OS_VERSION = ios13.0 This appears to be what makes Carthage not build the .xcframework for macOS. John

Thank you so much, this example helps a lot!

Thank you. I did watch that video a few times, but I still do not understand. I have a custom view controller that serves as my navigation controller. I want it to mimic the behavior of the view's title moving up into the title area. Perhaps UIScrollEdgeElementContainerInteraction will not help me with that anyway, I do not know. The video showed that interaction seeming to blur out content of the view behind it, but I have had no success in implementing that. In my code above, adding the interaction to a view that overlays the scroll view (the table view) does nothing. I am hoping someone can tell me why it does nothing, or what I am missing. Alternatively, I would love to see code I can run that uses UIScrollEdgeElementContainerInteraction successfully. Thank you. John

Thank you so much, this is exactly what I needed. And it worked perfectly! John

Thank you for the response, Leo! The problem was me being silly. When I thought I had added the com.apple.security.personal-information.photos-library entitlement, I was wrong. I added it to the wrong place. 🤦‍♂️

Yes, I have both NSPhotoLibraryAddUsageDescription and NSPhotoLibraryUsageDescription in my Info.plist: <key>NSPhotoLibraryAddUsageDescription</key> <string>photo library additions</string> <key>NSPhotoLibraryUsageDescription</key> <string>photo library usage</string>

I figured out my problem. I had configured the app extension with a different prefix from the main app. The main app has my Team ID as the prefix. Somehow I configured the extension to have some other prefix for its bundle identifier. I fixed it by creating a new App ID for the extension. Thank you for the reply, Quinn. John

After I was still seeing the behavior when just creating an App Delegate, Scene Delegate, and View Controller that did just about nothing else, I deleted all other code in the app. I could then see the problem was gone. I then put a breakpoint in every method with a dispatch_once_t call. That led me to where my code was being called that I did not expect. I hope this is somehow helpful, @SeanMcMains! John

The crash report said the reason was running out of memory. The app's memory usage would climb by roughly 30MB/second until the app crashed. I since figured out the source of the problem. I had an Objective-C extension on UIColor that implemented secondaryLabelColor. I do not know why that had the effect it did on share sheets, but removing that extension method fixed it. Thank you for replying! John

I tracked my issue down to CSS opacity values that were below 1.0 (but much higher than 0.0. I reported this as FB9652283. It sounds like the issue you are encountering is different, though.