I've encountered an issue when using TabView inside a Popover on iPadOS, and I wanted to see if anyone else has run into this or if there's a known workaround before I file a bug report. Issue: When placing a TabView inside a Popover on iPadOS, the tab bar is not center-aligned correctly if the popover’s arrow appears on either the leading or trailing edge. It seems that the centering calculation for the TabView includes the width of the arrow itself. If the popover arrow is on the left, the tabs inside the TabView are pushed to the left. If the popover arrow is on the right, the tabs shift toward the right. This suggests that SwiftUI is incorporating the popover arrow’s width into the alignment calculation, which results in the misalignment. Questions: Has anyone else encountered this behavior? Is there a known workaround to ensure proper centering? If this is indeed a bug, should I file a report through Feedback Assistant? Any insights would be greatly appreciated!

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?

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!

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?