I my App I use the sheetPresentationController to get a sheet that sits on top of the main view (a Map) and that can be slided up and down, similar to the Maps or FindMy Apps. This works great with iOS 18 and older. But under iOS 26 Beta I see issues, especially on the iPad. When the window is small (iPhone or compact size class on iPad), changing the height of the sheet works as expected, the sheet window is attached to the bottom of the screen and I can slide it up and down. But when the App window is wider (regular size class on the iPad), the sheet is shown at the left (as expected), but it is no longer attached to the bottom of the screen, there's a very large (but constant) gap between the bottom of the App window and the bottom of the sheet. I haven't found a way to minimize the gap, the sheet window seems to totally ignore the vertical position and size of the "sourceView" to which the sheet should be attached to (it still evaluates the horizontal position, so I can move the sheet to the right, but the vertical position can't be controlled anymore). The Maps App or FindMy Apps do not show this issue, also iOS 18 and older do not show this issue. Is this normal or can I do something to prevent this? The sheet should always be positioned to the bottom left corner of the App window, Another problem is the window background with a UIGlassContainer effect. In the Apple Maps App the sheet looses its glass effect transparency under iOS 26 when the sheet is fully expanded. The FindMy does not have this issue, here the glass effect/transparency is always present. In my App the background shows the glass effect when the window is not fully expanded when the overall App window is above a certain height (like the Apple Maps App), but when the App window is below a certain height then it is the opposite way: fully expanded it shows the glass effect and at smaller heights it is opaque. Why is this the case? How can I get the behavior of the FindMy App where the sheet window keeps its transparent glass effect in all cases? I do not want to have it changing its appearance depending of the height of the sheet. I can "solve" some of the issues when presenting the "sheet" as popover (via popoverPresentationController) and from within the popoverPresentationController use the adaptiveSheetPresentationController property to get the UISheetPresentationController (instead of directly using the sheetPresentationController property). In small App windows (iPhone or compact size class) it works exactly as when directly using sheetPresentationController. With larger App windows (iPad and regular size class) the sheet will be attached to the bottom of the App window (as expected) and the glass effect is always present. However in this case the detents which define the allowed heights of the sheet window will be always ignored, the window seems to have always the maximum height (minus some safe areas), Even when using the preferredContentSize property to set the size, only the width is respected, but never the height. Is there any way to get this working? Is this supposed to work this way or is this still a beta issue?

I've added some menus to the new (mac-like) menu bar on the iPad App under iPadOS 26, which is working fine. However if the main view controller covers the whole screen and shows a fullscreen Map (MKMapView), the menu bar has a dark gradient as a background, which makes it extremely difficult to see the menu. I guess the iPadOS tries to put a semi-transparent layer between the view controller and the menu bar to make sure that the content of the view controller doesn't interfere with with the menubar and the menu is easy to read. But when the view controller shows a map, the system seems to get the colors for this transparent layer wrong. Is it possible to solve this, or is this still a bug of iPad OS 26? Interestingly, when I create a screenshot of the screen, this dark gradient which makes the menu bar unreadably is not included in the screenshot. So in the screenshot the menu is easy to read. Only on the real device, the menu bar is almost unreadably

I have an App which supports multiple windows on the iPad. The App can receive URLs from other Apps (via application.openURL()) and also files via "share sheet" (via UIActivityViewController). When receiving a URL from another App the delegate method scene(_ scene: UIScene, openURLContexts URLContexts: Set) will be called on an existing UIScene, however when a file is received through the share sheet from another App, a new UIScene is created and therefore also a new window (eg the delegates application(_ application: UIApplication, configurationForConnecting connectingSceneSession: UISceneSession, options: UIScene.ConnectionOptions) and scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) are called). In both cases I do get the URL and file just fine, however I do not want to get new UIScenes and windows created when receiving a file via share sheet. How can I prevent to get a new UIScene or window? The received files should be used in the existing windows and should not create new ones.

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

When you have multiple Apps on the Mac which all provide Quicklook extensions for the same file type, then I would assume that if I activate one of these Quicklook extensions in the system settings, this one would be used. But this doesn't seem to be the case. It looks like the macOS just looks the very first extension it can find for a certain file type, and if this Quicklook extension is switched off, the file can not be previewed anymore. The macOS just doesn't bother to look for the other existing quicklook extension for this file, even if this other is enabled. The only option right now to get this other extension to be used by the system would be to completely delete the first App, so its extension is deleted as well. Is this really the way how it is supposed to work? How can this be fixed? Can I tell my users something else than "just delete the other App"?