Build, test, and submit your app using Xcode, Apple's integrated development environment.

Xcode Documentation

Posts under Xcode subtopic

Post

Replies

Boosts

Views

Created

Is it possible for Xcode to display warnings from package dependencies?
I have quite a few in-door local packages that I do not really develop outside of the context of Xcode projects - meaning that I add local references to these libraries (and other content) to my Xcode project - and I update the libraries directly in Xcode within the project. I very rarely open up the library package on its own and work on it just like that. The unfortunate thing is that Xcode seems to be silencing warnings from all the packages during the build phase, resulting in me not seeing warnings from those libraries. I then need to open them separately in Xcode and review whether they contain any warnings and fix them. Using treat warnings as errors is, of course, one solution, but it doesn't help in cases where it's impossible to avoid them (e.g. https://github.com/swiftlang/swift/issues/86650) as there's no #pragma push; or in case of user-defined #warning which I often use to mark parts of code that need revisiting. I've gone through various settings, but I don't see anything relevant. Most of Google search is filled with attempts to silence the warnings instead of enabling them or wanting errors instead of warnings. Does anyone here know if it's possible for Xcode to display warnings from included packages and how to adjust such an option? Thanks!
0
0
73
2w
Xcode 26.2 fails building Flutter iOS app – xcode_backend.dart null exception
Hello, after updating macOS to 26.2 and Xcode to 26.2 (Build 17C52), I am unable to build a Flutter iOS application for the simulator. Environment: macOS 26.2 (darwin-arm64) Xcode 26.2 (17C52) Flutter 3.38.7 (stable) Dart 3.10.7 CocoaPods 1.16.2 Target device: iPhone 16e Simulator (iOS 26.x) Issue: The build fails during the Flutter Xcode build phase with this error: Unhandled exception: Null check operator used on a null value #0 Context._embedNativeAssets (file:///opt/homebrew/share/flutter/packages/flutter_tools/bin/xcode_backend.dart:341) Command PhaseScriptExecution failed with a nonzero exit code. Additional info: Runner target uses Pods-Runner.debug/profile/release.xcconfig correctly SUPPORTED_PLATFORMS = iphoneos iphonesimulator SDKROOT resolves to iPhoneOS26.2.sdk even when building for simulator Build Settings and Run Script phases are default Flutter-generated Issue occurs both via flutter run and directly from Xcode Project worked before macOS/Xcode update It appears Xcode 26.2 may be resolving SDKROOT or build environment incorrectly for Flutter projects, causing Flutter’s xcode_backend.dart to crash. Could you please advise whether this is a known issue or requires a workaround? Thank you. Best regards David
1
0
53
2w
Inconsistent Symbol Linking Behavior for UTType from UniformTypeIdentifiers Framework
In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray<UTType *> *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@"iOS 14+ Adding type: %@", uti); } else { NSLog(@"Warning: Unable to create UTI: %@", uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files (.o) show undefined references to UTType symbols (e.g., UTTypeCreatePreferredIdentifierForTag), yet the final linked binaries differ in how these symbols are resolved. Impact of the Issue This inconsistency causes problems on iOS 14.0+ devices: Strong reference version: Fails to launch on devices where the UniformTypeIdentifiers framework is not present (e.g., certain older iOS 14.x devices), due to link-time failure. Weak reference version: Launches successfully but crashes at runtime when attempting to call UTType methods, because the implementation cannot be found. Our Analysis Using nm -u, both versions show an undefined symbol: U _UTTypeCreatePreferredIdentifierForTag However, in the final binaries: One shows: T _UTTypeCreatePreferredIdentifierForTag (strong) The other shows: W _UTTypeCreatePreferredIdentifierForTag (weak) Both projects link against the framework identically in their build logs: -framework UniformTypeIdentifiers (no -weak_framework flag is used in either case). Questions Why do identical source code and linker flags result in different symbol reference strengths (T vs W) for the same framework? Are there specific compiler or linker behaviors (e.g., deployment target, SDK version, module imports, or bitcode settings) that influence whether symbols from UniformTypeIdentifiers are treated as strong or weak? What is the recommended best practice to ensure consistent symbol referencing when using newer APIs like UTType, especially when supporting older OS versions? We aim to understand this behavior to guarantee stable operation across all supported iOS versions—avoiding both launch failures and runtime crashes caused by inconsistent symbol linking. Any insights or guidance from the community or Apple engineers would be greatly appreciated! Let me know if you'd like a shorter version or want to include additional build environment details (Xcode version, deployment target, etc.)!
1
0
98
2w
Inconsistent Symbol Linking Behavior for UTType from UniformTypeIdentifiers Framework
In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray<UTType *> *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@"iOS 14+ Adding type: %@", uti); } else { NSLog(@"Warning: Unable to create UTI: %@", uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files (.o) show undefined references to UTType symbols (e.g., UTTypeCreatePreferredIdentifierForTag), yet the final linked binaries differ in how these symbols are resolved. Impact of the Issue This inconsistency causes problems on iOS 14.0+ devices: Strong reference version: Fails to launch on devices where the UniformTypeIdentifiers framework is not present (e.g., certain older iOS 14.x devices), due to link-time failure. Weak reference version: Launches successfully but crashes at runtime when attempting to call UTType methods, because the implementation cannot be found. Our Analysis Using nm -u, both versions show an undefined symbol: U _UTTypeCreatePreferredIdentifierForTag However, in the final binaries: One shows: T _UTTypeCreatePreferredIdentifierForTag (strong) The other shows: W _UTTypeCreatePreferredIdentifierForTag (weak) Both projects link against the framework identically in their build logs: -framework UniformTypeIdentifiers (no -weak_framework flag is used in either case). Questions Why do identical source code and linker flags result in different symbol reference strengths (T vs W) for the same framework? Are there specific compiler or linker behaviors (e.g., deployment target, SDK version, module imports, or bitcode settings) that influence whether symbols from UniformTypeIdentifiers are treated as strong or weak? What is the recommended best practice to ensure consistent symbol referencing when using newer APIs like UTType, especially when supporting older OS versions? We aim to understand this behavior to guarantee stable operation across all supported iOS versions—avoiding both launch failures and runtime crashes caused by inconsistent symbol linking. Any insights or guidance from the community or Apple engineers would be greatly appreciated! Let me know if you'd like a shorter version or want to include additional build environment details (Xcode version, deployment target, etc.)!
1
0
80
2w
Git Integration needs serious work.
After committing and pushing code changes, the Repository Up Arrow remains. Not matter how many times you Refresh or Fetch..it only goes away when you shutdown Xcode and restart. .gitignore processing is a nightmare to correct. There should be a clearer way to remove/delete files from the repository and also synch with new .gitignore settings. But even the .gitignore file name is misleading. Please clean this up in the settings and/or IDE. It costs huge time to correct. Not seeing a difference between, Fetch Changes, Refresh, or Pull. The only indications of a code changes seems to occur with a Pull. Just not clear what is supposed to happen at the code level.
3
0
166
2w
Apple watch Xcode pairing & connection issues
I’m blocked debugging a watchOS app on a physical Apple Watch. The iPhone connects to Xcode normally (wired), but the Watch either fails to connect with a tunnel timeout or disappears entirely from Xcode after I unpaired it inside Devices & Simulators. Environment Mac: macOS 26.x (Apple Silicon Mac) Xcode: 26.2 iPhone: iOS 26.1 Apple Watch Ultra: watchOS 26.2 (build 23S303) Connection: iPhone connected to Mac via USB (trusted). Watch paired to iPhone and working normally in the Watch app. Issue A (when Watch is visible in Xcode) In Xcode → Window → Devices and Simulators, the Watch shows up but is not usable and fails to connect. Error: “Previous preparation error: A connection to this device could not be established.” “Timed out while attempting to establish tunnel using negotiated network parameters.” In some attempts the Watch shows “Capacity: Unknown” / limited details, and then fails during preparation. Issue B (after unpairing Watch in Xcode only) I unpaired/removed the Watch in Xcode (Devices & Simulators). I did not unpair the Watch from the iPhone. Now: iPhone appears in Xcode and works normally for builds. Watch is still paired to the iPhone and works normally. Watch no longer appears anywhere in Xcode Devices & Simulators (no paired watch section, no watch run destination). What I’ve tried Reboots of Mac, iPhone, Watch (multiple times) Watch unlocked, awake; iPhone unlocked and close to Watch Verified Watch is paired and connected in iPhone Watch app Developer Mode enabled on iPhone and Watch Wi-Fi and Bluetooth ON (Mac/iPhone/Watch), tried toggling both Tried on home Wi-Fi and also with iPhone hotspot (same result) Resetting trust prompts / reconnecting iPhone via USB, re-trusting Mac Apple Watch: “Clear Trusted Computers” Xcode: removing/re-adding devices; clearing derived data; restarting Xcode Watch Developer networking test: Responsiveness = Medium (430 RPM) Questions 1. Is this a known issue/regression with Xcode 26.2 + watchOS 26.2 tunneling (CoreDevice / devicectl)? 2. Is there an Apple-supported way to force Xcode to re-discover a paired Watch after it was removed from Xcode Devices & Simulators (without unpairing the Watch from the iPhone)? 3. Any recommended logs or diagnostic steps I should collect (Console logs, sysdiagnose, specific Xcode/CoreDevice logs) to include in a Feedback report? If helpful, I can provide the full error text from Xcode’s Devices window and any logs you recommend. Thank you in advance,
6
3
453
2w
Is it safe to run Xcode from an external drive?
I’m currently facing a disk space limitation on my Mac. I’ve already freed up some storage by following the suggestions shared in a previous post, which helped partially, but the issue is not fully resolved and space is still a bottleneck for my workflow. To move forward, I’d like to ask a very concrete question: Is it safe and supported to move Xcode to an external hard drive (SSD), use it from there, and simply connect the drive whenever I need to work with Xcode? Specifically: Are there known issues with performance, stability, or updates? Are there components that must remain on the internal disk to avoid unexpected behavior? Is this a reasonable long-term setup, or just a temporary workaround? I want to make sure I’m not setting myself up for hidden problems down the road. Thanks in advance for any clarification or best practices you can share.
3
0
162
2w
Failed to download iOS 26.2 (23C53) SDK + iOS 26.2 (23C54) Simulator (Components absent)
for detailed Download failed. Domain: DVTDownloadableErrorDomain Code: 41 User Info: { DVTErrorCreationDateKey = "2026-01-17 08:51:49 +0000"; } Download failed. Domain: DVTDownloadableErrorDomain Code: 41 Failed fetching catalog for assetType (com.apple.MobileAsset.iOSSimulatorRuntime), serverParameters ({ RequestedBuild = 23C54; }) Domain: DVTDownloadsUtilitiesErrorDomain Code: -1 Download failed due to not being able to connect to the host. (Catalog download for com.apple.MobileAsset.iOSSimulatorRuntime) Domain: com.apple.MobileAssetError.Download Code: 60 User Info: { checkNetwork = 1; } System Information macOS Version 15.7.3 (Build 24G419) Xcode 26.2 (24553) (Build 17C52) Timestamp: 2026-01-17T16:51:49+08:00
0
0
74
2w
Orphaned 9GB Simulator Runtime in /System/Library/AssetsV2 - Cannot Delete (SIP protected)
I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.
5
3
365
2w
Issue with SwiftPM and multiple targets
Hi! I have a bigger Xcode project that has multiple targets: the main app (MainApp) helper command line tool (HelperTool) The project also lists multiple package dependencies via SwiftPM and these dependencies have dependencies between themselves. One of such packages produces a dynamic library MyFramework which is a dependency for both the main app and the HelperTool which has it listed under Build Phases > Dependencies as well as under Link with Frameworks. This builds just fine, but the issue somes when I want to add another target called AdditionalHelperTool which it has pretty much the same dependencies as HelperTool. When I add this second target, I start running into issues like the following: Multiple commands produce '[...]/Build/Products/Debug/Frameworks/MyFramework.framework/Versions/A' Target 'HelperTool' (project 'MyApp') has copy command from '[...]/Build/Products/Debug/PackageFrameworks/MyFramework.framework' to '[...]/Build/Products/Debug/Frameworks/MyFramework.framework' Target 'AdditionalHelperTool' (project 'MyApp') has copy command from '[...]/Build/Products/Debug/PackageFrameworks/MyFramework.framework' to '[...]/Build/Products/Debug/Frameworks/MyFramework.framework'` It seems that Xcode runs the build of both targets separately and it sees a conflict given that both targets have same dependencies that it's trying to built separately. Has anyone encountered something similar? Can anyone suggest a solution for this?
3
0
103
2w
iPhone mini simulator error Xcode 26.2
Hello, I just updated my Xcode to 26.2 and downloaded the relevant simulator for it to test how my app looks in general. I use the newest iPhone and mini version, in this case, iPhone 13 mini, and the SE (3rd generation). Everything is working as expected, but for the iPhone mini simulator, this weird red line is showing. Is anyone having this issue?
1
0
140
2w
Xcode Suddenly Failing to Build for ARM64 Simulator on Apple Silicon (M1)
Hi all, I’m suddenly experiencing an old issue again and can no longer build my project to run on the local iOS simulator. I’m using a MacBook with an M1 (ARM64) processor and Xcode for development. Until recently, everything was working as expected. However, when I opened Xcode today, I noticed new build options such as ARM64 and ARM64 + x86_64, and I’m also seeing simulator entries running under Rosetta. I don’t recall seeing these options the last time I used Xcode. At the moment: Building for “Any iOS Device (arm64)” succeeds. Building for Rosetta-based simulators also succeeds (which I understand are intended for Intel-based processes). However, when I select an ARM64 simulator, the build fails with the error: “Framework Podd_App not found.” It appears that simulator builds targeting ARM64 are being restricted or misconfigured, possibly due to a corrupted setting or a recent update. Has anyone experienced this before, or can suggest which settings I should check to resolve this issue? Thanks in advance.
1
0
37
2w
XCode 26.2 (17C52) vs iOS 26.2 (23C55): Cannot mount any DDI onto my device
Hi... Is there not an available Developer Disk Image for this situation? I am unable to do my professional job because I have not been able to overcome this issue on my machine. I have various things to try to resolve this issue so that I can install, run, and test apps onto my iPhone (iPhone 13). The version of MacOSX is Sequoia 15.7.3. I've tried everything from hard resetting the pairing stack, to resetting the trust on my iPhone. I've even sought help from AI. AI says, in a nutshell I'm screwed. Apparently, I am unable to downgrade from iOS 26.2 to, say, iOS 18 or below. I'll be honest: this is frustrating, and this situation seems to happen like clockwork with every update in either direction. I hope someone somewhere has ideas. Thanks. Update: I'm not even reaching the step where the shared Cache symbols are being copied from my iPhone. The developer disk image could not be mounted on this device. Domain: com.apple.dt.CoreDeviceError Code: 12040 Failure Reason: Failed to find a DDI that can be used to enable DDI services on the device. Usually this means the best DDI we could find for a platform did not have compatible CoreDevice content. Run 'devicectl list preferredDDI' from the command line to get more details on why no valid DDI can be found. User Info: { DVTErrorCreationDateKey = "2026-01-14 18:56:43 +0000"; DeviceIdentifier = "C471EDF8-4385-5669-BA17-976B325B2EC4"; "com.apple.dt.DVTCoreDevice.operationName" = enablePersonalizedDDI; } -- Failed to find a DDI that can be used to enable DDI services on the device. Usually this means the best DDI we could find for a platform did not have compatible CoreDevice content. Run 'devicectl list preferredDDI' from the command line to get more details on why no valid DDI can be found. Domain: com.apple.dt.CoreDeviceError Code: 12001 -- System Information macOS Version 15.7.3 (Build 24G419) Xcode 26.2 (24553) (Build 17C52) Timestamp: 2026-01-14T10:56:43-08:00 COMMAND LINE Developer % devicectl list preferredDDI Host CoreDevice version: 506.6 WARNING: No usable DDI found for the iOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/iOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17C5038g • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: iOS ▿ projectMetadata: • Citrine-1500.1 • CoreDevice-506.5 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-312.4 • JetsamProperties-2648.0.21 • LiveExecutionResultsLogger-20100 • Mercury-67 • Playgrounds-11 • XCTest-24507 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No DDI was found for the macOS platform. No usable DDI found for the tvOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/tvOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17C5038g • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: tvOS ▿ projectMetadata: • Citrine-1500.1 • CoreDevice-506.5 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-312.4 • JetsamProperties-2648.0.21 • LiveExecutionResultsLogger-20100 • Mercury-67 • Playgrounds-11 • XCTest-24507 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No usable DDI found for the watchOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/watchOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17C5038g • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: watchOS ▿ projectMetadata: • Citrine-1500.1 • CoreDevice-506.5 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-312.4 • JetsamProperties-2648.0.21 • LiveExecutionResultsLogger-20100 • Mercury-67 • Playgrounds-11 • XCTest-24507 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external WARNING: No usable DDI found for the visionOS platform (The DDI's CoreDevice content is too old.). Best (unusable) DDI found is: • hostDDI: file:///Library/Developer/DeveloperDiskImages/xrOS_DDI/ ▿ ddiMetadata: • buildUpdate: 17C5038g • contentIsCompatible: false • coreDeviceVersionChecksIncludeDevelopmentRevision: true • developmentRevision: 0 • enforcingCoreDeviceVersionChecks: true • platform: xrOS ▿ projectMetadata: • Citrine-1500.1 • CoreDevice-506.5 • DTDeveloperDiskImageSupport-14.0.0 • DTOCMock-23002 • GPUToolsDevice_DDI-312.4 • JetsamProperties-2648.0.21 • LiveExecutionResultsLogger-20100 • Mercury-67 • Playgrounds-11 • XCTest-24507 • incompatibleContentReason: The DDI's CoreDevice content is too old. • isUsable: false • variant: external
3
0
392
2w
Xcode 26.2 stuck on "Select the Components..."
I've downloaded Xcode 26.2 directly from Developer.Apple.com and I'm stuck here. I have deleted and redownloaded, restarted computer, tried the App Store version, tried 26.1, and maybe a couple other things. Regardless always end up stock here. I hit "Install" and it just brings me right back to this same window. Thank you. This is my first time downloaded any version of Xcode on this machine MacBook Pro, Apple M4 Max, Tahoe 26.2.
1
0
47
2w
Linker trying to link Metal toolchain for every object file on Catalyst
When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?
0
2
122
2w