build disappears

Let's examine this log: objc[39953]: Class _TtC10KingfisherP33_6AA794C9C370CDB07604B4D8B99AEAA312BundleFinder is implemented in both /Users/Name/Library/Developer/Xcode/DerivedData/TestApp-capvhjiqxrdgdnbevpkajicnjpcs/Build/Products/Debug-iphonesimulator/WallpaperKit.framework/WallpaperKit (0x100e8bbf8) and /Users/Name/Library/Developer/CoreSimulator/Devices/E0AF13C2-874C-47B9-B864-72AF3E4D5D4B/data/Containers/Bundle/Application/AF32011A-92E7-4E26-9A97-9F0C25C07863/TestApp.app/TestApp.debug.dylib (0x101a543b0). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed. You have mangled Swift class names there, and they exist in two places, so the system doesn't know which implementation to use. While the crux of your question is Why are these symbols still given an _implementationOnly import, there's something subtle here — this log is being generated by the Objective-C runtime, for a Swift class — notice the system logging this is named objc at

My understanding is that NWConnection holds a reference to the closure, and if I capture the NWConnection instance inside the closure, the closure will have a reference back to the connection, which, according to my understanding, creates a strong reference cycle. Is my understanding correct? Sort of. You're right that it would be holding a strong reference; however, the key word in the documentation for receive(minimumIncompleteLength..) and receiveMessage(completion:) is single: Schedules a single ... completion handler In both cases, what NWConnection is actually doing is: Retaining the block for later use. Calling the block when the data is received. Releasing the block after it's been called once. That leads to here: If so, how can we break the strong reference cycle — using a capture list, or is there any other way as well? Strictly speaking, I believe there's already a retain cycle here as I don't think NWConnection will destroy itself as long as there is a pending receive block. However, NWConnection

While updating our test devices to iOS 26, we noticed that the connection between devices is flaky. Often when connecting to a peer from a device running iOS 26, we can observe the invite coming through and when accepting said invite, both ends go to .connecting state and a while later go back to .notConnected within the peer(_ peerID: MCPeerID, didChange state: MCSessionState) function. This happens regularly, and retrying the invitation process several times usually resolves it. Have you filed a bug on this, and if so, what is the bug number? Does anyone have any information or guidance on how to resolve this issue? Well, unfortunately, my (and Quinn's) longstanding advice has been to move to a new API and stop using MultipeerConnectivity. Quinn actually has an extended forum post describing how to move to the Network framework. I'd also suggest taking a look at the Building a custom peer-to-peer protocol sample, which uses the Network framework to implement something very similar to what Multipeer

App Store Connect UI frozen — can’t attach build or create new version. Case ID 102715606681. Multiple tickets, no response. Need backend metadata cleared. #AppStoreConnect #iOSDev” They’ll usually DM you for the case ID within 24–48 hours.

If you run codesign on your executable, it tells you exactly what the problem is: /tmp $ codesign -vv -R=anchor apple generic renderrob.app renderrob.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /private/tmp/renderrob.app/Contents/Frameworks/Python.framework If you explore that framework using Terminal, you'll see what it's complaining about: /tmp $ find /private/tmp/renderrob.app/Contents/Frameworks/Python.framework ... /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python Remove those files and try again: /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/Versions/._Current /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Resources /tmp $ rm /private/tmp/renderrob.app/Contents/Frameworks/Python.framework/._Python /tmp $ codesign -vv -

Hi Smith, To add more context to my previous reply, especially regarding the userclient-access entitlement: The main reason we switched our testing focus to the communicates-with-drivers entitlement is because the userclient-access path is completely blocked at build time for us, exactly as you suspected. Here is a detailed breakdown of what happens when we use userclient-access: Entitlement Configuration: We configure our DriverKitSampleApp.entitlements with the correct, specific bundle ID of our DEXT: com.apple.developer.driverkit.userclient-access com.accusys.Acxxx.driver Immediate Build Failure: As soon as we try to build the app with this entitlement, Xcode's signing process fails instantly. This happens with both Automatic Signing and a manually created Provisioning Profile. The Error Message: The error is always the same: Provisioning profile ... doesn't match the entitlements file's value for the com.apple.developer.driverkit.userclient-access entitlement. The Proof (from

Hi Smith, Thank you so much for your excellent suggestions. I've followed your advice and have some definitive results to share. Regarding your first suggestion (Inspecting the Provisioning Profile): You were absolutely right. I inspected the latest Xcode-managed .provisionprofile for my app (com.accusys.Acxxx.app) after a complete cleanup. The profile does not contain the correct value for the userclient-access entitlement. Here is what the profile's Entitlements dictionary contains: com.apple.developer.driverkit.userclient-access: com.accusys.Acxxx.app com.apple.application-identifier: K3TDMD9Y6B.com.accusys.Acxxx.app keychain-access-groups: K3TDMD9Y6B.* As you can see, the value for userclient-access is incorrectly set to the app's own bundle ID, not the DEXT's (com.accusys.Acxxx.driver). Regarding your second suggestion (Using allow-any-userclient-access): I also tried the alternative strategy you proposed, which is a setup we had already been testing. Here is the configuration: App Entitlements (DriverKi

Thanks for bringing up the question. It is intentional that watchOS is not an option for UIDesignRequiresCompatibility. On watchOS, Liquid Glass builds atop the watchOS 10 redesign. When building your watchOS app against watchOS 10 SDK (or later), you automatically gain the L&F of Liquid Glass, without needing to do anything specific to watchOS 26. There is no way to opt out of the new design. Having said that, I am super curious about why you would opt out. Is there anything preventing you from adopting the new design? Best, —— Ziqiao Chen  Worldwide Developer Relations.