Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

i recently upgraded to sequoia, and now, more often than not, when running in the debugger, opening my database causes a hang: When i run outside the debugger, it opens just fine. I suspect it has to do with "full disk access"? but i've given my app full disk access. i've also set Qt and Xcode to have "Allow apps to use developer tools" permissions. as a test i also added my app into that permission group, all to no avail. the path to the DB being opened is in my user's Music folder, and having full disk access gives permission for everything, including things in that folder. confused!

Hello, I would like to draw your attention to the following imperfection. For validating purchases of my paid application Guru Maps Pro, I use the download id. This is a unique ID that can replace the Transaction ID for paid applications. However, with the release of the new AppTransaction API, this field is no longer present in the data. I tried parsing the receipt, but that field is absent there as well. The only way to obtain the download id is to send the receipt to the deprecated /verifyReceipt endpoint. This deprecated status concerns me, because at some point it might stop working. Let me explain a little about why I need this. My users have a guru-account, which they can use both in the web version and on Android. When a user purchases the paid version of the application, they can access the paid features on both web and Android. This works great for in-app purchases, where there is a transaction ID, but it may soon stop working for paid applications because there is no way to determine any ID associated with the purchase. Transaction ID or Download ID – I don't mind which.

When I install my application, it installs fine and everything works alongwith all the system level daemons but when I reboot the system, none of my daemons are getting launched and this happens only on MacOS 15x, on older version it is working fine. In the system logs, I see that my daemons have been detected as legacy daemons by backgroundtaskmanagementd with Disposition [enabled, allowed, visible, notified] 2025-01-13 21:17:04.919128+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Type: legacy daemon (0x10010) 2025-01-13 21:17:04.919128+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Flags: [ legacy ] (0x1) 2025-01-13 21:17:04.919129+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Disposition: [enabled, allowed, visible, notified] (0xb) But later, it backgroundtaskmanagementd decides to disallow it. 2025-01-13 21:17:05.013202+0530 0x32d Default 0x4d6 89 0 smd: (BackgroundTaskManagement) [com.apple.backgroundtaskmanagement:main] getEffectiveDisposition: disposition=[enabled, disallowed, visible, notified], have LWCR=true 2025-01-13 21:17:05.013214+0530 0x32d Error 0x0 89 0 smd: [com.apple.xpc.smd:all] Legacy job is not allowed to launch: <private> status: 2 Is there anything changed in latest Mac OS which is causing this issue? Also what does this status 2 means. Can someone please help with this error? The plist has is true

on a span of 4 months we sent 2 for nfc entitlement requests and refused , no reason nothing . i mean all we want is the ability to use nfc on passes nothing else , no idea why this is so complex . with google you don’t even need a developer account and it’s for free , here we pay and we can’t even get the full functionality the passes offer , we got the hardware and the solution but we find out we need an nfc entitlement to allow passes to have nfc ? i mean our use case is very simple instead of having barcode on the passes we want them to be via nfc and we already got the nfc hardware but we find out we need nfc entitlement which we tried requesting but getting refused with no reason at all. at least tell u what is the problem what how to fix it not outright refuse without any reason at all. if anyone got any solution please provide.

I am developing an app to add Discover cards to Apple Wallet. Unlike Visa, MasterCard, etc., Discover does not have APIs that return activationData, encryptedPassData and ephemeralPublicKey for a given card, so I have created a backend server to handle this. In my server, I am unsure how to generate the ephemeralPublicKey. Do I need to use the merchant certificate? If so, how do I use it to generate the ephemeralPublicKey? I would appreciate it if someone could provide me with a step-by-step guide on how to generate ephemeralPublicKey for provisioning a card.

My app needs to track background location for a period of several hours while the user is using it, and we want to allow the user to switch apps or lock their phone while this is happening. We don't need to track location permanently and because of this, we don't want to request the "Always allow" permission. The app requests "While in use" permission and it has the "Location updates" background mode enabled. The CLLocationManager has 'allowsBackgroundLocationUpdates' set to true, 'pausesLocationUpdatesAutomatically' false, kCLLocationAccuracyBest, kCLDistanceFilterNone, and .fitness for the activity type (we expect the user to be walking). The app also initializes a CLBackgroundActivitySession while it is tracking location and invalidates it when done. When I test this combination on my iPhone, it works fine. I get location tracking in the background for as long as I need it, regardless of what else I do with the phone. However, my customer says it doesn't work for him. He is using a Wifi-only iPad with an external GPS receiver called "BadElf GPS Pro". He says that the external GPS receiver works fine with other apps on his iPad. With my app, he gets background location tracking only for a short time, and then it stops. The app does monitor the "locationManagerDidPauseLocationUpdates" callback and posts a local notification if it gets called, but it doesn't get called. I've also confirmed with him that he is not force-quitting the app and the app is not otherwise being terminated by iOS. Is there something I'm missing?

I've been stuck for days trying to figure out how to extract the full text of a Siri prompt that launches my app. We need to be able to get the text of the full command, such as "Hey siri, buy dogfood...." so I can get "dogfood" or anything else following 'buy' . The examples I am finding are a) out of date or b) incomplelete. Right now we're using AppIntents with Shortcuts, but have to use dedicated shortcuts for each specific purchase, which are obviously very limiting.

I have been trying to investigate some of the kernel crashes I have noticed on my IOS crash logs. Some of these are in device driver software for the peripheral interfaces. Given that the driver code executes with kernel privileges, these kind of crashes leave the device vulnerable to remote code injection, with no user interaction required in some cases. Crash Report from IOS 18.2.1 If Apple can provide the symbol table for IOS 18.2.1 blue tooth driver and source code, I can gladly help investigate this further.

The UIApplication background task mechanism allows you to prevent your app from being suspended for short periods of time. While the API involved is quite small, there’s still a bunch of things to watch out for. The name background task is somewhat misappropriate. Specifically, beginBackgroundTask(expirationHandler:) doesn’t actually start any sort of background task, but rather it tells the system that you have started some ongoing work that you want to continue even if your app is in the background. You still have to write the code to create and manage that work. So it’s best to think of the background task API as raising a “don’t suspend me” assertion. You must end every background task that you begin. Failure to do so will result in your app being killed by the watchdog. For this reason I recommend that you attach a name to each background task you start (by calling beginBackgroundTask(withName:expirationHandler:) rather than beginBackgroundTask(expirationHandler:)). A good name is critical for tracking down problems when things go wrong. IMPORTANT Failing to end a background task is the number one cause of background task problems on iOS. This usually involves some easy-to-overlook error in bookkeeping that results in the app begining a background task and not ending it. For example, you might have a property that stores your current background task identifier (of type UIBackgroundTaskIdentifier). If you accidentally creates a second background task and store it in that property without calling endBackgroundTask on the identifier that’s currently stored there, the app will ‘leak’ a background task, something that will get it killed by the watchdog. One way to avoid this is to wrap the background task in an object; see the QRunInBackgroundAssertion post on this thread for an example. Background tasks can end in one of two ways: When your app has finished doing whatever it set out to do. When the system calls the task’s expiry handler. Your code is responsible for calling endBackgroundTask(_:) in both cases. All background tasks must have an expiry handler that the system can use to ‘call in’ the task. The background task API allows the system to do that at any time. Your expiry handler is your opportunity to clean things up. It should not return until everything is actually cleaned up. It must run quickly, that is, in less than a second or so. If it takes too long, your app will be killed by the watchdog. Your expiry handler is called on the main thread. It is legal to begin and end background tasks on any thread, but doing this from a secondary thread can be tricky because you have to coordinate that work with the expiry handler, which is always called on the main thread. The system puts strict limits on the total amount of time that you can prevent suspension using background tasks. On current systems you can expect about 30 seconds. IMPORTANT I’m quoting these numbers just to give you a rough idea of what to expect. The target values have changed in the past and may well change in the future, and the amount of time you actually get depends on the state of the system. The thing to remember here is that the exact value doesn’t matter as long as your background tasks have a functional expiry handler. You can get a rough estimate of the amount of time available to you by looking at UIApplication’s backgroundTimeRemaining property. IMPORTANT The value returned by backgroundTimeRemaining is an estimate and can change at any time. You must design your app to function correctly regardless of the value returned. It’s reasonable to use this property for debugging but we strongly recommend that you avoid using as part of your app’s logic. IMPORTANT Basing app behaviour on the value returned by backgroundTimeRemaining is the number two cause of background task problems on iOS. The system does not guarantee any background task execution time. It’s possible (albeit unlikely, as covered in the next point) that you’ll be unable to create a background task. And even if you do manage to create one, its expiry handler can be called at any time. beginBackgroundTask(expirationHandler:) can fail, returning UIBackgroundTaskInvalid, to indicate that you the system is unable to create a background task. While this was a real possibility when background tasks were first introduced, where some devices did not support multitasking, you’re unlikely to see this on modern systems. The background time ‘clock’ only starts to tick when the background task becomes effective. For example, if you start a background task while the app is in the foreground and then stay in the foreground, the background task remains dormant until your app moves to the background. This can help simplify your background task tracking logic. The amount of background execution time you get is a property of your app, not a property of the background tasks themselves. For example, starting two background task in a row won’t give you 60 seconds of background execution time. Notwithstanding the previous point, it can still make sense to create multiple background tasks, just to help with your tracking logic. For example, it’s common to create a background task for each job being done by your app, ending the task when the job is done. Do not create too many background tasks. How many is too many? It’s absolutely fine to create tens of background tasks but creating thousands is not a good idea. IMPORTANT iOS 11 introduced a hard limit on the number of background task assertions a process can have (currently about 1000, but the specific value may change in the future). If you see a crash report with the exception code 0xbada5e47, you’ve hit that limit. Note The practical limit that you’re most likely to see here is the time taken to call your expiry handlers. The watchdog has a strict limit (a few seconds) on the total amount of time taken to run background task expiry handlers. If you have thousands of handlers, you may well run into this limit. If you’re working in a context where you don’t have access to UIApplication (an app extension or on watchOS) you can achieve a similar effect using the performExpiringActivity(withReason:using:) method on ProcessInfo. If your app ‘leaks’ a background task, it may end up being killed by the watchdog. This results in a crash report with the exception code 0x8badf00d (“ate bad food”). IMPORTANT A leaked background task is not the only reason for an 0x8badf00d crash. You should look at the backtrace of the main thread to see if the main thread is stuck in your code, for example, in a synchronous networking request. If, however, the main thread is happily blocked in the run loop, a leaked background task should be your primary suspect. Prior to iOS 11 information about any outstanding background tasks would appear in the resulting crash report (look for the text BKProcessAssertion). This information is not included by iOS 11 and later, but you can find equivalent information in the system log. The system log is very noisy so it’s important that you give each of your background tasks an easy-to-find name. For more system log hints and tips, see Your Friend the System Log. iOS 13 introduced the Background Tasks framework. This supports two type of requests: The BGAppRefreshTaskRequest class subsumes UIKit’s older background app refresh functionality. The BGProcessingTaskRequest class lets you request extended background execution time, typically overnight. WWDC 2020 Session 10063 Background execution demystified is an excellent summary of iOS’s background execution model. Watch it, learn it, love it! For more background execution hints and tips, see Background Tasks Resources. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Revision History 2023-06-16 Added a link to my QRunInBackgroundAssertion post. 2022-06-08 Corrected a serious error in the discussion of BGProcessingTaskRequest. Replaced the basic system log info with a reference to Your Friend the System Log. Added a link to Background Tasks Resources. Made other minor editorial changes. 2021-02-27 Fixed the formatting. Added a reference to the Background Tasks framework and the Background execution demystified WWDC presentation. Minor editorial changes. 2019-01-20 Added a note about changes in the iOS 13 beta. Added a short discussion about beginning and ending background tasks on a secondary thread. 2018-02-28 Updated the task name discussion to account for iOS 11 changes. Added a section on how to debug ‘leaked’ background tasks. 2017-10-31 Added a note about iOS 11’s background task limit. 2017-09-12 Numerous updates to clarify various points. 2017-08-17 First posted.

Hello everyone, I want send haptics to ps4 controller. CHHapticPatternPlayer and CHHapticAdvancedPatternPlayer good work with iPhone. On PS4 controller If I use CHHapticPatternPlayer all work good, but if I use CHHapticAdvancedPatternPlayer I get error. I want use CHHapticAdvancedPatternPlayer to use additional settings. I don't found any information how to fix it - CHHapticEngine.mm:624 -[CHHapticEngine finishInit:]_block_invoke: ERROR: Server connection broke with error 'Не удалось завершить операцию. (com.apple.CoreHaptics, ошибка -4811)' The engine stopped because a system error occurred. AVHapticClient.mm:1228 -[AVHapticClient getSyncDelegateForMethod:errorHandler:]_block_invoke: ERROR: Sync XPC call for 'loadAndPrepareHapticSequenceFromEvents:reply:' (client ID 0x21) failed: Не удалось установить связь с приложением-помощником. Не удалось создать или воспроизвести паттерн: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service with pid 5087 named com.apple.GameController.gamecontrollerd.haptics" UserInfo={NSDebugDescription=connection to service with pid 5087 named com.apple.GameController.gamecontrollerd.haptics} My Haptic class - import Foundation import CoreHaptics import GameController protocol HapticsControllerDelegate: AnyObject { func didConnectController() func didDisconnectController() func enginePlayerStart(value: Bool) } final class HapticsControllerManager { static let shared = HapticsControllerManager() private var isSetup = false private var hapticEngine: CHHapticEngine? private var hapticPlayer: CHHapticAdvancedPatternPlayer? weak var delegate: HapticsControllerDelegate? { didSet { if delegate != nil { startObserving() } } } deinit { NotificationCenter.default.removeObserver(self) } private func startObserving() { guard !isSetup else { return } NotificationCenter.default.addObserver( self, selector: #selector(controllerDidConnect), name: .GCControllerDidConnect, object: nil ) NotificationCenter.default.addObserver( self, selector: #selector(controllerDidDisconnect), name: .GCControllerDidDisconnect, object: nil ) isSetup = true } @objc private func controllerDidConnect(notification: Notification) { delegate?.didConnectController() self.createAndStartHapticEngine() } @objc private func controllerDidDisconnect(notification: Notification) { delegate?.didDisconnectController() hapticEngine = nil hapticPlayer = nil } private func createAndStartHapticEngine() { guard let controller = GCController.controllers().first else { print("No controller connected") return } guard controller.haptics != nil else { print("Haptics not supported on this controller") return } hapticEngine = createEngine(for: controller, locality: .default) hapticEngine?.playsHapticsOnly = true do { try hapticEngine?.start() } catch { print("Не удалось запустить движок тактильной обратной связи: \(error)") } } private func createEngine(for controller: GCController, locality: GCHapticsLocality) -> CHHapticEngine? { guard let engine = controller.haptics?.createEngine(withLocality: locality) else { print("Failed to create engine.") return nil } print("Successfully created engine.") engine.stoppedHandler = { reason in print("The engine stopped because \(reason.message)") } engine.resetHandler = { print("The engine reset --> Restarting now!") do { try engine.start() } catch { print("Failed to restart the engine: \(error)") } } return engine } func startHapticFeedback(haptics: [CHHapticEvent]) { do { let pattern = try CHHapticPattern(events: haptics, parameters: []) hapticPlayer = try hapticEngine?.makeAdvancedPlayer(with: pattern) hapticPlayer?.loopEnabled = true try hapticPlayer?.start(atTime: 0) self.delegate?.enginePlayerStart(value: true) } catch { self.delegate?.enginePlayerStart(value: false) print("Не удалось создать или воспроизвести паттерн: \(error)") } } func stopHapticFeedback() { do { try hapticPlayer?.stop(atTime: 0) self.delegate?.enginePlayerStart(value: false) } catch { self.delegate?.enginePlayerStart(value: true) print("Не удалось остановить воспроизведение вибрации: \(error)") } } } extension CHHapticEngine.StoppedReason { var message: String { switch self { case .audioSessionInterrupt: return "the audio session was interrupted." case .applicationSuspended: return "the application was suspended." case .idleTimeout: return "an idle timeout occurred." case .systemError: return "a system error occurred." case .notifyWhenFinished: return "playback finished." case .engineDestroyed: return "the engine was destroyed." case .gameControllerDisconnect: return "the game controller disconnected." @unknown default: return "an unknown error occurred." } } } custom haptic events - static func changeVibrationPower(power: HapricPower) -> [CHHapticEvent] { let continuousEvent = CHHapticEvent(eventType: .hapticContinuous, parameters: [ CHHapticEventParameter(parameterID: .hapticSharpness, value: 1.0), CHHapticEventParameter(parameterID: .hapticIntensity, value: power.value) ], relativeTime: 0, duration: 0.5) return [continuousEvent] }

Hello. Recently, the users of our APP have reported using our products, and they can normally receive push in Hong Kong. However, when traveling to Japan or some countries and regions in Europe, push will not be received. we checked that -the cert is valid -the server get 'sent successfully' response -used pushtry to test the cert and token and it can receive push in app

I haven't been able to find a definitive answer to this online. Is NSUbiquitousKeyValueStore end-to-end encrypted with Advanced Data Protection turned on? It’s not specifically called out here https://support.apple.com/en-us/102651.

Hi, I'm developer in fintech company, we have setup process for onboarding merchants for our partner and processing payments with usage of Apple Pay API. Daily system is processing ca. 10k payments but every day ca. 100 of transactions are declined because of merchant validation error: request to https://apple-pay-gateway.apple.com/paymentservices/paymentSession (with all required parameters in body) is returning response with status code 417 "statusMessage": "Payment Services Exception merchantId={root merchant id} unauthorized to process transactions on behalf of merchantId={merchant id hash} reason={merchant id hash} is not a registered merchant in WWDR and isn't properly authorized via Mass Enablement, either." Issue impacts recurring merchants, most of their transactions are processed successfully but randomly some of them are failing with such reason. All prerequisites are met: merchant have deployed 'apple-developer-merchantid-domain-association' certificate, certificates are valid and not expired. Apple Support is not able to provide any information based on provided requests timestamps. We would to know what may be the reason just part of the requests are failing and what 417 error code means.

I'd like to set up a communication mechanism between the Ui test runner and my iOS app. The purpose is to be able to collect some custom performance metrics in addition to standard ones like scrollingAndDecelerationMetric. Let's say we measure some specific intervals in our code using signposts, then serialize the result into a structured payload and report it back to the runner. So, are there any good options for that kind of IPC? The primary concern is running on Simulator. However, since it is not a regular UI test but more a performance UI test, and it is usually recommended to run those on a real device, with release optimizations/flags in place, I wonder if it is feasible to have it for device too.

I am currently facing an issue when trying to enable Shortcut support and would greatly appreciate your assistance in resolving it. I have successfully enabled Shortcut support, and I can find my app and its respective functionalities within the Shortcuts app. However, I am unable to locate my app when attempting to create an automation within Shortcuts. I would appreciate any guidance or solutions you may offer regarding this matter.

I'm having some issues where only a subset of records appear in CloudKit dashboard after I have saved some records in my iOS app using NSPersistentCloudKitContainer. I have noticed that when I'm running my app using the development environment of my CloudKit container everything works smoothly and is uploaded as expected but when I'm using the production environment only a subset of records are actually uploaded. I'm pulling my hair on how to debug this. -com.apple.CoreData.CloudKitDebug and -com.apple.CoreData.SQLDebug pukes out too much info in the console for me to pinpoint any issue.

Hi team, I'm developing a feature that's collecting the device locations for home security app. We've been following https://developer.apple.com/documentation/corelocation/creating-a-location-push-service-extension apns-push-type set to location. apns-priority set to 5. during testing, we found that the device's notification extension cannot be triggered after device going into lock screen for 10 mins. Wonder should we set the priority to 10? Thanks!

I have my application named "TestDataPro" in apple store. When I open the application and click on apple icon, my application crash. It is working fine in MACOS version 14.2.1. But it is causing crash in MACOS version 14.5 and 14.6 with having Apple M1 or M2 chip. While for the same MACOS version with having intel chip it is working fine. I have attached crash log. Can you please help me to find the root cause for this? TDPCrashReport.txt

I'm trying to use ScreenCaptureKit on a Mac Catalyst app, on macOS 12.5.1. I'm not sure if I'm doing something wrong, but it crashes as soon as I try to request SCShareableContent. It crashes on internal code, calling a method it can't find, which makes me think this is a bug in the framework rather than incorrect configuration. Any hints on how to work around this problem? The crash is: ** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[RPDaemonProxy fetchShareableContentWithOption:windowID:withCompletionHandler:]: unrecognized selector sent to instance 0x6000037d5dc0' terminating with uncaught exception of type NSException ScreenCaptureKit-Crash.txt