SwiftUI List performance

Environment iOS 18.1+ StoreKit External Purchase Link Entitlement (EU) App distributed via App Store in France Problem Summary I'm implementing external purchase links for EU users using ExternalPurchaseCustomLink. While the implementation works correctly in my TestFlight testing, some production users experience token(for:) returning nil. Implementation Following Apple's documentation, my flow is: Check eligibility using ExternalPurchaseCustomLink.isEligible If eligible, call ExternalPurchaseCustomLink.token(for: ACQUISITION) Store the token for use in the external purchase flow // Simplified implementation guard #available(iOS 18.1, *) else { return } let isEligible = await ExternalPurchaseCustomLink.isEligible guard isEligible else { return } // This returns nil for some users despite isEligible being true let token = try await ExternalPurchaseCustomLink.token(for: ACQUISITION) Configuration Entitlement: com.apple.developer.storekit.external-purchase-link is present Info.plist: SKExternalPurchaseCustomLink

I’m running Xcode 26.1.1 (17B100) with deployment target iOS 18.0+, and I’m seeing a consistent and reproducible issue on real devices (iPhone 13 Pro, iPhone 15 Pro): Problem The first time the user taps into a TextField or a SwiftUI .searchable field after app launch, the app freezes for 30–45 seconds before the keyboard appears. During the freeze, the device console floods with: XPC connection interrupted Reporter disconnected. { function=sendMessage, reporterID=XXXXXXXXXXXX } -[RTIInputSystemClient remoteTextInputSessionWithID:performInputOperation:] perform input operation requires a valid sessionID. inputModality = Keyboard customInfoType = UIEmojiSearchOperations After the keyboard finally appears once, the issue never happens again until the app is force-quit. This occurs on device Reproduction Steps Minimal reproducible setup: Create a new SwiftUI app. Add a single TextField or .searchable modifier. Install Firebase (Firestore or Analytics is enough). Build and run on device

Hardware Specifications Regarding the LiDAR scanner in the iPhone 13/14/15/16/17 Pro series, could you please provide the following technical details for academic verification: Point Cloud Density / Resolution: The effective resolution of the depth map. Sampling Frequency: The sensor's refresh rate. Accuracy Metrics: Official tolerance levels regarding depth accuracy relative to distance (specifically within 0.5m – 2m range). Data Acquisition Methodology For a scientific thesis requiring high data integrity: Does Apple recommend a custom ARKit implementation over third-party applications (e.g., Polycam) to access raw depth data? I need to confirm if third-party apps typically apply smoothing or post-processing that would obscure the sensor's native performance, which must be avoided for my error analysis.

With iOS 26 the CPListSection header has a transparent background, and when the list scrolls under the header it doesn't look good at all. We expected to see a glass fading effect maybe, like the one on the top of the screen. Is it a known bug?

I have been playing around with the new AsyncImage Api in SwiftUI I am using the initialiser that passes in a closure with the AsyncImagePhase, to view why an image may not load, when I looked at the error that is passed in if the phase is failure, the localised description of the error is Cancelled but this is happening before the view is being displayed. I am loading these images in a list, I imagine I am probably doing something which is causing the system to decide to cancel the loading, but I cannot see what. Are there any tips to investigate this further?

Hi, I'm running into a weird notarization issue and wanted to see if anyone else has seen something similar. I have one main macOS app that keeps doing the following: The notarization sits in In Progress for a few days Then it flips to Rejected with error code 7000 The notarytool log shows no issues and no ticket info At the same time, smaller test apps on the same Apple Developer account notarize. They do take around 2-3 days though. So it doesn't seem like an account or certificate problem. It looks like something about this specific app causes it to go into a long review and then fail with that vague 7000 error. The app is fairly large (Python + Qt, lots of bundled libraries), so I'm wondering if that triggers deeper scanning or some kind of policy check. Has anyone else seen: Multi day notarization jobs? Error 7000 that only affects one particular app? Rejections with no issues listed? If so, did you find a way around it? Also for context, my Apple Developer account was created recently I have co

Issue When an Entity with a ViewAttachmentComponent is: disabled using isEnabled = false removed using removeFromParent() and then enabled or added back again, the attached SwiftUI view is rendered correctly, but tap interactions stop working. Specifically: Button actions inside the attached view do not fire TapGesture closures on child views do not respond Expected Behavior Tap interactions inside the attached view should continue to work after the Entity is re-enabled or re-added. Actual Behavior After being disabled or removed once, all tap interactions stop responding. Comparison When displaying the same SwiftUI view using RealityViewAttachments, this issue does not occur. Removing and re-displaying the attachment still allows taps to work correctly. Reproduction Attached sample code reproduces the issue: A RealityView with an Entity that has a ViewAttachmentComponent The attached SwiftUI view contains a Toggle The toggle updates isEnabled on the Entity After toggling off and on

Hi everyone, In the simple app below, I have a QueryView that has LazyVStack containing 100k TextField's that edit the item's content. The items are fetched with a @Query. On launch, the app will generate 100k items. Once created, when I press any of the TextField's , a severe hang happens, and every time I type a single character, it will cause another hang over and over again. I looked at it in Instruments and it shows that the main thread is busy during the duration of the hang (2.31 seconds) updating QueryView. From the cause and effect graph, the update is caused by @Observable QueryController .(Bool). Why does it take too long to recalculate the view, given that it's in a LazyVStack? (In other words, why is the hang duration directly proportional to the number of items?) How to fix the performance of this app? I thought adding LazyVStack was all I need to handle the large dataset, but maybe I need to add a custom pagination with .fetchLimit on top of that? (I understand that ModelActor would be