SwiftUI List performance

Good news—we have successfully addressed the final App Store requirements thanks to detailed feedback from the review team. This process, though intensive, proved to be a blessing in disguise. The iOS app is now more polished and robust than our current Android version. We’ve already identified a list of improvements derived from this review that we plan to implement on Android over the next few weeks to ensure parity and quality across both platforms. Thanks again for the help.

Well, that’s not good. I suggest you retry this on the current 26.3 beta, just in case. Assuming the problem shows up there as well, you should file a bug about it. Make sure to include a sysdiagnose log taken shortly after reproducing the problem, ideally as soon as you see the fuzzy screen you showed in your screenshot. Once you’re done, please post your bug number and I’ll take another look. At the API level, one option you have is to create an LAContext and pass it in to each SecItemCopyMatching call via kSecUseAuthenticationContext. It’s not clear whether you’re doing that or not. Please confirm either way. It’s also not clear if it’s even the right thing to do. This technique makes sense when the user performs a single high-level operation that requires multiple cryptographic operations with the same key. However, if the user performs two separate high-level operations back-to-back and that reproduces this issue, then trying to work around this using kSecUseAuthenticationContext isn’t

Entitlements and code-signing requirements are very different. See the following for more background on each: TN3125 Inside Code Signing: Provisioning Profiles TN3127 Inside Code Signing: Requirements You can use a code-signing requirement to check for an entitlement, for example: % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /Applications/Pages.app … /Applications/Pages.app: explicit requirement satisfied % codesign --verify -R '=entitlement [com.apple.security.app-sandbox] exists' -v /usr/bin/true … test-requirement: code failed to satisfy specified code requirement(s) However, entitlements are tricky to use in this situation because: You can’t create a provisioning profile that authorises a custom requirement. Many of of the popular entitlements are either unrestricted on macOS, or only restricted in that they clear the entitlement-validate flag [1]. Given that, I think maintaining your previous approach makes sense, that is, check for the Team ID and a list of c

CloudKit share acceptance still requires a UIWindowSceneDelegate on iOS. Can try this approach ---- Keep SwiftUI lifecycle @main struct MyApp: App { var body: some Scene { WindowGroup { ContentView() } } } Add SceneDelegate import UIKit import CloudKit class SceneDelegate: UIResponder, UIWindowSceneDelegate { func windowScene( _ windowScene: UIWindowScene, userDidAcceptCloudKitShareWith metadata: CKShare.Metadata ) { acceptShare(with: metadata) } } Register it in Info.plist UISceneDelegateClassName = SceneDelegate

Thoughtful review responses boost ratings trust and sentiment driving higher rankings and stronger ASO performance

@DTS Engineer I am expecting the part on the left, in SwiftUI to animate exactly like the counterpart in UIKit on the right. But they do not; UIKit animation affects both UIView.center and UIView.bounds, and they travel using the same timing curve over the same duration, which makes it seem that the top of the UIKit view is attached to the top of the screen. However, this illusion is not preserved for SwiftUI view because UIHostingController.view.center is not animated; it's teleported to the end position. And I also happen to know that really bounds are not animated either, the UIView actually just fully teleports to the new state, while only the SwiftUI content is animated. And my question is - what is the way to make UIHostingController animate along its SwiftUI content? Can you maybe confirm that there isn't a built-in support for that?