DTiPhoneSimulatorErrorDomain Code 2

Thanks for the post, can you provide a little more information about the URL you are passing or just the code you are using when that message shows in your console? As that API can be called in a thread that is not the main thread as shows in the documentation: You can call this method safely on a thread that isn’t the main thread. https://developer.apple.com/documentation/uikit/uiapplication/canopenurl(_:) Interesting to see what URL are you calling, the method should return a true or false only. Providing a focused sample and iOS version, Xcode and macOS is always a good idea. Thanks Albert Pascual
  Worldwide Developer Relations.

thank you for your reply. diffing the scene is a good idea. until now, I had no idea how to even approach the bug hunting, since it seems not connected to any interaction / changes nor code. it is most likely the serialization of scene data. I'll keep you updated and try to reproduce it. I can actually provide the project as it is not super complex and nor confidential.

In general, the notary service should include all Mach-O images in your submission in the ticket that it issues. Thus, you shouldn’t have to notarise helper independently, or Application Bundle.app for that matter [1]. However, I recommend that you check this, just to be sure. To do that: Submit your package for notarisation. On successful notarisation, fetch the notary log. See if it lists the cdhash values for helper. IMPORTANT If your helper has multiple architectures, check that both cdhash values are present. For more on cdhash values, see TN3126 Inside Code Signing: Hashes. For more background on how this stuff works, see Notarisation Fundamentals. For links to lots of other notarisation info, see Notarisation Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Although it’s fine to do that if, for example, you also distribute the app via some other channel that doesn’t involve this installer package.

OK. Thanks for confirming. When you see this, is there only one user involved? That is: You’ve log in via the GUI. And are working with networking, including your VPN. Without logging out. Or fast user switching to a different user. Is that right? This matters because appex packaging only really works in the context of a single user, so if you add other users into the mix things get complicated. Also, you wrote: [quote='811887021, disinghal, /thread/811887, /profile/disinghal'] internet goes away on machine leading to a connection stuck state. [/quote] Can you clarify what this means? I see two possibilities: Networking goes away for other apps on the system but the system doesn’t start your packet tunnel provider. Alternatively, the system starts your packet tunnel provider and it attempts to connect to your VPN server and that connection acts like there’s no Internet. Is it either of these? Or something else? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail =

[quote='812219021, madsodgaard, /thread/812219, /profile/madsodgaard'] I have read most of the Background Tasks Resources here [/quote] Cool. But there are some network specific ones you should also read: Moving to Fewer, Larger Transfers Testing Background Session Code The first one is probably most relevant to your issue. Networking Resources has these links and a lot more. [quote='812219021, madsodgaard, /thread/812219, /profile/madsodgaard'] But, what if they just stay with the app in the foreground? Will it start uploading immediately? [/quote] I would expect so. However, that’s not guaranteed. The nature of background sessions is that the system gets to choose when to run the transfer, based on its global view of the device state. IMPORTANT A lot of this stuff is not documented, and deliberately so. These policies are considered to be implementation details. They’ve changed in the past and it wouldn’t surprise me if they changed again in the future. So, when you ask “Will it do X?” the only rea