Translated Report (Full Report Below) Process: XCBBuildService [47544] Path: /Applications/Xcode.app/Contents/SharedFrameworks/XCBuild.framework/Versions/A/PlugIns/XCBBuildService.bundle/Contents/MacOS/XCBBuildService Identifier: com.apple.dt.XCBBuildService Version: 1.0 (23000.1.226) Build Info: XCBuild-23000001226000000~21 (16A242d) Code Type: ARM-64 (Native) Parent Process: Xcode [25688] Responsible: Xcode [25688] User ID: 502 Date/Time: 2024-09-22 15:45:07.2531 +0530 OS Version: macOS 15.0 (24A335) Report Version: 12 Anonymous UUID: 286B9741-8E5D-765F-A412-4814BBAEFFF8 Sleep/Wake UUID: 633F27DD-DBD3-495A-852E-25513538F671 Time Awake Since Boot: 9600 seconds Time Since Wake: 7346 seconds "name" : "XCBTaskConstruction", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 4397056000, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.XCBTaskExecution", "size" : 1179648, "uuid" : "908f7c32-c5d5-3027-ace3-874d6c83e90c", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/XCBuild.framework\/Versions\/A\/PlugIns\/XCBBuildService.bundle\/Contents\/Frameworks\/XCBTaskExecution.framework\/Versions\/A\/XCBTaskExecution", "name" : "XCBTaskExecution", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 4384325632, "size" : 3653632, "uuid" : "5e5f39eb-5e1c-356d-9d28-28d1b62b7f8b", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/libSwiftDriver.dylib", "name" : "libSwiftDriver.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4380737536, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.XCBLLBuild", "size" : 16384, "uuid" : "28f5320e-9f77-3100-a346-b00eb9cadcf6", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/XCBuild.framework\/Versions\/A\/PlugIns\/XCBBuildService.bundle\/Contents\/Frameworks\/XCBLLBuild.framework\/Versions\/A\/XCBLLBuild", "name" : "XCBLLBuild", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 4380590080, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.XCBCSupport", "size" : 65536, "uuid" : "bb4f1b7a-89be-3b20-b5d9-e930fcbca265", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/XCBuild.framework\/Versions\/A\/PlugIns\/XCBBuildService.bundle\/Contents\/Frameworks\/XCBCSupport.framework\/Versions\/A\/XCBCSupport", "name" : "XCBCSupport", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 4389109760, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.llbuild", "size" : 835584, "uuid" : "8b38eaf5-b815-390c-940e-34a645e10bfc", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/llbuild.framework\/Versions\/A\/llbuild", "name" : "llbuild", "CFBundleVersion" : "23000.0.31" }, { "source" : "P", "arch" : "arm64", "base" : 4382588928, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.XCBLibc", "size" : 16384, "uuid" : "be7fa119-c9cc-3863-af3f-ae96cd4228cc", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/XCBuild.framework\/Versions\/A\/PlugIns\/XCBBuildService.bundle\/Contents\/Frameworks\/XCBLibc.framework\/Versions\/A\/XCBLibc", "name" : "XCBLibc", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 4380917760, "CFBundleShortVersionString" : "1.0", "CFBundleIdentifier" : "com.apple.dt.XCBCLibc", "size" : 16384, "uuid" : "31deeefc-7a76-3112-a73b-51f66534b781", "path" : "\/Applications\/Xcode.app\/Contents\/SharedFrameworks\/XCBuild.framework\/Versions\/A\/PlugIns\/XCBBuildService.bundle\/Contents\/Frameworks\/XCBCLibc.framework\/Versions\/A\/XCBCLibc", "name" : "XCBCLibc", "CFBundleVersion" : "23000.1.226" }, { "source" : "P", "arch" : "arm64", "base" : 13191659520, "size" : 115720192, "uuid" : "476e35ff-6787-31e0-870a-597bd525254d", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/lib_InternalSwiftScan.dylib", "name" : "lib_InternalSwiftScan.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4919033856, "size" : 65536, "uuid" : "9fe47d2a-a9b4-3de6-a20d-9153fc7f3563", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftIDEUtils.dylib", "name" : "libSwiftIDEUtils.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4921032704, "size" : 294912, "uuid" : "ff5c9933-0266-35a3-a857-52de4f1ca1ca", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftCompilerPluginMessageHandling.dylib", "name" : "libSwiftCompilerPluginMessageHandling.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4918607872, "size" : 163840, "uuid" : "e55b9c97-b69a-3240-99d0-26107b16fd45", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftSyntaxMacroExpansion.dylib", "name" : "libSwiftSyntaxMacroExpansion.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4919820288, "size" : 114688, "uuid" : "ff72542b-0d39-38f9-b909-2d8585f02814", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftOperators.dylib", "name" : "libSwiftOperators.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4919558144, "size" : 32768, "uuid" : "2612e448-1b3d-35fd-b68d-94eca7e31285", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftSyntaxMacros.dylib", "name" : "libSwiftSyntaxMacros.dylib" }, { "source" : "P", "arch" : "arm64", "base" : 4932501504, "size" : 212992, "uuid" : "2f7da703-7979-3616-b30f-96ce4e2f54c7", "path" : "\/Applications\/Xcode.app\/Contents\/Developer\/Toolchains\/XcodeDefault.xctoolchain\/usr\/lib\/swift\/host\/libSwiftSyntaxBuilder.dylib", "source" : "P", "arch" : "arm64", "base" : 4933500928, "size" : 376832, "uuid" : "4757e13b-4636-326c-8588-82a4070536d4",

Setup: PLATFORM AND VERSION: iOS Development environment: Xcode Version 16.0 (16A242d), macOS 14.6.1 Run-time configuration: iOS 15-18 tried with same error. When building the app despite the fact it's pure Swift code getting error: CaPark.swift file is here: import Foundation class CarPark: Identifiable, Decodable { var carParkId: String var address: String var totalLots: String var lotsAvailable: String? var lotType:String var lat: Double var lng: Double var couponEps: String var agency: String } Issue seems like started after xcode update to version mentioned above. What i've tried: Clean ups Reinstallation of Xcoce Rollback to previous versions of Xcode Start clean project from VCS App is published and multiple versions were uploaded to AppStore, this problem is new and came out of nowhere. Let me know if additional info is required. Thank you!

I often get questions about third-party crash reporting. These usually show up in one of two contexts: Folks are trying to implement their own crash reporter. Folks have implemented their own crash reporter and are trying to debug a problem based on the report it generated. This is a complex issue and this post is my attempt to untangle some of that complexity. If you have a follow-up question about anything I've raised here, please put it in a new thread with the Debugging tag. IMPORTANT All of the following is my own direct experience. None of it should be considered official DTS policy. If you have a specific question that needs a direct answer — perhaps you’re trying to convince your boss that implementing your own crash reporter is a very bad idea — start a dedicated thread here on the forums and we can discuss the details there. Use whatever subtopic is appropriate for your issue, but make sure to add the Debugging tag so that I see it go by. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Scope First, I can only speak to the technical side of this issue. There are other aspects that are beyond my remit: I don’t work for App Review, and only they can give definitive answers about what will or won’t be allowed on the store. Implementing your own crash reporter has significant privacy implications. IMPORTANT If you implement your own crash reporter, discuss the privacy impact with a lawyer. This post assumes that you are implementing your own crash reporter. A lot of folks use a crash reporter from another third party. From my perspective these are the same thing. If you use a custom crash reporter, you are responsible for its behaviour, both good and bad, regardless of where the actual code came from. Note If you use a crash reporter from another third party, run the tests outlined in Preserve the Apple Crash Report to verify that it’s working well. General Advice I strongly advise against implementing your own crash reporter. It’s very easy to create a basic crash reporter that works well enough to debug simple problems. It’s impossible to implement a good crash reporter, one that’s reliable, binary compatible, and sufficient to debug complex problems. The bulk of this post is a low-level explanation of that impossibility. Rather than attempting the impossible, I recommend that you lean in to Apple’s crash reporter. In recent years it’s acquired some really cool new features: If you’re creating an App Store app, the Xcode organiser gives you easy, interactive access to Apple crash reports. If you’re an enterprise developer, consider switching to Custom App Distribution. This yields all the benefits of App Store distribution without your app being generally available on the store. iOS 14 and macOS 12 report crashes in MetricKit. This is a very cool feature, and I’m surprised by how few people use it effectively. If you previously dismissed Apple crash reports as insufficient, I encourage you to reconsider that decision. Why Is This Impossible? Earlier I said “It’s impossible to implement a good crash reporter”, and I want to explain why I’m confident enough in my conclusions to use that specific word. There are two fundamental problems here: On iOS (and the other iOS-based platforms, watchOS and tvOS) your crash reporter must run inside the crashed process. That means it can never be 100% reliable. If the process is crashing then, by definition, it’s in an undefined state. Attempting to do real work in that state is just asking for problems [1]. To get good results your crash reporter must be intimately tied to system implementation details. These can change from release to release, which invalidates the assumptions made by your crash reporter. This isn’t a problem for the Apple crash reporter because it ships with the system. However, a crash reporter that’s built in to your product is always going to be brittle. I’m speaking from hard-won experience here. I worked for DTS during the PowerPC-to-Intel transition, and saw a lot of folks with custom crash reporters struggle through that process. Still, this post exists because lots of folks ignore this reality, so the subsequent sections contain advice about specific technical issues. WARNING Do not interpret any of the following as encouragement to implement your own crash reporter. I strongly advise against that. However, if you ignore my advice then you should at least try to minimise the risk, which is what the rest of this document is about. [1] On macOS it’s possible for your crash reporter to run out of process, just like the Apple crash reporter. However, possible is not the same as easy. In fact, running out of process can make things worse: It prevents you from geting critical state for the crashed process without being tightly bound to OS implementation details. It would be nice if Apple provided APIs for this sort of thing, but that’s currently not the case. Preserve the Apple Crash Report You must ensure that your crash reporter doesn’t disrupt the Apple crash reporter. This is important for three reasons: Some fraction of your crashes will not be caused by your code but by problems in framework code, and accurate Apple crash reports are critical in diagnosing such issues. When dealing with really hard-to-debug problems, you need the more obscure info that’s shown in the Apple crash report. If you’re working with someone from Apple (here on the forums, via a bug report, or a DTS case, or whatever), they’re going to want an accurate Apple crash report. If your crash reporter is disrupting the Apple crash reporter — either preventing it from generating crash reports entirely [1], or distorting those crash reports — that limits how much they can help you. IMPORTANT This is not a theoretical concern. The forums have many threads where I’ve been unable to help folks debug a gnarly problem because their third-party crash reporter didn’t preserve the Apple crash report (see here, here, and here for some examples). To avoid these issues I recommend that you test your crash reporter’s impact on the Apple crash reporter. The basic idea is: Create a program that generates a set of specific crashes. Run through each crash. Verify that your crash reporter produces sensible results. Verify that the Apple crash reporter produces the same results as it does without your crash reporter With regards step 1, your test suite should include: An un-handled language exception thrown by your code An un-handled language exception thrown by the OS (accessing an NSArray out of bounds is an easy way to get this) Various machine exceptions (at a minimum, memory access, illegal instruction, and breakpoint exceptions) Stack overflow Make sure to test all of these cases on both the main thread and a secondary thread. With regards step 4, check that the resulting Apple crash report includes correct values for: The exception info The crashed thread That thread’s state Any application-specific info, and especially the last exception backtrace [1] A particularly pathological behaviour here is to end your crash reporter by calling exit. This completely suppresses the Apple crash report. Some third-party language runtimes ‘helpfully’ include such a crash reporter, which makes it very hard to debug problems that occur within your process but outside of that language. Signals Many third-party crash reporters use UNIX signals to catch the crash. This is a shame because using Mach exception handling, the mechanism used by the Apple crash reporter, is generally a better option. However, there are two reasons to favour UNIX signals over Mach exception handling: On iOS-based platforms your crash reporter must run in-process, and doing in-process Mach exception handling is not feasible. Folks are a lot more familiar with UNIX signals. Mach exception handling, and Mach messaging in general, is pretty darned obscure. If you use UNIX signals for your crash reporter, be aware that this API has some gaping pitfalls. First and foremost, your signal handler can only use async signal safe functions [1]. You can find a list of these functions in sigaction man page [2] [3]. WARNING This list does not include malloc. This means that a crash reporter’s signal handler cannot use Objective-C or Swift, as there’s no way to constrain how those language runtimes allocate memory [4]. That means you’re stuck with C or C++, but even there you have to be careful to comply with this constraint. The Operative: It’s worse than you know. Captain Malcolm Reynolds: It usually is. Many crash reports use functions like backtrace (see its man page) to get a backtrace from their signal handler. There’s two problems with this: backtrace is not an async signal safe function. backtrace uses a naïve algorithm that doesn’t deal well with cross signal handler stack frames [5]. The latter point is particularly worrying, because it hides the identity of the stack frame that triggered the signal. If you’re going to backtrace out of a signal, you must use the crashed thread’s state (accessible via the handlers uap parameter) to start your backtrace. Apropos that, if your crash reporter wants to log the state of the crashed thread, that’s the place to get it. Your signal handler must be prepared to be called by multiple threads. A typical crashing signal (like SIGSEGV) is delivered to the thread that triggered the machine exception. While your signal handler is running on that thread, other threads in your process continue to run. One of these threads could crash, causing it to call your signal handler. It’s a good idea to suspend all threads in your process early in your signal handler. However, there’s no way to completely eliminate this window. Note The need to suspend all the other threads in your process is further evidence that sticking to async signal safe functions is required. An unsafe function might depend on a thread you’ve suspended. A typical crashing signal is delivered on the thread that triggered the machine exception. If the machine exception was caused by a stack overflow, the system won’t have enough stack space to call your signal handler. You can tell the system to switch to an alternative stack (see the discussion of SA_ONSTACK in the sigaction man page) but that isn’t a complete solution (because of the thread issue discussed immediately above). Finally, there’s the question of how to exit from your signal handler. You must not call exit. There’s two problems with doing that: exit is not async signal safe. In fact, exit can run arbitrary code via handlers registered with atexit. If you want to exit the process, call _exit. Exiting the process is a bad idea anyway, because it will prevent the Apple crash reporter from running. This is very poor form. For an explanation as to why, see Preserve the Apple Crash Report (above). A better solution is to unregister your signal handler (set it to SIG_DFL) and then return. This will cause the crashed process to continue execution, crash again, and generate a crash report via the Apple crash reporter. [1] While the common signals caught by a crash reporter are not technically async signals (except SIGABRT), you still have to treat them as async signals because they can occur on any thread at any time. [2] It’s reasonable to extend this list to other routines that are implemented as thin shims on a system call. For example, I have no qualms about calling vm_read (see below) from a signal handler. [3] Be aware, however, that even this list has caveats. See my Async Signal Safe Functions vs Dyld Lazy Binding post for details. [4] I expect that it’ll eventually be possible to write signal handlers in Swift, possibly using some facility that evolves from the the existing, but unsupported, @_noAllocation and @_noLocks attributes. If you’d like to get involved with that effort, I recommend that engage with the Swift Evolution process. [5] Cross signal handler stack frames are pushed on to the stack by the kernel when it runs a signal handler on a thread. As there’s no API to learn about the structure of these frames, there’s no way to backtrace across one of these frames in isolation. I’m happy to go into details but it’s really not relevant to this discussion [6]. If you’re interested, start a new thread with the Debugging tag and we can chat there. [6] (Arg, my footnotes have footnotes!) The exception to this is where your trying to generate a crash report for code running in a signal handler. That’s not easy, and frankly you’re better off avoiding signal handlers in general. Where possible, handle signals via a Dispatch event source. Reading Memory A signal handler must be very careful about the memory it touches, because the contents of that memory might have been corrupted by the crash that triggered the signal. My general rule here is that the signal handler can safely access: Its code Its stack (subject to the constraints discussed earlier) Its arguments Immutable global state In the last point, I’m using immutable to mean immutable after startup. It’s reasonable to set up some global state when the process starts, before installing your signal handler, and then rely on it in your signal handler. Changing any global state after the signal handler is installed is dangerous, and if you need to do that you must be careful to ensure that your signal handler sees consistent state, even though a crash might occur halfway through your change. You can’t protect this global state with a mutex because mutexes are not async signal safe (and even if they were you’d deadlock if the mutex was held by the thread that crashed). You should be able to use atomic operations for this, but atomic operations are notoriously hard to use correctly (if I had a dollar for every time I’ve pointed out to a developer they’re using atomic operations incorrectly, I’d be very badly paid (-: but that’s still a lot of developers!). If your signal handler reads other memory, it must take care to avoid crashing while doing that read. There’s no BSD-level API for this [1], so I recommend that you use vm_read. [1] The traditional UNIX approach for doing this is to install a signal handler to catch any memory access exceptions triggered by the read, but now we’re talking signal handling within a signal handler and that’s just silly. Writing Files If your want to write a crash report from your signal handler, you must use low-level UNIX APIs (open, write, close) because only those low-level APIs are documented to be async signal safe. You must also set up the path in advance because the standard APIs for determining where to write the file (NSFileManager, for example) are not async signal safe. Offline Symbolication Do not attempt to do symbolication from your signal handler. Rather, write enough information to your crash report to support offline symbolication. Specifically: The addresses to symbolicate For each Mach-O image in the process: The image’s path The image’s build UUID [1] The image’s load address You can get most of the Mach-O image information using the APIs in <mach-o/dyld.h> [2]. Be aware, however, that these APIs are not async signal safe. You’ll need to get this information in advance and cache it for your signal handler to record. This is complicated by the fact that the list of Mach-O images can change as you process loads and unloads code. This requires you to share mutable state with your signal handler, which is exactly what I recommend against in Reading Memory. Note You can learn about images loading and unloading using _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image respectively. [1] If you’re unfamiliar with that term, see TN3178 Checking for and resolving build UUID problems and the documents it links to. [2] I believe you’ll need to parse the Mach-O load commands to get the build UUID. What to Include When deciding what to include in a crash report, there’s a three-way balance to be struck: The more information you include, the easier it is to diagnose problems. Some information is hard to obtain, either because there’s no public API to get that information, or because the API is not available to your crash reporter. Some information is so privacy-sensitive that it has no place in a crash report. Apple’s crash reporter strikes its own balance here, and I recommend that you try to include everything that it includes, subject to the limitations described in the second point. Here’s what I’d considered to be a minimal list: Information about the machine exception that triggered the crash For memory access exceptions, the address of the access that triggered the crash Backtraces of all the threads (sometimes the backtrace of a non-crashing thread can yield critical information about the crash) The crashed thread Its thread state A list of Mach-O images, as discussed in the Offline Symbolication section IMPORTANT Make sure you report the thread backtraces in a consistent order. Without that it’s hard to correlate information across crash reports. Revision History 2025-08-25 Added some links to examples of third-party crash reports not preserving the Apple crash report. Added a link to TN3178. Made other minor editorial changes. 2022-05-16 Fixed a broken link. 2021-09-10 Expanded the General Advice section to include pointers to Apple crash report resources, including MetricKit. Split the second half of that section out in to a new Why Is This Impossible? section. Made minor editoral changes. 2021-02-27 Fixed the formatting. Made minor editoral changes. 2019-05-13 Added a reference to my Async Signal Safe Functions vs Dyld Lazy Binding post. 2019-02-15 Expanded the introduction to the Preserve the Apple Crash Report section. 2019-02-14 Clarified the complexities of an out-of-process crash reporter. Added the What to Include section. Enhanced the Signals section to cover reentrancy and stack overflow. Made minor editoral changes. 2019-02-13 Made minor editoral changes. Added a new footnote to the Signals section. 2019-02-12 First posted.

Hi there. We are trying to implement SensorKit into our App to explore the data quality of accelerometer data recorded even when the App is terminated. So far we managed everything to work, even the fetch, except the SRSensorReaderDelegate never seems to reach func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult) -> Bool { ... } Any clue as to what we need to adjust in our code to get the FetchResult? import Foundation import SensorKit import CoreMotion import os.log class SensorKitDataManager: NSObject, SRSensorReaderDelegate { static let shared = SensorKitDataManager() // Sensor Readers let accelerometerReader = SRSensorReader(sensor: .accelerometer) let rotationRateReader = SRSensorReader(sensor: .rotationRate) let deviceUsageReader = SRSensorReader(sensor: .deviceUsageReport) let phoneUsageReader = SRSensorReader(sensor: .phoneUsageReport) let wristUsageReader = SRSensorReader(sensor: .onWristState) var startTime: CFTimeInterval = CFTimeInterval(Date().timeIntervalSince1970) var endTime: CFTimeInterval = CFTimeInterval(Date().timeIntervalSince1970) override init() { super.init() configureSensorReaders() } // Configure sensor readers and set delegate private func configureSensorReaders() { if SRSensorReader(sensor: .accelerometer).authorizationStatus == .authorized { accelerometerReader.delegate = self } ... } func sensorReaderWillStartRecording(_ reader: SRSensorReader) { print("\(reader.description) Delegate starts recording") } func sensorReader(_ reader: SRSensorReader, startRecordingFailedWithError error: Error) { print("\(reader.description) Delegate failed recording") } func sensorReader(_ reader: SRSensorReader, didChange authorizationStatus: SRAuthorizationStatus) { if reader.sensor == .accelerometer { if authorizationStatus == SRAuthorizationStatus.authorized { accelerometerReader.startRecording() } else if authorizationStatus == SRAuthorizationStatus.denied { accelerometerReader.stopRecording() } } ... } // Request SensorKit Authorization func requestAuthorization() { } if UserDefaults.standard.bool(forKey: "JTrack_accelerometerEnabled") && accelerometerReader.authorizationStatus == .notDetermined { SRSensorReader.requestAuthorization(sensors: [.accelerometer]) { error in if let error = error { os_log("Authorization denied: %@", log: OSLog.default, type: .error, error.localizedDescription) } else { os_log("Authorization granted for accelerometer sensor", log: OSLog.default, type: .info) } } } ... self.startRecordingIfAuthorized() } // Start recording for each authorized sensor private func startRecordingIfAuthorized() { if accelerometerReader.authorizationStatus == .authorized { accelerometerReader.startRecording() } ... } func fetchAllDataSinceJoined(from startTime: CFTimeInterval, to endTime: CFTimeInterval) { self.startTime = startTime self.endTime = endTime if accelerometerReader.authorizationStatus == .authorized { accelerometerReader.fetchDevices() } .... } func stopAllRecordings() { if accelerometerReader.authorizationStatus == .authorized { accelerometerReader.stopRecording() } ... } func sensorReader(_ reader: SRSensorReader, didFetch devices: [SRDevice]) { let now = CFTimeInterval(Date().timeIntervalSince1970) // Ensure the data is at least 24 hours old let holdingPeriod: CFTimeInterval = 24 * 60 * 60 // 24 hours in seconds let earliestFetchTime = now - holdingPeriod // Adjust the start time if it's within the holding period let adjustedStartTime = min(startTime, earliestFetchTime) // If adjustedStartTime is after endTime, no data is available for fetching guard adjustedStartTime < endTime else { print("No data available to fetch as it falls within the 24-hour holding period.") return } let fetchRequest = SRFetchRequest() fetchRequest.from = SRAbsoluteTime(adjustedStartTime) fetchRequest.to = SRAbsoluteTime(endTime) // Log information about the devices that contributed data for device in devices { print("Device model: \(device.model), OS version: \(device.systemVersion), Identifier: \(device.description)") if device.model == "iPhone" { fetchRequest.device = device } } if accelerometerReader.authorizationStatus == .authorized { accelerometerReader.fetch(fetchRequest) } ... } // SensorKit Delegate Methods func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) { os_log("Fetch completed for sensor: %@", log: OSLog.default, type: .info, reader.sensor.rawValue) } func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool { if reader.sensor == .accelerometer { .... } .... } func sensorReaderDidStopRecording(_ reader: SRSensorReader) { print("\(reader.description) Delegate stops recording") } func sensorReader(_ reader: SRSensorReader, stopRecordingFailedWithError error: Error) { print("\(reader.description) Delegate failed stopping") }

I currently own an Apple Watch SE2 device. However, when I try to debug from the watch to the actual device, the connection loss issue occurs all too often. Once the connection is lost, it continues to try to connect in the Disconnected list on the Xcode "Devices and Simulators" screen and is in a loading state. Very often, even when the connection is established and you are trying to start debugging, it drops out. Xcode cannot debug properly on the actual device. I later found out that the Apple Watch SE2 does not support 5.0 Hz Wi-Fi, only 2.5 Hz. I think that might be the cause. Is this phenomenon less likely to occur if you debug on an actual device such as a regular Apple Watch 7/8/9 or Ultra model? In fact, if debugging is difficult with the Apple Watch SE model, I am wondering whether I should purchase an additional Apple Watch. Or is there another way to improve this issue? It would be nice if the Apple Watch could be debugged by connecting it to a Mac with an actual cable like the iPhone. I am wondering if there is a way to disable and enable network debugging in Xcode. In the past, debugging the watch using only Bluetooth with the iPhone in Xcode seemed to be more stable. Except for the Watch, the iPad doesn't have any major issues with Wi-Fi debugging on the iPhone.

On my mac I have MacOs15 and Xcode 16 installed. I'm working with cocoapods, when adding a new target to my App pod update it fails. What can I do to solve the problem?

is there anyone who came across an error below and managed to fix it: Lexical or Preprocessor Issue (Xcode): 'Flutter/Flutter.h' file not found

I compiled the project with Xcode16 and ran it in the iOS15 simulator, but even though there should be no problem with the compatible version at the project level, buttons and other components did not respond at all. They worked in the iOS17.5 simulator and on an actual iOS16.7 device. Does this issue occur in environments other than ours? I can't immediately find a device that runs iOS15, will this issue occur on an actual device as well?

I’m encountering an issue since I started using Xcode 16. I have a widget in my app, and I'm trying to organize the code by splitting it into different files for better structure. However, when I do this, I get an error: error: Unexpected input file: /Users/******/Desktop/TestApp/TestAppWidget/Provider.Swift (in target 'TestAppWidgetExtension' from project 'TestApp') I want to emphasize that if I keep all the code in one file, everything works fine. I've checked the Target Membership, and it's set up correctly. but I don't understand why this is happening only in Xcode 16. Has anyone else experienced a similar issue or has any ideas on why this is occurring? I would appreciate any help!

We build a number of iOS apps using different distribution certificates on a "headless" build machine in a data center. It is a burden to have to accept a newly imported certificate because codesign causes a dialog to pop up requesting to authorize the private key We have tried a number of suggestions in various posts, including deleting the certificate and re-importing with security import using the -T flag to allow codesign. After doing this, and even though the ACL shows a very similar picture to the post authorized state, keychain still requires a dialog to be "Allowed". What can be done, from the command line, to avoid this popup?

Hello , am facing issue in submitting my app to store I have submitted my case to apple developer team my case ids "101969263018","101975805043". they told me to submit the report from feedback assistance my case id : FB12141270. but still I don't get any replay form feedback assistance. after that I submitted my case to DTS engineer case id : 2394373. got email to submit some file which I have submitted after that still I don't get any reply from DTS team. please help me to short out this issue. last one month am trying to short out this issue with apple developer team. still I don't get solution.

I have a few questions on build options. Deployment post processing - is this for Mac apps? Or is it a setting for Xcode ? Does "Symbols hidden by default" set to yes enable symbolicated crash dumps? Can "Product name" and "Product module name" be different from bundleID component? Generate_Info_Plist is set to no. Will the Application Category value be reflected if there is no Info_plist file generated? I notice in my tests that the category is always wrong and defaults to team name. Privacy - GameKit Friend List Usage Description should this be yes or no if I am using Apple suggested privacy preserving scoped identifier gamePlayerID? Install Group/Permissions/Owner are these referring to setting in Dev environment or are these Mac App Only settings? ( I was not sure if iOS like Unix, has system users exposed at this high level anyway ) How do I export copy of existing build settings to a xconfig file? There was talk of a tool not sure if it is still available. For my TestFlight build for stress testing , what options would you recommend to help debug and trace easily ? Note I have tested the build with various Address Sanitizer, Memory Sanitizer, Guard malloc etc. options enabled to prep but haven't turned any of those on for the test build. Should I be enabling some? ( Some do not work together ) Alternately, if there is a document or video that addresses all of the above please let me know! Thanks in advance!!

When running a simple C++ OpenGL project in Xcode, multiple instances of the program are created and launched by Xcode when I build and run...I am not sure why it happens, does anyone know how can I stop this?

Hello! 👋 We are seeing a bug on macOS Sequoia related to the test running. When attempting to run tests, the iOS simulator becomes stuck indefinitely. This can occur whether we run tests for a specific module, all unit tests, or even a single test. We narrowed down the issue and is due to the OS failing to copy some named pipes (FIFO). For example: db.realm.note db.realm.management/access_control.new_commit.cv db.realm.management/access_control.pick_writer.cv We saw in the CoreSimulator log file the following error: NSCocoaErrorDomain Code=512 ""access_control.new_commit.cv" couldn't be copied The copy fails and then a new clone of the simulator is created retrying the process. And this goes on and on. What is happening? When running the tests for the iOS app on the simulator, under the hood, the OS tries to clone the simulator device. A list of folders is created, including one Shared/AppGroup. Under the AppGroup folder, the list of multiple UDIDs corresponds to the specific App Group containers created for individual app targets or extensions that are sharing data within that App Group. One of these folders contains the Realm DB files. There are a few files called named pipes which are invisible in Finder (even if you have hidden files to true). You need to list them with ls -l. So, when we select the test target and run the tests, the OS clones the permanent simulator and copies all files from its folders. All files are being copied except those pipes. When the OS attempts to copy the pipes, the operation fails with the error Code=512. Reproduction Steps Run the iOS app on a simulator (e.g. iPhone SE 3rd gen. with iOS 18.1). Quit Xcode and the iOS simulator. Reopen Xcode. Select a test target to run. Select the same simulator you previously ran the iOS app. Run the tests (CMD + U). The simulator is now stuck. Are there any workarounds available? Yes. We found that running the tests works if we first “Erase All Content and Settings” from the simulator. Another workaround is to remove all simulators and reinstall the iOS runtimes. This prevents the issue for a longer period (almost a full day), but eventually, the problem reoccurs. Alternatively, we can delete the named pipes from the App Groups directory before running the tests. Have we tried to give full disk permissions? Yes, we tried to give full disk permissions to a lot of things (Xcode, simulator, file paths, directories, etc.) but with no luck. We still get the same error. Is the issue happening on a specific version of Xcode? No, it happens for multiple Xcode versions: Xcode 15.4 Xcode 16.0 Xcode 16.1 Is the issue happening on a specific macOS Sequoia version? No, it happens on multiple macOS Sequoia versions: 15.0 Beta 8 15.0 RC 15.0 15.1 Stacktrace Oct 29 17:41:18 CoreSimulatorService[14079] <Error>: New device is stuck in creation state, deleting: Clone 712 of iPhone SE (3rd generation) (58D6DED6-2C55-4E7C-BBB4-E0D661DC41A1, iOS 18.1, Creating) Oct 29 17:41:20 CoreSimulatorService[14079] <Error>: Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Device was allocated but was stuck in creation state. Check CoreSimulator.log for more information.} Oct 29 17:41:20 com.apple.dt.Xcode[90147] <Error>: Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Device was allocated but was stuck in creation state. Check CoreSimulator.log for more information.} Oct 29 17:41:30 CoreSimulatorService[14079] <Warning>: Device 6C270BDB-2945-42B5-A985-884F93BFD3E1 encountered in creation state at launch. The device will be re-created. Oct 29 17:41:38 CoreSimulatorService[14079] <Error>: Failed to clone the device data path, error = Error Domain=NSCocoaErrorDomain Code=512 "“access_control.new_commit.cv” couldn’t be copied to “db.realm.management”." UserInfo={NSSourceFilePathErrorKey=[...]/db.realm.management/access_control.new_commit.cv, NSUserStringVariant=( Copy ), NSDestinationFilePath=[...]/db.realm.management/access_control.new_commit.cv, NSUnderlyingError=0x600000ffa490 {Error Domain=NSPOSIXErrorDomain Code=45 "Operation not supported"}} Oct 29 17:41:38 CoreSimulatorService[14079] <Error>: Failed to re-create device that was encountered in the creation state (Clone 713 of iPhone SE (3rd generation) (6C270BDB-2945-42B5-A985-884F93BFD3E1, iOS 18.1, Creating)): Error Domain=NSCocoaErrorDomain Code=512 "“access_control.new_commit.cv” couldn’t be copied to “db.realm.management”." UserInfo={NSSourceFilePathErrorKey=[...]/db.realm.management/access_control.new_commit.cv, NSUserStringVariant=( Copy ), NSDestinationFilePath=[...]/db.realm.management/access_control.new_commit.cv, NSUnderlyingError=0x600000ffa490 {Error Domain=NSPOSIXErrorDomain Code=45 "Operation not supported"}} Oct 29 17:41:40 CoreSimulatorService[14079] <Error>: Error Domain=NSPOSIXErrorDomain Code=22 "Invalid argument" UserInfo={NSLocalizedFailureReason=Device was allocated but was stuck in creation state. Check CoreSimulator.log for more information.} Oct 29 17:41:50 CoreSimulatorService[14079] <Warning>: Device C6DEBFBB-6EFA-4E4C-B51B-9DDA08AF9BDB encountered in creation state at launch. The device will be re-created. Oct 29 17:41:55 CoreSimulatorService[14079] <Error>: Failed to clone the device data path, error = Error Domain=NSCocoaErrorDomain Code=512 "“access_control.new_commit.cv” couldn’t be copied to “db.realm.management”." UserInfo={NSSourceFilePathErrorKey=[...]/db.realm.management/access_control.new_commit.cv, NSUserStringVariant=( Copy ), NSDestinationFilePath=[...]/db.realm.management/access_control.new_commit.cv, NSUnderlyingError=0x600000ffb000 {Error Domain=NSPOSIXErrorDomain Code=45 "Operation not supported"}} Oct 29 17:42:06 CoreSimulatorService[14079] <Warning>: Device 032BAE7E-E345-48F2-86EB-4DF1AD4D5291 encountered in creation state at launch. The device will be re-created.

I may miss something obvious but... Choosing the "New File From Template..." menu item, I just can't find how to create a SpriteKit Scene file (or SceneKit, by the way). They seem to have disappeared from the chooser window (iOS and macOS). Where are those gone ?

In my React Native mobile application, we are experiencing app termination issues on a few devices (iPhone 13 & 14). We are not getting any logs on Xcode organizer after app termination due to memory leak or terminates by OS. Could you please suggest a way to log app terminations or recommend any other platform where we can log such events? Alternatively, do you have any suggestions on how to resolve app termination issues?

Hi, I am using Xcode version 14.2 I am getting these errors when trying to build.

We convert a .onnx file to mpsgraphpackage for iOS deploymentPlatform with command “Mpsgraphtool convert -deploymentPlatform iOS -minimumDeploymentTarget17.0.0 model.onnx -path .” When open output.mpsgraphpackage with Xcode16, there are only “generic” and “ Apple M2(MTLDevice)” options in the “Device” selection list. Cannot find any option for iOS device. How can we view mpsgraph compiled for iOS platform? We use Xcode16 on a MacBook Pro M2 with macOS 15.

Hi, I recently updated my Xcode, and I've been experiencing frequent crashes with the preview. Here’s a screenshot of the preview: https://ibb.co/WnwWMjh

I compile plugins for Adobe Illustrator using CORE and Adobe SDK libraries. Xcode 14 has recently refused to clean any of my Xcode projects, system wide, although they compile and run fine. If I change Project Settings > Advanced > Build Location from Legacy to Default, it cleans fine, but when debugging, many breakpoints cannot be used. The marker has a dotted outline and a popup states that the breakpoint cannot be resolved. I'd like to stay with Legacy for the Build Location, and resolve the cleaning problem. Changing permissions or deleting contents of build folders hasn't helped. Has anyone else seen and solved this issue? macOS Sonoma 14.6.1 Xcode 14.3