macOS 15 introduces SwiftUI.WindowLevel for macOS which allows setting the level of windows. Is there an equivalent new API for UIKit.UIWindowScene on Mac Catalyst? I haven't been able to find it.

Hi, when setting up our Core Data stack in our iOS app (manually, with a NSManagedObjectModel/Context & NSPersistentStoreCoordinator) we have reports a rare bug we haven't been able to reproduce. Occasionally when adding a persistent store we get a NSCocoaErrorDomain 256 error (NSFileReadUnknownError) with NSSQLiteErrorDomain=4618 in the user info. That's SQLITE_IOERR_SHMOPEN , which the SQLite docs describe this way: I/O error within the xShmMap method on the sqlite3_io_methods object while trying to open a new shared memory segment It seems to specifically /not/ be a SQLITE_FULL error. Do you know what type of issue can cause this? Or where/how I can start tracking this down?

Hi, I’m investigating switching from the /verifyReceipt endpoint to the App Store Server API. I’ve noticed that some transaction IDs we have in our system return 4040001 (AccountNotFound) from the “Get All Subscription Statuses” endpoint. These transaction IDs are associated with receipts that used to verify OK with the /verifyReceipt endpoint, but now return 21010 (receipt unauthorized). Under what circumstances do transactions which used to be valid start returning “account not found”?

I'm attempting to gracefully handle "media services reset" in my audio recording implementation. When AVAudioSession.mediaServicesWereResetNotification is posted, QA1749 (referred to by the docs, even though it's "archived") says that we should dispose of any "orphaned audio objects" and recreate them. Should an instance of AVAudioRecorder be disposed of & recreated? Or is there something else we should do with them? If we should dispose of & recreate the AVAudioRecorder, is it possible to resume recording to the same file? Currently if we just pause on "media services reset" and just resume when the user asks us to, we get a corrupted audio file. (One where ExtAudioFileOpenURL returns kAudioFileInvalidFileError (OSStatus 1685348671))

Hello! I am trying to use the new Xcode 13 Cloud Signing feature (authenticationKeyPath & friends) to archive (and eventually upload) my iOS app via a CI service (GitHub actions in this case). My xcodebuild invocation is as such: xcrun xcodebuild archive \ -workspace '/path/to/MyApp.xcworkspace' \ -scheme 'MyApp - App Store' \ -archivePath '/path/to/output.xcarchive' \ -allowProvisioningUpdates \ -authenticationKeyID 'KEY_ID_HERE' \ -authenticationKeyIssuerID 'ISSUER_ID_HERE' \ -authenticationKeyPath '/complete/path/to/key.p8' \ -destination 'generic/platform=iOS,name=Any iOS Device' The first run on CI with this invocation succeeds! The second run (i.e. on a clean machine) outputs this error: error: Revoke certificate: Your account already has an Apple Development signing certificate for this machine, but its private key is not installed in your keychain. Xcode can create a new one after revoking your existing certificate. (in target 'MyApp' from project 'MyApp') The "Certificates, Identifiers, & Profiles" page does, indeed, list a certificate created by the API key in question. If I revoke this certificate, the next build succeeds and the one after that fails. I thought the idea with Cloud Signing was to keep from manually installing certificates & provisioning profiles. Am I misunderstanding something? Is there a modification I can make to this command to make it succeed? Do I need to manually create & install development certificate? Xcode version: 13.2 beta 2 macOS version: 11 (macOS 12 is not yet supported on GitHub actions) API key: has admin role (As a sidenote: I have tried Xcode Cloud, but it suffers random failures & long build times, plus it won't work for all my apps. So that's not currently a viable alternative for me.)

We have a Mac Catalyst app which uses the keychain to store secrets. We’ve received a report from a user that the app ran fine for a number of days, but has recently started failing to store OR retrieve that secret and displays an in-app alert to that effect. Top line is that both SecItemAdd and SecItemCopyMatching return errSecInteractionNotAllowed, though they have been working just fine previously. I know that on iOS this issue can be the result of the device being locked while the app operates in the background. But the user is actively using the app when this happens (ergo the device should be unlocked). Is there something more about keychains on macOS that I’m missing? Is this something particular to Catalyst? We haven’t been able to reproduce it. Any help would be appreciated! From an actual solution to suggestions for reproducing the bug to suggestions on differences between macOS and iOS in this respect. The secret in question is stored with the following dictionary: let insertQuery: [String:Any] = [ kSecClass as String: kSecClassGenericPassword, kSecValueData as String: Data(secret.utf8), // `secret` being a String with the secret’s value kSecAttrService as String: serviceTag, // `serviceTag` being a String with the name of the secret kSecAttrAccessible as String: kSecAttrAccessibleWhenUnlockedThisDeviceOnly ] let insertQueryCFValue = query as CFDictionary let status = SecItemAdd(insertQueryCFValue, nil) Looking up the secret goes like this: let findQuery: [String: Any] = [ kSecClass as String: kSecClassGenericPassword, kSecAttrService as String: serviceTag, // As above kSecMatchLimit as String: kSecMatchLimitOne, kSecReturnAttributes as String: true, kSecReturnData as String: true ] let findQueryCFValue = findQuery as CFDictionary var item: CFTypeRef? let status = SecItemCopyMatching(findQueryCFValue, &item) In both code snippets status == errSecInteractionNotAllowed.

We recently started receiving CONSUMPTION_REQUEST notifications on our server, but our app only supports a single auto-renewable subscription group. The documentation here and here seem to indicate that this only happens for consumable IAPs. Is it intended for us to receive & respond to these notifications for subscriptions as well?