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

Hi all, I’m running into a “double update” effect in SwiftUI when using the @Observable with @State. I’m trying to understand whether this is expected behavior, a misuse on my side, or a potential bug. Setup I have an observable store using the Observation macro: @Observable class AlbumStore { var albums: [Album] = [ Album(id: 1, title: Album 1, author: user1), Album(id: 2, title: Album 2, author: user1), Album(id: 3, title: Album 3, author: user1), Album(id: 4, title: Album 4, author: user1), Album(id: 5, title: Album 5, author: user1), Album(id: 6, title: Album 6, author: user1) ] func addAlbum(_ album: Album) { albums.insert(album, at: 0) } func removeAlbum(_ album: Album) { albums.removeAll(where: { $0 == album }) } } In my view, I inject it via @Environment and also keep some local state: @Environment(AlbumStore.self) var albumStore @State private var albumToAdd: Album? I derive a computed array that depends on both the environment store and local state: private var filteredAlbums: [Album] { let albums =

I am using the native SwiftUI WebView and WebPage APIs (iOS 26+) and would like to implement file download functionality using the native SwiftUI WebView. However, I have not been able to find any APIs equivalent to WKDownload. In WKWebView, the WKDownload API can be used to handle downloads. I am looking for a similar API or recommended approach in the native SwiftUI WebView that would allow downloading files. If anyone has guidance or suggestions on how to implement this, I would appreciate your help.

Hello Apple Developer Support Team, We are developing an iOS iPhone application and would like clarification on whether Apple provides any APIs or system-level support to implement parental approval workflows aligned with certain regional regulatory requirements (for example, Texas, Utah, and Louisiana). Our intended use cases are outlined below: Initial Approval (App Download Stage) We understand that, in some situations, when a minor attempts to download an app from the App Store on iPhone, iOS may require approval through Family Sharing / Ask to Buy. We would like to confirm: • Whether there is any developer-accessible API that allows an iPhone app to detect if installation was approved via parental consent. • Whether apps can receive any callback, status indicator, or system signal confirming parental approval or rejection. • Whether the Declared Age Range API or any related framework provides access to parental approval or age verification signals. Ongoing Approval for Signific

I’ve honestly never received service this bad from a company and I don’t say that lightly. This is the worst support experience I’ve ever had. I’m trying to enroll in the Apple Developer Program, but I’m stuck in a loop that has been going on for months: The Apple Developer app repeatedly fails during identity verification and tells me there’s an issue. When I contact support, they tell me they’ll email me instructions. The email says: “Please use the Apple Developer app to enroll.” I reply saying: “I did. It doesn’t work. The verification fails.” And the response is again: “Use the Apple Developer app.” Over and over, with no actual troubleshooting or escalation. This is not a user-error situation — I’m following the instructions exactly. I need someone to look at what’s happening on Apple’s side (verification/enrollment status) and give a real resolution path, not the same copy-paste response. Details: Country/Region: [your region] Devices tried: [iPhone model + iOS version], [Mac model + macOS ver

Hi, our Xcode Cloud runs produce dsyms for test targets that massively increase the artifacts size, more specifically the Test Products for zip, that slows down the build due to the upload artifacts phase. These dsyms are useless, so we would like to stop producing them on Xcode Cloud builds. Consider that the workflow uses the autogenerated scheme for a package that's part of the Xcode project. How can we tell Xcode Cloud to not produce dsyms?

I am building an app for iOS and MacCatalyst that indexes files by storing their local paths. Because the app relies on the file remaining at its original location, I only want to accept items that can be opened in place. I am struggling to determine if an item is Open In Place compatible early in the drag-and-drop lifecycle. Specifically: In dropInteraction(_:canHandle:) and dropInteraction(_:sessionDidUpdate:), calling itemProvider.registeredTypeIdentifiers(fileOptions: [.openInPlace]) returns an empty array. Only once the drop is actually committed in dropInteraction(_:performDrop:) does that same call return the expected type identifiers. This creates a poor user experience. I want to validate the In Place capability at the very start of the session so the drop target only activates for valid files. If an item is ephemeral (like a dragged photo from the Photos app or a temporary export), the drop zone should not react at all. How can I reliably detect if an NSItemProvider supports .openI