LLDB crash

@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

@Engineer I am running into this same Springboard crash when posting a Critical Alert notification in the iOS 26 Simulator. @mnydigital Did you ever get a resolution, or even a workaround, to this issue?

Thanks for the post and the crash file. Looks like you have received no replies. Looking at the crash file it seems like 135 threads at least. I would recommend to go ahead and create a focused sample project that reproduces this issue as I'm not aware of any open bugs on that API. Why not calling it from the main thread? Do you get the same results with just the relevant code in a small test project? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. Albert Pascual
  Worldwide Developer Relations.

Apologies I meant to ask about activity tracing as well (they are related to this topic but if we think another forum post is better I can do it too). At certain point this also became one of the directions we wanted to explore but we've only uncovered more questions. The related documentation stated something but very vaguely. https://developer.apple.com/documentation/os/generating-log-messages-from-your-code?language=objc#Choose-the-Appropriate-Log-Level-for-Each-Message If an activity object exists, the system captures information for the related process chain We had hoped that this would somewhat play into the speculative logging approach we had touched upon, in the sense that if we try to log an error or fault within an activity, then it helps to capture and persist other logs on the activity chain even though they are originally not meant to be. But unfortunately from our test it didn't seem to be behaving towards that understanding. Then our question is, if we may ask - what are the exact additional in

Termination in the background is part of the normal iOS app lifecycle. When the user moves your app to the background, the system typically suspends it. After that, if the system gets low on resources, typically memory, it’ll terminate your app, thus removing it from memory. This is absolutely normal; iOS has behaved this way since we introduced multitasking. This doesn’t generate a crash report because the app hasn’t crashed. The system tends to terminate apps that are using more memory, so one way to reduce the chances of this happening to your app is to reduce your memory footprint as you move into the background. If you’d like to explore that option, check out Making changes to reduce memory use. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

After thinking about this some more, I'm not sure reading a store directly from the asset pack will solve my issue. The database get's updated regularly, so if there's an update that finishes downloading while the app is running, the original linked store will be destroyed and replaced with the new one. Which probably will crash the app.