Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for

Using gen32IOVMSegments() will return kIOReturnMessageTooLarge. If I don't set the maximum value of 8M, the result will still be the same, so I think it may not be related to the maximum value. If you haven't already, take a look at my post here. I haven't checked the code to confirm, but I strongly suspect that calling gen32IOVMSegments with a mask of the wrong size (like 0xFFFFF000) will cause kIOReturnMessageTooLarge, as the true mask range you've specified (0x00000000FFFFF000) is too large to fit in 32 bits. Does Apple M silicon not allocate <=32-bit bus addresses to third-party PCIe devices (FPGA)? Quite the opposite. We've actually gone to considerable trouble to ensure that we COULD provide 32-bit addresses to the PCI bus. Quoting Address Translation on 64-Bit System Architectures: Apple solved the problem with address translation which “maps” blocks of memory into the 32-bit address space of a PCI device. In this scheme, the PCI device still sees a 4-gigabyte space, but that space can be made up of

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 mismatch

Thanks for the post and great customization. This is a complete post, with code and the great screenshot showing the results.I hope other engineers jump in this thread as well to provide their opinion. Based on your description and the provided code, it does seem like this could either be an unintended side effect of recent changes in iOS 26? You said you have a project showing this? Have you tried it in Xcode 26.2 and 26.3 beta? As you've mentioned is no advised against tinting or customizing toolbar items extensively. Double-check to ensure that your use case aligns with their guidance, as deviations might lead to inconsistent behaviors or future compatibility risks. Make sure that your testing device or simulator is running the latest version of iOS 26.2. What version of iOS are you running? I always recommend to use a plain with custom styling that mimics the glass effect. I don’t think yet this is a bug, but let’s invite other engineers and good deeper on what versions

Hi, The problems you are facing is due to the fact that you named your project SwiftUI. This is causing the build system to create a module for your app called SwiftUI which is the exact same module name that the system library is called. I expect you'd see these issues resolved if you rename your app to something that doesn't match one of the system frameworks.

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 itse

Apologies for the delay! Please see our doc main page: https://developer.apple.com/documentation/foundationmodels The Foundation Models framework provides access to Apple’s on-device large language model that powers Apple Intelligence to help you perform intelligent tasks specific to your use case. This article from Apple says something similar: https://machinelearning.apple.com/research/apple-foundation-models-2025-updates The new Foundation Models framework gives access to developers to start creating their own reliable, production-quality generative AI features with the ~3B parameter on-device language model.

Thanks so much for the post, very interesting on those 2 points: In case the alarm fires while the user has unlocked their screen and they do things on the screen, the alarm is dismissed (and stopped), but the stopIntent is not executed. In case the alarm fires while the user has unlocked their screen and they swipe up the Live Activity banner, the alarm is also dismissed (and stopped), but again the stopIntent is not executed. I never seen that issue on AlarmKit. Very interested to see if you can reproduce that in a simple focused sample you can share here? 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.

We are seeing this issue as well. Began with a build on January 28, 2026 and is ongoing. FB21813671

Thanks for that dump. Much nicer! My reading of the stuff in your latest post suggests that you’re authorised to use the entitlement but you’re not actually claiming it. Remember that a provisioning profile acts an allowlist. It tells the system what entitlements you’re allowed to claim, but it doesn’t actually claim them. You actually claim entitlements in your app’s code signature. Note To learn more about how this works, see TN3125 Inside Code Signing: Provisioning Profiles. I usually debug problems like this by first confirming the nature of the problem: Instead of sending my app directly to App Store Connect, I export an archive. For example, when using Xcode’s organiser window I click Distribute App and then follow the Custom > App Store Connect > Export workflow. I then upload that archive using Transporter. Presuming that reproduces the problem, I unpack the archive by hand. See Unpacking Apple Archives. I can then dump the profile and the entitlements in the resulting app. The profile dump comm