file uri scheme

Thank you for reporting here @Claude31 - always recommend filing a FB so we're all sure to see it and so we can track it as well.

Apologies for the delayed update. Yesterday, we completed the rollout of your workaround solution, and our metrics indicate its effectiveness. The issue count has decreased significantly during the implementation, dropping from 6000 per day to 1000 per day as of today. Fabulous, that's great to hear and thank you for sharing concrete numbers. I was fairly confident it would work, but it's good to get independent confirmation. We would like to express our gratitude for the workaround solution you provided. You're very welcome. Currently, we have implemented the workaround only for incoming calls, as these were the primary source of issues observed in our app. We plan to extend the implementation to outbound calls as well. I don't know this for certain, but my guess is that the difference between the incoming/outgoing rate is mostly due to usage patterns and the details of your existing implementation. In particular, these two factors: I suspect most calls originate from the foreground (the user opening your ap

I tried to disable swift-tasks-plugin-enabled as you described, but that barely had noticeable effect (<1s difference). With the debugger attached (and iPhone connected with USB) our app becomes responsive after about 6-7 seconds from start, while this time decreases to less than 1s if I turn off Debug executable option in scheme. I collected lldb-rpc-server sample as you described and added it to FB21378487. Hope it would be helpful!

Hi again @DTS Engineer and thanks :) We have also a run with just address sanitizer and that shows a double free in 'com.apple.coreanimation.imageprovider.concurrent' - see attached file AppleAddressSanitizer.txt . We are a bit desperate by now, so I think we will create a TSI and refer to this forum thread... Best regards :)

Thanks for that, if you can reproduce it on a real device, can you look on the sysdiagnose sw_util file for the error related to the bundle id and the registration of the AASA file? Will give us the reason of the issue. Thanks Albert Pascual
  Worldwide Developer Relations.

I've heard that when a Mac app implements their version of the Standard AppleEvent suite, the developer can copy CocoaStandard.sdef and trim out whatever they don't need. What are the constraints on this trimming? Well, strictly speaking, there aren't any. The point of the sdef file is to map a human-readable syntax onto the AppleEvents your app chooses to implement. There isn't really much point in limiting your app’s ability to modify the content of the definition file, given that your app has full control of what it actually does regardless of what the sdef file says. For example, we can't really require even a basic event like quit, given that your app doesn't actually have do anything when it receives that event. I guess that we could remove commands wholesale, but can we remove sub-parts of a command? Can we change an enumeration? A record type? Have you taken a look at TN2106: Scripting Interface Guidelines? That document was basically written to provide the same kind of guid