By default, AppleClang adds /usr/local/include to the application search folders for include files (as opposed to the system include dirs). This causes problems with the expected include order because application search folders always have priority over system includes. Specifically it causes problems with the conan package manager as library includes are added with -isystem This behaviour differs from LLVM mainline clang and GCC, where /usr/local/include is a system include (added with -internal-isystem). Steps to reproduce - run echo 'int main() { return 0; }' | clang -xc -v - the output is as follows Apple clang version 17.0.0 (clang-1700.0.13.5) Target: arm64-apple-darwin24.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" ... -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include ...

Hi! For the past few days I have been experiencing slower builds in my workflows, without a clear reason of the cause as sometimes they run with the old usual time. I tried contacting the Developer Support without success in finding out the reason of these issues, the case number was 102661768064. As an example, I have a workflow for Pull request checks that involves testing and analyzing. This usually ran for 11-15mins, but now it could take up to 30mins or more. Looking into the logs it just seems that the machine it's particularly slow, then in another build it goes with usual times again. As an example, below are the summaries of two builds of the same branch: Being in the free tier, these new long times are burning my free time quite faster and probably will need to look into running this checks in GitHub Actions if it doesn't improve. A hint of what might be wrong is also found in an error in the test workflow, which denotes a problem booting a simulator. Any help on this will be appreciated, thanks!

Hello, I’m trying to test a Xamarin.iOS application using the iOS 26 simulators in Mac Visual Studio, but I’m encountering an issue where the simulators are not appearing or accessible from Visual Studio. Details: macOS version: 15.6 (24G84) Xcode version: 26 Beta 5 Visual Studio version: 17.6.0.80 Xamarin.iOS version: Xamarin.Forms (Version: 4.6.0.1180) using XAML for cross-platform support (iOS/Android) The problem started after updating to iOS 26 SDK. I am unable to select or run the app on any iOS 26 simulator from Visual Studio. Has anyone faced a similar issue? Is there any configuration or workaround to enable iOS 26 simulators for Xamarin projects? Thanks in advance for your help.

Hello everyone, I urgently need help with my Apple Developer account. It has been over one month since I started the enrollment process, and I still cannot access my account. My app must be published before September, and this delay is causing serious impact on my work. Every time I try to proceed, I get this error: pgsql Copy Edit Unable to find a team with the given Team ID '7QVTL796RL' to which you belong. Please contact Apple Developer Program Support. https://developer.apple.com/support I have already contacted Apple Developer Program Support, but the issue is still unresolved. I am willing to provide any additional documents or payments immediately to get this fixed. This is time-sensitive and business-critical — if any Apple staff or experienced developers have advice, please let me know how I can escalate or resolve this quickly. Thank you in advance for any urgent help.

Good day! When your project have total 887 or more SPM local targets and then you try to build it, xcodebuild will be crash. Crash log: SWBBuildService-2025-08-11-151103.ips Thread 2 Crashed:: Dispatch queue: com.apple.root.default-qos.cooperative 0 libxpc.dylib 0x197c4826c _availability_version_check + 8 1 libswiftCore.dylib 0x1a9b44428 __isPlatformVersionAtLeast + 92 2 libswiftCore.dylib 0x1a9a6e054 _swift_allocObject_ + 1100 3 SWBMacro 0x104a9c408 specialized _ArrayBuffer._consumeAndCreateNew(bufferIsUnique:minimumCapacity:growForAppend:) + 116 4 SWBMacro 0x104a97b58 specialized Array.append<A>(contentsOf:) + 116 5 SWBMacro 0x104a954e8 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 160 6 SWBMacro 0x104a96548 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 4352 7 SWBMacro 0x104a96548 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 4352 8 SWBMacro 0x104a96548 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 4352 9 SWBMacro 0x104a96548 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 4352 10 SWBMacro 0x104a96548 MacroEvaluationProgram.executeInContext(_:withResultBuilder:alwaysEvalAsString:) + 4352 But if you try to build Package.swift via swift build command, it works. Here you can open sample project: Just Package.swift with SPM 900 targets Open Package.swift via Xcode 26 any beta and try to build Xcode workspace with SPM 900 targets Open MyApp.xcworkspace and try to build You can also make by self the Package.swift (also make required directories for SPM): // swift-tools-version: 5.9 import PackageDescription // let count = 800 // no crash let count = 900 // crash let targetsNames = (1...count).map { "Pkg1Target\($0)" } let targets = targetsNames.map { Target.target(name: $0) } let package = Package( name: "Pkg1TargetLibrary", platforms: [.iOS(.v16)], products: [ .library(name: "Pkg1TargetLibrary", targets: targets.map(\.name)), ], targets: targets )

When I update the macOS from 15.5 to 15.6, Preview error. 1、I try remove simulator cache， sdk 2、remove Xcode build cache 3、reinstall Xcode 4、try with this method https://byby.dev/uninstall-xcode#:%7E:text=Delete%20old%20simulators%20and%20devices,moving%20them%20to%20the%20Trash but all failed swiftui log.txt

So basically Apple suspended my developer account for no reason, I just had a lot of purchases from my game, then Apple sent me an email saying they are investigating my account, and finally they suspended my account, I don't know why, so can anyone help me?

Ok, I'm going crazy here. I have a static library for iOS that I want to build for the simulator. I use xcodebuild -destination="iOS Simulator" and then check the library using otool which tells me the platform is 6, which is Mac Catalyst. When I look at the output of xcodebuild, it says --- xcodebuild: WARNING: Using the first of multiple matching destinations: { platform:macOS, arch:arm64, variant:Mac Catalyst, id:00006041-0008492E3AA1801C, name:My Mac } ... It has the simulator listed too, way down the list: { platform:iOS Simulator, arch:x86_64, id:AB7A99B3-8D24-4F73-A42D-9BB45321928D, OS:18.6, name:iPad (A16) } When I put all of that into xcodebuild for the platform, it still says there are multiple matching destinations and chooses Mac Catalyst. Why? How? What? Does platform="iOS Simulator" mean nothing? How in the world does "Mac Catalyst" match "iOS Simulator"????? I don't want Mac Catalyst, I don't need Mac Catalyst, and I can't get rid of Mac Catalyst. Nothing I specify in xcodebuild results in anything I can build that will compile for the simulator. What the heck am I doing wrong?

Hello, I'm hoping to find a solution for a persistent enrollment issue and would appreciate any advice from the community. For several months, I have been unable to enroll in the Apple Developer Program. The automated system rejected my application, stating my identity could not be verified. This first occurred in December 2023. I have contacted Apple Support and spoken with a Senior Advisor. I explained that I am willing to provide any documentation needed to verify my identity (passport, driver's license, etc.), but was told this was not possible. The advisor stated the decision from the automated system is final and the issue cannot be escalated or resolved. This has put my app, which is fully developed and ready for submission, on indefinite hold. Has anyone else encountered this specific "identity verification" block where support states the decision is final? Is there a known workaround, a different department to contact, or any other path to get this reviewed by a human? Thank you for any help you can provide.

When I try to install the iOS 26.0 Universal Simulator component with Xcode-beta 5 I get the following error: Download failed. Domain: DVTDownloadableErrorDomain Code: 41 User Info: { DVTErrorCreationDateKey = "2025-08-11 14:39:06 +0000"; } -- Download failed. Domain: DVTDownloadableErrorDomain Code: 41 -- System Information macOS Version 15.6 (Build 24G84) Xcode 26.0 (24198.5) (Build 17A5295f) Timestamp: 2025-08-11T17:39:06+03:00

I regularly bump into folks confused by this issue, so I thought I’d collect my thoughts on the topic into a single (hopefully) coherent post. If you have questions or comments, put them in a new thread here on the forums. Feel free to use whatever subtopic and tags that apply to your situation, but make sure to add the Debugging tag so that I see your thread go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Testing and Debugging Code Running in the Background I regularly see questions like this: My background code works just fine in Xcode but fails when I download the app from the App Store. or this: … or fails when I run my app from the Home screen. or this: How do I step through my background code? These suggest a fundamental misunderstanding of how the debugger interacts with iOS’s background execution model. The goal of this post is to explain that misunderstanding so that you can effectively test and debug background code. Note The focus of this post is iOS. The advice here generally applies to any of iOS’s ‘child’ platforms, so iPadOS, tvOS, and so on. However, there will be some platform specific differences, especially on watchOS. This advice here doesn’t apply to macOS. It’s background execution model is completely different than the one used by iOS. Understand the Fundamentals The key point to note here is that the debugger prevents your app from suspending. This has important consequences for iOS’s background execution model. Normally: iOS suspends your app when it’s in the background. Once your app is suspended, it becomes eligible for termination. The most common reason for this is that the system wants to recover memory, but it can happen for various other reasons. For example, the system might terminate a suspended app in order to update it. Under various circumstances your app can continue running after moving to the background. A great example of this is the continued processed task feature, introduced in iOS 26 beta. Alternatively, your app can be resumed or relaunched in the background to perform some task. For example, the region monitor feature of Core Location can resume or relaunch your app in the background when the user enters or leaves a region. If no app needs to be executing, the system can sleep the CPU. None of this happens in the normal way if the debugger is attached to your app, and it’s vital that you take that into account when debugging code that runs in the background. An Example of the Problem For an example of how this can cause problems, imagine an app that uses an URLSession background session. A background session will resume or relaunch your app in the background when specific events happen. This involves two separate code paths: If your app is suspended, the session resumes it in the background. If your app is terminated, it relaunches it in the background. Neither code path behaves normally if the debugger is attached. In the first case, the app never suspends, so the resume case isn’t properly exercised. Rather, your background session acts like it would if your app were in the foreground. Normally this doesn’t cause too many problems, so this isn’t a huge concern. On the other hand, the second case is much more problematic. The debugger prevents your app from suspending, and hence from terminating, and thus you can’t exercise this code path at all. Seek Framework-Specific Advice The above is just an example, and there are likely other things to keep in mind when debugging background code for a specific framework. Consult the documentation for the framework you’re working with to see if it has specific advice. Note For URLSession background sessions, check out Testing Background Session Code. The rest of this post focuses on the general case, offering advice that applies to all frameworks that support background execution. Run Your App Outside of Xcode When debugging background execution, launch your app from the Home screen. For day-to-day development: Run the app from Xcode in the normal way (Product > Run). Stop it. Run it again from the Home screen. Alternatively, install a build from TestFlight. This accurately replicates the App Store install experience. Write Code with Debugging in Mind It’s obvious that, if you run the app without attaching the debugger, you won’t be able to use the debugger to debug it. Rather: Extract the core logic of your code into libraries, and then write extensive unit tests for those libraries. You’ll be able to debug these unit tests with the debugger. Add log points to help debug your integration with the system. Treat your logging as a feature of your product. Carefully consider where to add log points and at what level to log. Check this logging code into your source code repository and ship it — or at least the bulk of it — as part of your final product. This logging will be super helpful when it comes to debugging problems that only show up in the field. My general advice is that you use the system log for these log points. See Your Friend the System Log for lots of advice on that front. One of the great features of the system log is that disabled log points are very cheap. In most cases it’s fine to leave these in your final product. Attach and Detach In some cases it really is helpful to debug with the debugger. One option here is to attach to your running app, debug a specific thing, and then detach from it. Specifically: To attach to a running app, choose Debug > Attach to Process > YourAppName in Xcode. To detach, choose Debug > Detach. Understand Force Quit iOS allows users to remove an app from the multitasking UI. This is commonly known as force quit, but that’s not a particularly accurate term: The multitasking UI doesn’t show apps that are running, it shows apps that have been run by the user. The UI shows recently run apps regardless of whether they’re in the foreground, running in the background, suspended, or terminated. So, removing an app from the UI may not actually quit anything. Removing an app sets a flag that prevents the app from being launched in the background. That flag gets cleared when the user next launches the app manually. Note In some circumstances iOS will not honour this flag. The exact cases where this happens are not documented and have changed over time. Keep these behaviours in mind as you debug your background execution code. For example, imagine you’re trying to test the URLSession background relaunch code path discussed above. If you force quit your app, you’ll never hit this code path because iOS won’t relaunch your app in the background. Rather, add a debug-only button that causes your app to call exit. IMPORTANT This suggestion is for debugging only. Don’t include a Quit button in your final app! This is specifically proscribed by QA1561. Alternatively, if you’re attached to your app with Xcode, simply choose Product > Stop. This is like calling exit; it has no impact on your app’s ability to run in the background. Test With Various Background App Refresh Settings iOS puts users in control of background execution via the options in Settings > General > Background App Refresh. Test how your app performs with the following settings: Background app refresh turned off overall Background app refresh turned on in general but turned off for your app Background app refresh turned on in general and turned on for your app IMPORTANT While these settings are labelled Background App Refresh, they affect subsystems other than background app refresh. Test all of these cases regardless of what specific background execution feature you’re using. Test Realistic User Scenarios In many cases you won’t be able to fully test background execution code at your desk. Rather, install a TestFlight build of your app and then use the device as a normal user would. For example: To test Core Location background execution properly, actual leave your office and move around as a user might. To test background app refresh, use your app regularly during the day and then put your device on charge at night. Testing like this requires two things: Patience Good logging The system log may be sufficient here, but you might need to investigate other logging solutions that are more appropriate for your product. These testing challenges are why it’s critical that you have unit tests to exercise your core logic. It takes a lot of time to run integration tests like this, so you want to focus on integration issues. Before starting your integration tests, make sure that your unit tests have flushed out any bugs in your core logic. Revision History 2025-08-12 Made various editorial changes. 2025-08-11 First posted.

Getting a weird build failure with Xcode 26 beta 5 that I haven't seen before. Build works fine locally but fails in CI when building with xcodebuild with this error: build description signature: 7cb0bf47dd6decc14090f5ae23d66594 Build description path: /Users/user/Library/Developer/Xcode/DerivedData/ProjectName-dpklhpaqruhpwdbkihszqtqogzfb/Build/Intermediates.noindex/XCBuildData/7cb0bf47dd6decc14090f5ae23d66594.xcbuilddata error: Failed to decode version info for '/Applications/Xcode-beta.app/Contents/Developer/usr/bin/actool': The data couldn’t be read because it is missing. (stdout: '<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.ibtool.version</key> <dict> <key>bundle-version</key> <string>24118.1</string> <key>short-bundle-version</key> <string>26.0</string> </dict> </dict> </plist> ', stderr: '' The thing is, the data is definitely there - actool is outputting valid XML: <key>com.apple.ibtool.version</key> <dict> <key>bundle-version</key> <string>24118.1</string> <key>short-bundle-version</key> <string>26.0</string> </dict> But xcodebuild keeps saying it's missing. This error repeats like 15 times in the build log. Build command: set -o pipefail && xcodebuild -workspace "ProjectName/ProjectName.xcworkspace" -scheme "ProjectNameDeviceTests" -configuration "Debug" -destination "generic/platform=iOS" -resultBundlePath "Build for device/result_bundle.xcresult" -verbose TREAT_WARNINGS_AS_ERRORS=YES COMPILER_INDEX_STORE_ENABLE=NO -IDEBuildLocationStyle=Custom -IDECustomBuildLocationType=Absolute -IDECustomBuildProductsPath="$PWD/test_package" OTHER_SWIFT_FLAGS='${inherited} -Xfrontend -debug-time-function-bodies -Xfrontend -debug-time-expression-type-checking' SWIFT_COMPILATION_MODE=wholemodule clean build-for-testing The issue seems to come and go, sometimes cleaning the derived data and/or reset helps, sometimes it doesn't. Anyone else hitting this? Seems like a parsing bug in the beta where it can't read its own version info properly.

OS version:15.6 (24G84). mac mini m 4 Xcode:16.4 stack: Translated Report (Full Report Below) Process: Xcode [5261] Path: /Applications/Xcode.app/Contents/MacOS/Xcode Identifier: com.apple.dt.Xcode Version: 16.4 (23792) Build Info: IDEApplication-23792000000000000~2 (16F6) App Item ID: 497799835 App External ID: 874973124 Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 501 Date/Time: 2025-08-11 19:57:18.7642 +0800 OS Version: macOS 15.6 (24G84) Report Version: 12 Anonymous UUID: 314F3813-7BB3-0263-1826-79D64A62D963 Time Awake Since Boot: 700 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000001, 0x00000001ab5dc1f8 Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Terminating Process: exc handler [5261] Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libswiftCore.dylib 0x1ab5dc1f8 assertionFailure(:_:file:line:flags:) + 176 1 libswiftCore.dylib 0x1ab64a378 swift_unexpectedError + 656 2 IDEKit 0x108d2edc4 EditorGalleryView.exhibitIdentifiers(in:) + 972 3 IDEKit 0x108d2978c EditorGalleryView.commitState(to:) + 2640 4 IDEKit 0x108d29a64 @objc EditorGalleryView.commitState(to:) + 52 5 DVTFoundation 0x1046fe9d0 -[DVTStateToken _copyStatefulObjectState] + 84 6 DVTFoundation 0x1046feaa8 -[DVTStateToken pushStateToRepositoryAndReturnError:] + 52 7 DVTFoundation 0x10481ab48 -[DVTStateRepository _updateStateIfNeeded] + 232 8 DVTFoundation 0x1046fe9f0 -[DVTStateToken _copyStatefulObjectState] + 116 9 DVTFoundation 0x1046feaa8 -[DVTStateToken pushStateToRepositoryAndReturnError:] + 52 10 DVTFoundation 0x10481ab48 -[DVTStateRepository _updateStateIfNeeded] + 232 11 DVTFoundation 0x1046fe9f0 -[DVTStateToken _copyStatefulObjectState] + 116 12 DVTFoundation 0x1046feb04 -[DVTStateToken _stateDictionary] + 12 13 IDEKit 0x1089a2a38 -[IDEEditorContext _currentHistoryItemAllowingCoalescingAdjustment:] + 508 14 IDEKit 0x10899f11c -[IDEEditorContext willBeginTransactionScopeForNavigableItemCoordinator:] + 332 15 IDEKit 0x1087b3600 __35-[IDENavigableItemCoordinator init]_block_invoke + 148 16 DVTFoundation 0x1047a3ef0 -[DVTObservingBlockToken observeValueForKeyPath:ofObject:change:context:] + 440 17 Foundation 0x19b49c7b4 NSKeyValueNotifyObserver + 252 18 Foundation 0x19b549560 NSKeyValueDidChange + 388 19 Foundation 0x19b48f99c -[NSObject(NSKeyValueObservingPrivate) _changeValueForKeys:count:maybeOldValuesDict:maybeNewValuesDict:usingBlock:] + 760 20 Foundation 0x19b4b805c -[NSObject(NSKeyValueObservingPrivate) _changeValueForKey:key:key:usingBlock:] + 64 21 Foundation 0x19b577434 _NSSetBoolValueAndNotify + 404 22 DVTFoundation 0x104895f18 -[DVTModelGraphTransactionScope _beginTransactionDownward] + 48 23 DVTFoundation 0x104896160 -[DVTModelGraphTransactionScope performTransaction:] + 48 24 DVTFoundation 0x1047a0b30 -[DVTModelObjectGraph performBlockCoalescingModelChanges:] + 136 25 IDEFoundation 0x10d510c80 -[IDEFileReference _invalidateStartingWith:changeBlock:] + 172 26 IDEFoundation 0x10d511c00 -[IDEFileReference discoveredFileDataType] + 300 27 IDEKit 0x1088cda84 -[IDEFileReference(IDEKitFileReferencePropertyAdditions) navigableItem_contentDocumentLocation] + 32 28 IDEKit 0x1089030c0 -[IDEKeyDrivenNavigableItem contentDocumentLocation] + 68 29 IDEKit 0x108a4a644 +[IDENavigableItem _navigableItemForNavigationFromNavigableItem:workspace:] + 80

Hi, experts, I want to find Siri response window by bundle id and use it for checking or printing, here is my example code: XCUIDevice.shared.siriService.activate(voiceRecognitionText: "call mom") let siriApp = XCUIApplication(bundleIdentifier: "***") // Print out text from siriApp, // expecte print: "Sorry, I can't make a phone call with your iphone." Where should I put into ***? I tried "com.apple.SiriViewService", "com.apple.siri.velocity", "com.apple.springboard' but nothing work Any suggestion appreciated, thanks!

dyld[2515]: Symbol not found: _NSUserActivityTypeBrowsingWeb Referenced from: /private/var/containers/Bundle/Application/94D2F46D-70B0-4770-9DC3-50953F03A984/jiaxiaozhijia-ios.app/jiaxiaozhijia-ios.debug.dylib Expected in: <3BCD2D21-B96D-3B5F-8C58-3AFFFD6466A4> /System/Library/Frameworks/CoreServices.framework/CoreServices Symbol not found: _NSUserActivityTypeBrowsingWeb Referenced from: /private/var/containers/Bundle/Application/94D2F46D-70B0-4770-9DC3-50953F03A984/jiaxiaozhijia-ios.app/jiaxiaozhijia-ios.debug.dylib Expected in: <3BCD2D21-B96D-3B5F-8C58-3AFFFD6466A4> /System/Library/Frameworks/CoreServices.framework/CoreServices dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib:/System/Library/PrivateFrameworks/GPUToolsCapture.framework/GPUToolsCapture 请告诉我们该怎么做？现在xcode26beta5版本是不是还没有修复？

在项目中没有发现CoreServices.framework，然后编译运行就出现崩溃

Why can't Weatherkit return the corresponding language's ConditionCode based on Langular

I am trying to add some more capabilities to my app in the apple developer website. I checked the Notification option and hit save but whenever i refresh the option is left unchecked. I checked console logs and whenever i try saving I get an error.

**Background: Many iOS/macOS developers have faced issues like: • Autocomplete randomly stopping • Indexing freezing or slowing down • SwiftUI previews breaking unexpectedly • Build process hanging or crashing Even after multiple updates, these issues seem to come back in different forms. ** Do you think Apple should consider a full architectural rewrite of Xcode? Would separating SDK updates from IDE updates help? How do you personally deal with Xcode’s instability in your workflow?

I created an app that uses the camera function in Xcode, but it says I don't have camera permission. The app only runs once and then won't run again. The log below says "No active account." Is this because my paid account isn't properly reflected in Xcode? In Xcode Settings > Account, I'm logged in my acciunt, with the team set to "my Organization name" and the role set to "admin." However, in Manage Certificates, the Status is blank. It should say "Valid." How can I properly reflect my account in Xcode? Error enumerating all transactions: Error Domain=ASDErrorDomain Code=509 "No active account" UserInfo={NSLocalizedDescription=No active account}