“build disappears”

I am seeing a similar issue, but only for my Mac Catalyst archive on XCode 26. My app is a SwiftUI application that embeds an Objective-C framework built from a separate Xcode project. The framework binary itself does have UUIDs, but when I inspect the .xcarchive, the corresponding framework dSYM is missing from the archive’s dSYMs folder. What is confusing is that this does not happen for the iOS build. I use the same framework target, and when I archive the iOS app and upload to TestFlight, I do not get the warning. The problem only appears when I archive the Mac Catalyst version. So in summary: • The embedded framework binary is present in the archive • The framework executable has valid UUIDs • The app archive’s dSYMs folder does not contain the matching dSYM for that embedded framework • This only happens for Mac Catalyst • The same setup works correctly for iOS Has anyone seen Catalyst archives skip generating or packaging dSYMs for embedded frameworks, even though the binary itself contains de

Filed here: FB22276321 (Xcode Cloud build encountering persistent Connection Refused error)

> I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route? Depends on exactly what your needs are and the hardware you're working with. Starting with MFi, the biggest advantage is that the software side (ExternalAccessory framework) is far simpler to use and includes support for background access (DriverKit does not). The main downside is that it requires a certain amount of custom hardware and the certification process. Comparing it with DriverKit is... complicated. The software side of DriverKit is FAR more complicated. To start with, the DriverKit API is a somewhat odd derivative of the IOKit kernel API. For someone who's familiar with IOKit, it's similar enough to be understandable, but for a new developer, the learning curve can be quite significant. None of this is helped by the fact that DriverKit is poorly documented[1], to the point that my standard advice to new developers is to study the IOKit kernel API (which has o

Thank you for reporting this — it's a clear and well-documented write-up. I was able to reproduce this on a MacBook M5 Max running macOS 26.3.1 (25D2128). I built a small test app that exercises both CGSetDisplayTransferByTable and CGSetDisplayTransferByFormula with several different gamma tables (identity, warm tint, inverted, red-only, gamma 1.8). On the M5 Max: Both APIs return kCGErrorSuccess Reading back the table with CGGetDisplayTransferByTable returns the correct values that were just set No visual change occurs on the display The same test app works correctly on an M5 (non-Max) machine running the same macOS build — all gamma changes are immediately visible on screen. This suggests the gamma tables are being stored correctly at the CoreGraphics level, but are not being applied to the display pipeline on M5 Max hardware. Tested on both built-in and external displays. I've related your two bugs (FB22273730 and FB22273782) together and attached the sample project I used to reproduce the problem

If you consistently see this, please file a bug report with a link to a build, and details of the URL that is unavailable during the build. Please post the FB number here for the record. — Ed Ford,  DTS Engineer

Do these IP's ever change? Rarely, but it does happen. The list you see was recently updated, and these changes are announced through the Xcode Cloud Release Notes, so you can see when the recent update happened. Are there specific ports Apple uses? Would be nice to limit to only what's needed. None are documented, so you shouldn't make any assumptions about port selection. Do we have to open in-bound access or can we instead have our builds reach out with an outbound only setup? Xcode Cloud requires inbound access, that is noted in the document you linked to very briefly. — Ed Ford,  DTS Engineer

Hello - In order to resubmit your three IAP subscription products, the status of each needs to change from Developer Action Needed to Ready to Submit. We recommend editing each of them, in order to save an update (e.g.: add a note to the Review Notes section like [Date] Updating IAP to resubmit with new binary of Version 1.x of [App Name]. Once the status of the IAPs has been successfully updated, proceed to submit a new version of the app - and attach the three IAPs for review as documented here under Submit an In-App Purchase of the first time. If you are still unable to resubmit the IAPs with a new app build, please file a detailed ticket (including screenshots and/or video) via Feedback Assistant, and reply back to this thread with that ticket number - and we will follow-up. Thank you.

Hi @Ziqiao Chen and everyone, Thank you for the follow-up. You were right to push for more precise testing — it led me to discover an issue with my original test setup and reach a much clearer understanding of the problem. == Correction: Original Test Setup == My initial frontmost test had a build configuration error: the test build still had an active HKWorkoutSession running in the background. This means the results I would have reported (~10 minutes before termination) did not reflect pure frontmost app state behavior. I've since corrected this and re-tested with precise instrumentation. == Hardware & Software == Apple Watch Series 8 (45mm) — not Series 4 watchOS 11.6.1 (latest stable) Build: Debug, standalone watch app Xcode debugger disconnected before all tests (to avoid priority elevation) == Methodology == I added a 30-second heartbeat timer that logs: Sequential counter and elapsed seconds Current heart rate value and time since last HR sample (hr_age_sec) App lifecycle

Yes, both are signed Executable=/Users/alexf/Library/Developer/Xcode/DerivedData/Passthrough-fmtxodvbsknmqegwvscnzsczlopk/Build/Products/Debug/PassthroughAppEx.appex/Contents/MacOS/PassthroughAppEx Identifier=com.example.apple-samplecode.PassthroughXXXXXXXX.AppEx Format=bundle with Mach-O thin (arm64) CodeDirectory v=20400 size=476 flags=0x0(none) hashes=3+7 location=embedded Hash type=sha256 size=32 CandidateCDHash sha256=9abcde7d8b79d23164600c46c55cdace7136690a CandidateCDHashFull sha256=9abcde7d8b79d23164600c46c55cdace7136690aecb06f89082b53853a045b76 Hash choices=sha256 CMSDigest=9abcde7d8b79d23164600c46c55cdace7136690aecb06f89082b53853a045b76 CMSDigestType=2 CDHash=9abcde7d8b79d23164600c46c55cdace7136690a Signature size=4781 Authority=XXXXXXXXXXXXX Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=17 Mar 2026 at 15:00:17 Info.plist entries=21 TeamIdentifier=XXXXXXXX Sealed Resources version=2 rules=13 files=3 Internal requirements count=1 si

*I can't install the build

I have the exact same issue, also I can install the newest build on my phone through TestFlight