build disappears

My current goal is to ship the PCIe DriverKit. I want my customers to be able to install our DriverKit without having to disable SIP or anything like that. I tried the following value as suggested, and the build did indeed pass. 0xFFFFFFFF&0x00000000 After checking the contents of the downloaded provisioning file again, I was able to clarify the problem. The value in the file created in App Development wasn't set properly. Created a provisioning file with DriverKit App Development and checked the value of IOPCIPrimaryMatch. 0xFFFFFFFF&0x00000000 Created a provisioning file with the Distribution Developer ID and checked the value of IOPCIPrimaryMatch. 0x00001916&0x0000FFFF Why is there a difference between the Apple Development value and the Developer ID value? My account belongs to a corporate account. Is this related? Also, when I check your post, it seems like I've never created a provisioning file. That's strange. Is the local file on my PC invalid? As I mentioned at the beginning, I f

I installed the RC (replacing 26.1), tested my app, and went to create a release for an update that happens to need to be released pretty quickly. I recall from previous experience RC builds could submit apps to the App Store so figured I wouldn’t run into any problems. Now I’m blocked. I could go download Xcode 26.1 and redownload the iOS 26.1 Simulator and retest my app with that SDK version but that’s a lot of wasted time/resources only to release the update on a very soon to be out of date SDK. :/ Do you expect this RC build to be accepted in the near future?

Hi Albert, Thanks for the clarification. In past cycles, RC builds have typically been permitted for submission within a few hours, so this situation is a bit unusual. I’m assuming iOS 26.2 will likely ship next week, but ASC is also warning developers that they may be overwhelmed during the holidays and encouraging early submissions — which puts us in a difficult position when RC uploads aren’t yet allowed. Being able to submit with the RC would let us validate TestFlight builds ahead of time and ensure a smooth transition once 26.2 is released. At the moment, it isn’t even possible to test distribution builds, which makes it hard to prepare properly. Could you shed some light on why RC submissions are blocked this time around? Thanks again for your help.

Thank you for providing this information. You are correct that the 26.2 RC is still not permitted to submit builds. The team typically updates this page when it is ready and open to submissions. https://developer.apple.com/help/app-store-connect/release-notes/ On the release notes, you’ll see something like “You can now upload apps built with Xcode….” I understand that submitting with RC versions is often possible, and I acknowledge that this may be an inconvenience. Please continue to monitor the release notes for updates. Could you please provide any reasons why you are unable to submit with the previous released version? Albert Pascual
  Worldwide Developer Relations.

Any chance you can take this code, put it in a small test project that reproduces the issue, and then attach that to your bug (FB21240977)? I tried grabbing the code snippet from your bug and putting it in my own test project, but that didn’t reproduce the problem. Given that, I’m not sure whether that’s because I’m not seeing the problem in my environment or whether I made a mistake when building my test project. If you can share a test project that reproduces the problem, that’ll eliminate that second possibility. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is tricky. My best guess is that translationTask(_:action:) is missing all the magic concurrency decorations required to make this work nicely. To get this to build right now you can mark the closure as sendable, like so: .translationTask(configuration) { @Sendable session in do { try await session.prepareTranslation() } catch { // Handle any errors. } } This compiles in Xcode 26.1 using the Swift 6 language mode and: Approachable Concurrency enabled Default Actor Isolation set to MainActor Note I’m using prepareTranslation() in my examples because it’s simpler, and that makes it easier to focus on the core issue. The drawback to this is that you can no longer access main-actor-isolated state from the closure. You can work around that using MainActor.run(…): try await session.prepareTranslation() … no isolation … await MainActor.run { … main-actor isolated … } Clearly this is less than ideal and I encourage you to file a bug against… actually, I think it’d be best to file a bug against the Trans

[quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] our earlier “Network Extension” tag was a mistake. [/quote] And presumably so was the reply you posted about 10 hours before this one |-: Anyway, the behaviour you’ve described doesn’t gel with Network Extension at all, so I’ve re-tagged your thread accordingly. When dealing with keychain sharing, there are two factors in play: Build time Run time I’m gonna focus on the build-time stuff, because a) that’s where you seem to be stuck, and b) I’m not familiar with Matter extensions and there could be run-time restrictions I’m not familiar with. So, regarding your build, you wrote: [quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] Could you enable Keychain Sharing for these iOS App IDs … ? [/quote] There’s nothing for us to enable here. Every App ID supports keychain sharing [1]. To illustrate this: I using Xcode 26.1 to create a new test project

[quote='809030021, pankaja, /thread/809030, /profile/pankaja'] This makes me believe something related to local network access … is not being applied correctly in the release/TestFlight environment. [/quote] That’s not impossible, but my experience is that it’s not common. Rather, most folks who see problems like this actually have a Release build issue. I recommend that you check this by following the process in Isolating Code Signing Problems from Build Problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you, Quinn. Your suggestion about using app group IDs worked. After investigation, I found that adding my Team ID-prefixed app group (XXXXXXXXXX.com.mycompany.myapp) to com.apple.security.application-groups in my entitlements resolves both mach-register and mach-lookup without needing any temporary exceptions. Looking at /System/Library/Sandbox/Profiles/application.sb, I can see why this works: (sandbox-array-entitlement com.apple.security.application-groups (lambda (suite) ... (allow mach-lookup mach-register (global-name-prefix (string-append suite .))) ...)) With XXXXXXXXXX.com.mycompany.myapp as the app group, the sandbox allows any Mach service name starting with XXXXXXXXXX.com.mycompany.myapp., which matches Chromium's naming pattern: XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.. My Developer ID provisioning profile already included XXXXXXXXXX.* in its application-groups, which authorizes any Team ID-prefixed app group. I just needed to explicitly claim it in my entitlements. For Elect