Thank you for all of that information Greg and for answering each query individually. That exception is being thrown because isMatchingFrameRateSupported is reporting false for your external display, but your AVCaptureExternalDisplayConfiguration specified true for shouldMatchFrameRate. What determines 'isMatchingFrameRateSupported'? I use the same USB Hub and External Display on a MacBook Pro and I can go to Settings -> Displays and change the resolution and frame rate. I tested 1920 x 1080 at 60fps, 50fps, 30fps and 25fps and they all work. When I use that exact same hardware on an M4 iPad Pro it returns 'false' for 'isMatchingFrameRateSupported', presumably iPadOS is limiting this? Great to know that I can use CAMetalLayer for this purpose. That would mean it could work for a Metal Backed Live Video Feed if I can get the display to work as per the above. Though I think given the limitation of this functionality to AVCaptureDevice and that it wouldn't be respected when the user plays back video from within the app it may not be worth implementing. I feel like it's about time iPadOS opened up frame rate selection for external displays to the user. It's getting more and more like a Desktop OS each year and many people use their iPad with an external display. Sure, have it default to what iPadOS thinks is best, but having an option in settings to set the resolution and frame rate doesn't feel like that big of an ask for users that know what they need for their specific use case.

Also, in the past I have done extensive testing with 'AVCaptureVideoPreviewLayer'. My understanding is that you can only ever have one 'AVCaptureVideoPreviewLayer' in use, is that right? In my use case the Live Video from a UVC Capture Card (AVCaptureDevice) needs to be displayed on the iPad Screen as well as the External Display. There seems to be something special about 'AVCaptureVideoPreviewLayer' as it has the least delay from Capture Device to the Screen. When I try to implement any other way of displaying the image from the CMSampleBuffer there is always more delay than using 'AVCaptureVideoPreviewLayer' directly. Around 1fps is the delay from my measurements. I ended up ditching 'AVCaptureVideoPreviewLayer' due to this dual use limitation and moving a to fully Metal backed pipeline. The CMSampleBuffer is converted to a MTLTexture and this is used for the iPad and the External Display. This also allows for other GPU Backed Functionality like LUTs, False Color, Focus Peaking, etc. The only trade off is the slight increase in delay. Given this new functionality with AVCaptureExternalDisplayConfigurator, my initial understanding is that it wouldn't be able to be used with a MTLTexture? Only a CALayer? Could you pass the CALayer from the MTKView into this to match the frame rate? Also I have recently implemented support for a MFi Device that brings in H264 Video Frames directly, so if a user was using that instead of a UVC Capture Card (AVCaptureDevice) then this framework wouldn't be available right? I haven't got to playback yet, in the app the user can also playback video files that were recorded from the AVCaptureDevice or MFi Device, if the recorded file is 25fps, I couldn't use this API to set the external display to be at 25fps as it's only for Live Video, is that correct?

Thank you for the answer and explanation Greg, much appreciated. The 'init' for 'AVCaptureExternalDisplayConfigurator' refers to the CALayer as 'previewLayer'. Does it work on any CALayer or does it need to specifically be a need to be a 'AVCaptureVideoPreviewLayer'? I tried to use it on a CALayer like this: func setupDisplayConfigurator() { if #available(iOS 26.0, *) { // Fetch Video Input guard let videoInput = videoInput else { return } // Fetch CALayer for window in additionalWindows { print("window: \(window) | \(window.rootViewController?.view.layer)") } guard let layer = additionalWindows.first?.rootViewController?.view.layer else { return } // Create Display Config let config = AVCaptureExternalDisplayConfiguration() config.shouldMatchFrameRate = true // Create Configurator let configurator = AVCaptureExternalDisplayConfigurator(device: videoInput, previewLayer: layer, configuration: config) } } The CALayer is coming from an array of UIWindow: private var additionalWindows: [UIWindow] = [] When I call it like this the app crashes: *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[AVCaptureExternalDisplayConfigurator initWithDevice:previewLayer:configuration:] shouldMatchFrameRate is not supported' It's unclear why this crash is occuring, is it because the CALayer is not a 'AVCaptureVideoPreviewLayer'? I know the external display can handle UHD 60fps, I am feeding it HD at 60fps, my intention is to change this 25fps which matches the frame rate of the External UVC Input Device. Thank you!

@Palace Software I explored this quite extensively before committing to a solution, as stated above using 'UIModalPresentationStyle.overFullScreen' and 'UIModalTransitionStyle.crossDissolve' will allow the background to stay transparent however the user loses the ability to 'swipe to dismiss' as is expected for a modal view. An alternate that works is to set 'UIModalPresentationStyle.custom' and then write your own transition. I tried this and wrote a transition that attempts to mimic the default iOS Behaviour Modal Behaviour. Swipe to dismiss works and it feels okay but the tricky thing is implementing the partial swipe logic, where a user may swipe it down 50% and the popover moves down with the users touch but doesn't fully dismiss until the user swipes down further. I couldn't get this working and ended up giving up. The approach I took in the end was to embrace the new look and access the already present UISheetPresentationController and use detents. The process of implementing it is tricky as I want to retain the same functionality I have now for people using iOS 18 and prior and only implement this new look for iOS 26 and later. I ended up writing a bunch of helper functions similar to the below: static func preparePopoverForPresentation(vc: UIViewController, customDetents: [CGFloat] = [], mediumDetents: Bool = true, largeDetents: Bool = true) { if #available(iOS 26.0, *) { if let sheet = vc.sheetPresentationController { // Create Detents var detents: [UISheetPresentationController.Detent] = [] for value in customDetents { let detentValue = getDetent(basedOn: value) detents.append(.custom(resolver: { context in detentValue })) } if mediumDetents { detents.append(.medium()) } if largeDetents { detents.append(.large()) } // Assign Sheet Values sheet.detents = detents if detents.count > 1 { sheet.prefersGrabberVisible = true } sheet.prefersScrollingExpandsWhenScrolledToEdge = true } } else { // Pre iOS 26 Implementation vc.modalPresentationStyle = UIModalPresentationStyle.popover vc.modalTransitionStyle = UIModalTransitionStyle.coverVertical } } All up the work to move my UIKit App to support iOS 26 was around 7-8 Full Days, with a few outstanding issues I'm yet to fully resolve pending future beta builds. My SwiftUI Apps make the transition a bunch easier but this project is built in UIKit and there is a lot of extra work required for the older UI Frameworks. It's frustrating to have to spend that long updating things just so my app doesn't look horrible for exisiting users. I'm sure they would have preferred I spent that time building new functionality that is actually useful for them rather than spending 70-80 Hours on what is essentially a compatibility update. If I could have simply set 'have transparent background' myself I would have easily saved a bunch of time as most of the work was adapting 20+ VCs that used a transparent background with a smaller popover.

@DTS Engineer I have filled feedback. FB19648533. I am not explicitly trying to change the Tab Bar Color, the problem is that the system sometimes adds a '.systemBackground' color as the background instead of letting the content beneath 'peek through'. Please refer to this image for reference: The image on the left side allows for the content to 'peek through'. The image on the right does not when it should. The image on the right does have content underneath, it is just hidden by '_UITabBarContainerWrapperView'. Within the black square in the image I have highlighted '_UITabBarContainerWrapperView' from View Hierarchy Debugging. On the left instance it shows the content below. On the right instance it assigns a system background which obscures the content below thus taking away the intended system 'peek through' effect. I can not find why the system is putting a background color here. It. happens on many of my views and I can not find a way to change it.

Hello, I took a little bit of a break from looking at this and then decided to come back to it today. I tried to proceed with a solution using NavigationStack but encountered two issues. I'll detail them below. My NavigationStack follows this hierarchy. Welcome -> Enter Name -> Enter Job I use NavigationLink as follows to go from one view to another: NavigationLink(destination: OnboardingNameView(vc: vc)) { OnboardingButtonView(buttonString: "next".localized()) } Issue 01: If I press Next on WelcomeView, it takes me to EnterNameView as expected. If I hit back to return to WelcomeView, the Next Button no longer works until I force quit and re-open the app. Issue 02: On EnterNameView the Next Button is greyed out and can not be pressed. Normally it will appear blue and can be used as normal. I tested both of these issues in iOS 17 vs iOS 18 using the exact same code. No issues in iOS 17 and everything works as expected. It seems to fix this I may need to completely re-build every facet of my navigation. This is a lot of work so I opted to look for an alternate solution. Alternate Solution Previously I detailed that NavigationView would present a blank screen with a sidebar button. This is still the case. I could never pressed the sidebar button as it would appear outside of the safe area and thus taps would not work. When I added padding I could press the button and it printed this in the console: unknown display mode: Automatic With this in mind I found that you can still use NavigationView in iOS 18 with: .navigationViewStyle(.stack) It seems that the .automatic navigationViewStyle has been removed in iOS 18 which is why it doesn't work by default. However I still had an issue. Same code, in iOS 17 it automatically adds safe area insets to NavigationView or NavigationStack, in iOS 18 this is not the case. I found that if I add 0.5 Vertical Padding as per the below the NavigationView and/or NavigationStack would show as intended: .padding(.vertical, 0.5) The only other issue that I am facing is that the slide animation when you navigate forward and back in a NavigationView or NavigationStack does not work in iOS 18 which my existing code. It does work with a clean project using NavigationStack and Rectangles with different colors. I'm not sure what it is in my existing code that causes the animation to break, however the animation works fine in iOS 17. I have seen that a few other developers have had the 'no animation' issue in iOS 18. As this overarching issue essentially breaks my onboarding process which means new users can not access the app if running iOS 18, I opted for a manual version check workaround. For reference, Apple will not let you use a normal version check for an unreleased iOS Version as per the below: if #available(iOS 16.0, *) Please see below for a complete code snippet with all workarounds. I may not have animation on iOS 18 but at least users can use my app as intended on iOS 17 and still access it if they opt to try the iOS 18 Beta. import SwiftUI struct FirstLoadOnboardingView: View { @StateObject var vc: FirstLoadOnboardingViewController @State private var verticalPadding: Double = 0 var body: some View { NavigationView { OnboardingWelcomeView(vc: vc) } .navigationViewStyle(.stack) .padding(.vertical, verticalPadding) .onAppear { let systemVersion = UIDevice.current.systemVersion if systemVersion.contains("18.") { // Update Vertical Padding for iOS 18 verticalPadding = 0.5 } } } }

Yes, that is what I thought until I tried to use the UIContainerView in my actual project, rather than the new, bare bones test project. Using UIContainerView in my actual project still has the same issues as described above. Also, I noticed that UIContainerView isn't actually a subclass of UIView, it is just a UIView inserted as a child. So it's unclear exactly why using UIContainerView via Interface Builder fixes the problem in the Test Project and why UIView is functioning different than it did in iOS 17.

I just did a test with a UIContainerView instead of a UIView as the 'containerView' in which the SwiftUI View is drawn. Everything works as expected in UIContainerView. It seems that there are changes to UIView in iOS 18 that impact how it handles safe area insets.

Thanks for getting back so quickly. I am using Xcode 16.0 beta 3 on macOS 15.0 beta 3 (24A5289h) running in a VM with a 14.5 Host. At a glance, one difference I can see if that I am using a UIView as my 'containerView' where it looks you are using a 'UIContainerView'. I understand that I can switch to using Safe Area and tweak all of the subsequent views, but in iOS 17 it is setup as Superview and all safe area insets are handled on the Swift UI Side. It seems I can not upload my project here as a Zip File, this is a link to download my project so we are 100% on the same page: https://drive.google.com/file/d/1cCaY4trWLJqDSxtxTwUGqwQIfQ305_j2/view?usp=drivesdk

Thanks Sydney! I created a sample project and the issue persists, please see the below code snippet: import UIKit import SwiftUI class ViewController: UIViewController { @IBOutlet weak var containerView: UIView! override func viewDidLoad() { super.viewDidLoad() let onboardingView = UIHostingController(rootView: FirstLoadOnboardingView()) SwiftUIBrain().assign(hostingController: onboardingView, to: containerView) } } struct SwiftUIBrain { func assign(hostingController: UIHostingController<some View>, to uiKitView: UIView) { uiKitView.addSubview(hostingController.view) hostingController.view.translatesAutoresizingMaskIntoConstraints = false hostingController.view.topAnchor.constraint(equalTo: uiKitView.topAnchor).isActive = true hostingController.view.bottomAnchor.constraint(equalTo: uiKitView.bottomAnchor).isActive = true hostingController.view.leftAnchor.constraint(equalTo: uiKitView.leftAnchor).isActive = true hostingController.view.rightAnchor.constraint(equalTo: uiKitView.rightAnchor).isActive = true } } struct FirstLoadOnboardingView: View { var body: some View { NavigationView { Rectangle().foregroundColor(.red) } } } The 'containerView' is setup as per the below images with constraints to the edge of the display: NavigationView in the sample project still just displays the Sidebar Button in the top left and does not show the Red Rectangle. I'm not sure why it is doing this. If you comment out NavigationView and just have the Red Rectangle View it shows as it should, that is a SwiftUI View that respects the safe areas. It seems that if I use NavigationStack and modify the constraints of the 'containerView' it will work as expected, however those constraints work in iOS 17 with NavigationView and display correctly as is, so it'd mean I'd need to programatically change the constraint values if it's running on iOS 18. My understanding of this is that I am giving the SwiftUI View the full screen to work with within the UIViewController, as I am using NavigationStack it should apply it's own Safe Area Insets considering the NavBar based on the iPhone. But it seems that NavigationStack does not create it's own safe area insets in iOS 18. I just tested NavigationStack in iOS 17 and the Safe Area Insets are created and respected. So I think there are two issues here: NavigationView does not display content and shows a Sidebar Button NavigationStack does not create it's own Safe Area Insets Thank you!

I was in contact with 'Apple Developer Support - Development and Technical' about this issue, they say they can not help and to wait for an Apple Engineer to engage on this forum? Unfortunately, we are unable to provide support for the issue you are facing. Apple Developer Program Support Team provides administrative-level support to members of the Apple Developer Programs. As mentioned previously, please refer to the Developer Forums to engage with Apple engineers and other developers. I have posted the file that shows as a Keylogger to VirusTotal: https://www.virustotal.com/gui/file/13a83bec5ada72c38d4da13657f95acc9682bab8ca14671d00b0941779236468 Only ClamAV and Google seem to detect it as a Keylogger. Not sure if this is a false flag or it is indeed a problem. Again, I can confirm that these files only exist in /Users/username/Library/Developer/Xcode/iOS DeviceSupport/. If you delete the contents of this directory they are gone and not appear again until you test with Xcode using a physical iOS Device. This implies that files are present on iOS/iPadOS and are transferred across for debug. So again, I'm not sure if the iOS Devices are compromised or if this is a false flag. Any help from Apple would be appreciated!

I finally got to the bottom of my issue thanks to some help on reddit. The problem was an image that I was using in the widget was too large in resolution, thus large in file size and it capped out the 30MB Memory Limit of Widgets. The reddit user that helped me had this to say: 'Black or redacted widget means that during loading you hit the 30 mb memory limit. Also if you're reloading more than one widget at a time, it seems that there's a higher chance you'll hit the memory budget.' 'Forgot to mention that black/redacted widget can also happen if the widget crashes (not necessary due to memory budget). So maybe you have some threading problems or are force unwrapping something that is nil.'