how to register more than 10 shortcuts

Hello Devs, I'm encountering a persistent INTERNAL_ERROR (HTTP 500) when making Server-to-Server API calls to CloudKit, specifically when trying to hit the /users/current endpoint, even after meticulously verifying all client-side components. I'm hoping someone might have insight into what could cause this. Context: Goal: Authenticate to CloudKit from a Vercel Serverless Function (Node.js) to perform operations like record queries. Problem Endpoint: POST https://api.apple-cloudkit.com/database/1/iCloud.com.dannybaseball.Danny-Baseball/production/public/users/current Key Generation Method: Using the CloudKit Dashboard's "Tokens & Keys" -> "New Server-to-Server Key" flow, where I generate the private key using openssl ecparam -name prime256v1 -genkey -noout -out mykey.pem, then extract the public key using openssl ec -in mykey.pem -pubout, and paste the public key material (between BEGIN/END markers) into the dashboard. The private key was then converted to PKCS#8 format using openssl pkcs8 -topk8 -nocrypt -in mykey.pem -out mykey_pkcs8.pem. Current Setup Being Tested (in a Vercel Node.js function): CLOUDKIT_CONTAINER: iCloud.com.dannybaseball.Danny-Baseball CLOUDKIT_KEY_ID: 9368dddf141ce9bc0da743b9f69bc3eda132b9bb3e62a4167e428d4f320b656e (This is the Key ID generated from the CloudKit Dashboard for the public key I provided). CLOUDKIT_P8_KEY (Environment Variable): Contains the base64 encoded string of the entire content of my PKCS#8 formatted private key file. Key Processing in Code: const p8Base64 = process.env.CLOUDKIT_P8_KEY; const privateKeyPEM = Buffer.from(p8Base64, 'base64').toString('utf8'); // This privateKeyPEM string starts with "-----BEGIN PRIVATE KEY-----" and ends with "-----END PRIVATE KEY-----" const privateKey = crypto.createPrivateKey({ key: privateKeyPEM, format: 'pem' }); // This line SUCCEEDS without DECODER errors in my Vercel function logs. Use code with caution. JavaScript Request Body for /users/current: "{}" Signing String (message = Date:BodyHash:Path): Date: Correct ISO8601 format (e.g., "2025-05-21T19:38:11.886Z") BodyHash: Correct SHA256 hash of "{}", then Base64 encoded (e.g., "RBNvo1WzZ4oRRq0W9+hknpT7T8If536DEMBg9hyq/4o=") Path: Exactly /database/1/iCloud.com.dannybaseball.Danny-Baseball/production/public/users/current Headers: X-Apple-CloudKit-Request-KeyID: Set to the correct Key ID. X-Apple-CloudKit-Request-ISO8601Date: Set to the date used in the signature. X-Apple-CloudKit-Request-SignatureV1: Set to the generated signature. X-Apple-CloudKit-Environment: "production" Content-Type: "application/json" Observed Behavior & Logs: The Node.js crypto.createPrivateKey call successfully parses the decoded PEM key in my Vercel function. The request is sent to CloudKit. CloudKit responds with HTTP 500 and the following JSON body (UUID varies per request): { "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "serverErrorCode": "INTERNAL_ERROR" } Use code with caution. Json This happens consistently. Previously, with other key pairs or different P8 processing attempts, I was getting AUTHENTICATION_FAILED (401) or local DECODER errors. Now that the key parsing is successful on my end with this current key pair and setup, I'm hitting this INTERNAL_ERROR. Troubleshooting Done: Verified Key ID (9368dddf...) is correct and corresponds to the key generated via CloudKit Dashboard. Verified Container ID (iCloud.com.dannybaseball.Danny-Baseball) is correct. Successfully parsed the private key from the environment variable (after base64 decoding) within the Vercel function. Meticulously checked the signing string components (Date, BodyHash, Path) against Apple's documentation. Path format is /database/1////. Ensured all required headers are present with correct values. Local Node.js tests (bypassing Vercel but using the same key data and signing logic) also result in this INTERNAL_ERROR. Question: What could cause CloudKit to return an INTERNAL_ERROR (500) for a /users/current request when the client-side key parsing is successful and all request components (path, body hash for signature, date, headers) appear to conform exactly to the Server-to-Server Web Services Reference? Are there any known subtle issues with EC keys generated via openssl ecparam (and then converted to PKCS#8) that might lead to this, even if crypto.createPrivateKey parses them in Node.js? Could there be an issue with my specific Key ID or container that would manifest this way, requiring Apple intervention? Any insights or suggestions would be greatly appreciated. I can provide more detailed logs of the request components if needed. Thank you!

I need to implement a VPN connection from the ios 17 widget without opening the main application. (I have seen such an implementation in other applications) How can this be implemented?

Hi, I would like to asking , can I setup a. alarm to alert when phone if OFF power ? since we would like to design a timer with emergence alert. so I need a alert on even phone power is off , Thanks.

I try to refresh the SDP data for a Bluetooth device that has reconnected. So when I receive connect notification I call -[IOBluetoothDevice performSDPQuery:] passing object, that should receive the query completion call. What I observe is that sdpQueryComplete:status: is not being called, buit calling performSDPQuery causes additional connect notification to be dispatched. Running this under debugger results in some weird log line: [IOBluetooth] **** This currently won't trigger SDP delegate I run this code on Sequoia 15.5

Hi everyone, I recently migrated my individual Apple Developer account to an Organization account for my company "". My Team ID remained the same. I'm now facing persistent issues with code signing and push notifications for my iOS app (Bundle ID: com.).
 Current Problems:
 "Untitled" Certificates in Xcode: When I go to Xcode -> Settings -> Accounts -> [My Apple ID] -> Select "" Team -> "Manage Certificates...", a number of my newly created Apple Development and Apple Distribution certificates are listed древ "Untitled". Some older ones are "Revoked". (See attached screenshot if possible).
 "No App ID" for Push Notifications Console: In my app target's "Signing & Capabilities" tab, I've added the "Push Notifications" capability. However, when I click the info button to open the "Push Notifications Console", it states: "no app IDs: Register an App ID with the Push Notifications capability enabled to use the Push Notifications console." This is despite the fact that the Push Notifications capability IS enabled for my App ID com. in the Developer Portal, and I've configured an APNs Auth Key (.p8) for it.
 Push Notifications Not Received (from Backend): While I can successfully send a test push notification directly from the Firebase Console to my device's FCM token, notifications triggered by my backend (Firebase Cloud Functions writing to a Firestore collection, which then triggers another function to send via FCM) are not being delivered to iOS devices. (Android seems to be working more reliably now).
 Setup: Using an APNs Authentication Key (.p8) linked to my Organization Team ID in Firebase Cloud Messaging. Main App ID com. has "Push Notifications" capability enabled. Notification Service Extension com..ImageNotification also has its App ID and Provisioning Profile set up for the Organization team. Created new Development and Distribution certificates and Provisioning Profiles specifically for the Organization team. Using "Automatically manage signing" in Xcode with the Organization team selected for both the main app target and the extension target.
 Troubleshooting Done: Revoked old/problematic certificates and profiles. Recreated CSRs and new Development/Distribution certificates under the Organization team multiple times. Recreated Provisioning Profiles. Cleaned Derived Data in Xcode. Ensured Bundle Identifiers are consistent. Verified APNs Auth Key details (Key ID, Team ID) in Firebase.
 I suspect there's a fundamental issue with how Xcode is recognizing or linking the signing assets for my Organization team after the account type change, despite the Team ID being the same. The "Untitled" certificates are a major red flag.
 Has anyone encountered similar issues, particularly the "Untitled" certificates or the "No App ID" message for the Push Console, after an account migration or when working with Organization accounts? Any insights on how to resolve this would be greatly appreciated.
 Thanks,
Benni

I have two call directory extensions, each with InfoPlist.strings in en.lproj and nb.lproj directories. In these files I've defined CFBundleDisplayName for both locales. These names are displayed under Settings -> Phone -> Call Blocking & Identification. On iOS 12.2 the names are displayed correctly in both Norwegian and English. Testing on iOS 15.3 the English names are displayed even when device language is set to Norwegian. Worth noting: When updating the English versions of CFBundleDisplayName this is immediately reflected in Call Blocking & Identification page with Norwegian device language. As this feature requires a real device, I'm unable to test on iOS 13 and 14.

Back story: I'm developing an app that communicates with a personal medical device. We use critical alerts when we have hardware issues that could result in harm to the patient. The audio file is a 30 second file to make sure the patient is aware. If the app is open when they occur, we pop up a modal message in the app. When the user dismisses the notice, we call UNNotificationCenter::removeDeliveredNotifications(withIdentifiers:) to remove the critical alert and also to stop the audio file that is playing. This normally works fine. However we discovered that if the patient leaves critical alert enabled but disables notifications for our app, that we can still post the critical alert and it goes off. However when the user dismisses the message, the removeDeliveredNotifications call does not work. I did some debugging and if call getDeliveredNotifications with this permission combination, it return 0 (normally it would return 1). Does anyone know of another way to remove the critical alert in this situation? (or should I be submitting this as a bug?)

I have an accessory with MFi authenticaiton passed(got 0xAA05) and identification accepted (got 0x1D02). But when I try to open the target stream by using iAP2 EA session framework, I always enounter the same error looking like: XPC connection error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.accessories.externalaccessory-server was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.accessories.externalaccessory-server was invalidated from this process.} anybody can tell me what it related with? And what can I do to go through it quickly? Thank you much in advance.

I am reaching out to seek clarification on the usage of exit(0) within an iOS application under specific circumstances, as I have not been able to find concrete guidance on this in the App Store Review Guidelines Context of Our Application: We are developing a mobile game using Cocos2d-JS (Cocos2d-x JavaScript bindings). The game is built in C++ with JavaScript used for game logic, and it runs on both Android and iOS. Occasionally, due to an unrecoverable fatal JavaScript error (e.g., corrupted state or unexpected runtime crash), the game’s screen goes completely black. When this occurs, the rendering engine halts, user interaction becomes impossible, and the app enters a non-functional state. From this point, the only way to return to a working state is to manually terminate and relaunch the app. We are exploring a user-friendly solution where, upon detecting such a critical failure, we present a native UIAlertController to the user explaining the issue and informing them that the app needs to restart. Upon confirmation (i.e., tapping “OK”), we call exit(0) to gracefully close the app, so the user can relaunch it in a working state. Our Question: Is it acceptable to use exit(0) in this very limited and clearly explained context? The intention is to improve the user experience during unrecoverable fatal states that cannot be handled through standard UI or engine resets. I understand that the use of exit(0) is generally discouraged, but in our case: The user explicitly initiates the exit via a native prompt. The app is not quitting on its own or in response to a policy violation. We are not using exit(0) to bypass App Review or circumvent system behavior. There is no mention in the App Review Guidelines explicitly stating whether or not exit(0) is disallowed in such edge cases. Please confirm whether this approach aligns with Apple's policies, or suggest an alternative method for cleanly handling such irrecoverable errors on iOS? Looking forward to your guidance.

We are developing a matter device. How can we display our own APP under the Home device information?

Confusion Based on the fact that the subscription is requested on a Activity type, I assumed that the push-to-start tokens would be different. But the push-to-start token for WidgetExtensionAttributes and WidgetExtensionAttributesOther were identical. This is misleading. The code below prints identical tokens even though the name of the token and their underlying schema are different. Code Sample func getTokens() { Task { if let data = Activity<func getTokens() { Task { if let data = Activity<WidgetExtensionAttributes>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } }>.pushToStartToken { print("exists:", data.hexadecimalString) } else { print("requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributes> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("new:", ptsTokenString) } } } Task { if let data = Activity<WidgetExtensionAttributesOther>.pushToStartToken { print("other exists:", data.hexadecimalString) } else { print("other requesting pushToStartToken") for await ptsToken in Activity<WidgetExtensionAttributesOther> .pushToStartTokenUpdates { let ptsTokenString = ptsToken.hexadecimalString print("other new:", ptsTokenString) } } } } Activity Types struct WidgetExtensionAttributesOther: ActivityAttributes { public struct ContentState: Codable, Hashable { var age: Int } var addresses: [String] } struct WidgetExtensionAttributes: ActivityAttributes { public struct ContentState: Codable, Hashable { var emoji: String } var name: String } Docs After much investigation I noticed the wording of the docs kind of hint that the push-to-start token is per ActivityKit as it says: An asynchronous sequence you use to observe changes to the token for starting a Live Activity with an ActivityKit push notification. But docs and the API don't align well. Questions Is it correct that the push-to-start token is per app? If so then is there a reason that that API designers decided to still have to pass a specific type and not just make a request without passing a type? Should I maybe file a radar? Is it correct to say push-to-start is per app, while update tokens are per instance. i.e. if I have two soccer matches, then unless the push-to-start token was refreshed by the OS, then both would use the same push-to-start token, however each match would have a unique update token?

Hi all, I'm working on a non-interactive macOS application (a service or daemon), and I'm trying to understand the best practices around logging and error reporting, particularly in failure scenarios. If a daemon or service fails in macOS, where is it expected to log errors, and how can users or developers discover what went wrong? Specifically, I have a few questions: What is the recommended location or system for logging errors from a non-interactive macOS application? Should we use os_log, standard error output, or write directly to files somewhere? How can a user or developer access these logs to diagnose issues—should logs be visible via the Console app? Is there a standard approach to making failure information easily accessible for debugging and support, especially for daemons running under launchd? Any guidance or best practices would be appreciated.

We have a setup where the system uses proxy settings configured via a PAC file. We are investigating how NWConnection behaves inside a Network Extension (NETransparentProxyProvider) with a transparent proxy configuration based on this PAC file. Scenario: The browser makes a connection which the PAC file resolves as "DIRECT" (bypassing the proxy) Our Network Extension intercepts this traffic for analysis The extension creates a new connection using NWConnection to the original remote address. The issue: despite the PAC file’s "DIRECT" decision, NWConnection still respects the system proxy settings and routes the connection through the proxy. Our questions: Is it correct that NWConnection always uses the system proxy if configured ? Does setting preferNoProxies = true guarantee bypassing the system proxy? Additionally: Whitelisting IPs in the Network Extension to avoid interception is not a viable solution because IPs may correspond to multiple services, and the extension only sees IP addresses, not domains (e.g., we want to skip scanning meet.google.com traffic but still scan other Google services on the same IP range). Are there any recommended approaches or best practices to ensure that connections initiated from a Network Extension can truly bypass the proxy (for example, for specific IP ranges or domains)?

Hi all, We've been exploring the capabilities of the Network.framework for peer-to-peer communication and have run into some behavior that we haven't been able to fully explain with the existing documentation. In our tests, we’re working with 12 iOS devices, all disconnected from Wi-Fi to force communication over Apple Wireless Direct Link (AWDL). While using the Network.framework to create peer-to-peer connections, we observed that the number of connected peers never exceeded 8, despite all 12 devices being active and configured identically. Some questions we’re hoping to get clarification or discussion on: Is there a known upper limit to the number of peer-to-peer connections supported via AWDL? Are there conditions under which the framework or system limits or throttles visible peers? Does AWDL behavior vary by hardware model, iOS version, or backgrounding state of the app? Is there any official documentation or guidance around peer discovery or connection limits when using NWBrowser and NWConnection in a peer-to-peer context? We’d appreciate any insights from the Apple engineering team or other developers who have worked with larger peer groups using Network.framework in peer-to-peer mode.

Hello! The localization isn't working when using SubscriptionStoreView. The app hasn't been published yet. The subscription has been created and localization strings have been added. Status - ready to submit. Testing environment: Sandbox When calling SubscriptionStoreView, the debug console shows this error: GenerativeModelsAvailability.Parameters: Initialized with invalid language code: ru-RU. Expected to receive two-letter ISO 639 code. e.g. 'zh' or 'en'. Falling back to: ru Despite this, the subscription interface appears in English when Russian is expected. I don't use any locale setting for ru-RU anywhere in my code. The test device's region is set to Russia, and the language is Russian. Any help would be appreciated.

Does live activity require notification permission? If you need to update card data through APNS, I remember that it was required in the past, otherwise the card could not be created. This year I tried it and some apps did not have notification permission, but they could also use live activity and update data

Hi, We're in the process of following Apple’s guidance on transitioning away from Packet Filter (pf) and migrating to a Network Extension-based solution that functions as a firewall. During this transition, we've encountered several limitations with the current Content Filter API and wanted to share our findings. Our VPN client relies on firewall functionality to enforce strict adherence to split tunneling rules defined via the routing table. This ensures that no traffic leaks outside the VPN tunnel, which is critical for our users for a variety of reasons. To enforce this, our product currently uses interface-scoped rules to block all non-VPN traffic outside the tunnel. Replicating this behavior with the Content Filter API (NEFilterDataProvider) appears to be infeasible today. The key limitation we've encountered is that the current Content Filter API does not expose information about the network interface associated with a flow. As a workaround, we considered using the flow’s local endpoint IP to infer the interface, but this data is not available until after returning a verdict to peek into the flow’s data—at which point the connection has already been established. This can result in connection metadata leaking outside the tunnel, which may contain sensitive information depending on the connection. What is the recommended approach for this use case? NEFilterPacketProvider? This may work, but it has a negative impact on network performance. Using a Packet Tunnel Provider and purely relying on enforceRoutes? Would this indeed ensure that no traffic can leak by targeting a specific interface or by using a second VPN extension? And more broadly—especially if no such approach is currently feasible with the existing APIs—we're interpreting TN3165 as a signal that pf should be considered deprecated and may not be available in the next major macOS release. Is that a reasonable interpretation?

I'm seeing a lot of these in my logs: PersistentIdentifier PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-swiftdata://Course/BC9CF99A-DE6A-46F1-A18D-8034255A56D8), implementation: SwiftData.PersistentIdentifierImplementation) was remapped to a temporary identifier during save: PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata:///Course/t58C849CD-D895-4773-BF53-3F63CF48935B210), implementation: SwiftData.PersistentIdentifierImplementation). This is a fatal logic error in DefaultStore ... though everything seems to work. Does anyone know what this means in this context? Anything I can do to not have this appear?

Hi all, I’m encountering a consistent issue with SwiftData on watchOS when using CloudKit sync. After enabling: let config = ModelConfiguration(schema: schema, cloudKitDatabase: .automatic) …the app terminates ~30–60 seconds into a WKExtendedRuntimeSession. This happens specifically when: Always-On Display is OFF The iPhone is disconnected or in Airplane Mode The app is running in a WKExtendedRuntimeSession (e.g., used for meditation tracking) The Xcode logs show a warning: Background Task ("CoreData: CloudKit Setup"), was created over 30 seconds ago. In applications running in the background, this creates a risk of termination. It appears CloudKit sync setup is being triggered automatically and flagged by the system as an unmanaged long-running task, leading to termination. Workaround: Switching to: let config = ModelConfiguration(schema: schema, cloudKitDatabase: .none) …prevents the issue entirely — no background task warning, no crash. Feedback ID submitted: FB17685611 Just wanted to check if others have seen this behavior or found alternative solutions. It seems like something Apple may need to address in SwiftData’s CloudKit handling on watchOS.