LLDB crash

I can confirm there is something crashing my Apps that only have Launchscreen storyboards. I use Autoresizing and not Autolayout. And guys please, make a real effort to build a Launchscreen component in SwiftUI. It makes no sense in 2026, always ten years after and we still have a storyboard file messing/crashing our Apps in Swift.

[quote='875486022, DTS Engineer, /thread/815033?answerId=875486022#875486022'] Hmmm, that’s a minimum failing example, right? That is, you wrote this code specifically to reproduce the crash, right? [/quote] Yes, that's correct! I used the wrong term earlier. The snippet is a minimum failing example, written specifically to reproduce the crash as simply as possible.

[quote='815033021, AndriiSulimenko, /thread/815033, /profile/AndriiSulimenko'] Minimum Working Example [/quote] Hmmm, that’s a minimum failing example, right? That is, you wrote this code specifically to reproduce the crash, right? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Kevin, Thank you for the guidance. Based on your suggestions, we have implemented architectural modifications. Below is the status of implementation and the current issue. We store and retain IOMemoryDescriptor and IOMemoryMap objects in ivars. The ISR accesses the shared buffer address, which resolved the issue where GetAddress() returned NULL. The ISR differentiates between command sources. In Bundled mode, the DEXT calls BundledParallelTaskCompletion without calling release(). In Legacy mode, it calls ParallelTaskCompletion followed by release(). These changes eliminated the 0x92000006 Kernel Panic and DEXT Corpse crashes. The kernel dispatches Bundled commands immediately after UserInitializeTargetForID returns, but before UserCreateTargetForID completes. We found that reporting command completion while UserCreateTargetForID is still executing causes the UserCreateTargetForID call to hang. Based on this behavior, we infer a re-entrancy deadlock. The registration thread waits for the SAM target

@zhaotaotao have you looked at any of the AnalyticsReports available via the App Store Connect API? One of the crash reports analytics might be a good way to determine differences in Xcode Organizer vs MetricKit vs App Store Connect Metrics data. https://developer.apple.com/documentation/analytics-reports/app-crashes @Technology Evangelist could you comment on if the same under-reporting and fixed issue in 26 would also muddy the App Store Connect crashes analytics reports with over reporting?

@naftaly I submitted a somewhat relevant feedback a few years ago. FB9616844 - MetricKit: MXDiagnostic, MXDiagnosticPayload and MXMetricPayload should have 'identifier' properties I mostly wanted a unique identifier built-in because IPS files have them and then I wouldn't need to decorate the MetricKit payloads myself and it would be just built in. If you want to correlate runtime data you captured against a payload, your best bet is to do this with diagnostics since those are truly the PID at time of diagnostic--well at least I assume. I've never bothered to check. This could easily be tested by crashing and check the PID in the IPS crash file against that identified in the MXDiagnosticPayload metadata. The metadata is required in the diagnostic payload but it isn't in the metrics payload. While I have not in practice seen the metrics metadata object to be empty in a metric payload, you're right that you can't do much for variation over time. The API just simply doesn't have a way to repres

Hi Michael, Thank you for the previous suggestion about using AnchorEntity(.head) with trackingMode = .once for positioning entities relative to the user's gaze — that approach worked great for our immersive menu positioning. Now I'm running into a different issue with 360° video playback. When rendering an equirectangular video on a sphere using VideoMaterial and MeshResource.generateSphere(), there is a visible black seam line running vertically on the sphere. This appears to be at the UV seam where the texture coordinates wrap from 1.0 back to 0.0. The same video file plays without any visible seam in other 360° video players on Vision Pro, so the issue is not with the video content itself. Here is the relevant code: private func createVideoSphere(content: RealityViewContent, player: AVPlayer) { let sphere = MeshResource.generateSphere(radius: 1000) let material = VideoMaterial(avPlayer: player) let entity = ModelEntity(mesh: sphere, materials: [material]) entity.scale *= .init(x: -1, y: 1, z: 1) // Flip t

There are a few different issues that are at play here, so I'll try to untangle it a bit. Firstly to highlight what I send back to all reports of this symptom. This is what you probably saw in email already, but sharing here for everyone else's benefit: This symptom (Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding) occurs when launchd_sim (the principal process that kicks off the simulator) doesn't respond to an initial checkin message within a set time window. It is known to be caused by a variety of issues. Incorrect permissions on system temporary directories: Some users inadvertently change the permissions on system temporary directories, which can lead to this issue as well as problems in other software. If this is the issue, it can be fixed by running sudo chmod 1777 /private/var/tmp /private/tmp. 3rd Party Security Software: Some 3rd party security software can cause significant performance delays loading processes from the simulator runt

I believe you filed a bug asking about this earlier, and I have my own bug on this (r.169737319). It fell off my radar for a bit, but I've asked the team for some guidance on the right way to handle this today. Following up on myself after talking with the team, here is how I would suggest handling this: In the first call to UserProcessBundledParallelTasks, you should: Store the OSAction you receive into your DEXTs own ivars. Intentionally retain() that OSAction. This retain will NOT be balanced, so you're intentionally over-retaining the OSAction (it will be destroyed when your DEXT is). You can actually retain it a few times if you want. On all future calls to UserProcessBundledParallelTasks, assert that the OSAction you receive is the same as the action you received in #1, intentionally crashing if it changes. Note that the point of #3 is NOT to detect a valid state you should anticipate or handle. It's purely there as an overall safety check that will either never trigger or will trigger years fr

I've asked Gemini. It says the following. To answer your question directly: Yes, you absolutely need the Privacy keys in your Info.plist. Even though you are only using the user’s location to show a blue dot on the map, Apple considers the act of calling requestWhenInUseAuthorization() a request for private data. If that key is missing, your app will not only be rejected, it will likely crash the moment it executes that line of code on a real device.

Part 1... However, a subsequent call to ivars->fResponseMap->GetAddress() returns NULL (0x0). Subsequent call when? The expectation (and what our driver does) is that you'd immediately call GetAddress() and then basically never look at the map again. In one of our drivers, that never is quite literal. The code is basically: IOMemoryMap *memoryMap = NULL; if ( parallelCommandIOMemoryDescriptor->CreateMapping(0, 0, 0, 0, 0, &memoryMap) == kIOReturnSuccess ) { ivars->fCommandAddress = memoryMap->GetAddress(); } ... if ( parallelResponseIOMemoryDescriptor->CreateMapping(0, 0, 0, 0, 0, &memoryMap) == kIOReturnSuccess ) { ivars->fParallelResponseAddress = memoryMap->GetAddress(); } ...and, yes, that code leaks two IOMemoryMap's. I don't know what the exact thinking was, but I suspect they realized that the only reason that mapping would ever become invalid/useless was because the driver was being torn down, so freeing doesn't really matter. I'll admit, there is a certain charm to tha