“build disappears”

is the issue fixed and may i know the root cause? Thank you This particular issue was determined to be an accessory failure, caused by the developer reducing the CHIP_IM_MAX_REPORTS_IN_FLIGHT constant from it's default value of 4 to 2. The difference between the working and failing cases where then caused by small differences pairing implementation, which then altered the report timing. I don't know why they original reduced that constant but, in general, altering this sort of constant in a hardware implementation is something I would recommend against. Part of the reason reference platforms exists is that, in practice, it's very difficult for platform and accessory implementors to create products the perfectly interoperate. Theoretically that's addressed by increasingly detailed specifications but anyone who's spent significant time reading a hardware specification knows that increased detail isn't necessarily all that helpful. Reference platforms help smooth out that process by providing a standardized impl

Hi, We are also affected by this TestFlight issue. The build is visible for internal testing, but when testers tap Install, TestFlight says: “The requested app is not available or doesn't exist.” We already checked the usual things and even tried creating a brand new app record, but the exact same problem still happens. It looks like many developers have run into this before. If anyone has a confirmed solution, please help share it. Was it: an Apple/TestFlight backend issue? an account/app distribution state issue? something Apple Support had to manually fix? Any real experience would be greatly appreciated.

It sounds like you’re using Developer ID signing for day-to-day development. That’s a mistake on multiple levels. I talk about this in general in The Care and Feeding of Developer ID, but there are extra issues with system extensions, where system policy requires that Developer ID signed sysexen be notarised. So my advice in this case. Use Apple Development code signing for day-to-day development. Use Developer ID for pre-release testing and distribution. There are a couple of key benefits with this approach: It lets you build and debug without enabling development mode, which is a big win IMO. Xcode’s automatic code signing works well with Apple Development signing. Even if you’re not using Xcode, you can create a small test project in Xcode, get it working, and then follow the same path it took. See Debugging a Network Extension Provider for specific advice on how to bring up a provider in Xcode. One thing that Xcode doesn’t handle is the -systemextension suffix )-: To learn more about that, read E

Have you solved it ? I am facing same issue with IPhone 14 (26.04) and Xcode (26.4). CoreDevice / devicectl layer the device remains unavailable, and Xcode cannot use it for on-device build/run.

Hi Ziqiao, thanks for looking into this! I've verified using CKFetchSubscriptionsOperation.fetchAllSubscriptionsOperation() on both Development and Production (TestFlight) devices. All 5 subscriptions are present and correctly configured in both environments. The output is identical between both environments. Here are all 5 subscriptions as returned by CKFetchSubscriptionsOperation: fr-sub-v3 (FriendRequest) Predicate: receiverID == [userID] AND status == pending badge=true, sound=default, contentAvail=false locKey=FRIEND_REQUEST_BODY, locArgs=[senderUsername] category=FRIEND_REQUEST, desiredKeys=[senderID, senderUsername] rec-sub-v3 (MediaRecommendation) Predicate: receiverID == [userID] AND status == pending badge=true, sound=default, contentAvail=false locKey=RECOMMENDATION_BODY, locArgs=[senderUsername, mediaTitle] category=RECOMMENDATION, desiredKeys=[mediaTitle, mediaType, senderID, senderUsername] fs-a-sub-v3 (Friendship) Predicate: userAID == [userID] badge=true, sound=default, contentAvail=false locK