build disappears

@bryan1anderson I don't think you can. If your dataset is large enough (like my example), you'll always get hangs. It looks to me like Query/Predicate is the issue here, they seem to run everything on the Swift side rather than being transformed into SQL queries that run directly on the underlying SQL database. On the example that I posted and that @DTS Engineer confirmed, the SQL part runs really fast, but the overall fetch is slow. I'd love for Apple to give this more attention, because if having a big dataset is a deal breaker, nobody -unless you're 100% sure your data will always be very small- should use Swift Data. Imagine if you build a very complex app using Swift Data and your dataset keeps growing, you'll hit a point where you need to re-write the model layer using Core Data, kinda insane if you ask me.

Update / Resolution In my case, the flashing preview was not a capture pipeline issue, but a SwiftUI view lifecycle issue. The camera preview was conditionally shown using: authorized && session.isRunning && cameraReady During lock/unlock or camera switches, SwiftUI re-evaluates this condition multiple times. AVCaptureSession.isRunning can briefly fluctuate during interruption recovery, causing SwiftUI to: remove the preview view show a placeholder immediately reinsert the preview This rapid view swapping appeared as a “blank flash”. The preview layer itself was fine. Fix I removed session.isRunning from the SwiftUI visibility condition. The logic is now: authorized && cameraReady cameraReady is set once after initial setup and never toggles during interruptions. The preview view stays mounted at all times. Why this works AVCaptureVideoPreviewLayer already handles short “no frames” periods gracefully. By keeping the preview layer mounted and avoiding view teardown, the flashing disappears

Thanks for the post. Based on your description, you are encountering an issue with loading the library and deploying it into macOS versions 15? I believe there was a bug on previous versions of Xcode, but that should have been fixed. Are you using Xcode 26.2 to build the app? The error message indicates that the library cannot be found at runtime, despite being included in your build setup. If you are getting this error on macOS Sonoma with the app build in Xcode 26.2, it means the bug is on that version of macOS. If you are not getting the error in macOS Tahoe, the bug has been fixed. The good news is that the bug has been fixed, but the bad news is that the bug is also in macOS 15? And it was not just Xcode as I initially thought. Can you confirm that when you deploy the app built in Xcode 26.2 to macOS 15, you still encounter this bug? Albert Pascual
  Worldwide Developer Relations.

Mistake on my part here. I was catching the error and not printing it. The sporadic working in the simulator was a red herring. The error was that my AASA file was missing the appropriate values, but it wasn’t. What eventually solved it was cleaning my build folder AND deleting the copy installed by TestFlight from macOS. Worked great on the next build.

So basically, could I build the Photos app (or something like it) in SwiftData. Seems to be no. Because Query cannot handle anything remotely close to the thousands of displayed objects. I tested a manual fetch on context. Performed in milliseconds as expected. But anything in Query, completely fails with like 10 seconds when it gets bad

Due to the very low latency of our hardware for specific commands (e.g., TEST UNIT READY). Logs reveal a severe timing conflict: The interrupt handler (Completion path) is triggered and successfully invokes BundledParallelTaskCompletion, which returns normally. Crucially, at this exact microsecond, the original UserProcessBundledParallelTasks call (Submission path) has not yet finished its loop or returned to the system. Immediately after both paths eventually return, the DEXT process crashes (Corpse), subsequently triggering a Kernel Panic. Something doesn't sounds right here. There are actually a few different things that concern me: (1) There's a reasonably long cycle to get to your interrupt handler from the kernel. I'm skeptical that there's any way for an interrupted to fire before UserProcessBundledParallelTasks finishes running unless UserProcessBundledParallelTasks is doing something that substantially delays its own process. (2) From the kernel side, how bundled commands actually work is that Proces

Thanks for the very interesting post. Experiencing discrepancies between crash reports from App Store Connect and other tools like Xcode Organizer or Firebase Crashlytics can be frustrating. If using Firebase Crashlytics alongside Apple’s built-in crash reporting, ensure there are no conflicts. Consider disabling one to see if crash reporting aligns with the other tool. Ensure that the correct dSYM files were uploaded for each build version. Mismatched or missing dSYMs can prevent proper symbolication. Check the build logs or archives in Xcode to confirm that dSYMs were generated successfully and uploaded. Use on the dSYM file to ensure it includes UUIDs matching those in the crash logs. Confirm that no third-party libraries are missing their dSYMs or are causing symbolication issues. During your testing, have you been able to reproduce the crash? Is the crash reported as terminated by the user? I would personally disable the third-party crash library to observe the results. However, this is

The easy ones: You can delete DerivedData at any time. It grows back as you load and build projects. In iOS DeviceSupport you can delete any OS versions that don't correspond to devices you actually use for debugging. That could be old versions (after you install OS updates on your devices) or devices you just don't use any more.