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?

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/

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

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?