Could it be the local area network permission? When that is accidentally not granted the app will not do any networking at all…

I would love to learn the same, from what I gathered over the years (but can not confirm officially), vImage uses CPU vector instructions, Metal shaders go to GPU, and Core Image depdends on what kernel it will use. Core Image can be made to work with custom Metal kernel, which means it will go to GPU.

€ curl -vvv https://kato332.ddns.net/public/Auth/debug * Trying 35.197.102.232:443... * Connected to kato332.ddns.net (35.197.102.232) port 443 (#0) * ALPN: offers h2 * ALPN: offers http/1.1 * CAfile: /etc/ssl/cert.pem * CApath: none * [CONN-0-0][CF-SSL] (304) (OUT), TLS handshake, Client hello (1): * [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Server hello (2): * [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Unknown (8): * [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Certificate (11): * [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, CERT verify (15): * [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Finished (20): * [CONN-0-0][CF-SSL] (304) (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 * ALPN: server accepted http/1.1 * Server certificate: * subject: CN=kato332.ddns.net * start date: Jan 31 04:52:33 2023 GMT * expire date: May 1 04:52:32 2023 GMT * subjectAltName: host "kato332.ddns.net" matched cert's "kato332.ddns.net" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. > GET /public/Auth/debug HTTP/1.1 > Host: kato332.ddns.net > User-Agent: curl/7.87.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Date: Fri, 17 Mar 2023 18:14:55 GMT < Server: Apache/2.4.41 (Ubuntu) < Cache-control: no-store, max-age=0, no-cache < Debugbar-Time: 1679076895 < Debugbar-Link: https://kato332.ddns.net/index.php/?debugbar_time=1679076895 < Access-Control-Allow-Origin: * < Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Request-With < Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS < Access-Control-Allow-Credentials: true < Content-Length: 15 < Content-Type: application/json; charset=UTF-8 < * Connection #0 to host kato332.ddns.net left intact {"status":"OK"}%

Could be that Apple is intercepting or proxying certain outbout connections from Xcode Cloud to make sure no deails are leaking out? I’d not be surprised.

Do ifconfig on your Mac and see if any of the interfaces has configured link local IPv4 address from 169.254.x.x subnet. Jsut checked my Ventura and I do not have any. If you do not have one on your Mac, link local communication over IPv4 will not work. The fact that you even see ougoing SYN is strange. You can try using IPv6 however, because with IPv6 all interfaces are guaranteed to have link local address (prefix fe80::) always assigned and usable. For IPv4 I do not believe the behavior is standartized, and link local addresses are only assigned when there is no static IP, and DHCP fails. So if your Mac is on WiFi or ethernet, it might not have link local IPv4 configured by default. my .2 cents, Martin

I would not rely on getaddrinfo giving me back entries in any particular order. Even if I could, the code would be prone to breaking soon... I have made a couple utility swift extensions that examine an address by looking into sockaddr_t and return whether the address is IPv6 or IPv5, whether it is link local, v4 mapped to v6, etc… and then sort entries into any particular order I need for a given case.

Hi Quinn (@eskimo), The String(cString: __dispatch_queue_get_label(nil)) works great under macOS, but it fails to compile under Linux. Looking through the https://github.com/apple/swift-corelibs-libdispatch/tree/main/src/swift there does not seem to be any mention of this. Thoughts? Martin

For anyone following along, I was missing SWIFT_REFLECTION_METADATA_LEVEL=all for my release mode builds, and thus appintentsmetadataprocessor was unable to parse swift types from the binary.

Tried today using Xcode 14.0.1 and macOS 13 beta 11 and it still does not work... 2022-10-21T08:18:19.464926299Z 2022-10-21 01:18:15.119 appintentsmetadataprocessor[13377:45511] Starting appintentsmetadataprocessor export 2022-10-21T08:18:19.465332813Z 2022-10-21 01:18:19.180 appintentsmetadataprocessor[13377:45511] +[LNSystemProtocol startDiveProtocol]: unrecognized selector sent to class 0x7ffb5b5d74e8 2022-10-21T08:18:19.465447214Z 2022-10-21 01:18:19.208 appintentsmetadataprocessor[13377:45511] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[LNSystemProtocol startDiveProtocol]: unrecognized selector sent to class 0x7ffb5b5d74e8' 2022-10-21T08:18:19.465533034Z *** First throw call stack: 2022-10-21T08:18:19.465625400Z ( 2022-10-21T08:18:19.465838417Z 0 CoreFoundation 0x00007ff81a32143b __exceptionPreprocess + 242 2022-10-21T08:18:19.465919509Z 1 libobjc.A.dylib 0x00007ff819e70e25 objc_exception_throw + 48 2022-10-21T08:18:19.466014768Z 2 CoreFoundation 0x00007ff81a3b84c3 __CFExceptionProem + 0 2022-10-21T08:18:19.466092171Z 3 CoreFoundation 0x00007ff81a28b69b ___forwarding___ + 1324 2022-10-21T08:18:19.466173957Z 4 CoreFoundation 0x00007ff81a28b0d8 _CF_forwarding_prep_0 + 120 2022-10-21T08:18:19.466276709Z 5 SiriLinkBuilderCore 0x000000010b4383b6 $s19SiriLinkBuilderCore15PrebuiltActionsV23prebuiltProtocolMappingSDySSSo08LNSystemH0CGvgTf4d_n + 4630 2022-10-21T08:18:19.466336660Z 6 SiriLinkBuilderCore 0x000000010b438d06 $s19SiriLinkBuilderCore15PrebuiltActionsVACycfCTf4d_n + 22 2022-10-21T08:18:19.466395632Z 7 SiriLinkBuilderCore 0x000000010b437189 $s19SiriLinkBuilderCore15PrebuiltActionsV6shared_WZ + 9 2022-10-21T08:18:19.466444276Z 8 libdispatch.dylib 0x00007ff81a04ea44 _dispatch_client_callout + 8 2022-10-21T08:18:19.466514595Z 9 libdispatch.dylib 0x00007ff81a04fc32 _dispatch_once_callout + 20 2022-10-21T08:18:19.466589533Z 10 SiriLinkBuilderCore 0x000000010b3bf27a $s19SiriLinkBuilderCore0b8ManifestC0V19preBuiltActionNamesShySSGvg + 826 2022-10-21T08:18:19.466657415Z 11 SiriLinkBuilderCore 0x000000010b3bfa33 $s19SiriLinkBuilderCore0b8ManifestC0V19gatherAbsoluteNames33_B40B2C8FAD2FF01ECB89CC6A5DB9C638LL12conformancesSDySSSaySSGGSay17AppIntentsSupport25ConformanceMetadataBundleVG_tF + 1715 2022-10-21T08:18:19.466738365Z 12 SiriLinkBuilderCore 0x000000010b3bd2c9 $s19SiriLinkBuilderCore0b8ManifestC0V06createbE011sourceFiles10binaryURLs22linkFrameworkBinaryURL12toolchainDir12targetTriple10moduleName10deepGatherAA0eC6ResultVSay10Foundation0N0VG_Aq2PS2SSbtF + 2441 2022-10-21T08:18:19.466836207Z 13 appintentsmetadataprocessor 0x000000010a90a3ec $s27appintentsmetadataprocessor7OptionsV8_executeSay19SiriLinkBuilderCore08ManifestF5ErrorVGyF + 1084 2022-10-21T08:18:19.466904501Z 14 appintentsmetadataprocessor 0x000000010a9060d1 main + 977 2022-10-21T08:18:19.466959638Z 15 dyld 0x00007ff819e9d310 start + 2432 2022-10-21T08:18:19.467022975Z ) 2022-10-21T08:18:19.467095495Z libc++abi: terminating with uncaught exception of type NSException 2022-10-21T08:18:19.467233534Z Command ExtractAppIntentsMetadata failed with a nonzero exit code

FYI: Got a reply from DTS, seems to be fixed from macOS Ventura beta 11. Do not have a way to test currently.

App Shortcuts working for me in Simulator just fine, but unable to archive... Just got this from Xcode 14.0.1 and Xcode 14.1 beta 3: code-block 2022-10-07 18:44:36.743 appintentsmetadataprocessor[61515:24985498] Starting appintentsmetadataprocessor export 2022-10-07 18:44:38.645 appintentsmetadataprocessor[61515:24985498] Writing Metadata.appintents 2022-10-07 18:44:38.645 appintentsmetadataprocessor[61515:24985498] Metadata root: /Users/XXXXX/Metadata.appintents 2022-10-07 18:44:38.661 appintentsmetadataprocessor[61515:24985498] Writing ExtractedAppShortcutsMetadata.stringsdata file 2022-10-07 18:44:38.662 appintentsmetadataprocessor[61515:24985498] Writing ExtractedParameterSummaryMetadata.stringsdata file 2022-10-07 18:44:38.664 appintentsmetadataprocessor[61515:24985498] Warning: error: could not determine type for property: PetMonitor.StartPetMonitorIntent.cameras from binary Command ExtractAppIntentsMetadata emitted errors but did not return a nonzero exit code to indicate failure

I think you can achieve the same by using the bypass property of AVAudioUnitDelay (https://developer.apple.com/documentation/avfoundation/avaudiouniteffect/1386894-bypass). I have enough experience to say that you could disconnect/reconnect node inputs outputs in the past using `AUGraph methods, so it should generally work. But I do not have enough experience to claim that it should work in AVAudioEngine` as well. It may be buggy.

A quick update. I am still battling with this problem and the crashes are consistently showing only on iOS 9. With radically larger number of sessions, in hundreds of thousands daily on iOS 10+. And since iOS 9 is considered dead by many it has become an academic effort of mine to figure this one out. With Apple dropping iOS 9 from Xcode probably next year, I still want to have a version in App Store that works great on these older devices. I am having a hard time producing a reproducible test case, because the problem shows up absolutely randomly and appears to have something to do with how internals of Dictionary and Set behave on iOS 9. Code compiled with Xcode 12.2, latest available swift, swift runtime embedded in the app. I was able to reduce intensity of the crashes drastically by prepending each Dictionary lookup with forced computation of hashValue, and although I can not explain why it would help, it seems to somewhat reduce the crashes. Additionally, whenever I stop the debugger on failed precondition, and then examine the Dictionary, the value is always there, as if the debugger forced something to happen on the Dictionary after the process stopped. Here is what I'm doing: _ = key.hashValue dict.forEach { k, _ in k.hashValue } precondition(dict[key] != nil) guard let x = dict[key] else { &#9;NSLog("dict[key] => \(String(describing: dict[key]))" } And I can still fail randomly and infrequently on line 4, or on line 5. If it fails on line 5, the NSLog prints the value successfully. So the second lookup always succeeds. Nonsense? The `Equatable and Hashable` requirement was reduced to absolute minimum simply comparing/hashing one string value. The Dictionary is accessed via dispatchPrecondition checks from always the same non-main queue and is buttery smooth on iOS 10+ in production. Random iOS 9 madness :)

Additionally I should add that the bug is not reproducible 100% times, it works most of the time and fails sometimes on the precondition on line 5 but in a significant number of cases, always on iOS 9. Never crashed on iOS 10+. One detail I just figured out is that getters for instance variables that are used for Hashable and Equatable actually use serial queue to synchronize reads and writes to allow the class to be accessed from multiple queues at the same time.

Here is a simplified example of the Hashable and Equatable conformance: class MyClass { /// remoteAddress.description always produces the same String /// connectId is Int } extension MyClass: Hashable {     public func hash(into hasher: inout Hasher) {         hasher.combine(remoteAddress.description)         hasher.combine(connectId)     }     public static func ==(lhs: MyClass, rhs: MyClass) -> Bool {         guard lhs.remoteAddress.description == rhs.remoteAddress.description else {             return false         }         guard lhs.connectId == rhs.connectId else {             return false         }         return true     } }