“xcode github”

Thanks for this interesting post! I'm not an expert on that field nor that API. Hope one of the engineers on that team can jump into this thread for better info. These specific FigXPCUtilities and FigCaptureSourceRemote logs are almost certainly benign internal framework noise rather than a regression or a flaw in your capture pipeline. Looking up the err=-17281 is a CoreMedia error code that, without knowing here, typically points to a minor XPC synchronization hiccup, a port invalidation, or an asynchronous state mismatch during the setup or teardown of the capture session? I believe this logs are for information only and should be removed. Code paths that silently recovered in older iOS versions often have their log levels elevated in newer releases (or beta releases), resulting in console spam. If your AVCaptureVideoDataOutputSampleBufferDelegate is successfully receiving CMSampleBuffer frames and your preview layer is rendering smoothly. You can safely ignore these logs. If you want to temporarily hide t

@AlkensoDev I would recommend to file a bug because I'm unable to reproduce it on the latest release of Xcode. I would also recommend when filing the bug to provide your sysdiagnose as maybe could be something on the set up of your environment. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

Hello - Additional troubleshooting tips for testing IAP and product(s) availability in Xcode and in Sandbox can be found in the linked pages. Please let us know if you have any other questions. Thank you.

[quote='880167022, parker9, /thread/810258?answerId=880167022#880167022, /profile/parker9'] GitHub has the actual source for that version in Releases [/quote] OK. I downloaded the app, the .dSYM, and the source code and took a look. First, the crash report has this: Binary Images: 0x102c6c000 - 0x102c9ffff DIM arm64 <3e247524da7930099f63cd12ace4ab0e> …/DIM I used dwarfdump to confirm that I have the right .dSYM: % dwarfdump --uuid DIM.app/Contents/MacOS/DIM UUID: 7A4DAC69-55A2-3D1B-B9E0-6A14AB2D5EEA (x86_64) DIM.app/Contents/MacOS/DIM UUID: 3E247524-DA79-3009-9F63-CD12ACE4AB0E (arm64) DIM.app/Contents/MacOS/DIM I then symbolicated those frames: % atos -l 0x102c6c000 -o DIM.app.dSYM 0x102c799bc 0x102c8b4d4 closure #1 in ViewController.restore(_:) (in DIM) (ViewController.swift:207) thunk for @escaping @callee_guaranteed () -> () (in DIM) + 28 Plugging that into the backtrace, I get this: Thread 1 Crashed:: Dispatch queue: com.apple.root.utility-qos 0 DIM … 0x102c6c000 + 55740 closure #1 in Vi

Update: I've had a chance to speak with an Apple build-tools engineer and was told that this is intentional after all. There are certain app-validation tools that have not yet been updated to support static frameworks. These tools would reject apps with frameworks that do not contain binaries, and therefore, at least for now, Xcode does add this stub on purpose.

The same problem on Xcode 26.3 NSInternalInconsistencyException event dispatch <_MPRemoteCommandEventDispatch: sourceID=SenderDevice = , SenderBundleIdentifier = , SenderPID = <9154> ((null))> state:201> deallocated without calling continuation userInfo: { NSAssertFile = _MPRemoteCommandEventDispatch.m; NSAssertLine = 39; } Crashed: Thread 0 CoreFoundation __exceptionPreprocess + 164 1 libobjc.A.dylib objc_exception_throw + 88 2 Foundation _userInfoForFileAndLine + 0 3 MediaPlayer -[_MPRemoteCommandEventDispatch dealloc] + 144 4 CoreFoundation -[__NSArrayI_Transfer dealloc] + 84 5 libobjc.A.dylib AutoreleasePoolPage::releaseUntil(objc_object**) + 204 6 libobjc.A.dylib objc_autoreleasePoolPop + 244 7 CoreFoundation _CFAutoreleasePoolPop + 32 8 CoreFoundation __CFRunLoopPerCalloutARPEnd + 48 9 CoreFoundation __CFRunLoopRun + 1976 10 CoreFoundation _CFRunLoopRunSpecificWithOptions + 532 11 GraphicsServices GSEventRunModal + 120 12 UIKitCore -[UIApplication _run] + 792 13 UIKitCore UIAppl

[quote='880225022, wu_aaron, /thread/818708?answerId=880225022#880225022, /profile/wu_aaron'] we need to establish multiple additional NWConnection instances … over the Wi‑Fi Aware network [/quote] I don’t think you can do this on currently shipping systems. However, we’ve added support for it in iOS 26.4 beta. This is sufficiently ‘bleeding edge’ that the docs haven’t hit the Developer website yet. But the APIs are in the iOS 26.4 beta SDK (I’m using Xcode 26.4b3, build 17E5179g) and there’s documentation in Xcode itself. To set up a listener: let devices: WAPublisherListener.Devices = … specific devices … let listener = try NetworkListener(for: .wifiAware(.addingConnections(from: devices)), using: .parameters({ TCP() }).localPort(12345)) On the client side, do this: let connection: NetworkConnection = … original connection … guard let wifiAwareEndpoint = connection.currentPath?.remoteEndpoint?.wifiAware(port: 12345) else { // … handle the failure … } // … connect to that endpoint … If you

[quote='880225022, wu_aaron, /thread/818708?answerId=880225022#880225022, /profile/wu_aaron'] we need to establish multiple additional NWConnection instances … over the Wi‑Fi Aware network [/quote] I don’t think you can do this on currently shipping systems. However, we’ve added support for it in iOS 26.4 beta. This is sufficiently ‘bleeding edge’ that the docs haven’t hit the Developer website yet. But the APIs are in the iOS 26.4 beta SDK (I’m using Xcode 26.4b3, build 17E5179g) and there’s documentation in Xcode itself. To set up a listener: let devices: WAPublisherListener.Devices = … specific devices … let listener = try NetworkListener(for: .wifiAware(.addingConnections(from: devices)), using: .parameters({ TCP() }).localPort(12345)) On the client side, do this: let connection: NetworkConnection = … original connection … guard let wifiAwareEndpoint = connection.currentPath?.remoteEndpoint?.wifiAware(port: 12345) else { // … handle the failure … } // … connect to that endpoint … If you