I want to check if this behaviour is legit in iOS 26 Beta: We have an admittedly stranger setup where a child view controller acts as a TabBar and is a UIHostingController so that we can use SwiftUI for the tab bar items. One of the tab pages has a scrollview whose content (imagine a chat view) might go from a lighter aspect to darker colors and back when scrolling. When we scroll to predominantly dark bubbles, the trait of the tabBar changes to dark mode. The function traitCollectionDidChange() on the UIHostingController is called ! but only for the tabBar controller. I know that in iOS there is some blending going on at the tabBar level when scrolling, but changing just one view + subviews to dark mode, automatically, instead of user triggered? It might be some optimisation if the view is considered opaque? But then I would expect to not change anything visually, if opaque. Is this expected behaviour on iOS 26? And if so, can we disable it? But just this blending/ trait changing, and keep the user triggered trait changes.

We are using the contactAccessPicker modifier connected to a Button to allow the user to change the selection of contacts that he allows for use in our app. In the two places where the iOS UI screen refers to our app: "manage which contacts can access." on top, and below in the explanatory text, again , the value of is taken probably from the app's PRODUCT_NAME. Instead, we need it to be either CFBundleName or CFDisplayBundleName. In our case they are different (PRODUCT_NAME is legacy, reasons of rebranding, which is a very common reason in apps). Is there a specific reason why iOS is using PRODUCT_NAME (or something similar) in the contactAccessPicker UI screen instead of the user facing CFBundleName or CFDisplayBundleName? or is this a bug?