build disappears

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.

However, if a build fails during the actual Xcode build phase (for example, due to a compilation error, unit test failure, or signing issue), the ci_post_xcodebuild.sh script does not run. It should, and is documented that it will always run: ci_post_xcodebuild.sh: The post-xcodebuild script runs after Xcode Cloud runs the xcodebuild command — even if the xcodebuild command fails. As such, would you mind opening a bug report with as much information about your build and Xcode Cloud configuration that you can so that we can look into this? — Ed Ford,  DTS Engineer

Is there a workaround, unofficial method, or private API to generate a local hotspot from an app on iOS, similar to what can be done on Android? No APIs exist that will allow an app to turn the iOS device into a hotspot. Are there any best practices for improving the local Wi-Fi connection experience between an accessory and an iPhone in the absence of hotspot controls? We have a range of APIs an app can use to have the iPhone connect to a specific hotspot. In a modern app, that flow starts by pairing with your Wi-Fi accessory using AccessorySetupKit, then using either NEHotspotManager or our Wi-Fi aware support to actually join that hotspot. Note that while the AccessorySetupKit documentation is primarily focused on Bluetooth, that's largely because the Bluetooth process is significantly more complicated than the Wi-Fi flow. Is there an alternative within the MFi program? Nothing* in the MFi program applies to your particular situation. We do license WAC (Wireless Accessory Configuration) through the MFi pro