dsym file

Thanks for the post. I love crash files and you came to the correct place as they are better developers here that can help you with a crash. The interesting issue is that is crashing on swift core lib? However will be a great idea you follow this recommendations to post a crash file with all the information that can help them figure it out. Kindly submit a comprehensive crash report, adhering to the guidelines outlined in Posting a Crash Report. https://developer.apple.com/forums/thread/688669 Have you test it with iOS 26.2? In my modest opinion and without code nor much besides the header, the crash you're encountering, suggests that there might be an attempt to access memory that's either invalid or no longer valid. Ensure that the object or table or table items managing the isn't being deallocated prematurely. Any strong reference cycles or unintentional over-release could lead to accessing a dangling pointer. If the table view is being loaded from a storyboard or XIB, ensure there are no

Thanks for providing such a detailed report. Just to be sure that the testing environment on different devices is exactly the same: Does your app have an complication on the current watch face? In watchOS, you can expect that your app receives four background updates per hour if your app has an active complication, as mentioned here. The device's battery level is another important factor as well, so be sure your device has 80+% battery level when doing your tests. The behavior I described is on an app. It seems though that you are using HKObserverQuery + enableBackgroundDelivery in an App Extension, which has a quite different life cycle. Would you mind to share details about what extension you are working on, how you use HKObserverQuery + enableBackgroundDelivery in your app extension, and if the issue happens in an app on the same device as well. Other than that, given that the issue only occurs on a certain device, I think it's reasonable to start with filing a feedback report with a sysdiagnose f

For comparison, this command on my machine: nvram -p | grep boot-args Returns: boot-args debug=0x104c0c vm_compression_limit=4000000000 The debug entry is not required; that just happens to be how my machine is configured. Once the changes display correctly, the machine should behave according to these, and I run the test Python script aforementioned. Do you do anything different (besides the checks, of course, and the test script/language used)? Have you not been rebooting after you set the value? It looks like I wasn't entirely clear on this, but the boot-args values are quite literally the arguments passed into the kernel when it boots up. Many of them, including this one, are used to set critical constants that are then used to define the system’s wider behavior, often in ways that simply cannot be dynamically modified. At a purely technical level, I'm not sure ANY of them actually apply dynamically; in general, the system relationship to pre-boot state (like firmware variables) is that they're pushed int

So far I've been unable to reproduce the problem you are seeing. Would you be able to make a reproducer project and file a feedback with it attached? If you do please reply back here with the feedback ID so I can make sure it gets to the right team asap.

Here are some debug tips we've seen work best, in order of what to try first: Make sure your macOS, Xcode, and other operating systems you're developing for all are on the exact same version >= 26.0. It's most important that Xcode and Mac have the same exact version number, since these asset issues typically arise from version mismatches. Settings > turn Apple Intelligence off > restart your Mac > turn Apple Intelligence back on to trigger re-download of assets Settings > make sure Siri is turned on and Apple Intelligence is turned on to ensure all assets are downloaded If all else fails, kindly file a feedback report and include all of your OS and Xcode version numbers, so we can debug your issue.

Thanks for your post and interesting on your comment about: Long press on the Safari icon and choose Remove app If you make the system avoid using Universal Links by telling how to handle the link. Since you mentioned universal links, make sure there's no conflict with any custom URL schemes defined in your app's . Universal links should ideally not interfere with opening URLs in a browser unless specifically set up to redirect to an app. 
Since you observed different behavior on iOS 26.0+, double-check whether this is related to a beta version or a specific OS bug. Review Apple's release notes or beta forums for any related issues and consider filing a bug report if necessary. Ensure you're testing on various devices and simulators, as sometimes configuration or environment-specific issues can cause unexpected behavior. But I’m wondering if you are disabling the link itself, you can see that on the swctutils file search for the link itself inside that file. Can you publish the resu

Are there any plans to introduce its system registers to HVF’s EL2 support? We can't talk about The Future™ [1], but if you'd like to see this change I encourage you to file an enhancement request describing your requirements. Please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] See tip 3 in Quinn's Top Ten DevForums Tips.

Thanks for filing FB9972410. I took a quick look at its with the right folks. Beyond that, I’ve no info to share as to if or when something like might land. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi, Sorry to hear you are occasionally having problems with foundation models and previews working. The best next step will be to file a feedback with diagnostics the next time you hit this so we can take a look. Install the logging profile using instructions available here: https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift On your mac running Xcode, and on your physical preview device (if you are using one). Install the logging profile using the following instructions on your mac running Xcode; and if you are using one, your physical preview device (iOS or visionOS): https://developer.apple.com/bug-reporting/profiles-and-logs/?name=swift Then when you reproduce the problem in Xcode: Either (a) an error banner will appear, click the Diagnostics button in that banner; or (b) if you're not seeing an error but you still want to provide diagnostics you can get the same diagnostics window by going under the Editor menu in the menu bar, then selecting the Canvas submenu, then selectin

[quote='875443022, Midnite630, /thread/814338?answerId=875443022#875443022, /profile/Midnite630'] Apps tested and showing this issue are Safari, Chrome, Mail to start. [/quote] Ah, OK, I thought that this might be an issue specific to an app that you’re developing. The Apple Developer Forums are primarily focused on helping developers with the APIs in Apple’s various platform SDKs. With an issue like this, where you’re having problems with system behaviour that affects all apps, your best path forward is to file a bug in Feedback Assistant. And it seems that you’ve done that already (FB21483619), which is great. Thank you! [quote='875443022, Midnite630, /thread/814338?answerId=875443022#875443022, /profile/Midnite630'] After doing some testing, I determined the possible issue. [/quote] Interesting. When you find new factoids like this, please make sure to update your bug. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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.