We created apps for many credit unions in Canada. Some of those apps has the feature to directly add users' debit cards to Apple Wallet (which is called by Apple as "in-app provisioning"). The feature has been working fine for at least 6 years for many credit unions. Recently, after updating one of those existing apps, we found out that the in-app provisioning is no longer working. Found it very strange, as we didn't touch the code base related to this feature for a very long time. One thing we found out is that the option to add in-app provisioning entitlement is missing during generating "provisioning profile" for the app. Is this a misconfiguration by App? Or do we need to request for additional entitlement migration as mentioned in the page: https://developer.apple.com/help/account/reference/provisioning-with-managed-capabilities ? Apple, please help, it's rather urgent.

Dear Apple： We found that after mirroring an iPhone and a Mac, calling the NEHotspotConfigurationManager applyConfiguration interface on the iPhone fails to connect to Wi-Fi. Are there any restrictions on using this interface in mirror mode?

I am facing an issue with Apple Pay js while doing the integration we are using reference https://applepaydemo.apple.com/apple-pay-js-api In this I can generate the merchantSession correctly But when I pass that merchantSession in session.completeMerchantValidation(merchantValidation) as per documentation It is getting failed and also no appropriate error is being shown in the console

https://developer.apple.com/documentation/apple_pay_on_the_web/applepaypaymentrequest/3955945-multitokencontexts According to this document, I know that I can initialize a multiTokenContexts when initializing ApplePayPaymentRequest. But I am now facing a tricky problem. If the user's order does not require multiTokenContexts, then I will not initialize this field when I first make ApplePayPaymentRequest. When the user is in the payment process, I may update multiTokenContexts. But this time, the update is not allowed, ApplePay will be cancelled and the payment will be closed. For example, if the user's address in Apple Pay is different, I need to update multiTokenContexts to support the payment of goods to multiple merchants, which will generate an update of multiTokenContexts. MultiTokenContexts can be updated in the onshippingcontactselected method. https://developer.apple.com/documentation/apple_pay_on_the_web/applepaysession/1778009-onshippingcontactselected My question is that from the beginning, there was no multiTokenContexts to update multiTokenContexts in onshippingcontactselected, which would cause the user to close the payment and need to manually click to pay again. This user experience is not very friendly. Is there a better way for me to go from no multiTokenContexts to multiTokenContexts without interrupting the user's payment process?

Live Activity Start Token not generating after certain days of usage. We have implemented Live Activity feature where the initial activity is launched by our backend. But to start that first live activity I need push to start token which is generating for few days but all of sudden after certain days it stops generating. Currently we are in development phase so we test it on multiple devices and multiple time we are doing install and uninstall. STEPS TO REPRODUCE Install the app Start token gets generated which is sent to our server After certain duration server sends the first live activity using that token user opens the app then we receive the updated token and send that token to server server uses that updated token to further update the live activity. All this works fine. But after a week of usage we are observing that we stop getting start token from APNS. Not sure where exactly the thing is breaking. We have tried with different devices and different bundle identifiers but behaviour is same for all. func generateStartToken() { Task.detached { [weak self] in guard let self else { return } await self.observeActivityPushTokenAndState() for await data in ActivityKit.Activity<LiveActivityAttribute>.pushToStartTokenUpdates { let token = data.map { String(format: "%02x", $0) }.joined() print("Activity Start token: ", token) } } } func observeActivityPushTokenAndState() { Task.detached { for await activity in ActivityKit.Activity<LiveActivityAttribute>.activityUpdates { Task { for await tokenData in activity.pushTokenUpdates { let updatedToken = tokenData.map { String(format: "%02x", $0) }.joined() print("Activity Update token: ", updatedToken) } } Task { for await content in activity.contentUpdates { let updatedContent = content.state print("Activity Updated: ", updatedContent) } } } } }

Hi, I’m using a Local Push Connectivity Extension and encountering an issue with DispatchSourceTimer. In my extension, I create a DispatchSourceTimer that is supposed to fire every 1 second. It works as expected at first. However, when the app is in the foreground and the device is locked, the timer eventually stops firing after 1–3 hours. The extension process is still alive, and no errors are thrown Has anyone experienced this behavior? Is this a known limitation for timers inside NEAppPushProvider, or is the extension being deprioritized silently by the system? Any insights or suggestions would be greatly appreciated. Thanks!

My ASA file is located here https://staging.docyt.com/apple-appsite-association It downloads fine. It does not have .json extension and neither does it reside inside the ./well-known folder. Should it work? Because opening the link https://staging.docyt.com/reset-password is not opening the app installed via TestFlight . Installing via XCode however works fine. Please help

I've been reading this question: https://developer.apple.com/forums/thread/701945 and watching the videos on background tasks But can't arrive to a concrete solution. Q1: Are there any tips (or sample app) on how to handle a launch in background in a streamlined way? How to have a shared code that is ran for both 'launch in background' & 'launch in foreground'? Specifically the case I'm talking about is: You set up some observance of some OS callback at a Foo screen of your app. Example app should request and then send push-to-start live activity tokens to server. Or setup location tracking. App is then suspended and then later terminated but is eligible for relaunch App is then launched in background because it has requested a push-to-start live activity token or an update for location tracking. User DOES NOT go back to screen Foo. So at this point app is no longer tracking / listening to updates for token update or location changes. How should I architecture my code for this? I'm trying to see if there's a an approach where I can avoid having multiple places in code where I do the same thing. Currently what I'm doing is as such: Q2: Is it then correct to say that anytime you've launched your app, whether it's in foreground or background then you must immediately match 'all observations done by the previous app launch'? Like store items in UserDefaults and upon launch retrieve them and do: handleGeneralAppLaunchFlow() // ALSO if defaults.contains("didLastLaunchSetupLiveActivtiyTokenObservance") { for await ptsToken in Activity<EmojiRangers> .pushToStartTokenUpdates { ... } } if defaults.contains("didLastLaunchSetupLocationTracking") { locationManager = CLLocationManager() locationManager?.delegate = itsDelegate locationManager?.allowsBackgroundLocationUpdates = true locationManager?.showsBackgroundLocationIndicator = true locationManager?.startUpdatingLocation() } // Other checks for prior observance setup Q3: Actually I think even if app is launched in foreground then because you may not end up at screen Foo again, then you must setup things regardless of app state and just based on prior observations set. Right? Q4: And then later if the user ever made it again to screen Foo, then we just skip the re-do of the observance, or maybe to just keep things simple, we'd just redo without over-engineering things? I tried to mark my questions with Q1- Q4.

Hi, We are using Firebase to configure APNs (Apple Push Notification Service) for sending push notifications. During local testing, the push notifications are received properly when the app is in the foreground or background. After TestFlight testing and passing review, we found that when the app is installed using the developer's Apple ID, push notifications are received correctly whether the app is in the foreground or background. However, when the app is provided to other testers (using non-developer Apple IDs), notifications are only received when the app is in the foreground, and they are not triggered when the app is in the background or inactive state. Request for Assistance: Why, after TestFlight testing and passing review, does the app receive push notifications properly in the background when installed using the developer's Apple ID, but on other testers' devices, notifications are not received when the app is in the background? Are there any differences in Apple ID types or device configurations (developer ID vs. regular tester ID) that could affect the behavior of push notifications in the background mode? Do we need to apply any additional settings or permissions, particularly for handling background push notifications? Are there any iOS version or device-specific limitations that could impact the proper delivery of background push notifications? Additional Information: The app is properly configured for APNs, and push notifications are being sent via Firebase. In the developer's Apple ID test environment, the app receives push notifications properly whether it is in the foreground or background. On other testers' devices, push notifications are only received when the app is in the foreground, and they are not received when the app is in the background. All test devices have been verified to have notification permissions enabled, and Firebase configuration is correct.

I'm developing an iPad app and encountered a strange issue with external Bluetooth keyboards. Issue: I have a Bluetooth keyboard set to JIS layout in Settings > General > Keyboard > Hardware Keyboard > Keyboard Type. If I connect the keyboard before launching the app, everything works fine, and the input follows the JIS layout. However, if I launch the app first and then turn on the Bluetooth keyboard, the input behaves as if the keyboard is in ANSI layout, even though the settings still show JIS. It seems like iPadOS defaults to ANSI if no external keyboard is connected when the app starts, and later connections do not update the layout properly. Has anyone encountered a similar issue, and is there a programmatic way to ensure that the correct keyboard layout is applied after the keyboard is connected? Any help or insights would be greatly appreciated!

I've successfully started the Live Caller ID Lookup example and initialized the PIRService. I added several identities to the input.txtpb file, some with block: true and others with block: false. Here is the file but modified phone digits: identities { key: "+40790123123" value { name: "Blocking 1" cache_expiry_minutes: 7 block: true } } identities { key: "+972526111111" value { name: "Blocking 2" cache_expiry_minutes: 7 block: true } } identities { key: "+123" value { name: "Adam" cache_expiry_minutes: 8 block: false category: IDENTITY_CATEGORY_PERSON } } identities { key: "+972526111112" value { name: "Identified Business Name 1" cache_expiry_minutes: 1 block: false category: IDENTITY_CATEGORY_BUSINESS } } identities { key: "+972526111113" value { name: "Identified Business Name 2" cache_expiry_minutes: 1 block: false category: IDENTITY_CATEGORY_BUSINESS } } The main issue is that only the number marked as +40790123123 was actually blocked, while "Blocking 2" appeared as identified contacts with their assigned name displayed. Notably, the only blocked number was a foreign number with a different country code than the number being called. The other numbers belonged to the same country. Can someone clarify whether this is a bug in the example project or an issue with the data file?

Issue: We noticed inconsistent BLE device discovery times (ranging from 0.5s to 1.5s) despite the peripheral advertising at 2Hz (500ms interval). Questions: Does iOS regulate the BLE scan interval or duty cycle internally? If yes, what factors affect this behavior (e.g., foreground/background state, connected devices)? Are there recommended practices to reduce discovery latency for peripherals with fixed advertising intervals? Is there a way to configure scan parameters (e.g., scan window/interval) programmatically, similar to Android's BluetoothLeScanner? Test Context: Device: iPhone 13 mini (iOS 17.6.1) Code: CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true])

Hi everyone, I’m developing a screen-time and focus app that uses Apple’s Family Controls framework to block distracting apps and reward users through a gamified experience. Apple approved Family Controls (Distribution) for the main app identifier, but they did not approve the required extension target (which implements DeviceActivityMonitor, required for the framework to function). Because of this, I can’t archive or upload the app to TestFlight — and I’ve been stuck in limbo for over 2 months. This is severely delaying my launch. The app works perfectly, but I can’t release it because the extension wasn’t included in the entitlement approval. Has anyone else run into this with Family Controls? Is there any known way to escalate or fast-track approval for additional app IDs or targets? Would really appreciate any help, advice, or hacks. 🙏 Thanks, Enzer

When using the old withTaskCancellationHandler(operation:onCancel:isolation:) to run background tasks, you were notified that the background task gets cancelled via the handler being called. SwiftUI provides the backgroundTask(_:action:) modifier which looks quite handy. However how can I check if the background task will be cancelled to avoid being terminated by the system? I have tried to check that via Task.isCancelled but this always returns false no matter what. Is this not possible when using the modifier in which case I should file a bug report? Thanks for your help

Hello Developers! I am trying to run a test In-App Purchase (IAP) for a renewable subscription product in the sandbox environment. I have set up everything required for sandbox testing, but it’s unclear whether the subscription product needs to be pre-approved by Apple for testing. If approval is required, I have already added the necessary metadata, but the status still shows "Ready for Submit." Additionally, when I save the page, a "Submit for Review" button briefly appears for a fraction of a second on the subscription page before disappearing. Is this button missing, or is there a known issue with this process? This is my first time running this test, and I would appreciate any pointers or suggestions. Thanks!

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?

Why did my sandbox test fail due to not being able to obtain the product list?

Ever since the last update i have issues with my camera app. Sometimes when I open the app the forward facing cameras don’t work and it’s just a Black screen. I also get a warning that I may not have genuine iPhone parts installed. I have to reboot the phone every time just to have it app function again. It’s annoying. Please fix this. I never had any issues with the camera or its app up until after the update.

Hello all, I have run into a weird situation in my watchOS app with a companion iOS app. Issue: Watch fails to receive sendMessage string sent from phone while watch is in foreground. This is not consistent and seems to happen randomly under certain conditions. Order of operations: User Opens phone app & watch app -> user presses "sendMessage" button, func is called -> watch does not receive message while in foreground Condition explanation: To my knowledge, without a HealthKit workout session active, the apple watch is not available to receive messages (using any internal library transmission type) from its iOS companion app while the watch screen is not in the foreground (i.e. inactive). However, my issue is that sometimes, while the watch IS in the foreground, it does not receive the companion app's message. Additionally, this is not resolved by force quitting both iOS and watchOS apps. The only way I have gotten this issue to go away is by restarting both the phone and the watch. Again, it is not a consistent behavior and seemingly happens randomly. This behavior has been observed across multiple different beta testers on different hardware. This is only apparent when transmitting from Phone -> Watch. I have not experienced any transmission issues when transmitting Watch -> Phone. My team and I have speculated that it could be an issue with WCSession.isReachable returning true before we transmit the message but changing to false before the hardware actually transmits. However, this wouldn't explain why the watch would not be available while in the foreground. This is just a preliminary thought. My goal in posting on here is to see if anyone else has experienced this, or if it's a known bug. All message protocols have been coded to follow Apple's WCSession documentation as closely as possible. Hardware specs: Watch Model: A2093 (series 5) WatchOS ver: 10.6.1 Phone: MU693LL/A (15 pro max) iOS ver: 18.3.2 XCode ver: 16.0

Good morning, I'm encountering reliability issues with DDC/CI communication when using USB-C connection. Initially using ddc-hi (which uses this package), I ran into several issues that I've partially resolved but still need help addressing. Environment OS: macOS Display Connection: USB-C for _ in 1 ... (numOfRetryAttemps ?? 4) + 1 { for _ in 1 ... max((numOfWriteCycles ?? 2) + 0, 1) { usleep(writeSleepTime ?? 10000) success = IOAVServiceWriteI2C(service, UInt32(ARM64_DDC_7BIT_ADDRESS), UInt32(dataAddress), &packet, UInt32(packet.count)) == 0 } if !reply.isEmpty { usleep(readSleepTime ?? 50000) if IOAVServiceReadI2C(service, UInt32(ARM64_DDC_7BIT_ADDRESS), 0, &reply, UInt32(reply.count)) == 0 { success = self.checksum(chk: 0x50, data: &reply, start: 0, end: reply.count - 2) == reply[reply.count - 1] } } if success { return success } usleep(retrySleepTime ?? 20000) } The result from IOAVServiceReadI2C is not reliable in some cases. Do we have any other API to get VCP code from monitor like Intel version done. The previous APIs weren’t working anymore on the M1 GPU, the IOFramebuffer was now an IOMobileFramebuffer and the IOI2C* functions weren’t doing anything.