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.

it seems that is going to the appstore to find the app to execute the share but my app is not in the appstore yet. I am using a sandboxed user and a non sandboxed user, I have tried real phones connected to xcode and simulator same effect, looking for how to test my ckshare in testflight thanks

Hello everyone, I’m experiencing a visual issue when dismissing a sheet on iOS 26. I’m using the same implementation shown in the official Apple documentation. While testing, I noticed that some apps do not exhibit this behavior. However, when running this code on iOS 26, the issue consistently occurs. Issue description: The sheet dismisses abruptly A white screen briefly appears for a few milliseconds and then disappears This results in a noticeable visual glitch and a poor user experience I tested the exact same code on iOS 18, where the sheet dismisses smoothly and behaves as expected, without any visual artifacts. Has anyone else encountered this issue on iOS 26? Is this a known bug, or is there a recommended workaround? Any insights would be greatly appreciated. Thank you.

I'm seeking clarification on how Requirement 4.1 ("Card Issuers with a Mobile App must support In-App provisioning") applies when the card issuer uses a third-party mobile banking platform rather than a self-developed app. Our situation: We are a small credit union (the card issuer) Our mobile banking app is provided by a third-party digital banking vendor (white-label, but branded with our name) Card processing is handled by a separate vendor The ambiguity: The Apple Pay Specifications define "Card Issuer Mobile App" as: "The Card Issuer-branded, iOS software application made available on a Device that is used by such Card Issuer's customers to manage, administer, or use Cards." Our mobile banking app meets this definition—it's branded with our name and used by our members to manage their accounts and cards. However, we don't develop or directly control the app; our digital banking vendor does. The webinar FAQ stated: "Do we have to implement in-app provisioning? Yes, if you have an app." Our digital banking vendor interprets this as not applying to them because they are "not the issuer." They've stated: "Apple's requirements are at the card-processor level... our credit unions and, by extension, we are not required to support Apple Pay's in-app provisioning." Our card processor has indicated they will support in-app provisioning integrations but notes "this would be digital provisioning and we would need the digital banking vendor to work with us to enable." Specific questions: When a card issuer uses a third-party mobile banking app (branded for the issuer but developed/maintained by a vendor), does Requirement 4.1 apply? If yes, who bears compliance responsibility—the issuer, the mobile app vendor, or both? If the mobile app vendor does not implement in-app provisioning by January 15, 2026, what is the issuer's exposure? Does the issuer face suspension from the Program due to vendor non-compliance? Is there an alternative compliance path under Requirement 4.8 (Web Provisioning) for issuers whose mobile app vendors cannot deliver in-app provisioning by the deadline? This scenario likely affects hundreds of small financial institutions using shared digital banking platforms. Clarity on vendor vs. issuer responsibility would help the entire ecosystem prepare appropriately. Thank you.

We are a regulated financial institution and Apple Pay issuer seeking clarification on the in-app push provisioning requirement and the January 15, 2026 timeline. Like many community financial institutions: Our mobile banking app is issuer-branded but provided by a third-party vendor Apple Pay enablement and tokenization are handled by a separate card processor While we support Apple’s goals and understand the issuer is ultimately responsible, delivery of in-app provisioning is dependent on third-party vendor roadmaps and cross-vendor integrations that are outside our direct control. Despite active, good-faith efforts with both vendors, current platform constraints make the January 15, 2026 deadline challenging. We would appreciate clarification on: How Apple evaluates compliance when an issuer’s mobile app is built and maintained by a third party Whether any transitional flexibility or phased enforcement is expected for issuers showing documented progress Whether approved web-based provisioning may be acceptable as an interim option How issuers should document due diligence when vendor dependencies delay implementation Additional guidance would help many credit unions and community banks plan appropriately and remain compliant. Thank you for your guidance.

I’m testing auto-renewable subscription purchases in the sandbox environment. When I buy a subscription package using a sandbox test user, I don’t receive any App Store Server Notifications from the sandbox. However, when I use the “Request Test Notification” option in App Store Connect, the notification is received successfully. My sandbox server notification URL is configured correctly and publicly accessible. I also call finishTransaction() after purchase, and the receipt is verified successfully with the sandbox verification endpoint. To further debug, I used the getNotificationHistory API to fetch notifications for yesterday and today (Nov 3–4, 2025). Apple’s API response does not include any notifications or transaction IDs for my today’s purchases (Nov 4, 2025) — even though I can confirm from logs that those transactions were completed and verified successfully. It looks like sandbox purchase notifications are not being sent or logged, even though test notifications work fine. Could someone from Apple please confirm if there’s currently an issue with sandbox server notifications for auto-renewable subscriptions?

Hello, Back in January 2024, I filed a bug report regarding a cache being kept by the macOS Wallpaper Agent. This cache contains every image ever set as a users wallpaper, and at the time the issue was reported, it never cleared, leaving hundreds of gigabytes wasted on users disks in some cases. FB13536275 This issue was ultimately fixed in macOS 15.1 beta 6, and remained fixed for the duration of macOS 15. The fix was excellent - the cache was reduced to storing just 2-3 days worth of images. Sadly, we've discovered that this issue is back in macOS Tahoe. The cache has moved locations, and once again is not clearing. We have filed this bug again, less than a year after it was first fixed: FB20636593 We develop an app called 24 Hour Wallpaper that keeps the wallpaper in sync with the time of day. This necessitates that the app regularly changes the wallpaper, which sadly now results in an infinitely growing and useless cache of BMP files generated by the system. As we waited 10 months for this to get fixed the first time, we expect to wait at least that long to get it fixed again, and have no confidence that it will stay fixed because the last fix lasted less than a year. This leaves us in a bad position, as people can't use our app without the cache growing arbitrarily and ultimately completely filling their disk. We've already had customers call Apple to complain about this, and the good news is that the support agents understand that this is a problem with macOS, not with our app. What we've decided to do is add a feature to the app that monitors the size of this cache and periodically deletes it. We're required to get the users permission the first time to do this, but after that the permission is cached, so the app can keep the cache folder clean regardless of if macOS is doing it's job or not. We haven't seen any side effects or problems as a result of doing this. We've seen other apps like CleanMyMac do this without any problems. We're wondering if there is anything we should be aware of regarding this caches behavior before releasing this flushing feature. Thanks for your time, -josh

Hi everyone, We’re running into a serious issue with App Clip Experience updates not propagating to devices, and I’m hoping someone here has encountered (or solved) this before. Problem Once an App Clip Experience is created and used on devices, subsequent updates made in App Store Connect do not reflect on any devices, even after a long period of time. We’ve tried: • Updating the App Clip Experience URL (adding utm parameters, for example, utm_source and scanning via QR code) • Modifying Experience metadata/content • Waiting several days (over a week) • Testing on multiple devices (including devices that never opened the App Clip before) Despite this, the App Clip continues to show the initially created content, while App Store Connect clearly shows the updated configuration. Important Details • We currently have ~1,300 App Clip Experiences created • All App Clips use the same App Clip Bundle ID • The content behind the URLs updates correctly on the website • Only the App Clip continues to show stale / initial data • Removing and re-invoking the App Clip on devices does not consistently fix the issue At this point, manual updates via App Store Connect appear to be completely ignored once the App Clip is “established.” Questions 1. Is there a known hard cache or CDN behavior on Apple’s side that prevents App Clip Experience updates from propagating? 2. Is there any way to invalidate or refresh an existing App Clip Experience? 3. Does having a large number of App Clip Experiences (~1300) affect update behavior or caching? 4. Is the recommended approach to treat App Clip Experience as immutable and handle all updates via backend / dynamic content only? Right now it feels like: App Clip Experience is effectively a one-time snapshot and not a live-updatable configuration. Any insights, confirmations, or official guidance would be greatly appreciated. Thanks in advance.

Is there any way for an iOS app to get a log of all Airdrop transfers originating in all apps on the iOS device e.g. from the last week?

Description The Shortcut Automation Trigger Transaction frequently times out, ultimately causing the shortcut automation to fail. Please see the attached trace for details. Additionally, the Trigger is activated even when the Transaction is declined. Details In the trace I see the error: [WFWalletTransactionProvider observeForUpdatesWithInitialTransactionIfNeeded:transactionIdentifier:completion:]_block_invoke Hit timeout waiting for transaction with identifier: <private>, finishing. Open bug report: FB14035016

Since watchOS 26, watch face sharing has stopped working completely. I tested the following: Sharing via CLKWatchFaceLibrary Other public APIs Sharing via iMessage In all cases, the watch face cannot be reinstalled after being shared. This issue is not limited to my app. Large third-party apps such as Facer and other major watch face platforms are also affected, which suggests this is a system-level change or bug. Everything worked correctly before watchOS 26. Has Apple officially acknowledged this issue? Is there a recommended place to report or track this bug?

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home APP version

It’s been 3 days and enrollment still pending. Can you help me please? App is ready to publish

Hey Apple Sipport, can you double check enrollment? its been a while for this profile. Thank you

Hello, I am working on a cross‑platform application that uses libiconv to convert strings to/from Unicode. I need to modify the existing code for compatibility with macOS. However, the call to iconv() fails with an unclear errno value (92) when using "WCHAR_T": std::wstring ConvertToWchar(const std::string& iconvCodeSet, const std::string_view str) { iconv_t conv = iconv_open("WCHAR_T//TRANSLIT", iconvCodeSet.c_str()); if (conv == (iconv_t)-1) { std::cerr << "iconv_open() failed" << std::endl; return {}; } std::wstring out(str.size(), L'\0'); auto inPtr = (char*)str.data(); size_t inSize = str.size(); auto outPtr = (char*)out.data(); size_t outSize = out.size() * sizeof(wchar_t); if (iconv(conv, &inPtr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } if (iconv(conv, nullptr, &inSize, &outPtr, &outSize) == (size_t)-1) { std::cerr << "iconv() failed. errno = " << errno << std::endl; return {}; } iconv_close(conv); return out; } int main() { std::string str1((const char*)u8"ΟΔΥΣΣΕΥΣ"); std::wstring str2 = ConvertToWchar("UTF-8", str1); if (str2.empty()) return 1; std::cout << "converted" << std::endl; return 0; } Using "UTF-32" works fine, but "WCHAR_T//TRANSLIT" fails. What is the recommended way to convert wchar_t strings using libiconv? Why does the conversion fail with "WCHAR_T//TRANSLIT"? Thank you in advance!

I am developing the electronic part of product, it includes a Find-My features. I saw some forum that testing Find-My feature needs a CSR and testing token. Can anyone teach me how to apply CSR and testing token step by step? Thank you very much. Best regards Sam Ng

We integrated DeviceCheck framework into our app to prevent fraudulent call to our app service around one year ago. Recently, we received a few cases related to this function over Christmas Eve period. Based on the logs we have, it indicated both the following two functions returned errors. But we don't have the exactly errors logged and now we cannot replicate. DCAppAttestService.shared.attestKey() DCAppAttestService.shared.generateAssertion() The other finding we have is some users reporting this issue recently upgraded their devices from iOS 18 to iOS 26. So we are suspecting it's due to either the OS upgrading, or Apple's app attest service degrading. Anyone encountered the similar issues before, or have any idea regarding the root cause? Thanks!

Hi all, I’m building an iOS app that uses CoreNFC to communicate with a YubiKey 5C NFC over ISO14443 / ISO7816 and send APDUs (e.g. select an applet by AID). Environment • Device: iPhone 13 Pro Max • iOS: 18.6.2 • Xcode: 26.1.1 (17B100) • API: NFCTagReaderSession(pollingOption: .iso14443) using NFCTag.iso7816 What I’m trying to do 1. Start NFCTagReaderSession(.iso14443) 2. Detect tag → connect 3. Send ISO7816 APDUs (SELECT AID, etc.) Issue A — Entitlements / signing If I add ISO7816-related NFC entitlements, Xcode fails signing with an error like: • “Provisioning profile … doesn’t match entitlements file value for com.apple.developer.nfc.readersession.formats” When I inspect the generated .mobileprovision, I only see something like: • com.apple.developer.nfc.readersession.formats = [NDEF, TAG, PACE] …and I do not see an ISO7816 / select-identifiers entitlement (and the Developer portal UI doesn’t appear to let me enable it). Questions: 1. Is ISO7816 access under com.apple.developer.nfc.readersession.formats restricted and requires Apple approval? If yes, what’s the correct request process? 2. Is com.apple.developer.nfc.readersession.iso7816.select-identifiers required for sending ISO7816 APDUs? If yes, how do developers obtain it / enable it for an App ID + provisioning profiles? 3. What is the Apple-supported way to configure entitlements/profiles for CoreNFC ISO7816 APDU communication with a token like a YubiKey? Issue B — Runtime NFC error Separately (even when I can run), I intermittently/consistently get: • NFCError Code=104 (“Tag is not connected”) This occurs after the tag is detected/connected when trying to establish a session or send APDUs. I’ve verified: • No phone case interference • Correct placement • Consistent detection “tick” from the phone for "Ready to Scan" prompt after tapping YubiKey 5C NFC device. If helpful, I can share: • A minimal sample project • The exact entitlements I tried • Console logs around the Code 104 failure Thanks!

We've often observed connectivity issues from our VPN app that can only be remedied by removing the VPN profile. It happens to a small but significant amount of our users, this often happens more when the app is updated, but the VPN profile corruption can happen without that too. The behavior we're observing is that any socket opened by the packet tunnel process just fails to send any data whatsoever. Stopping and restarting the packet tunnel does not help. The only solution is to remove the profile and create a new one. We believe our app is not the only one suffering from this issue as other VPN apps have added a specific button to refresh their VPN profile, which seemingly deletes and re-created the VPN configuration profile. Previously, we've caught glimpses of this in a sysdiagnose, but that was a while ago and we found nothing of interest. Alas, the sysdiagnose was not captured on a device with the network extension diagnostic profile (it was not a developer device). I would love to get technical support with this, as our bug reports have gone unanswered for long enough, yet we are still struggling with this issue. But of course, there is no minimum viable xcodeproject that reproduces this. Is there anything we can feasibly do to help with this issue? Is it even an acknowledged issue?

Approx Dec 13th 2025 til now (Dec 29th) I noticed my APNS dropped off to nothing daily. When I try to send APNS alerts on the developer site tool it always returns "discarded as device was offline" for multiple devices which I know are online. When I try pushing through my VPS (as I always have without any code changes for months) I get status codes of 400 and 403 mostly and a few 200's without it delivering also. I created a new sandbox certificate just in case it was that but still no luck, I get the same results. Ive checked for any firewall issues and I see the following on my VPS: nslookup gateway.push.apple.com Server: 1.1.1.1 Address: 1.1.1.1#53 ** server can't find gateway.push.apple.com: NXDOMAIN This seems like a second issue but not the primary issue that the portal is reporting. Any ideas what to check? Im at a loss as to why its not working at all through apples test notification portal on my developer account. It seems thats the initial issue I need to solve. Thank you for any ideas/help

We're building a parental control app using FamilyControls (.child authorization). Our architecture: Parent sends pause command → Firestore + FCM Child receives push → NotificationService Extension triggers main app Main app sets ManagedSettings Shields Problem: If child disables Notifications in Settings and force-quits the app, we cannot enforce Shields. What we've tried: Firestore Realtime Listener (works only when app is running) DeviceActivityMonitor (intervalDidStart/End only triggers at schedule boundaries, eventDidReachThreshold requires explicit app selection via FamilyActivityPicker) Question: Is there a recommended approach for parental control apps to reliably enforce Shields when the child has disabled notifications? Or is this a known limitation?