Hello, With the update from iOS 26 to iOS 27 I have noticed significant regressions and degraded performance when using the Vision Framework for OCR via 'VNRecognizeTextRequest'. The degraded performance is only applicable to the .accurate model, the .fast model is identical between iOS 26 and iOS 27. I have an app that uses this framework extensively for extracting information from the video feed of professional cinema cameras. This runs using en-US, language correction off with a specific region of interest. On iOS 26 everything works reliably as it has for the past few years, with the exact same codebase on iOS 27 many strings that were previously detected are no longer detected, some strings return as if they've been read upside down (ISO1280 is returned as 08ZLOSI) and there are a lot of Cyrillic look alikes mixed into Latin text, there also appears to be a lot more junk characters tacked onto the end of numbers ('12ł' is returned when previously it was just '12'). You often see whole line duplicates too where the same text is recognised twice, once as a single line with all strings combined and once as individual strings. The iOS 27 Simulator doesn't show any of this. I only saw it on real iPads, if you only test in the Simulator you'll miss it. To put numbers on it, I built a test set of about 26,500 frame grabs and ran them through 'VNRecognizeTextRequest' on iPadOS 18, 26 and 27. With the version of my app that's on the App Store today, iOS 26 reads 99.7% of values correctly. On iOS 27 that drops to 65%. I've resolved this issue now and have been able to retain the level of performance that existed on iOS 26, this involves various preprocessing steps to the images as well as a significant amount of validation after the Vision Framework returns its results. These fixes took around 3.5 Days of work which is incredibly frustrating. I would much rather use my time building new features instead of fixing regressions introduced by poorly validated new models that have been shipped in iOS 27. What frustrates me most is this change wasn't announced anywhere and there's no way to opt out. The revision number didn't change so there's no way to keep using the model that worked. If this had shipped as VNRecognizeTextRequestRevision4 apps could have stayed on VNRecognizeTextRequestRevision3 until they'd had a chance to test. Or permanently stayed on 'VNRecognizeTextRequestRevision3' as obviously the new version performs significantly worse. Instead an app that worked fine on iOS 26 now gets wrong text back on iOS 27 with no error, no warning and nothing in the release notes. For a framework people rely on for real work that's a significant regression. It seems that other developers have also come across this issue: https://developer.apple.com/forums/thread/845452 For technical reference, if you diff System/Library/PrivateFrameworks/TextRecognition.framework between iOS 26.5 (23F77) and iOS 27.0 (24A434) you uncover a number of changes. New models on iOS 27 seem to use an '_e5' variant. The text detector in iOS 26 references training run 'yyzn76u6fs' with 88560 iterations, iOS 27 references training run 'hvcthxumvz' with only 10116 iterations. Perhaps an 8x reduction in iterations has something to do with the poor performance in iOS 27? Further, the orientation model changes from iOS 26 'cr_orientation_model_v1' with 1858472 iterations vs. iOS 27 'cr_orientation_model_v1_e5' with 671065 iterations. The Latin and Cyrillic Recogniser changed model entirely from 'cr_tr_model_latincyrillic_v3' on iOS 26 to 'cr_tr_model_latincyrillic_v3_e5' on iOS 27. It seems these 'e5' models are optimised for the neural engine. Is there any way to get the iOS 26 models/behaviour back or plans to back deploy the old model in iOS 27.1 or iOS 27.2? Can future model changes like this come with a new revision number? What testing process does the Vision Team use to validate models as clearly something was missed here? Thanks!

Hello, I've been very familiar with the UVC Support in iPadOS ever since it launched in iOS 17. There are a number of people that use the software I've developed built around UVC and there are often queries about 8-Bit vs. 10-Bit. My understanding is that the newest UVC Spec is 1.5 which was standardised in 2012 and almost every UVC Capture Card runs at 8-Bit. The only 10-Bit Capture Card that is on my radar is the AJA U-Tap SDI, however it looks like this is 10-Bit up until the UVC Part where the 10-Bit Input is downsampled to 8-Bit. Though I have read in certain places that it works as a 10-Bit Capture Card on macOS but not on iPadOS. I was just wondering if 10-Bit via UVC is even possible on iPadOS? If there was indeed a true 10-Bit Source being passed into an iPad, would iPadOS allow it or would it be downsampled by AVFoundation so it can show up as a valid external video input? All USB Capture Cards that I have encountered use one of the following formats: kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange kCVPixelFormatType_420YpCbCr8BiPlanarFullRange kCVPixelFormatType_32BGRA So if a UVC Device delivered a 10-Bit Format, would that be accessible by iPadOS or would it fallback to these 8-Bit Formats by default? Thanks!

Hello, As far as I know and in all of my testing there is no way for a user or a developer to change the frame rate of the video output on iPadOS. If you connect an iPad via a USB Hub or a USB to HDMI Adaptor and then connect it to an external monitor it will output at 59.94fps. I have a video app where a user monitors live video at 25fps and 30fps, they often output to an external display and there are times when the external display will stutter due to the mismatch in frame rate, ie. using 25fps and outputting at 59.94fps. I thought it was impossible to change the video output frame rate, then in V3.1 of the Blackmagic Camera App I saw an interesting change in their release notes: ‘Support for HDMI Monitoring at Sensor Rate and Resolution’ This means there is some way to modify it, not sure if this is done via a Private API that Apple has allowed Blackmagic to use. If so, how can we access this or is there a way to enable this that is undocumented? Thanks!

If you create a SwiftUI App where a ‘.sheet’ is presented and use a NavigationStack within that Sheet, when you use NavigationLink to present a view, the title of the Nav Bar will start at a height of 46px and pop to the Default Height of 54px when it loads causing a visual pop in the UI. In iOS 18 it functions correctly, in iOS 26 the visual pop is present. This impacts both inline and large styles, if you disable the back button it is still present, the only way I have discovered to get rid of it is by using 'fullScreenCover' instead of '.sheet'. This feels like buggy UI. This issue has been present since iOS 26 Beta 5, I was hoping it would be fixed but is still present in the GM. Feedback has been filed via Feedback Assistant: FB20228369 This is the code to re-produce the issue: import SwiftUI struct ContentView: View { @State private var showSheet: Bool = false var body: some View { VStack { Button { showSheet.toggle() } label: { Text("Show Sheet") } } .padding() .sheet(isPresented: $showSheet) { NavigationStack { List { NavigationLink { Rectangle() .foregroundStyle(.red) .navigationTitle("Red") } label: { Text("Show Red") } } } .presentationSizing(.page) } } } #Preview { ContentView() }

Hello, I have a number of UIViewControllers that are presented as follows: vc.modalPresentationStyle = UIModalPresentationStyle.popover vc.modalTransitionStyle = UIModalTransitionStyle.coverVertical self.present(vc, animated: true, completion: nil) The VC is designed from a Storyboard where I set the 'view' of the VC to have a .clear 'backgroundColor', I have a smaller 'Alert View' added as a subview which is what the user interacts with. In iOS 13 - iOS 18 this would present modally, not take up the entire screen and allow the user to see relevant context from the screen underneath. In iOS 26 Beta 5 and every beta prior the system injects a 'UIDropShadowView' in the View Hierarchy, this view has a solid color backdrop, either white/black depending on light/dark mode. This causes all underlying content to be blocked and essentially forces a full screen modal presentation despite the existing design. I am looking for a way to remove this solid color. I'm not sure if it's intentional or a bug / oversight. I have been able to remove it in a hacky way, I cycle the view hierarchy to find 'UIDropShadowView' and set it's backdrop to transparent. However when you swipe down to partially dismiss the view it turns to Liquid Glass when it is around 75% dismissed and then resets the background color to white/black. I tried creating a custom UIViewControllerTransitioningDelegate so that I could re-implement the existing behaviour but it's incredibly difficult to mimic the partial dismiss swipe down effect on the VC. I have also tried changing my presentation to: vc.modalPresentationStyle = UIModalPresentationStyle.overFullScreen vc.modalTransitionStyle = UIModalTransitionStyle.crossDissolve This works but then the user loses the ability to interactively swipe to dismiss. Any help would be appreciated. Thank you!

I do the majority of my test development on an iPhone 16 Pro in the iOS Simulator. As part of my UI rework to maintain compatibility with iOS 26 I decided to run on an older device with a small screen size for testing. The smallest device that supports iOS 26 is the iPhone SE 2nd Gen and 3rd Gen. Take a look at the image below: On the left is the iPhone SE 2nd Gen. On the right iPhone 16 Pro. It looks like the UITabBar which is from a UITabBarController is sized too tall. The actual Tab Bar itself is 62px while the container that houses it is 83px. Yes there should be some top/bottom space to allow for the Liquid Glass Effect to overlap as it often spills outside it's bounds but this feels like far too much. Looking at them side by side, the iPhone SE Tab Bar actually takes up more space which is not ideal for users who are working on a smaller screen to begin with and have less real estate. It looks like the bottom space is allowable room for the 'swipe to dismiss line' however these devices use Touch ID and that line is never present. Feels like the 83px for the Tab Bar should be reduced on these devices to allow for more useable screen real estate. Is this a design oversight as iOS 26 seems to be built predominantly for Face ID Devices? Just wondering if any Apple Design Engineers can chime in to see if this will be addressed in a future beta? The only way to change it at this stage is with a CGAffineTransform however this does not impact the '_UITabBarContainerWrapperView' that sits behind it. Also, on that note. The '_UITabBarContainerWrapperView' sometimes seems to be clear and other times displays a solid system background color. Is there anyway to control this? Many of my views both SwiftUI and UIKit have differing behaviour. My understanding is the idea of iOS 26 is for your app's content to be visible behind the Tab Bar, however the content is obscured by '_UITabBarContainerWrapperView' in many of my views and I can not figure out how to change that. Thanks!

When working with modal sheet views in iOS 26 I animate changes to detent size like this: if let sheet = self.sheetPresentationController { let newDetent = 400 sheet.animateChanges { sheet.invalidateDetents() sheet.detents = [.custom(resolver: { context in newDetent })] } } What I have found is that when using a Touch ID Device the input detent will be smaller when the system presents it. If I set the detent size to be 400, on an iPhone 16 Pro it will be 400px but on an iPhone SE 2nd Gen it will be 366. It seems to be consistently 34px shorter on devices with a Touch ID Square Shaped Screen. This 34px corresponds to the bottom safe area. This feels like a bug to me. I would expect the detent size to match what I assign on all devices. I will monitor if this is fixed in a future beta but it is present as of iOS 26 Beta 5. In the meantime I have built this helper function which will then correctly size it on all devices: static func getDetent(basedOn inputValue: Double) -> CGFloat { if let window = UIApplication.shared.windows.first { if window.safeAreaInsets.bottom > 0 { // Face ID Device, Bottom Inset of 34 return inputValue } else { // Touch ID Device, Bottom Inset of 0 return inputValue + 34 } } else { // Fallback, Return Input Value return inputValue } } This impacts when animating detents as per above but also when presenting a Sheet View for the first time and assigning a custom detent. Thanks!

Is iOS 26 Beta 6 available in the iOS Simulator? I saw that the latest betas launched earlier this week. I updated my dev machine to macOS 26 Beta 6, however this release had no corresponding Xcode 26 Beta 6. So I am still running Xcode Beta 5 and when I go into Settings -> Components within Xcode there is no option to install iOS 26 Beta 6. It's still running Beta 5 for macOS and iOS. Is that correct? My current assumption is that iOS Beta 6 is for physical devices only?

In my SceneDelegate via 'scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions)' I call the following code to assign a Storyboard: let storyboard = UIStoryboard(name: "Main", bundle: nil) let initialVC = storyboard.instantiateInitialViewController() self.window?.rootViewController = initialVC The Initial VC is a UITabBarController. The app crashes when calling 'instantiateInitialViewController': *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ because no class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' terminating due to uncaught exception of type NSException CoreSimulator 1047 - Device: iPhone 16 Pro (06A3EAF6-6623-49FD-BEFE-BE88FDD13BBE) - Runtime: iOS 18.6 (22G86) - DeviceType: iPhone 16 Pro Works fine in iOS 26 when compiling using Xcode 26. Works fine when compiling for iOS 18.6 in Xcode 16.4. Seems to just be an issue when using the iOS 26 SDK in iOS 18.6. This will be an issue for Day 01 Updates if a user hasn't updated to iOS 26 yet.

I have a SwiftUI NavigationView that is presented inside of a UIHostingController. In iOS 17 and earlier everything looks and works okay. I opened up my project in iOS 18 Beta 3 via the iOS Simulator running on macOS Sequoia, the NavigationView just displays a blank view with a Sidebar Button in the top left outside of the safe area. If I comment out the NavigationView and just display my 'root view' everything looks as it should but navigation is broken as it uses NavigationLink which of course doesn't work without NavigationView. I still target iOS 14 as Minimum Version so swapping completely to NavigationStack isn't possible given that NavigationView is deprecated from iOS 16 onwards. I tried to implement a solution with NavigationStack, it works but my UI displays outside of the safe area. I have a button towards the bottom of the screen which now overlaps the system line at the bottom of the screen. The Back Button in the Navigation Stack now sits behind the time in the top left. I do not have 'ignoreSafeArea' applied anywhere in this View Hierarchy. It looks like that is being applied by 'NavigationStack' on it's own accord. Is this happening to anyone else? Is this a known bug? I could not see this in the release notes if it is known. Thanks!

Hello, I recently ran a virus/malware scan on my dev machine using ClamAV, this was run via macOS Terminal using the 'clamscan' function. Everything came back okay except a keylogger in the ProVideo Framework for physical iOS Test Devices. Please see below for 'clamscan' output: /Users/username/Library/Developer/Xcode/iOS DeviceSupport/iPad8,11 17.4 (21E219)/Symbols/System/Library/PrivateFrameworks/ProVideo.framework/ProVideo: Unix.Keylogger.Macos-10023932-0 FOUND My understanding is that '/Library/Developer/Xcode/iOS DeviceSupport/' is where Xcode keeps the files related to physical test devices that are required for debug. There were 3 Instances of this keylogger, all of which corresponded to physical devices I own and iOS Versions that I have installed / were installed. Can anyone verify if 'Unix.Keylogger.Macos-10023932-0' is a valid file that ClamAV is incorrectly detecting as malicious? If it is a valid debug file provided by Apple, it seems strange that it's located in the ProVideo Framework. I couldn't find any documentation online about this so any information would be appreciated. At this stage I have deleted the contents of '/Library/Developer/Xcode/iOS DeviceSupport/', my understanding is that these symbols are only transferred to the system when I test software via Xcode on a physical device and will not reproduce until I do that again. To me it's unclear if perhaps this keylogger is present on my iOS Device and is being transferred to the Mac via Xcode? Or somehow it is just appearing in this folder? Thanks!

When you connect an external display via USB-C to an iPad, that displays shows in iPadOS via Settings -> Display and Brightness -> Name of Display. There is an option called 'Allow Display Mode Changes' for an external display which is described as follows: When this is on, the display mode will change to match the dynamic range and frame rate of the content you're viewing. This may result in flickering or long periods of black whenever content changes. Does anyone know how this functionality works and how to support it for an iPadOS App? In my tests the iPad always outputs at a frame rate of 60fps or sometimes 59.94fps. If the video I am playing back from an AVPlayer is at 25fps the external display stays at 60fps both with 'Allow Display Mode Changes' toggled on/off. Given that it's meant to 'match frame rate of content' I would expect the external display to change from 60fps -> 25fps. I can not find any documentation about this feature and what AV Frameworks it talks to or gets it's frame rate information from. If anyone has any idea or has experimented with it and learnt something that would be much appreciated.

Hello All, I've been using a UIDatePicker in my application since launch and it has been working without issue. Sometime in the past 4-6 Weeks I've had users reporting an intermittent problem where it does not work, at this stage I can not confirm if it's happening only on newer versions of the app, this shouldn't be the case as the code base has not changed at all for anything related to the UIDatePicker. I have seen it happen in the wild once on a friend's App Store Version of my app, on his iPhone he would move the UIDatePicker and the date would change in the picker view, but it wouldn't be reflected elsewhere in the app indicating that the UIDatePicker isn't sending data through to other components, in this case the UITextField. However on my device, two devices and the iOS Simulator, all on the same iOS Version, all with the latest version of the app, this issue did not occur. Code snippets are as follows: // Setup Date Picker     datePicker.datePickerMode = .date     datePicker.addTarget(self, action: #selector(AddWorkDayViewController.datePickerChanged(sender:)), for: .valueChanged)           // Set Date Picker Style     if #available(iOS 13.4, *) {       datePicker.preferredDatePickerStyle = .wheels     } else {       // Fallback on Earlier Versions     }           //Setup Date Toolbar     dateToolbar.barStyle = .default     dateToolbar.isTranslucent = true     dateToolbar.sizeToFit()     let doneButton = UIBarButtonItem(title: "done".localized(), style: .done, target: self, action: #selector(AddWorkDayViewController.doneTouched))     let spaceButton = UIBarButtonItem(barButtonSystemItem: .flexibleSpace, target: nil, action: nil)     let todayButton = UIBarButtonItem(title: "today".localized(), style: .done, target: self, action: #selector(AddWorkDayViewController.todayTouched))     dateToolbar.setItems([todayButton, spaceButton, doneButton], animated: false)     dateToolbar.isUserInteractionEnabled = true           // Assign Date Picker and Date Toolbar to Date Label     dateLabel.inputView = datePicker     dateLabel.inputAccessoryView = dateToolbar // Called When User Changes UIDatePicker @objc func datePickerChanged(sender: UIDatePicker) {     let pickerDate = sender.date     date = pickerDate     let dateFormatted = date.toFormat(settings.dateFormatLong)     dateTextField.text = dateFormatted   } Any ideas on where to start with this? Given it happens on some devices and not others it's quite troublesome to diagnose. On the device I saw it happen on I checked accessibility settings, rebooted the device, etc. and could not figure out why it was behaving this way. Thank you!