When I thought Xcode could not get any worse, here's the most absurd thing I have ever seen developing software in almost 20 years of work. When building a project, which I haven't touched lately, and last time it was building just fine, it raised errors on a class that doesn't even belong in any way to such project, it only exists in another one. To clarify, we're talking of a project written in C++ which runs only on mac, which is failing due to linker errors, where the linker can not find symbols of a class living in a different project and that is not referenced in any way inside this project. I mean, really? how does Apple manage to make Xcode more and more unstable by the minute? Starting from Xcode 15.1 I was already experiencing much longer building times, due to the fact that it doesn't manage the cache properly and is rebuilding lots of stuff every time..

I am trying to perform an unstash operation. I RC on the stash to restore, select "Apply Stashed Changes". It then launches a comparison window to allow me to cherrypick the changes I want to include. However, the button along the bottom, "Apply Changes" is grayed out and remains so no matter what I do. Switching stashes, exiting and restarting xcode. TG i made an emergency project backup right before I did the stash, just for a case like this. Bug? Feature?

The app stops on the breakpoint when "All Runtime Issues" is added. If I disable the breakpoint, the app runs normally. Is there a new project setting to avoid this breakpoint from being set. It does not appear to be a valid error. I am running Xcode 16.2. I edited the "Type" field in the breakpoint box. This occurs with the "System Frameworks" option only.

Hi all, I’m running into a persistent linker error when building my Unity 6 project (IL2CPP, iOS target) that calls a Swift method via an Objective-C++ wrapper. Despite following all known steps, I keep getting: Undefined symbols for architecture arm64: "_placeGeoAnchor", referenced from: _GeoAnchorTrigger_placeGeoAnchor in libGameAssembly.a ... ld: symbol(s) not found for architecture arm64 I’m trying to place a persistent AR anchor at real-world GPS coordinates (so that the same asset can appear at the same location for a returning user). Since I’m targeting iOS, I can’t use Google’s geospatial anchors (but I sooo wish I could--please apple I beg of you stop being so selfish lol). I've already done these things: Swift file is added to Unity-iPhone target. .mm and .h files are in Unity-iPhone target under Compile Sources. Bridging header is set to Unity-iPhone-Bridging-Header.h. Generated header name is correct (GeoTest-Swift.h). Build Active Architecture Only set to No. Function has attribute((visibility("default"))). Unity project uses IL2CPP scripting backend. Yet I'm still getting the same linker error — it appears Unity (via IL2CPP) references the function, but Xcode doesn't link it. It’s something small that’s being missed with how IL2CPP links native symbols? Or maybe I need to explicitly include something in Link Binary With Libraries? I’ve verified symbol visibility and targets repeatedly. I’ve built AR features in Unity before (for Quest), but this is my first time trying to bridge C# → Objective-C++ → Swift in this way for a geolocation-based AR anchor for an iphone. I'm going crazy, I’ve been stuck on this for 12+ hours now, so any insight or nudge would be deeply appreciated. SPECS: Macbook Pro M4 Pro--Sequoia 15.4 Unity 6000.0.45f1 IPhone 11 iOS 18.4 Xcode 15

I have a Apple Developer accounts for development purposes only and that is also used for testing builds via TestFlight. Is the Age Ratings Responses updates due by the end of January 2026 still required even to send builds to TestFlight?

I am running into an issue where when layers are grouped, the icon is not shown as it does within the preview in the Icon Composer app Is this a bug or is it some setting within the group/app?

I'm trying the "Connect and Solve" course of Swift Playground. I can't use "world.place" to place bricks at positions (2, 2), (6, 2) (automatically disappear), but I can place bricks at positions (4, 2) in the same way. Two bricks must be placed overlapping in positions (2, 2) and (6, 2) to achieve the goal. Only when a brick is placed in position (4, 2) can the goal be achieved. The problem is that the bricks placed on (6, 2) and (2, 2) will disappear and cannot be placed successfully. The following is my code writing... let Block1 = Block() for i in 1 ... 2 { world.place(Block1, atColumn: 2, row: 2) } for i in 1 ... 2 { world.place(Block1, atColumn: 6, row: 2) } world.place(Block1, atColumn: 4, row: 2) func turnaround() { turnRight() turnRight() } func walk4() { for i in 1 ... 3 { moveForward() } } func collet() { for i in 1 ... 2 { moveForward() } toggleSwitch() turnRight() walk4() collectGem() turnaround() walk4() turnRight() } for i in 1 ... 3 { collet() } ‌I would appreciate it if someone could offer some recommendations.‌ ‌Thanks a lot‌

Hi all, I’m running into an issue with my iOS + Apple Watch app project, and I could really use some advice. My WatchOS app requires an iOS companion for settings and configuration, so both apps need to be distributed together. Here’s how I structured my Xcode project: Main iOS App target WatchOS App target WatchOS Extension target However, I’m very confused about how these targets interact, and things are not working as expected. The problem: I can build and run the WatchOS app and its extension independently in the simulator by selecting their schemes. When I select the main iOS app scheme, I get an error about ITSWatchOnlyContainer in the Info.plist—even though there’s no Info tab for that target in Xcode. I’m able to distribute the WatchOS app by itself, and the extension as well. But I can’t distribute them bundled together as a single package, and I haven’t found any clear resources that explain how to fix this. This is my very first app, and it’s frustrating to get stuck just before the finish line! Project Structure / steps to reproduce Let’s say my project is called MyAppProject, with these targets: MyAppProject Main iOS App Embedded target: MyAppProject Watch App Bundle identifier: com.example.MyAppProject MyAppProject Watch App WKCompanionAppBundleIdentifier: com.example.MyAppProject “Requires iOS App”: YES MyAppProject Extension Bundle identifier: com.example.MyAppProject When running from the MyAppProject scheme, I get this error (even though I can’t see or edit the Info.plist in Xcode for this target): “Please try again later. This app has the ITSWatchOnlyContainer key set in its Info.plist, which identifies it as a shell app surrounding a Watch-only app; these are not installable.” As a result, I can’t distribute the app as a bundle. I’d appreciate help understanding: How should the Info.plist files be configured for each target? What do I do if the Info.plist path seems missing in the Xcode UI? Is there a “correct” way to structure an iOS + WatchOS app for bundled distribution?

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.

On my M4 Mac running macOS 15.5 using Xcode 16.4 & Xcode CLT 16.4, Swift code in my Swift Package Manager 5.9 project (https://github.com/mas-cli/mas) builds fine against some included Objective-C headers via the following command line: swift build -c release But cannot find modules for the included Objective-C headers when building inside Xcode 16.4 or with the following command line on the same Mac: xcodebuild -scheme mas -configuration Release -destination platform=macOS,arch=arm64,variant=macos The error is: Sources/mas/AppStore/AppleAccount.swift:9:16: error: no such module 'StoreFoundation' How can I get Xcode / xcodebuild to work? Note that the project is normally built by running: Scripts/build which runs: swift build -c release after running the following script, which must be run before any build (swift, Xcode, or xcodebuild) because it generates a necessary file (Sources/mas/Package.swift): Scripts/generate_package_swift I've tried moving the Objective-C headers into include subfolders of their existing module folders, using double quotes instead of angle brackets for the #import statements, having module.modulemap files in the include subfolders or their parent module folder, and moving the module folders one level up the file hierarchy, to no avail. I've also tried various changes to the root-level Package.swift (not the generated one deeper in the hierarchy, which isn't inclined in the build configuration), like making separate library targets for each of the Objective-C modules, various swiftSettings & linkerSettings, etc. Maybe some of those changes would have helped, but maybe they were in incorrect combinations. Thanks for any help.

For the Linux version of my application which is written in C++ using Qt, I display the CHM format help files with this code: QString helpFile{ QCoreApplication::applicationDirPath() + "/Help/" + tr("DeepSkyStacker Help.chm","IDS_HELPFILE") }; QString program{ "kchmviewer" }; QStringList arguments{ "-token", "com.github.deepskystacker", helpFile }; helpProcess->startDetached(program, arguments); (helpProcess is a pointer to a QProcess object) The -token com.github.deepskystackerpart of that ensures that only a single instance of the viewer is used for any code that uses that invocation. Are there any chm file viewers for macOS that are capable of that sort of trick? The ones I've found on the App Store give minimal information and appear to be very simple minded tools that are not not intended for integration into an application as above. I know that MacPorts offers ports of kchmviewer but I'd prefer not to use either that or HomeBrew ... David

When a new application runs on iOS 18.4 simulator and tries to access the Speech Framework, prompting a request for authorisation to use Speech Recognition, the application will crash if the user clicks allow. Same issue in the visionOS 2.4 simulator. Using Swift 6. Report Identifier: FB17686186 /// Checks speech recognition availability and requests necessary permissions. @MainActor func checkAvailabilityAndPermissions() async { logger.debug("Checking speech recognition availability and permissions...") // 1. Verify that the speechRecognizer instance exists guard let recognizer = speechRecognizer else { logger.error("Speech recognizer is nil - speech recognition won't be available.") reportError(.configurationError(description: "Speech recognizer could not be created."), context: "checkAvailabilityAndPermissions") self.isAvailable = false return } // 2. Check recognizer availability (might change at runtime) if !recognizer.isAvailable { logger.error("Speech recognizer is not available for the current locale.") reportError(.configurationError(description: "Speech recognizer not available."), context: "checkAvailabilityAndPermissions") self.isAvailable = false return } logger.trace("Speech recognizer exists and is available.") // 3. Request Speech Recognition Authorization // IMPORTANT: Add `NSSpeechRecognitionUsageDescription` to Info.plist let speechAuthStatus = SFSpeechRecognizer.authorizationStatus() logger.debug("Current Speech Recognition authorization status: \(speechAuthStatus.rawValue)") if speechAuthStatus == .notDetermined { logger.info("Requesting speech recognition authorization...") // Use structured concurrency to wait for permission result let authStatus = await withCheckedContinuation { continuation in SFSpeechRecognizer.requestAuthorization { status in continuation.resume(returning: status) } } logger.debug("Received authorization status: \(authStatus.rawValue)") // Now handle the authorization result let speechAuthorized = (authStatus == .authorized) handleAuthorizationStatus(status: authStatus, type: "Speech Recognition") // If speech is granted, now check microphone if speechAuthorized { await checkMicrophonePermission() } } else { // Already determined, just handle it let speechAuthorized = (speechAuthStatus == .authorized) handleAuthorizationStatus(status: speechAuthStatus, type: "Speech Recognition") // If speech is already authorized, check microphone if speechAuthorized { await checkMicrophonePermission() } } }

Hi everyone, I am developing a benchmarking tool to measure memory latency (L1/L2/DRAM) on Apple Silicon. I am currently using Xcode Instruments (CPU Counters) to validate my results. In my latest run for a 128 MB buffer with random access, Instruments shows: Latency (cycles): ~259 cycles (derived from LDST_UNIT_OLD_L1D_CACHE_MISS / L1D_CACHE_MISS_LD). Manual Timer Result: ~80 ns. To correlate these two values, I need the exact CPU Frequency (GHz) at the time of the sample. My Questions: Is there a recommended way to programmatically fetch the current frequency of the Performance cores (p-cores) during a benchmark run? Does Apple provide a "nominal" frequency value for M-series chips that we should use for cycle-to-nanosecond conversions? In Instruments, is there a hidden counter or "Average Frequency" metric that I can enable to avoid manual math? Hardware/Software Environment: Tool: Instruments 26.3+ (CPU Counters Template). Chip: A19, iPhone 17 pro. OS: 26.3.

Hi, I'm trying to plan some roadmaps out and also have some issues with ios 15.0. Since it's no longer supported by Apple, any word on if/when iOS 15.0 will be removed from the "minimum deployment" version list in Xcode?

We're having issues getting Sign in with Google to function on TestFlight (not experiencing these issues on iOS Browser) with user unable to be authorised and proceed to logged in screens of our app. Below are the three sign-in methods tested and the exact results for each. Button 1: Default Standard Google Sign-In button (Google JavaScript SDK) embedded in the frontend. Uses the normal OAuth browser redirect flow. Auth URL: https://accounts.google.com/o/oauth2/v2/auth?... Sometimes disallowed_useragent error. Other times a 400 invalid_request error. In most cases the callback is never triggered inside the wrapper. Appears that the wrapper does not retain cookies/session data from the external Google window. Button 2: Custom Custom button calling Google OAuth through our own redirect handler. Explicitly set a custom user-agent to bypass disallowed user agent logic. Later removed user-agent override entirely for testing. Added multiple ATS (App Transport Security) exceptions for Google domains. Added custom URL scheme to Info.plist for OAuth redirect. Changing the user-agent had no effect. ATS exceptions + scheme support verified and working. Redirect still fails to propagate tokens back to the WebView. In tests a few weeks ago we got to Google’s login page, but it never returned to the app with a valid code. Now we are consistently getting disallowed_useragent error. Button 3: Default Same as Button 1 however tested outside of Vue.js with just plain JavaScript. Added new Google domain exceptions and updated redirect URIs. Behaviour matches Button 1 Google account selection sometimes worked, however now consitently disallowed_useragent error Additional Technical Attempts User-Agent Modifications Set UA to standard desktop Chrome → no effect. Removed UA override → no effect. ATS / Domain / Scheme Configuration Added: accounts.google.com .googleusercontent.com *.googleapis.com

what is the diff between INST_ALL and Instructions(FIXED_INSTRUCTIONS)? also CORE_ACTIVE_CYCLE VS Cycles(FIXED_CYCLES)

I’m a registered iOS developer, and I’ve been facing an issue with installing iOS developer updates for the past couple of years. I can download the updates, but they get stuck at 99.9% complete and don’t finish. I’ve tried following the instructions to force restart the phone, but it stays on the Apple logo screen until it dies. I can update official iOS versions, but not beta versions. To update, I have to put the phone in DFU mode and install the update that way. This is frustrating and prevents me from making timely updates to my app and from diagnosing new issues during testing. I’d like to request that Apple investigate this issue and identify a solution. For reference, I’ve installed a bare-bones version with no new apps, and the problem persists. I would like a resolution that allows me to update normally without having to DFU the phone each time. This occurs via OTA or IPSW manual download and installation. Please refer to the following FB submission numbers: FB21642029 and FB21017894. CAN SOMEONE PLEASE RESPOND BACK TO THIS MESSAGE AND HELP ME TROUBLESHOOT THIS ISSUE?!

I have a valid dev certificate and created a valid provisioning Profile. I have added the Device UDID too , which I can see in provisioning Profile too. In XCode-16 both certificate and provisioning Profile looks good and no issue here with the expiration date too. Issue - While running the app on my iPhone connected to Mac.its shows the build is successful but shows the followinf errors . An IPA of APP failing the installation. Unable to install the App `A valid provisioning profile for this executable was not found. Domain: com.apple.dt.MobileDeviceErrorDomain`

Hi, I requested the https://itunes.apple.com/lookup?id=6482849843&country=us for getting the information of Goods puzzle sort challange , but the screenshotUrls in the response was empty. Is iTunes search API has issue with getting the screenshot urls ? Is there any plan to update it ?

I am creating an xcframework for a static library for iOS, but I am encountering a perplexing issue with Xcode 16.3. When I build an xcframework using C++ in one project and import it into another project, the application runs with corrupted memory. In the framework project, I use os_unfair_lock, but when attempting to lock, the app crashes due to a state error. This suggests that memory corruption is occurring. When the xcframework is built with Xcode 16.2, a proper binary is generated, and the app runs without any problems. Since I do not want to disclose the source code, I am trying to construct a minimal project that reproduces the issue, but so far I have not been successful. Fundamentally, I feel that the compiler in Xcode 16.3 cannot be trusted.