User Profile

I was following an example invoking the inner binary via "Contents/MacOS/<binary_name>". Instead, passing the path to the *.app container to .openApplication() resolved my permission issue. Code here: https://github.com/passepartoutvpn/passepartout-apple/commit/b966826f19f5d57d0c942860b5feb7b65befee8f

+1, I'm facing the very same issue. Below is the thrown error: Error Domain=NSOSStatusErrorDomain Code=-54 "permErr: permissions error (on file open)" UserInfo={_LSLine=3845, _LSFunction=_LSOpenStuffCallLocal}}} Not sure what permission I'm omitting. Add to the weirdness: with the same method I can open "/Application/SomeApp.app" without an issue, but I can't open my main app from a bundled login item (the typical app launcher).

I confirm that some users are occasionally reporting this to me too. One has fixed by reinstalling. Another one by rebooting. Experience is definitely crazy and randomic.Funny enough, I had just started charging people for an app feature based on that, and Apple decides to break it. Room for bad ratings and more time wasted to update the FAQ on my website. The time and patience we developers wasted on iOS 13 bugs -which remain unfixed for months- have become very, very hard to calculate.I'll file the umpteenth, useless report anyway. Useless because I got no fix nor relevant help from Apple about any of my multiple reports. Instead, the overall developer community helped a lot during this disgraceful 2019.Somebody may not like the rant but man, this is a job for many of us and you're making it a constant challenge. The text view bug in Xcode is like... gosh, I won't even start with what it took me to sort out my Catalina/Xcode work environment.Apple must stop rushing all these awful releases. The quality bar has gotten so unbearably low with iOS 13 and Catalina. Come on, you used to be much better than this.

So, I had to resort to the following to be 100% sure that users have a way to open their files:&lt;key&gt;CFBundleDocumentTypes&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;CFBundleTypeName&lt;/key&gt; &lt;string&gt;All files&lt;/string&gt; &lt;key&gt;LSItemContentTypes&lt;/key&gt; &lt;array&gt; &lt;string&gt;public.content&lt;/string&gt; &lt;string&gt;public.data&lt;/string&gt; &lt;/array&gt; &lt;key&gt;LSHandlerRank&lt;/key&gt; &lt;string&gt;Alternate&lt;/string&gt; &lt;key&gt;CFBundleTypeRole&lt;/key&gt; &lt;string&gt;Viewer&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt;I also dropped any Imported/Exported UTIs (unused in this scenario). Interestingly, I'm unable to open .ovpn files (which are plain text) with public.text or public.plain-text.Granted, it's bruteforce-like, but it's the only way I had my app appear consistently. The obvious downside is that the app is virtually able to open all files, but compared to a crippling bug it feels like minor cosmetics. Import would eventually fail so I don't really care much.Hope this can help other developers.Cheers

I posted a rough mitigation here: https://forums.developer.apple.com/thread/118932

You know what? UIDocumentPickerViewController exhibits the very same behavior. All .ovpn files are disabled as long as OpenVPN Connect is installed together with my own app, which handles the same file extension. ****.

Meta question: are you submitting your reports to the "Feedback Assistant"? Is the "FB"-prefixed ID supposed to be the radar ID? I still see looong IDs in openradar.

Subscribing the thread for facing the same annoying issue. In the meantime I'll have to resort to the UIDocumentPickerViewController trick too (@cfc good call on this). More development time wasted to have a degraded app functionality.. and I foresee user complaints. Gosh, I'd better say nothing.BTW I also filed a report a few days ago, but the bug has really been around since June. I had hoped that they could realize by themselves due to how blatant it is.Let's strongly hope they don't release GM with such a shameful bug.

I'll try this ASAP. Did you find it by luck or through advice by an Apple agent?

It's been 2 years already. This is still around in Mojave and is crazy stuff.It's unacceptable for such a severe bug to live this long without any feedback from Apple. No surprise as I have had other major issues and they pretty much received the same treatment, despite being properly and thoroughly reported. Ignored, marked as duplicate (i.e. no updates), stuck forever.I kind of hate this behavior, because in this case I have a decent user base for my app and people legitimately need answers. Everybody in software is asked deadlines. I can't possibly believe that in 2 years nobody looked into what is a severe bug nonetheless. More so given that the bug can be reproduced consistently.Absurd.

FWIW the annoying bug is still there as of iOS 12. It's unbelievable.

Sure, only I have to tread lightly as to how much I can disclose. I think these are the relevant bits, if not just let me know. All looks to me like the invocation of a released block.. somewhere. Even though I might have spotted a point of failure, it'd be helpful to have more insight first.First one:Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001847a1630 Termination Signal: Trace/BPT trap: 5 Termination Reason: Namespace SIGNAL, Code 0x5 Terminating Process: exc handler [0] Triggered by Thread: 5...Thread 5 name: Thread 5 Crashed: 0 libdispatch.dylib 0x00000001847a1630 _dispatch_queue_xref_dispose$VARIANT$mp + 72 (queue.c:1583) 1 libdispatch.dylib 0x000000018479ce18 -[OS_dispatch_source _xref_dispose] + 24 (object.m:337) 2 NetworkExtension 0x0000000191f8fda8 __NEVirtualInterfaceCreateReadSource_block_invoke + 24 (NEVirtualInterface.c:1848) 3 libdispatch.dylib 0x000000018479caa0 _dispatch_call_block_and_release + 24 (init.c:994) 4 libdispatch.dylib 0x000000018479ca60 _dispatch_client_callout + 16 (object.m:507) 5 libdispatch.dylib 0x00000001847a4e94 _dispatch_continuation_pop$VARIANT$mp + 424 (inline_internal.h:2500) 6 libdispatch.dylib 0x00000001847ae62c _dispatch_source_invoke$VARIANT$mp + 1020 (source.c:858) 7 libdispatch.dylib 0x00000001847a686c _dispatch_queue_serial_drain$VARIANT$mp + 280 (inline_internal.h:2539) 8 libdispatch.dylib 0x00000001847a72fc _dispatch_queue_invoke$VARIANT$mp + 336 (queue.c:5290) 9 libdispatch.dylib 0x00000001847a7cc8 _dispatch_root_queue_drain_deferred_wlh$VARIANT$mp + 340 (queue.c:5908) 10 libdispatch.dylib 0x00000001847b0098 _dispatch_workloop_worker_thread$VARIANT$mp + 668 (source.c:2529) 11 libsystem_pthread.dylib 0x0000000184acfe70 _pthread_wqthread + 860 (pthread.c:2218) 12 libsystem_pthread.dylib 0x0000000184acfb08 start_wqthread + 4Second one:Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000038 VM Region Info: 0x38 is not in any region. Bytes before following region: 4310450120 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---&gt; __TEXT 0000000100ec4000-0000000100ec8000 [ 16K] r-x/r-x SM=COW ... Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [0] Triggered by Thread: 7...Thread 7 name: Thread 7 Crashed: 0 libsystem_platform.dylib 0x0000000184d9ea90 os_unfair_lock_lock$VARIANT$mp + 12 (lock.c:613) 1 libnetwork.dylib 0x000000018611c674 nw_connection_endpoint_report_dry_run + 100 (connection.m:664) 2 libnetwork.dylib 0x00000001860b72f0 nw_endpoint_handler_report + 168 (endpoint_handler.m:0) 3 libnetwork.dylib 0x00000001860b81fc nw_endpoint_handler_path_change + 1680 (endpoint_handler.m:276) 4 libnetwork.dylib 0x00000001860b7b58 __nw_endpoint_handler_start_block_invoke + 116 (endpoint_handler.m:748) 5 libsystem_network.dylib 0x0000000184d35254 nw_path_necp_update_evaluator + 1368 (path_evaluation.m:562) 6 libsystem_network.dylib 0x0000000184d34b90 nw_path_necp_check_for_updates + 880 (path_evaluation.m:628) 7 libdispatch.dylib 0x0000000184a70a60 _dispatch_client_callout + 16 (object.m:507) 8 libdispatch.dylib 0x0000000184a78e94 _dispatch_continuation_pop$VARIANT$mp + 424 (inline_internal.h:2500) 9 libdispatch.dylib 0x0000000184a82784 _dispatch_source_invoke$VARIANT$mp + 1364 (source.c:531) 10 libdispatch.dylib 0x0000000184a7a86c _dispatch_queue_serial_drain$VARIANT$mp + 280 (inline_internal.h:2539) 11 libdispatch.dylib 0x0000000184a7b2fc _dispatch_queue_invoke$VARIANT$mp + 336 (queue.c:5290) 12 libdispatch.dylib 0x0000000184a7bcc8 _dispatch_root_queue_drain_deferred_wlh$VARIANT$mp + 340 (queue.c:5908) 13 libdispatch.dylib 0x0000000184a84098 _dispatch_workloop_worker_thread$VARIANT$mp + 668 (source.c:2529) 14 libsystem_pthread.dylib 0x0000000184da3e70 _pthread_wqthread + 860 (pthread.c:2218) 15 libsystem_pthread.dylib 0x0000000184da3b08 start_wqthread + 4EDIT: it's worth remarking that the other threads are either completely idle or doing whatever other stuff. So I would exclude race conditions on shared data. You're never sure but I believe the cause is right there in the thread stack trace.Thank you!

I see. While I review my code further, I posted two bug reports with a few crash logs:- 40559929- 40560298Thanks for now