Hi Kevin, Thank you for your response. We released a new version of our app with the following change as per your suggestion: urlRequest.cachePolicy = .reloadIgnoringLocalAndRemoteCacheData We are still seeing the -9816 error in our logs for the updated app. It is difficult to make any definitive conclusions whether this cache policy change combined with the urlSession.reset() has improved the ability of the app to recover. In some cases after the reset we see the logged SSL errors abruptly stop for the app session, which would suggest either a successful resolution (most likely) or the app being completely terminated by the user. However, we are seeing instances where the -9816 error still persists after the reset. There is not much more we can add other than our server engineers confirming TLS 1.2 as a minimum. Although reinstalling/updating the app seems to restore the ability to connect to the domain, your response leaned towards this potentially being more of a network side problem rather than app side. Is there anything else we could try in either the server side configuration or within the app?

I arrived at the following conclusions after experimenting with a real iPad device and sims: iPad devices use a different focus management system when a hardware keyboard is connected. The system often prioritises physical key inputs over programatically driven focus changes. The FocusState can only be changed programmatically when the view is visible AND the physical keyboard is disconnected - to test this on a sim untick "Connect Hardware Keyboard". Depending on your use case you might want to consider switching to a less pure SwiftUI approach. I am going to try using GCKeyboard with my use case being a virtual keyboard representing a classic 1980s home computer. See my reply to a Stack Overflow post here for more details: https://stackoverflow.com/a/79009141/3719695

The FocusState cannot be updated on iPadOS devices whilst the physical keyboard is attached. You can see the same behaviour with sims where unticking the "Connect Hardware Keyboard" option allows the state to be set and then ticking it allows it to work. See these two links from other developers experiencing the same limitations: https://forums.developer.apple.com/forums/thread/762842 https://stackoverflow.com/questions/78854380/swiftui-why-does-focusable-not-work-on-ipad/

Hi @TWA_PL, Unfortunately still no resolution yet. We did raise an Apple Developer Technology Support (ADTS) case complete with a demo project via our developer account. The case response was that we first needed to ask in this forum.. despite the first line of our problem description saying "See our post on: .." pointing to this post thread. When we replied politely pointing out that this was already in the description there were no subsequent responses. @DTS Engineer Are we permitted to cite the case number in this thread?

For those of you tempted to use a workaround like: extension View { func apply<V: View>(@ViewBuilder _ block: (Self) -> V) -> V { block(self) } } TabView { // Some tabs } .apply { if viewModel.showAccessoryView { $0.tabViewBottomAccessory { MyAccessoryView() } } else { $0 } } It is not recommendable. It might look like it works initially but you may well see problems with the TabView and content being recreated when the condition changes. We tried it and it lead to deeper problems within the tab content view stack. Hopefully as the DTS engineer mentioned the engineering team will consider adding an enhancement such as a hide parameter to the tabViewBottomAccessory modifier.

So as @andepopande pointed out above based on the first version of Xcode 26.2 beta we shall have a fix that seems backwards compatible with 26.1. extension View { func apply<V: View>(@ViewBuilder _ block: (Self) -> V) -> V { block(self) } } TabView { // Some tabs } .apply { if #unavailable(iOS 26.1) { // Previous approach that stopped working in iOS/iPadOS 26.1 $0.tabViewBottomAccessory() { if viewModel.showAccessoryView { // accessory content } else { EmptyView() } } } else { // When compiled with Xcode 26.2+ for iOS/iPadOS 26.1+ $0.tabViewBottomAccessory(isEnabled: viewModel.showAccessoryView) { // accessory content } } } I have tested and so far not seen the deeper problems within the tab content view stack I reported above.

From further testing of the new version of the modifier with the isEnabled: parameter, whilst it compiles as backwards compatible with iOS 26.1, with that OS version it exhibits problems of being laggy to hide/show the accessory view and sometimes fails to render the view. However, when running on iOS 26.2 the modifier is responsive and reliable. There seems to have been an overhaul of the implementation behind the tab bar view and its accessory view as evident in subtle differences with the behaviour of sub view content. My testing was with builds created by Xcode 26.2 beta 1 so subsequent Xcode betas or the RC version might improve the 26.1 support.

In our case we have been pending weeks to fix a problem that was broken with iOS 26.1 but resolved by a SwiftUI modifier with a new parameter available in Xcode 26.2: extension View { func apply<V: View>(@ViewBuilder _ block: (Self) -> V) -> V { block(self) } } TabView { // Some tabs } .apply { if #unavailable(iOS 26.1) { // Previous approach that stopped working in iOS/iPadOS 26.1 $0.tabViewBottomAccessory() { if viewModel.showAccessoryView { // accessory content } else { EmptyView() } } } else { // When compiled with Xcode 26.2+ for iOS/iPadOS 26.1+ $0.tabViewBottomAccessory(isEnabled: viewModel.showAccessoryView) { // accessory content } } } So we are further frustrated by this longer than typical delay to open submissions to an RC build.

For anyone watching the link kindly provided by Albert, a new note is probably not created: December 8, 2025 TestFlight update You can now upload apps built with Xcode 26.2 RC using the SDK for iOS 26.2 RC, iPadOS 26.2 RC, macOS 26.2 RC, tvOS 26.2 RC, visionOS 26. 2 RC, and watchOS 26.2 RC for internal testing through TestFlight. because towards the end of the following day, December 9th, observe how "and external" was silently inserted: December 8, 2025 TestFlight update You can now upload apps built with Xcode 26.2 RC using the SDK for iOS 26.2 RC, iPadOS 26.2 RC, macOS 26.2 RC, tvOS 26.2 RC, visionOS 26. 2 RC, and watchOS 26.2 RC for internal and external testing through TestFlight. So watch carefully the same previously dated release note for "App Store" to be inserted.

Apple now accepting Xcode 26.2 RC submissions

Maybe I posted too soon because despite the text updating to say App Store and Apple accepting the upload it fails: This was after many attempts to upload with timeouts and other strange errors messages with all three of our apps - I suspect from many of us were try to upload and it overloaded the servers. And then... Apple reverted the text to remove the "App Store". So something is clearly wrong at their side.

This screenshot is with the Xcode 26.2 (175C2), which supersedes the RC version and was downloaded from the Apple Developer website directly. Not showing at the time of writing on the App Store and seemingly its builds are not accepted (yet).

The link that Albert posted has updated to include this latest entry: December 12, 2025 App Store Connect update You can now upload apps built with Xcode 26.2 using the SDK for iOS 26.2, iPadOS 26.2, macOS 26.2, tvOS 26.2, visionOS 26. 2, and watchOS 26.2 for the App Store, and for internal and external testing through TestFlight. We were able to upload and submit our app. Conclusions: This is probably a rare situation. However, it demonstrates that Xcode RC builds might not reach the point of having their archived app builds accepted for App Store submissions. If anyone from Apple is reading this, our feedback: We respect your processes and accept that it is often in Apple's and the developers' interests to not convey information that is subject to change. That said, when a pattern is established like almost always accepting Xcode RC built submissions, then expectations will become established amongst the developers. If you multiply the time spent and frustration caused across all the developers who would have been trying to submit apps in recent days, then it would have been appropriate to be more forthcoming.