Visual Studio Maui IOS

An update regarding the state of this issue as of iOS 26.1 beta 1 Using 26.1 beta 1 (23B5044k), I tested this issue using the sample code provided with the original post, and there's a partial fix in this build of iOS 26.1, but there's a noticeable performance issue that folks will likely want to keep in mind. There's a significant regression between the responsive UI experience that was present in iOS 18.6 and the high-latency UI experience now present in iOS 26.1. I'll try to summarize how the behavior varies across OS versions: iOS 18.6: onTapGesture triggers callback nearly instantly iOS 26.0: onTapGesture fails to trigger callback at all iOS 26.1: onTapGesture eventually triggers callback, but there's a significant delay that causes the app to feel unresponsive Demo The attached gif attempts to show the delay, but it feels much more apparent when you're using an app yourself and you sense the delay between when you personally tap on the scree

I think you will need to update to iOS 26 and have this on UISceneDelegate: func windowScene( _ windowScene: UIWindowScene, didUpdateEffectiveGeometry previousGeometry: UIWindowScene.Geometry) { It completely messes up my app, which was a full-screen app with fixed orientation. I will post a repo in a few days with a possible solution - which, in my case, will be to letter-box the landscape-only or portrait-only content. Remove all animations when transitioning screen, assume the screen can change to any size at any time.

I'm hoping they revert the iOS 26 changes, iPad apps are entirely messed up. I needed to be able to lock the app to 1 orientation. Now this is impossible. I think the app will need to be inside a vrtual window within the app, using CGAffineTransform to fit the app inside the rotating window responding to the user blood pressure.

Have you found a fix for this bug? I think that it's because iPhone go to deep sleep after some time when screen is locked and device is inactive. This bug happens on both iOS 18.7 and iOS 26.

I came across the same bug: When in .dark mode AND reduced transparency, OS picks in the assets the Any Luminosity variant instead of the dark one for the inline title (not the large title). I have a Color with 4 variants: light/dark x normal/high-contrast. I apply it to navigationTitle with a UIKit function: .onAppear { setTitleMyColor(.text) } // apply TextColor from the assets And I used the following workaround in this UIKit function: import UIKit import SwiftUI /// A function relying on UIKit to force the navigation title color @MainActor func setTitleUIColor(_ color:UIColor) { // iOS bug workAround: if reducedTransparency and dark mode are both enabled, // For the inline title only (not the largeTitle) // iOS picks in the assets the Any Luminosity variant instead of the dark one let colorFixed = UIAccessibility.isReduceTransparencyEnabled ? .systemGray: color let appearance = UINavigationBarAppearance() appearance.titleTextAttributes = [.foregroundColor: colorFixed] appearance.largeTit

I tested this after writing the message above. When all iPhone devices are rotated horizontally, the safeAreaInsets.top value is 20.0. Up until iOS 18, it was displayed as 0.0. Even with iOS 26, the top status bar is not displayed in apps on iPhones when the device is rotated horizontally. Is this intentional on Apple's part? Or is it an OS bug or error?

Thanks Kevin! So I need to think about this a little differently then. Instead of performing the work once you get a BGContinuedProcessingTask, just begin performing the work (the exact same way you do in iOS 18), if a BGContinuedProcessingTask starts persist it and update it as the work completes, and reset state when the work finishes or gets canceled. I actually think both of those are perfectly reasonable approaches. The right answer here really depends on the what you're actually trying to do what what fits within your app's architecture. I put together code to demonstrate this approach. Did I understand correctly, this should be all good with this simple counting demo? Sure, I don't have any issue with that general approach. There are details I could argue about in a real application (notably, you're manipulating UIKit from a background thread), but that's not really relevant here. This seems to work, minus some behavior I did not expect: The Live Activity appears upon Start Counting while the