prior to upgrading from an M1 to M5 I could run the Mac on iPad via Xcode After upgrading to a M5 I keep getting dyld[88241]: Library not loaded: @rpath/APP.debug.dylib Referenced from: <207ED9FB-3483-3063-B9BC-81EC3BCB34AF> /private/var/folders/54/cwf8kbhx48j71vk_z3zm0t_m0000gn/X/471D0939-4FD4-59C7-8DB5-641DB2A36911/d/Wrapper/App.app/App Reason: tried: '/Users/xxx/Library/Developer/Xcode/DerivedData/project-esgmvpqlktgtvldltqmcjtupefnh/Build/Products/Debug-iphoneos/App.debug.dylib' (no such file), '/usr/lib/system/introspection/App.debug.dylib' (no such file, not in dyld cache), ... bunch more path searching.. Runpath Search paths: $(inherited) @executable_path/Frameworks Runpath Search paths with inherited /usr/lib/swit @executable_path/Frameworks @loader_path/Frameworks @executable_path/Frameworks

I just submitted a feedback for this (FB9662125) but in the spirit of “share and enjoy”… The cool new Generate Info.plist File feature in Xcode 13 crashes if you try to put an NSLocationTemporaryUsageDescriptionDictionary in your Info.plist file. Here’s a simple repro scenario: Create a minimal iOS app (no Core Data, no tests) Go to target settings → Info tab → Custom iOS Target Properties Click the (+) button on any row to begin inserting a new row Select Privacy - Location Temporary Usage Description Dictionary Click somewhere else or press Return to commit the selection Xcode crashes immediately More generally, it seems that Xcode crashes any time it tries to regenerate your Info.plist file if it contains an NSLocationTemporaryUsageDescriptionDictionary, even if (for example) you manually pasted that dictionary into the file earlier. In that case, merely tapping the (+) button in step 3 above is enough to crash it.

I’m developing an app that uses Family Controls to block other apps. I’ve already received approval from Apple for the entitlement, and everything works perfectly when I run the app from Xcode on a physical device. However, when I upload the same build to TestFlight, the app installs and runs, but the Family Controls functionality doesn’t work — it seems like the entitlement isn’t being applied in the TestFlight version. So I’d like to ask: 👉 Do Family Controls entitlements work automatically on TestFlight builds, or is there any additional step required to enable them?

Hi everyone, I’m building a full-screen Map (MapKit + SwiftUI) with persistent top/bottom chrome (menu buttons on top, session stats + map controls on bottom). I have three working implementations and I’d like guidance on which pattern Apple recommends long-term (gesture correctness, safe areas, Dynamic Island/home indicator, and future compatibility). Version 1 — overlay(alignment:) on Map Idea: Draw chrome using .overlay(alignment:) directly on the map and manage padding manually. Map(position: $viewModel.previewMapCameraPosition, scope: mapScope) { UserAnnotation { UserLocationCourseMarkerView(angle: viewModel.userCourse - mapHeading) } } .mapStyle(viewModel.mapType.mapStyle) .mapControls { MapUserLocationButton().mapControlVisibility(.hidden) MapCompass().mapControlVisibility(.hidden) MapPitchToggle().mapControlVisibility(.hidden) MapScaleView().mapControlVisibility(.hidden) } .overlay(alignment: .top) { mapMenu } // manual padding inside .overlay(alignment: .bottom) { bottomChrome } // manual padding inside Version 2 — ZStack + .safeAreaPadding Idea: Place the map at the back, then lay out top/bottom chrome in a VStack inside a ZStack, and use .safeAreaPadding(.all) so content respects safe areas. ZStack(alignment: .top) { Map(...).ignoresSafeArea() VStack { mapMenu Spacer() bottomChrome } .safeAreaPadding(.all) } Version 3 — .safeAreaInset on the Map Idea: Make the map full-bleed and then reserve top/bottom space with safeAreaInset, letting SwiftUI manage insets Map(...).ignoresSafeArea() .mapStyle(viewModel.mapType.mapStyle) .mapControls { MapUserLocationButton().mapControlVisibility(.hidden) MapCompass().mapControlVisibility(.hidden) MapPitchToggle().mapControlVisibility(.hidden) MapScaleView().mapControlVisibility(.hidden) } .safeAreaInset(edge: .top) { mapMenu } // manual padding inside .safeAreaInset(edge: .bottom) { bottomChrome } // manual padding inside Question I noticed: Safe-area / padding behavior – Version 2 requires the least extra padding and seems to create a small but partial safe-area spacing automatically. – Version 3 still needs roughly the same manual padding as Version 1, even though it uses safeAreaInset. Why doesn’t safeAreaInset fully handle that spacing? Rotation crash (Metal) When using Version 3 (safeAreaInset + ignoresSafeArea), rotating the device portrait↔landscape several times triggers a Metal crash: failed assertion 'The following Metal object is being destroyed while still required… CAMetalLayer Display Drawable' The same crash can happen with Version 1, though less often. I haven’t tested it much with Version 2. Is this a known issue or race condition between Map’s internal Metal rendering and view layout changes? Expected behavior What’s the intended or supported interaction between safeAreaInset, safeAreaPadding, and overlay when embedding persistent chrome inside a SwiftUI Map? Should safeAreaInset normally remove the need for manual padding, or is that by design?

I still use my own Info.plist, and I run a script as the last step of my builds to modify the final built Info.plist to have information about the build, like date, machine, git build count, etc. Works fine on latest Xcode 26.0.1 for archive builds, but on DEBUG builds to an attached device Xcode overwrites my processed plist with a copy of the original unmodified build, unless I first do a Clean Build Folder. Any ideas on how to fix this? Annoying, but not critical

Is Xcode 26 required for DeclaredAgeRange APIs? We ask because there appears to be a serious legal deadline on January 1, 2026 and if Xcode 26 is required to meet this deadline, it's about to be a huge burden for us to upgrade to it over the holidays. Our app does support teenagers.

I’m currently developing a visionOS app that includes an RCP scene with a large USDZ file (around 2GB). Each time I make adjustments to the CG model in Blender, I export it as USDZ again, place it in the RCP scene, and then build the app using Xcode. However, because the USDZ file is quite large, the build process takes a long time, significantly slowing down my development speed. For example, I’d like to know if there are any effective ways to: Improve overall build performance Reduce the time between updating the USDZ file and completing the build Any advice or best practices for optimizing this workflow would be greatly appreciated. Best regards, Sadao

My MBP M1 Pro gets really hot. iOS 26.1 Simulator in Xcode 26.1 makes ReportCrash process run at 60-160% of CPU shows Activity Monitor. MacOS 26.1. I've reported this via Feedback Assistant: FB20918609. Is there a way to quit this process permanently? When I Force Quit this it opens again immediately. Only way to stop it is to quit Simulator. But then again, I need to use the Simulator.

I often use a Wi-Fi network where: Whatever mechanism Xcode uses to automatically discover a previously paired iOS device seems to be blocked (the Devices and Simulators window shows "Browsing on the local area network for [iPhone]" and never proceeds), but I can connect to the iOS device from my Mac if I know its IP address, such as by pinging it The same hardware/software configuration works with wireless Xcode connections on a different Wi-Fi network. Thus I'm wondering if there's any functionality that allows the IP address to be manually entered into Xcode to avoid needing to connect a cable from my Mac to my iPhone during development. Searching around seems to suggest this existed at some point in the past but I can no longer find this in a current version of Xcode. Or if there are any other workarounds, although I can't modify the network itself as it's not my network.

Hello! Ive been working on a package tracking app for iOS and was looking forward to pushing it to TestFlight for some testers to use. When I go to archive the package, I get a warning about the "...TrackerIntents.appex is an ExtensionKit extension and must be embedded in the parent app bundle's Extensions directory, but is embedded in the parent app bundle's Tracker.app/Extensions directory". The extension is for siri integration with shortcuts. I have done quite a lot of things to try and diagnose this but cant seem to get passed this warning. I know it's a warning but would rather it not exist. Ideally I would think its a matter of "moving" the items but in the navigation area, I dont see an extensions area. The main app target has it in the dependencies along with the EmbedExtensionKit Extensions in the Build Phases. Any ideas or configs I can try? I can provide more information if needed. This is on the latest Xcode version 26.0.1 for iOS 26. Thank you.

I have an iOS app with a QuickLook extension. I also added Apple Vision Pro in the target's General > Supported Destinations section. About one year ago, I was able to run the app on iPhone, iPad and Apple Vision Pro Simulators. Today I tried running it again on Apple Vision Pro with Xcode 26.0.1, but Xcode shows this error: Try again later. Appex bundle at ~/Library/Developer/CoreSimulator/Devices/F6B3CCA8-82FA-485F-A306-CF85FF589096/data/Library/Caches/com.apple.mobile.installd.staging/temp.PWLT59/extracted/problem.app/PlugIns/problemQuickLook.appex with id org.example.problem.problemQuickLook specifies a value (com.apple.quicklook.preview) for the NSExtensionPointIdentifier key in the NSExtension dictionary in its Info.plist that does not correspond to a known extension point. I tried again later a couple times, even after running Clean Build Folder Immediately, without any change. I can reproduce this with a fresh Xcode project to which I add a Quick Look Preview Extension and Apple Vision Pro as a supported destination. The error doesn't happen when running on Apple Vision Pro (Designed for iPad) or iPad Pro 13-inch (M4) destinations. What is the problem? I created FB20448815.

Hello, I'm encountering a persistent issue when building my project with Xcode 26 and iOS 26. The console shows errors related to font file references that don't actually exist in my project. GSFont: file doesn't exist - "file:///private/var/containers/Bundle/Application/...../HiraginoKakuGothic.ttc" After investigation, I found that the issue originates from XIB files incorrectly referencing HiraginoKakuGothic.ttc: <customFonts key="customFonts"> <array key="HiraginoKakuGothic.ttc"> <string>HiraginoSans-W3</string> </array> </customFonts> The problem appears to be triggered when setting UILabel fonts to "ヒラギノ角ゴシック W3 16.0" in Interface Builder, which causes the XIB to reference HiraginoKakuGothic.ttc. Interestingly, when I create a new project and use the same fonts ("ヒラギノ角ゴシック W3 16.0"), it does NOT automatically reference HiraginoKakuGothic.ttc. Here's what I've tried: ①Changed both UILabels' fonts to system font ②Verified in XIB Source Code that the .ttc references were gone ③Cleaned Build Folder ④Cleared DerivedData ⑤Restarted Xcode ⑥Set the labels back to "ヒラギノ角ゴシック W3 16.0" ⑦Checked XIB Source Code again - the non-existent .ttc references reappeared Even if I manually remove the customFonts references from the source code, they get regenerated as soon as I make any font changes in Interface Builder. I've also noticed that Xcode 16.1 has the same underlying issue, though it doesn't produce the console errors that Xcode 26 does. This seems to be a long-standing XIB issue, possibly related to reference caching. While new projects aren't affected, existing projects continue to maintain these incorrect references. My questions: How can I permanently resolve this issue in my existing project? What's the potential impact of these incorrect font references? Is there a way to clean up these cached references without affecting the rest of the project? Any insights or workarounds would be greatly appreciated. Thank you.

Hi everyone, I’ve run into a strange issue while building my app with Xcode 26 beta 6 (targeting iOS 26). When I include an app icon created using Icon Composer, the build time jumps to over 5 minutes. During this time, I noticed that a utility called AssetCatalogSimulatorAgent is consuming a significant amount of CPU. If I remove the Icon Composer-generated icon from my target, the build completes in about 40 seconds. This behavior is consistent across multiple builds. Has anyone else experienced this? Is there a known workaround or optimization for icons created with Icon Composer? I’d love to keep using the new icon format, but the build time is becoming a real bottleneck. Thanks in advance!

We’re preparing our 2026 iOS development roadmap and need clarification on upcoming App Store submission requirements related to Xcode versions. Our team plans to migrate our apps to Xcode 26 by December 2025, and we’ve seen references indicating that Xcode 26 or later may become mandatory for App Store submissions starting April 2026. Could Apple please confirm: 1. Whether April 2026 is the official enforcement date after which builds created with earlier versions of Xcode (e.g., Xcode 16.x) will no longer be accepted for App Store submission. 2. Whether there will be any grace period or continued acceptance for builds created with older versions of Xcode beyond that date. We want to ensure our upgrade plans and release timelines are aligned with Apple’s official submission policies to prevent any disruption to our delivery schedules. Thank you for your guidance.

"EnableLiveAssetServerV2-com.apple.MobileAsset.MetalToolchain" = on; ProductName: macOS ProductVersion: 26.0.1 BuildVersion: 25A362 The MetalToolchain is installed, however I keep getting error that MetalToolchain cannot be found by the Xcode "Command CompileMetalFile failed with a nonzero exit code" error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain ❯ xcodebuild -downloadComponent MetalToolchain 2025-10-31 11:18:29.004 xcodebuild[6605:45524] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.k9JmEp” couldn’t be opened because you don’t have permission to view it. Beginning asset download... 2025-10-31 11:18:29.212 xcodebuild[6605:45523] IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “com.apple.MobileAsset.MetalToolchain-v17.1.324.0.k9JmEp” couldn’t be opened because you don’t have permission to view it. Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg Done downloading: Metal Toolchain 17A324.

We have found that on iOS 26 beta some of our app icons built from an Xcode 16 asset catalog containing a single 1024x1024 .png file have a Liquid Glass effect applied to them while others have not. The documentation states that If you choose not to use Icon Composer, you can still use an AppIcon asset catalog in your project containing individual app icon images and let the system apply the Liquid Glass material. and If you prefer, you can take advantage of the system’s automatically generated treatment that is applied to all app icons. Is there any insight into how the system treats app icons that have not yet been updated with Icon Composer?

Xcode SPM (Swift Package Manager) Error I added the "Apple App Store Server Swift Library" library to Xcode using Swift Package Manager. Both the project and target are set to iOS 14 or higher. However, when I build after adding the library, an error occurs with the library. A message appears stating that the target is set to iOS 12. I'm using Xcode 26.0.1. Even after adding it to all my projects, the build continues with the same error. I've tried building the library from version 1.0.0 to the latest version, but the same error persists. Even after completely cleaning the project and running it, the same error persists. Does anyone know how to fix this?

I am using SwiftData for my model. Until Xcode 15 beta 4 I did not have issues. Since beta 5 I am receiving the following red warning multiple times: 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release This seems to be a CoreData warning. However, I am not using CoreData directly. I have no way to change the config of CoreData as used by SwiftData. My model just uses UUID, Int, String, Double, some of them as optionals or Arrays. I only use one attribute (.unique).

Using Xcode to build and deploy the app to my watch, this is what I get: “Waiting to reconnect to Apple Watch. Previous preparation error: Transport error." And then “Connecting to Apple Watch. Xcode will continue when the operation completes.” And these messages continue to switch between each other. Sometimes the watch to connect and the application starts, but more often a scenario occurs with endless reconnection. I'm using: MacOS 14.4.1 (MacBook Pro 2019; 1.4 GHz Quad-Core Intel Core i5), Xcode 15.3, Watch OS 10.2 (Apple Watch SE 1), iOS 17.1.1 (iPhone 15 Pro). Methods I tried: Connecting Macbook, iPhone and Watch to the same WIfi network; Disabling Watch (and IPhone) from the "Devices and Simulators" menu and setting up Watch (and IPhone) from the beginning. Any help?

I didn't run benchmarks before update, but it seems at least 5x slower. Of course all the LLM work is on remote servers, so is non-intuitive to me this should be happening. Had updated MacOS and Xcode to 26.1RC at the same time, so can't even say I think it is MacOS or I think it is Xcode. Before the update the progress indicator for each piece of code might seem to get stuck at the very end (and toggling between Navigators and Coding Assistant) in Xcode UI seemed to refresh the UI and confirm coding complete... but now it seems progress races to 50%, then often is stuck at 75%... well earlier than used to get stuck. And it like something is legitimately processing not just a UI glitch. I'm wondering if this is somehow tied to visual rendering of the code in the little white window? CMD-TAB into Xcode seems laggy. Xcode is pinning a CPU. Why, this is all remote LLM work? MacBook Pro 2021 M1 64GB RAM. Went from 26.01 to 26.1RC. Didn't touch any of the betas until RC1.