As the title says, when a ScrollView is near a UIViewControllerRepresentable, then the ScrollView's content no longer accurately recognizes taps. In particular, taps along the leading edge (10 points-ish) are ignored. Here's a working example: struct ContentView: View { var body: some View { HStack(spacing: 0) { MyRepresentable() // .allowsHitTesting(false) ScrollView { LazyVStack { ForEach(0..<10, id: \.self) { index in HStack(spacing: 0) { Button { print("tapped \(index)") } label: { Color.red } .frame(width: 50) Color.blue } .frame(height: 50) } } } } } } Here's the representable and a placeholder controller: struct MyRepresentable: UIViewControllerRepresentable { func makeUIViewController(context: Context) -> MyViewController { MyViewController() } func updateUIViewController(_ uiViewController: MyViewController, context: Context) {} } final class MyViewController: UIViewController { override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .gray } } When you tap along the leading edge of the red buttons, the taps are ignored for about the first 10 points. But if you prevent hit testing on the representable (by un-commenting the .allowsHitTesting modifier), then the red buttons behave as expected. Also if you just remove the representable entirely, then all the buttons behave as expected. It's as if the hit targets of the buttons are getting "pushed" over by the representable. Or is the representable simply intercepting these touches? I've confirmed this incorrect behavior on iPad via touch and mouse. However, Apple Pencil (1st gen) and Apple Pencil Pro behave correctly - even in the presence of that UIViewControllerRepresentable. Perhaps the Pencil follows a different hit-test codepath? Is this expected behavior? If so, then how do I use UIViewControllerRepresentable and ScrollView side-by-side?

Our app was just rejected by Apple because they say the subscription management sheet never loads. It just spins indefinitely. We're using StoreKit's manageSubscriptionsSheet view modifier to present the sheet, and it's always worked for us when testing in SandBox. Has anyone else had this problem? Given that it's Apple's own code that got us rejected, what's our path forward?

In any SwiftData project with undo enabled, I noticed that repeatedly undoing and redoing a change will cause memory to continuously climb. The larger the change, the more memory is consumed. This is surprising to me. I confirmed this on iOS and macOS using Xcode 15.4 and 16 beta. To reproduce, simply add undo/redo functionality to any project and repeatedly undo/redo a change. Memory consumption will climb continuously and will not get released. In Paul Hudson's SwiftData tutorials, he has an entire section about the numerous tricks required to get SwiftData relationships to work correctly. Does anyone know if SwiftData also requires tricks to get the UndoManager to work correctly?

The StoreKit offerCodeRedemption(isPresented:) view modifier is working fine for redeeming consumable offers from App Store Connect, but it fails to redeem subscription offers: When this same offer code is used in the App Store redemption flow, everything works as expected. So there's nothing wrong with the offer codes. Is there a trick to using offerCodeRedemption(isPresented:) when working with subscriptions rather than consumables? Any help is appreciated!