I'm seeing the same failure on macOS. A clean build of my app rejects subscription purchases made using the StoreKit debugging features of Xcode. As far as I can tell, everything is up to date. It is not at all clear whether this is my problem or Apple's to resolve.

This appears to have finally been addressed in 15.1 beta 4. Is there any chance this particular fix will be back-ported to a 15.0.x release? Of course the urgency depends entirely on the timeframe for 15.1. Just a thought.

Sadly, Sequoia shipped with this bug. It's a lousy place to be in that prevents shipping an application that has been in beta for months – not to mention all the other SwiftUI applications that may be affected, and I can't help but feel it could have been avoided. Please escalate the specific example to see what could have been handled differently. I've never received any acknowledgement that this bug actually exists through normal channels, only a series of replies that claim that it doesn't reproduce (it does) and that my code is incorrect (it isn't.) So I eventually had to sidestep this whole process to make sure people took it seriously and that something was being done about it. I understand that the bug has finally been fixed and look forward to a 15.1 beta where I can confirm it. In the meantime, I'll have to sit on a finished app that works fine on Sonoma to avoid customers being burned by Sequoia.

I'm glad to hear it's reproducing for you, and understand your theory about duplicate IDs. The actual app where this was originally detected uses UUIDs extensively, but it certainly doesn't hurt to use the same strategy in the reduced test case as well. In the code below, not only are Item instances created with UUIDs rather than relying on string uniqueness, but every time the filter is invoked it generates new UUIDs for each item to ensure that there's not even overlap between the prior and new data sets. I still get the same crash. Table data is inherently ordered, so a Set is neither appropriate nor well-suited to SwiftUI's binding in this instance. import SwiftUI struct Item: Identifiable, Hashable { let id = UUID() let name: String init(_ name: String) { self.name = name } } struct ContentView: View { let allItems = [ Item("One"), Item("Two"), Item("Three"), Item("Four"), Item("Five"), Item("Six"), Item("Seven"), Item("Eight"), Item("Nine"), Item("Ten") ] @State var filteredItems = [Item]() @State var text: String = "" func filter() { let subset = if text == "" { allItems } else { allItems.filter { $0.name.localizedCaseInsensitiveContains(text) } } // To guarantee that there are no duplicate IDs, generate new // Item instances for the filtered set filteredItems = subset.map { item in Item(item.name) } } var body: some View { VStack { TextField("Search:", text: $text) .padding() .onChange(of: text) { filter() } .onAppear { filter() } Table($filteredItems) { TableColumn("Name") { item in Text(item.wrappedValue.name) } } } } }

I'm using macOS 15.0 (24A5320a) installed this week to make sure it still reproduced. It results in the same crash under exactly the same circumstances. I've tried a clean build using two Xcode betas, this week's Xcode 16.1 beta (16B5001e) and Xcode Version 16.0 beta 4 (16A5211f) where I originally built the reproduction case for submission. It crashes identically on both, as does the TestFlight installed app where I first discovered the problem, built using Xcode 15.4. The actual app uses the searchable modifier, which I eliminated from the repro case to try to narrow the possible sources of problems. Did you try building the project attached to the bug report referenced above? Or something new built around the code fragment in my first message? In case it matters for reasons that aren't immediately obvious, I'm running on a base M3 Max MacBook Pro 14".