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.
Delve into the world of built-in app and system services available to developers. Discuss leveraging these services to enhance your app's functionality and user experience.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
So I'm wondering if Apple makes commission on those payments since they're made in the app. For example a user may pay another user to clean their car. This will be handled with Stripe Connect and their balance, payment history, etc will be displayed in the app.
Does Apple charge commission on that?
The section the app review guidelines that I'm refrencing is below, but I'm still a little confused.
3.1.3(e) Goods and Services Outside of the App: If your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
Topic:
App & System Services
SubTopic:
Apple Pay
Some of my users reported they can not completed the purchase .
According to the logs and screen captures . Their purchase progress's last status are "purchasing"
func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
....
....
case .purchasing:
// 处理正在购买的情况
//print("购买中");
AppDelegate.log.debug("paymentQueue purchasing");
LoadingAlert.shared.setText(text: "购买中".localized())
....
After this ,It neither entered any error branch nor prompted the user to confirm the purchase or enter a password, but simply stopped here. There are no other purchase-related logs, and the program is still running normally.
At the same time, other users are able to complete their purchases without any issues. However, there have been 4-5 users recently who reported problems with purchasing. What could be the possible reasons?
In my local environment, I repeated the test many times, including using sandbox users from different regions and real Apple IDs, and everything worked fine.
//
// Payment.swift
// RadialMenu
//
// Created by pat on 2023/6/26.
//
import Foundation
import StoreKit
class Payment:NSObject,SKProductsRequestDelegate,SKPaymentTransactionObserver{
func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) {
for transaction in transactions {
AppDelegate.log.debug("paymentQueue transaction product = \(transaction.payment.productIdentifier) state = \(transaction.transactionState)");
//let productID = transaction.payment.productIdentifier
switch transaction.transactionState {
case .purchased,.restored:
if(transaction.transactionState == .purchased){
AppDelegate.log.debug("paymentQueue purchased");
LoadingAlert.shared.setText(text: "已购买".localized())
}
if(transaction.transactionState == .restored){
LoadingAlert.shared.setText(text: "已恢复".localized())
AppDelegate.log.debug("paymentQueue restored");
}
//}
break;
case .failed:
AppDelegate.log.debug("paymentQueue failed ");
if let error = transaction.error as? NSError {
// 获取错误代码和描述
let errorCode = error.code
let errorDescription = error.localizedDescription
AppDelegate.log.debug("paymentQueue Transaction failed with error code: \(errorCode), description: \(errorDescription)")
}
queue.finishTransaction(transaction)
LoadingAlert.shared.hideModal();
// 处理购买失败的情况
// 提供错误信息给用户
//print("购买失败");
alertRetry();
break;
case .deferred:
AppDelegate.log.debug("paymentQueue deferred");
LoadingAlert.shared.setText(text: "购买延迟".localized())
// 处理交易延迟的情况(仅限家庭共享)
break;
case .purchasing:
// 处理正在购买的情况
//print("购买中");
AppDelegate.log.debug("paymentQueue purchasing");
LoadingAlert.shared.setText(text: "购买中".localized())
break;
@unknown default:
AppDelegate.log.debug("paymentQueue nknown default\(transaction.transactionState)");
break
}
}
}
Please consider this very trivial C code, which was run on 15.3.1 of macos:
#include <stdio.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include "sys/socket.h"
#include <string.h>
#include <unistd.h>
#include <ifaddrs.h>
#include <net/if.h>
// prints out the sockaddr_in6
void print_addr(const char *msg_prefix, struct sockaddr_in6 sa6) {
char addr_text[INET6_ADDRSTRLEN] = {0};
printf("%s%s:%d, addr family=%u\n",
msg_prefix,
inet_ntop(AF_INET6, &sa6.sin6_addr, (char *) &addr_text, INET6_ADDRSTRLEN),
sa6.sin6_port,
sa6.sin6_family);
}
// creates a datagram socket
int create_dgram_socket() {
const int fd = socket(AF_INET6, SOCK_DGRAM, 0);
if (fd < 0) {
perror("Socket creation failed");
return -1;
}
return fd;
}
int main() {
printf("current process id:%ld parent process id: %ld\n", (long) getpid(), (long) getppid());
//
// hardcode a link-local IPv6 address of a interface which is down
// ifconfig:
// ,,,
// awdl0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
// options=6460<TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
// ...
// inet6 fe80::34be:50ff:fe14:ecd7%awdl0 prefixlen 64 scopeid 0x10
// nd6 options=201<PERFORMNUD,DAD>
// media: autoselect (<unknown type>)
// status: inactive
//
const char *ip6_addr_str = "fe80::34be:50ff:fe14:ecd7"; // link-local ipv6 address from above ifconfig output
// parse the string literal to in6_addr
struct in6_addr ip6_addr;
int rv = inet_pton(AF_INET6, ip6_addr_str, &ip6_addr);
if (rv != 1) {
fprintf(stderr, "failed to parse ipv6 addr %s\n", ip6_addr_str);
exit(EXIT_FAILURE);
}
// create a AF_INET6 SOCK_DGRAM socket
const int sock_fd = create_dgram_socket();
if (sock_fd < 0) {
exit(EXIT_FAILURE);
}
printf("created a socket, descriptor=%d\n", sock_fd);
// create a destination sockaddr which points to the above
// ipv6 link-local address and an arbitrary port
const int dest_port = 12345;
struct sockaddr_in6 dest_sock_addr;
memset((char *) &dest_sock_addr, 0, sizeof(struct sockaddr_in6));
dest_sock_addr.sin6_addr = ip6_addr;
dest_sock_addr.sin6_port = htons(dest_port);
dest_sock_addr.sin6_family = AF_INET6;
dest_sock_addr.sin6_scope_id = 0x10; // scopeid from the above ifconfig output
// now sendto() to that address, whose network interface is down.
// we expect sendto() to return an error
print_addr("sendto() to ", dest_sock_addr);
const char *msg = "hello";
const size_t msg_len = strlen(msg) + 1;
rv = sendto(sock_fd, msg, msg_len, 0, (struct sockaddr *) &dest_sock_addr, sizeof(dest_sock_addr));
if (rv == -1) {
perror("sendto() expectedly failed");
close(sock_fd);
exit(EXIT_FAILURE);
}
printf("sendto() unexpectedly succeeded\n"); // should not reach here, we expect sendto() to return an error
return 0;
}
It creates a SOCK_DGRAM socket and attempts to sendto() to a link-local IPv6 address of a local network interface which is not UP. The sendto() is expected to fail with a "network is down" (or at least fail with some error). Let's see how it behaves.
Copy that code to a file called netdown.c and compile it as follows:
clang netdown.c
Now run the program:
./a.out
That results in the following output:
current process id:29290 parent process id: 21614
created a socket, descriptor=3
sendto() to fe80::34be:50ff:fe14:ecd7:14640, addr family=30
sendto() unexpectedly succeeded
(To reproduce this locally, replace the IPv6 address in that code with a link-local IPv6 address of an interface that is not UP on your system)
Notice how the sendto() returned successfully without any error giving an impression to the application code that the message has been sent. In reality, the message isn't really sent. Here's the system logs from that run:
PID Type Date & Time Process Message
debug 2025-03-13 23:36:36.830147 +0530 kernel Process (a.out) allowed via dev tool environment (/System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal)
debug 2025-03-13 23:36:36.833054 +0530 kernel [SPI][HIDSPI]
TX: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
RX: 20 02 00 00 00 00 38 00 10 02 00 17 00 00 2E 00
26700 error 2025-03-13 23:36:36.838607 +0530 nehelper Failed to get the signing identifier for 29290: No such process
26700 error 2025-03-13 23:36:36.838608 +0530 nehelper Failed to get the code directory hash for 29290: No such process
default 2025-03-13 23:36:36.840070 +0530 kernel cfil_dispatch_attach_event:3507 CFIL: Failed to get effective audit token for <sockID 22289651233205710 <4f3051d7ec2dce>>
26700 error 2025-03-13 23:36:36.840678 +0530 nehelper Failed to get the signing identifier for 29290: No such process
26700 error 2025-03-13 23:36:36.840679 +0530 nehelper Failed to get the code directory hash for 29290: No such process
default 2025-03-13 23:36:36.841742 +0530 kernel cfil_hash_entry_log:6082 <CFIL: Error: sosend_reinject() failed>: [29290 ] <UDP(17) out so 891be95f39bd0385 22289651233205710 22289651233205710 age 0> lport 60244 fport 12345 laddr fe80::34be:50ff:fe14:ecd7 faddr fe80::34be:50ff:fe14:ecd7 hash D7EC2DCE
default 2025-03-13 23:36:36.841756 +0530 kernel cfil_service_inject_queue:4466 CFIL: sosend() failed 50
Notice the last line where it states the sosend() (and internal impl detail of macos) failed with error code 50, which corresponds to ENETDOWN ("Network is down"). However, like I noted, this error was never propagated back to the application from the sendto() system call.
The documentation of sendto() system call states:
man sendto
...
Locally detected errors are indicated by a return value of -1.
...
RETURN VALUES
Upon successful completion, the number of bytes which were sent is returned. Otherwise, -1 is returned and the global variable errno is set to indicate the error.
So I would expect sendto() to return -1, which it isn't.
The 15.3.1 source of xnu hasn't yet been published but there is the 15.3 version here https://github.com/apple-oss-distributions/xnu/tree/xnu-11215.81.4 and looking at the corresponding function cfil_service_inject_queue, line 4466 (the one which is reported in the logs) https://github.com/apple-oss-distributions/xnu/blob/xnu-11215.81.4/bsd/net/content_filter.c#L4466, the code there logs this error and the cfil_service_inject_queue function then returns back the error. However, looking at the call sites of the call to cfil_service_inject_queue(...), there are several places within that file which don't track the return value (representing an error value) and just ignore it. Is that intentional and does that explain this issue?
Does this deserve to be reported as a bug through feedback assistant?
Hi everyone,
I'm experiencing an issue with APNs server notifications where I receive a 404 error when trying to validate the signedPayload from Apple's notification. Below is a sanitized version of my code:
class ServerNotificationAppleController extends Controller
{
// URL for StoreKit keys (Sandbox environment)
private $storeKitKeysUrl = 'https://api.storekit-sandbox.itunes.apple.com/inApps/v1/keys';
public function handleNotification(Request $request)
{
\Log::info($request);
$signedPayload = $request->input('signedPayload');
if (!$signedPayload) {
return response()->json(['error' => 'signedPayload not provided'], 400);
}
// Step 1: Create your JWT token (token creation logic can be in a separate service)
$jwtToken = $this->generateAppleJWT();
// Step 2: Send a request to the StoreKit keys endpoint
$response = Http::withHeaders([
'Authorization' => 'Bearer ' . $jwtToken,
])->get($this->storeKitKeysUrl);
Log::info('Apple Keys Status:', ['status' => $response->status()]);
Log::info('Apple Keys Body:', ['body' => $response->body()]);
if ($response->status() !== 200) {
return response()->json(['error' => "Apple public keys couldn't be retrieved"], 401);
}
$keysData = $response->json();
// Step 3: Validate the signedPayload
$validatedPayload = $this->validateSignedPayload($signedPayload, $keysData);
if (!$validatedPayload) {
return response()->json(['error' => 'Invalid signedPayload'], 400);
}
// Process the validated data as needed
Log::info("Apple Purchase Data:", (array)$validatedPayload);
return response()->json(['message' => 'Notification processed successfully'], 200);
}
private function generateAppleJWT()
{
// API key details (replace placeholders with actual values)
$keyId = config('services.apple.key_id'); // e.g., <YOUR_KEY_ID>
$issuerId = config('services.apple.issuer_id'); // e.g., <YOUR_ISSUER_ID>
$privateKey = file_get_contents(storage_path(config('services.apple.private_key')));
// Set current UTC time and expiration time (20 minutes later)
$nowUtc = Carbon::now('UTC');
$expirationUtc = $nowUtc->copy()->addMinutes(20);
// Create the payload with UTC timestamps
$payload = [
'iss' => $issuerId,
'iat' => $nowUtc->timestamp,
'exp' => $expirationUtc->timestamp,
'aud' => 'appstoreconnect-v1',
'bid' => 'com.example.app', // Replace with your Bundle ID if necessary
];
// Generate the JWT token
return JWT::encode($payload, $privateKey, 'ES256', $keyId);
}
private function validateSignedPayload($signedPayload, $keysData)
{
try {
$jwkKeys = JWK::parseKeySet($keysData);
return JWT::decode($signedPayload, $jwkKeys, ['RS256']);
} catch (\Exception $e) {
Log::error("Apple Purchase Validation Error: " . $e->getMessage());
return null;
}
}
}
I’m particularly puzzled by the fact that I receive a 404 error when trying to retrieve the public keys from the StoreKit keys endpoint. Has anyone encountered this issue or can provide insight into what might be causing the error?
Any help or suggestions would be greatly appreciated. Thanks!
Hello everyone,
I need help updating business information on Apple Maps for locations in Ukraine. Unfortunately, the usual methods, like "Report an Issue" in the Maps app or using Apple Business Connect, don’t seem to be working properly for Ukrainian businesses.
Many locations have outdated or missing details, which is frustrating for both business owners and customers. Given the current situation, keeping information accurate is more important than ever.
Has anyone successfully updated business listings in Ukraine recently? If so, could you share the process or any contacts that might help? Any advice would be greatly appreciated!
Thanks in advance!
Topic:
App & System Services
SubTopic:
Maps & Location
Tags:
Apple Business Manager
Maps and Location
I have a renewing monthly subscription in my app and recently added upgrade possibilities to yearly and 6 month subscriptions. Those new subscriptions were reviewed, approved and published to App Store.
I'm showing a modal for users in the app from where they can upgrade their subscription. Upgrading was tested with real devices on Sandbox and TestFlight. There has been successful purchases through the in app modal in production app, and directly upgrading from App Store.
However, for some users there seems to happen a failed transaction with paymentCancelled error code during the upgrade. The IAP is still successful, their subscription is upgraded and they haven't voluntarily canceled the IAP. The localized description of the error is "Toimintoa ei voitu suorittaa. (Virhe 2 kohteessa SKErrorDomain.)" which translates to "The operation could not be completed. (Error 2 in SKErrorDomain.)"
These users have various iPhones (iPhone 12 Pro, iPhone 14 Pro, iPhone 15 Pro, iPhone 16 Pro) with up to date iOS versions (>= 18.3.1).
I'm receiving DID_CHANGE_RENEWAL_PREF (UPGRADE) server notification of these purchases on my server.
I haven't been able to reproduce this error myself.
Any ideas why StoreKit might fail the transaction with paymentCancelled error but still successfully upgrade the subscription?
Topic:
App & System Services
SubTopic:
StoreKit
In my case, when two functions that start each Live Activity(not connected each other) are performed in LiveActivityIntent's perform(), it seems that only one will start.
(It's the same to start independently with two Task{})
And, set one to 'opensIntent' and separate it by opening another LiveActivityIntent, the result is same.
Also, every time I tap the Intent directly in the shortcut app, one activity will end within a matter of seconds, even if there are two for a while.
But, If openAppWhenRun to true, it seem to works without any problems.
I would appreciate it if you could give me a tip to fix this problem.
I'm working on adding a single Non-Consumable In-App purchase to my app. Essentially a "try before you buy" type thing. Limited functionality unless the app is purchased.
I am currently testing this using Xcode and the Manage StoreKit Transactions window. So far most everything appears to be working except for declined pending transactions.
If I set Ask to Buy to Enabled, the Ask Permission (for parent or guardian) dialog appears. After pressing the Ask button, I see a transaction listed as Pending Approval. If I Approve the transaction, then my app is notified and all is well.
However, if I Decline the transaction then my app is not notified. Is that normal?
Also, how do I (i.e. the app) know that there is a pending transaction?
Topic:
App & System Services
SubTopic:
StoreKit
We had a question that came up when we comparing data from WeatherKit to other sources - WeatherKit visibility was well beyond the boundaries we had historically, even from Darksky. That raises two questions:
is visibility actually in meters like the docs say?
is this visibility at ground level, 500ft, or some other height?
We were seeing visibility numbers of up to 40 miles (after converting the number the API sent to miles), where all of our other sources are usually within 10 miles
I've discovered a bug in the Phone app on iOS related to how long verdicts are displayed.
When a call is identified by a third-party Caller ID app, long verdicts display correctly during the call (they auto-scroll) and in the call log (with an ellipsis at the end). However, on the call details screen, the text is strangely truncated - showing only the beginning of the string and the last word.
For testing, I used this verdict: "Musclemen grow on trees. They can tense their muscles and look good in a mirror. So what? I'm interested in practical strength that's going to help me run, jump, twist, punch."
I'll attach a screenshots demonstrating the problem:
Hi Apple Developers,
I am currently working on a message filtering application and facing issues specifically with filtering RCS (Rich Communication Services) messages. To debug this, I created a sample app that consistently categorizes all incoming messages as "junk." However, the filtering behaviour is inconsistent and not functioning as expected.
Here are the key issues observed during testing on iOS versions 18.2.1 and 18.3:
Inconsistent Filtering Behavior:
When a message is received from an unknown number, it sometimes gets moved to the Junk folder momentarily but is then immediately moved back to the main Messages inbox.
In some cases, the message does not get moved to the Junk folder at all, despite the app returning the verdict as "junk."
Duplicate Contact Tiles:
The Messages app displays two separate conversation tiles for the same mobile number, which is unexpected behavior.
I have attached both a sample app and a screen recording that clearly demonstrates the issue. The recording shows that the app categorizes messages as junk, yet they still end up in the main Messages inbox.
For reference, my carrier partner is T-Mobile. Please let me know if you need any additional information to investigate this issue further.
Looking forward to your insights and guidance.
Best regards,
Rijul Singhal
Hi,
To ensure the issue is not caused by an error within your app or web service request, please review the following documentation:
Wallet Passes
Wallet Developer Guide
If the resources above don’t help identify the cause of the error, please provide more information about your app or web services to get started. To prevent sending sensitive credentials in plain text, create a report in Feedback Assistant to share the details requested below. Additionally, if the error is something we need to investigate further, the appropriate engineering teams also have access to the same information and can communicate with you directly within Feedback Assistant for more information, as needed. Please follow the instructions below to submit your report.
For issues occurring with your native app or web service, perform the following steps:
Install the Wallet profile on your iOS or watchOS device.
Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video.
Gather a sysdiagnose on the same iOS or watchOS device.
Create a Feedback Assistant report with the following information:
The serial number of the device.
Open Settings > General > About > Serial Number (tap and hold to copy).
The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string.
Open Settings > General > About > SEID (tap and hold to copy).
The sysdiagnose gathered after reproducing the issue.
The .pkpass file(s), pass signing certificate(s) and pass type identiifier(s) (optional).
The timestamp of when the issue was reproduced.
Screenshots or videos of errors and unexpected behaviors (optional).
Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or pass type identifier in the Safari Web Inspector. See Inspecting Safari on macOS to learn more.
Submitting your feedback
Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Wallet pass implementation.
After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your web implementation, a configuration issue within your developer account, or an underlying system bug.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
I am developing an app that can help users disable selected apps at a specified time, so that users can get away from their phones and enjoy real life.
Here is my data structure:
extension ActivityModel {
@NSManaged public var id: UUID
@NSManaged public var name: String
@NSManaged public var weeks: Data
@NSManaged public var weekDates: Data
@NSManaged public var appTokens: Data
}
Among them, weeks is of [Bool] type, indicating which weeks from Sunday to Saturday are effective; weekDates is of [[Date,Date]] type, indicating the effective time period; appTokens is of Set type, indicating the selected apps。
At the beginning, I will open a main monitor:
let deviceActivityCenter = DeviceActivityCenter()
do{
try deviceActivityCenter.startMonitoring(
DeviceActivityName(activityModel.id),
during: DeviceActivitySchedule(
intervalStart: DateComponents(hour: 0,minute: 0,second: 0),
intervalEnd: DateComponents(hour: 23,minute: 59,second: 59),
repeats: true
)
)
}catch {
return false
}
Since the time range may be different every day, I will start the sub-monitoring of the day every time the main monitoring starts:
override func intervalDidStart(for activity: DeviceActivityName) {
super.intervalDidStart(for: activity)
if activity.rawValue.hasPrefix("Sub-") {
ActivityModelManager.disableApps(
Tools.getUUIDFromString(activity.rawValue)
)
return
}
let weekIndex = Calendar.current.component(.weekday, from: .now)
let weeks = ActivityModelManager.getWeeks(activity.rawValue)
if weeks[weekIndex] {
let weekDates =
ActivityModelManager.getWeekDates(activity.rawValue)
let deviceActivityCenter = DeviceActivityCenter()
do{
try deviceActivityCenter.startMonitoring(
DeviceActivityName("Sub-" + activityModel.id),
during: DeviceActivitySchedule(
intervalStart: getHourAndMinute(weekDates[weekIndex][0]),
intervalEnd: getHourAndMinute(weekDates[weekIndex][1]),
repeats: false
)
)
}catch {
return
}
}esle {
return
}
}
I will judge whether it is main monitoring or sub monitoring based on the different activity names.
When the sub-monitor starts, I will get the bound application and then disable it:
static func disableApps(_ id : UUID){
let appTokens = ActivityModelManager.getLimitAppById(id)
let name = ManagedSettingsStore.Name(id.uuidString)
let store = ManagedSettingsStore(named: name)
store.shield.applications = appTokens
return
}
When the child monitoring is finished, I resume the application:
static func enableApps(_ id : UUID){
let name = ManagedSettingsStore.Name(id.uuidString)
let store = ManagedSettingsStore(named: name)
store.shield.applications = []
}
The above is my code logic.
When using DeviceActivityMonitorExtension, I found the following problems:
intervalDidStart may be called multiple times, resulting in several sub-monitors being started.
After a period of time, the monitoring is turned off.
The static methods enableApps and disableApps are sometimes not called
Topic:
App & System Services
SubTopic:
General
Tags:
Family Controls
Device Activity
Screen Time
Entitlements
After the user initiates the subscription payment, the SDK returns an error type: user cancels. When the user initiates the payment again, Apple will deduct the payment twice and successfully deduct the previously cancelled SKU. This is a recent occurrence with a large amount of data, and the app has not been upgraded in any way. We need to seek help. Thank you
Topic:
App & System Services
SubTopic:
StoreKit
Hello,
I am unable to figure out how I tell the FamilyActivityPicker whether it should show apps installed on my personal device (to be used with AuthorizationCenter.shared.requestAuthorization(for: .individual)) or apps installed on my child’s device (authenticated their phone via AuthorizationCenter.shared.requestAuthorization(for: .child)).
Is there any parameter or SwiftUI modifier I need to apply?
Otherwise, how does the user or the app know which token belongs to them and which token belongs to their child’s device?
Radar: FB17020977
Thanks a lot for your help!
We have a user that has an active subscription according to the appstore in our product but it is registering as expired. Hitting the subscribe button in the SwiftUI SK2 dialog does nothing, meaning, nothing happens.
Any ideas?
Topic:
App & System Services
SubTopic:
StoreKit
Apple multi-peer with 12 devices is unstable. Dear All,
Has anyone tried Apple multi-peer with 12 devices connected? We are building an application relying on multi-peer where 12 Ipads will be updating data and each device needs to share data between. Can anyone tell me if we can use multi-peer framework for connecting 12 devices in the multi-peer network? We are facing stability problems in the connection when we connect 12 devices in the network.
I'm receiving the following error when attempting to validate an in‑app purchase receipt:
Certificate verification failed at depth 0 : forge.pki.UnknownCertificateAuthority
Certificate chain validation failed: Certificate is not trusted.
This error occurs during the certificate chain validation process of the receipt's PKCS#7 container. My implementation uses node‑forge to decode the receipt, extract the embedded certificate chain, and verify that the chain properly links from the leaf certificate (which directly signed the receipt) through the intermediate certificate to the trusted Apple Inc. Root certificate.
What the Error Indicates:
"UnknownCertificateAuthority" at depth 0:
This suggests that the leaf certificate in the receipt is not being recognized as part of a valid chain because it cannot be linked back to a trusted root in my CA store.
"Certificate chain validation failed: Certificate is not trusted":
This means that the entire certificate chain does not chain up to a trusted certificate authority (in this case, the Apple Inc. Root certificate) as expected.
Steps Taken:
I verified that the receipt is a valid PKCS#7 container.
I extracted the certificate chain from the receipt. However, the receipt only provided the leaf certificate.
I manually added the intermediate certificate (AppleWWDRCAG5.pem) to complete the chain.
I loaded the official Apple Inc. Root certificate (AppleIncRootCertificate.pem) into my CA store.
Despite these steps, the validation still fails at depth 0, indicating that the leaf certificate is not recognized as being issued by a trusted authority.
Request for Assistance:
Could you please help clarify the following points:
Is the certificate chain for receipts (leaf → intermediate → Apple Inc. Root) as expected, or has there been any change in the chain that I should account for?
Is there a recommended or updated intermediate certificate I should be using for receipt validation?
Are there known issues or recent changes on Apple's side that might cause the leaf certificate to not be recognized as part of a valid chain?
Any guidance to resolve this certificate chain validation error would be greatly appreciated.
This week I’m handling a DTS incident from a developer who wants to escalate privileges in their app. This is a tricky problem. Over the years I’ve explained aspects of this both here on DevForums and in numerous DTS incidents. Rather than do that again, I figured I’d collect my thoughts into one place and share them here.
If you have questions or comments, please start a new thread with an appropriate tag (Service Management or XPC are the most likely candidates here) in the App & System Services > Core OS topic area.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
BSD Privilege Escalation on macOS
macOS has multiple privilege models. Some of these were inherited from its ancestor platforms. For example, Mach messages has a capability-based privilege model. Others were introduced by Apple to address specific user scenarios. For example, macOS 10.14 and later have mandatory access control (MAC), as discussed in On File System Permissions.
One of the most important privilege models is the one inherited from BSD. This is the classic users and groups model. Many subsystems within macOS, especially those with a BSD heritage, use this model. For example, a packet tracing tool must open a BPF device, /dev/bpf*, and that requires root privileges. Specifically, the process that calls open must have an effective user ID of 0, that is, the root user. That process is said to be running as root, and escalating BSD privileges is the act of getting code to run as root.
IMPORTANT Escalating privileges does not bypass all privilege restrictions. For example, MAC applies to all processes, including those running as root. Indeed, running as root can make things harder because TCC will not display UI when a launchd daemon trips over a MAC restriction.
Escalating privileges on macOS is not straightforward. There are many different ways to do this, each with its own pros and cons. The best approach depends on your specific circumstances.
Note If you find operations where a root privilege restriction doesn’t make sense, feel free to file a bug requesting that it be lifted. This is not without precedent. For example, in macOS 10.2 (yes, back in 2002!) we made it possible to implement ICMP (ping) without root privileges. And in macOS 10.14 we removed the restriction on binding to low-number ports (r. 17427890). Nice!
Decide on One-Shot vs Ongoing Privileges
To start, decide whether you want one-shot or ongoing privileges. For one-shot privileges, the user authorises the operation, you perform it, and that’s that. For example, if you’re creating an un-installer for your product, one-shot privileges make sense because, once it’s done, your code is no longer present on the user’s system.
In contrast, for ongoing privileges the user authorises the installation of a launchd daemon. This code always runs as root and thus can perform privileged operations at any time.
Folks often ask for one-shot privileges but really need ongoing privileges. A classic example of this is a custom installer. In many cases installation isn’t a one-shot operation. Rather, the installer includes a software update mechanism that needs ongoing privileges. If that’s the case, there’s no point dealing with one-shot privileges at all. Just get ongoing privileges and treat your initial operation as a special case within that.
Keep in mind that you can convert one-shot privileges to ongoing privileges by installing a launchd daemon.
Just Because You Can, Doesn’t Mean You Should
Ongoing privileges represent an obvious security risk. Your daemon can perform an operation, but how does it know whether it should perform that operation?
There are two common ways to authorise operations:
Authorise the user
Authorise the client
To authorise the user, use Authorization Services. For a specific example of this, look at the EvenBetterAuthorizationSample sample code.
Note This sample hasn’t been updated in a while (sorry!) and it’s ironic that one of the things it demonstrates, opening a low-number port, no longer requires root privileges. However, the core concepts demonstrated by the sample are still valid.
The packet trace example from above is a situation where authorising the user with Authorization Services makes perfect sense. By default you might want your privileged helper tool to allow any user to run a packet trace. However, your code might be running on a Mac in a managed environment, where the site admin wants to restrict this to just admin users, or just a specific group of users. A custom authorisation right gives the site admin the flexibility to configure authorisation exactly as they want.
Authorising the client is a relatively new idea. It assumes that some process is using XPC to request that the daemon perform a privileged operation. In that case, the daemon can use XPC facilities to ensure that only certain processes can make such a request.
Doing this securely is a challenge. For specific API advice, see this post.
WARNING This authorisation is based on the code signature of the process’s main executable. If the process loads plug-ins [1], the daemon can’t tell the difference between a request coming from the main executable and a request coming from a plug-in.
[1] I’m talking in-process plug-ins here. Plug-ins that run in their own process, such as those managed by ExtensionKit, aren’t a concern.
Choose an Approach
There are (at least) seven different ways to run with root privileges on macOS:
A setuid-root executable
The sudo command-line tool
The authopen command-line tool
AppleScript’s do shell script command, passing true to the administrator privileges parameter
The osascript command-line tool to run an AppleScript
The AuthorizationExecuteWithPrivileges routine, deprecated since macOS 10.7
The SMJobSubmit routine targeting the kSMDomainSystemLaunchd domain, deprecated since macOS 10.10
The SMJobBless routine, deprecated since macOS 13
An installer package (.pkg)
The SMAppService class, a much-needed enhancement to the Service Management framework introduced in macOS 13
Note There’s one additional approach: The privileged file operation feature in NSWorkspace. I’ve not listed it here because it doesn’t let you run arbitrary code with root privileges. It does, however, have one critical benefit: It’s supported in sandboxed apps. See this post for a bunch of hints and tips.
To choose between them:
Do not use a setuid-root executable. Ever. It’s that simple! Doing that is creating a security vulnerability looking for an attacker to exploit it.
If you’re working interactively on the command line, use sudo, authopen, and osascript as you see fit.
IMPORTANT These are not appropriate to use as API. Specifically, while it may be possible to invoke sudo programmatically under some circumstances, by the time you’re done you’ll have code that’s way more complicated than the alternatives.
If you’re building an ad hoc solution to distribute to a limited audience, and you need one-shot privileges, use either AuthorizationExecuteWithPrivileges or AppleScript.
While AuthorizationExecuteWithPrivileges still works, it’s been deprecated for many years. Do not use it in a widely distributed product.
The AppleScript approach works great from AppleScript, but you can also use it from a shell script, using osascript, and from native code, using NSAppleScript. See the code snippet later in this post.
If you need one-shot privileges in a widely distributed product, consider using SMJobSubmit. While this is officially deprecated, it’s used by the very popular Sparkle update framework, and thus it’s unlikely to break without warning.
If you only need escalated privileges to install your product, consider using an installer package. That’s by far the easiest solution to this problem.
Keep in mind that an installer package can install a launchd daemon and thereby gain ongoing privileges.
If you need ongoing privileges but don’t want to ship an installer package, use SMAppService. If you need to deploy to older systems, use SMJobBless.
For instructions on using SMAppService, see Updating helper executables from earlier versions of macOS.
For a comprehensive example of how to use SMJobBless, see the EvenBetterAuthorizationSample sample code. For the simplest possible example, see the SMJobBless sample code. That has a Python script to help you debug your setup. Unfortunately this hasn’t been updated in a while; see this thread for more.
Hints and Tips
I’m sure I’ll think of more of these as time goes by but, for the moment, let’s start with the big one…
Do not run GUI code as root. In some cases you can make this work but it’s not supported. Moreover, it’s not safe. The GUI frameworks are huge, and thus have a huge attack surface. If you run GUI code as root, you are opening yourself up to security vulnerabilities.
Appendix: Running an AppleScript from Native Code
Below is an example of running a shell script with elevated privileges using NSAppleScript.
WARNING This is not meant to be the final word in privilege escalation. Before using this, work through the steps above to see if it’s the right option for you.
Hint It probably isn’t!
let url: URL = … file URL for the script to execute …
let script = NSAppleScript(source: """
on open (filePath)
if class of filePath is not text then
error "Expected a single file path argument."
end if
set shellScript to "exec " & quoted form of filePath
do shell script shellScript with administrator privileges
end open
""")!
// Create the Apple event.
let event = NSAppleEventDescriptor(
eventClass: AEEventClass(kCoreEventClass),
eventID: AEEventID(kAEOpenDocuments),
targetDescriptor: nil,
returnID: AEReturnID(kAutoGenerateReturnID),
transactionID: AETransactionID(kAnyTransactionID)
)
// Set up the direct object parameter to be a single string holding the
// path to our script.
let parameters = NSAppleEventDescriptor(string: url.path)
event.setDescriptor(parameters, forKeyword: AEKeyword(keyDirectObject))
// The `as NSAppleEventDescriptor?` is required due to a bug in the
// nullability annotation on this method’s result (r. 38702068).
var error: NSDictionary? = nil
guard let result = script.executeAppleEvent(event, error: &error) as NSAppleEventDescriptor? else {
let code = (error?[NSAppleScript.errorNumber] as? Int) ?? 1
let message = (error?[NSAppleScript.errorMessage] as? String) ?? "-"
throw NSError(domain: "ShellScript", code: code, userInfo: nil)
}
let scriptResult = result.stringValue ?? ""
Revision History
2025-03-24 Added info about authopen and osascript.
2024-11-15 Added info about SMJobSubmit. Made other minor editorial changes.
2024-07-29 Added a reference to the NSWorkspace privileged file operation feature. Made other minor editorial changes.
2022-06-22 First posted.
Hi,
In my application I am donating AppIntent instances that I have to the system using the donate() API. I recently came across this article that talks about deleting donations but it does not mention how to handle AppIntent instances.
I am wondering when working with dynamic AppIntents (with different properties that can change in the future), should I be worried about "outdated" donated AppIntent instances? And if yes how can I delete previously donated AppIntent instances.