Overview

I’m trying to diagnose an APNs provider authentication issue that began after APNs had previously been working. Summary: My iOS app can register for remote notifications and successfully sends its device token to my server. The app has the Push Notifications capability enabled in Xcode, the Bundle ID has Push Notifications enabled in Certificates, Identifiers & Profiles, and the APNs key is active in the Apple Developer portal. However, every server-side APNs send attempt now fails with: HTTP 403 {"reason":"InvalidProviderToken"} This happens against both sandbox and production APNs endpoints. App / account details: Bundle ID / apns-topic: app.terrasignal Team ID: 837F2XGDX Current APNs Key ID: HNW7XPK2H3 APNs key type: Apple Push Notifications service (APNs) Key configuration: Team scoped, Sandbox & Production Xcode signing team: David Buck / Team ID 837F2XGDX Push Notifications capability is enabled in Xcode Device token environment tested: sandbox Server clock verified against Apple/date header and matches UTC What works: iOS app launches successfully Push permission is granted Device token is generated Device registers with my server successfully Server stores the token as sandbox for bundle app.terrasignal What fails: Server-to-APNs provider authentication Direct HTTP/2 APNs request fails before notification delivery Failure reason is always InvalidProviderToken I tested three separate APNs keys: 34T746MWFV T9N75GU2AV HNW7XPK2H3 Each key was downloaded from the Developer portal, uploaded to the server, verified as a valid .p8 private key, and used with its matching Key ID. All produce the same InvalidProviderToken result. I also bypassed my APNs library and tested direct HTTP/2 + JOSE JWT signing. The direct APNs test also fails with the same response: HTTP status: 403 Response body: {"reason":"InvalidProviderToken"} Example direct APNs test details: Host: api.sandbox.push.apple.com Path: /3/device/ apns-topic: app.terrasignal apns-push-type: alert apns-priority: 10 JWT header: {"alg":"ES256","kid":"HNW7XPK2H3"} JWT payload includes iss: 837F2XGDX and current iat Key imports successfully with jose importPKCS8 JWT is generated successfully APNs rejects it with InvalidProviderToken I also tried production endpoint with the same result: Host: api.push.apple.com HTTP 403 {"reason":"InvalidProviderToken"} Things verified: System clock is correct Docker/server UTC time matches Apple Date header Bundle ID topic is app.terrasignal APNs key exists in the Apple Developer portal APNs service is enabled on the key Key is configured for Sandbox & Production Push Notifications capability is enabled for the app Xcode signing uses the same team The .p8 file is not empty or malformed The key imports successfully via jose/importPKCS8 The issue occurs before APNs evaluates the device token, because authentication fails first Question: What Apple-side account/key/app configuration state can cause multiple active APNs auth keys for the same team to return InvalidProviderToken, even when: the key is active, APNs is enabled, the Team ID matches, the Bundle ID topic matches, the server clock is correct, and a direct HTTP/2 APNs request with manually generated ES256 JWT also fails? Is there a way to force-refresh, repair, or re-sync APNs provider authentication for a Developer account / Bundle ID / APNs key?

Hi, I'm testing my first auto-renewable subscription using StoreKit 2 and TestFlight. When loading products via: let products = try await Product.products(for: ids) the product is returned successfully, but product.displayPrice shows: $4.99 even though: My App Store account is located in Germany. The app is only intended for the German market. The native Apple purchase sheet displays the correct price in EUR. The subscription pricing is configured correctly in App Store Connect. The subscription is still in "Ready to Submit / Prepare for Submission" state and has not yet been approved. Example: print(product.displayPrice) returns: $4.99 while the StoreKit purchase dialog shows: 5,99 € Has anyone seen this behavior before? Is this expected for new subscriptions in TestFlight/Sandbox before the first App Review approval, or could there be another reason why displayPrice differs from the actual purchase dialog? Thanks!

"Use location, address and addressRepresentations instead" Is it possible to know what kind of "Address" a MapItem is representing (State, County, Neighborhood etc) after a MKGeocodingRequest? Is it possible to find out the CLRegion or similar of an map item. (Now when we cannot read it from the Placemark)

I'm testing IPhone and iPad Apps on Apple Silicon Macs. When I purchase In-app product in the app on Apple Silicon Mac, the payment receipt is not created, so the purchase fails. In console log, it says it doesn't have permission to write to the file. storekitagent [6913DE38_SK1] Error writing receipt (5095 bytes) to file:///Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “sandboxReceipt” in the folder “StoreKit”" UserInfo={NSFilePath=/Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x14202c920 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} The App is using Original API for In-App Purchase written in Objective-C. When I purchase in-app product, the app calls SKPaymentQueue::addPayment. And then it gets paymentQueue:updatedTransactions callback with SKPaymentTransactionStatePurchased. This means that the payment was successful. But the receipt is not created so I can't continue the after process. I'm testing with sandbox in-app purchase. I have tested several times and confirmed that on macOS Monterey 12.2 the receipt is created successfully, but on macOS Ventura 13.2 the receipt isn't created. I think there is something to do with macOS version. Does anyone have any solutions? Here is a very similar thread on apple developer forum. (And there too has no anwsers)  https://developer.apple.com/forums/thread/719505

We have an app that uses CallKit for outgoing Voip calls. One of our users started experiencing an issue, where he sometimes receives an UnknownCallProvider error from CallKit 10 seconds after the transaction request. This happens both after the app stays open for a while, and on fresh launches. A device restart didn't help as well. He is not on any other call during that time. It seems to happen only to him, and only sometimes. Any estimation what could be the cause? Or how to find out? What are the possible reasons that produce this error?

My app, Campsite Tonight, is an existing app and sits in waiting for review a lot longer than before. id1578612896 There Was feedback about not having an ability to delete an account which app always had. despite this, I built a new feature in most recent version to ideally address it more. The app has been in mostly waiting states and I’ve tried to escalate it to no success This has been very frustrating as app reviews used to take a day or two but now it’s been closer to a month due to all these delays. I have a bug that has caused me to lose paying users and I’m trying to address but can’t because of this long delay.

Wonder if there are any changes we need to make in App Store Connect to replace a MacOS app with "Designed For iPad" app? Already added "Mac (Designed For iPad)" supported destination in Xcode. Thanks.

We have developed a Parental/Self control app using Screen time API. We have used individual authentication to authorize the app, using the instructions here: https://developer.apple.com/documentation/familycontrols/authorizationcenter The problem is , that individual auth can be disabled easily , by the following steps: enter Settings app. in Settings app, click on the Parental/Self control app. click to disable screen time restriction. show the device owner's face/fingerprint. (or pin code) Why is that a problem: Parental control apps, or self-control apps, are about giving control to the software, To make it hard for the user to disable the restrictions. So using the flow I have introduced above, it's super-easy for a user to disable his Parental control restrictions, which misses the entire point of Parental/Self control idea. Furthermore, not only the user have the means to unlock his screen time restrictions, he also MUST have the means to unlock it. This makes Screen time (with individual auth) useless: I have a code ready to make a great parental control app for my clients, with amazing ideas, but I can't use the Screen time API unless this problem is fixed. Why child-parent auth is not enough: My clients are grownups people between ages of 15-40, that are interested in self-control, so they don't have iCloud child accounts. also, the child-parent auth solution forces my clients to give some control to other person, and my clients prefer their privacy. Some of them prefer self-control and not parental-control. What I suggest as a solution: 1: Give more options to users how to disable the Screen time restrictions. including: a second faceID / FingerPrint (that isn't the same as the one used to unlock the device) a second pin password. a string password 2: Give the users the option to choose to not have the device's owner Face/Finger/Pincode ID , as a method to disable the Screen time restrictions.

My app has been stuck in “Waiting for Review” for a very long time and I’m honestly getting really frustrated. I already fixed all previous issues and submitted everything properly, but there has been no update at all. This delay is seriously affecting my launch plans and business operations. I understand reviews can take time, but the waiting period feels unusually long compared to my previous submissions. I have not received a response to multiple support requests for weeks. This is causing me quite a bit of stress as I don’t know what else I can do or how long this is going to last for. Has anyone else experienced this recently? Is there anything I can do to speed up the review process or get an update from Apple? I’d really appreciate any advice or shared experiences. Thank you.

Hi all, Looking for guidance from anyone who has navigated a similar 3.1.1 review. Our product is a freemium SaaS for creative groups (calendar, library, chat). It follows the same shape as Slack, Notion, Linear, Asana, etc.: Free tier exists and is fully usable Paid tiers are sold on our website via Stripe The iOS app is for participation: sign in, view sessions, RSVP, chat, edit groups, manage members The iOS app contains NO purchase UI, NO prices, NO plan/tier names, NO upgrade buttons, NO links to our pricing page, NO mention of paid features We've stripped the iOS build of everything subscription-related. Server error messages are sanitized before they reach the client so words like "plan", "subscription", "upgrade", "trial" never appear in the app. Settings has no billing section on iOS. Plan-limit errors are rephrased to neutral text ("Contact your group owner"). Despite all this, we've been rejected multiple times under Guideline 3.1.1 — most recently because reviewers observed that we "access subscriptions or premium content" (i.e. the account they signed in with has a paid plan that was activated on the web). Our question: Does Guideline 3.1.1 require us to implement In-App Purchase if: The iOS app contains no purchase mechanism, no prices, no upgrade UI, no mention of paid tiers All purchases happen on our website, before or outside the app The user's account simply happens to have a paid plan that unlocks higher limits Or is this a Reader App / 3.1.3(b) Multiplatform case, where we are allowed to NOT offer IAP as long as we don't promote external purchase inside the app? We've read 3.1.1, 3.1.3(b), and the Reader App guidance multiple times. Slack, Notion, Linear, Asana all ship iOS apps in this exact shape without IAP. We can't tell what distinguishes our case from theirs. If anyone has: Gotten clear guidance from App Review on this exact scenario Successfully argued 3.1.3(b) Multiplatform for a SaaS productivity app Or implemented IAP specifically because of 3.1.1 even though their app had no purchase UI — we'd love to hear how it went, what wording worked, and whether a 30-minute call with App Review was useful. Thanks!

Hello everyone, I've been unable to install any TestFlight build on my device for over a week. Every build shows "Complete" in App Store Connect, but installation always fails with the same error. I also submitted a support ticket to Apple Developer Support over a week ago but have not received any response. I'm posting here hoping someone from the community or Apple team can help. Error Message "The requested app is not available or doesn't exist" (Turkish: "İstenen uygulama kullanılamıyor veya yok") Environment Device: iPhone 17 Pro Max iOS: 26.4.2 App: Easyway Digital Library Bundle ID: com.abacusai.turkishsocialme.t1777823268 Build Framework: React Native (Expo SDK 54) What I've Tried (Nothing Works) ✅ Multiple builds uploaded (build 4, 5, 6, 7, 8) — all show "Complete" ✅ Deleted and reinstalled TestFlight app ✅ Signed out and back into Apple ID on device ✅ Restarted iPhone ✅ Tried different browsers (Safari, Chrome, Firefox) ✅ Tried Internal Testing — receive email but can't install ✅ Tried External Testing — same error ✅ Tried creating Public Link — same error ✅ Cleared browser cache, tried Incognito mode ✅ Verified Export Compliance (ITSAppUsesNonExemptEncryption: false) ✅ Paid Apps Agreement: Active ✅ Free Apps Agreement: Active ✅ Bank & Tax info: Complete Build Status in App Store Connect Version & Build: 1.0.1 (8) Status: Complete Date Created: May 15, 2026 Timeline May 8, 2026: First build uploaded — same error started May 10, 2026: Paid Apps Agreement activated May 15, 2026: Still the same error after 8 builds Apple Support — No Response Submitted a support ticket on approximately May 8, 2026 Category: App Store Connect & TestFlight Issue: Cannot install builds via TestFlight Status: No response received after over 1 week No case number update, no email reply Questions Has anyone experienced this with a new app on TestFlight? Is there a known issue with TestFlight and new Bundle IDs? Could this be related to the Paid Apps Agreement activation delay? Is there a way to reset the TestFlight state for a Bundle ID? How can I escalate my support ticket if there's no response? I'm completely stuck — I cannot test my app at all. Any help or guidance would be greatly appreciated. Thank you!

One of the possible solutions to a problem that I'm working on is to have two Drivers loading in one DriverKit dext, an IOUserHIDEventService and an IOUserHIDDevice. For this to work, however, I need to have the event service send a message to the Device. IOKit has the service and connection objects that I can use just like an app would (just like the app the driver communication example). But DriverKit complains whenever I try to add the IOKit framework, saying that it is not supported. Is there another way that I can send a message directly from one driver to another?

Hi Everyone! I am writing a media extension to playback old "Amiga" ANIM files, as a test project. I have build the following objects: MEFormatReader METrackReader MESampleCursor The subclassed objects seem fairly straightforward. Rather than create a Video Decoder, I followed the instructions in the SampleCursor object header, and use the function: loadSampleBufferContainingSamplesToEndCursor:completionHandler: to deliver an BGRA 8-bit image. This works great AVPlayer object in my Swift based test app, but QuickTime Player will not actually play the movie. If I scrub on QuickTime Player's timeline, I can watch the movie just fine. But if I click on the "Play" button. Nothing happens. For fun, I created a custom pixel type, and implemented a MEVideoDecoder object. This also works with my AVPlayer test app, but again, same problem with QuickTime Player. I have even generated a JPEG image in the SampleCursor, and that fails too. I am stumped on this. I do not see any way to have QuickTime Player work properly with my MediaExtension, nor is there any documentation as to what to do. Suggestions? bob

I have a FetchDescriptor that uses starts(with:) which works fine in debug builds but crashes in TestFlight and archive. For background information I'm using iCloud and model inheritance where the property being used in fetch descriptor is defined on the superclass, the fetch descriptor is for the subclass. Implementation: static func fetchDescriptor(nameStartingWith prefix: String) -> FetchDescriptor<ColorAsset> { let predicate = #Predicate<ColorAsset> { asset in asset.name.starts(with: prefix) } return FetchDescriptor<ColorAsset>(predicate: predicate) } @Model public class Asset: Identifiable { // MARK: - Properties var name: String = "" .... } @available(macOS 26.0, *) @Model public class ColorAsset: Asset { ... }

Hello, My app, Puls: Corporate Wellness (Apple ID: 6762296263), appears to be stuck in the App Review process, and I would like to check whether there might be an issue with my submission. The app has been in the review queue for approximately 10 days, which seems unusually long compared to my previous submissions. I have also opened multiple support cases regarding this issue but have not received any response so far. I would greatly appreciate it if someone could check whether there is an issue with the submission or if any additional information is required from my side. This delay is impacting our planned release timeline, so any assistance or guidance would be greatly appreciated.

As much as our team did a lot of work to update our app, we even did marketing plans for the release of the same. Regrettably, the more time our app spends under review, the more our app becomes outdated due to the version currently in use in the App Store. Please be assured that we know how busy the reviewers might be. However, at this stage, we are just hoping to receive help from people who have been through similar experiences before. Have any of you been in the same boat? Any information or guidance is appreciated? Thank you everyone.

Hi Kevin, I'm starting this new thread to focus on alignment optimization and recalibrating our HBA constraints. Following up on your suggestion about UserReportHBAConstraints and alignment optimization, here are our current DEXT settings: Via UserReportHBAConstraints(): kIOMaximumSegmentCountRead/WriteKey: 129 kIOMaximumSegmentByteCountRead/WriteKey: 65,536 (64 KB) kIOMinimumSegmentAlignmentByteCountKey: 4 bytes kIOMaximumSegmentAddressableBitCountKey: 32 kIOMinimumHBADataAlignmentMaskKey: 0 Via SetProperties() (additional injection): kIOMaximumByteCountRead/WriteKey: 524,288 (512 KB) kIOMaximumBlockCountRead/WriteKey: 1,024 We inherited the segment count (129) and max I/O length (512 KB) from our legacy KEXT, which were originally calculated based on a 4 KB segment size (Max I/O 512 KB / 4 KB + 1 = 129). The current alignment value of 4 was essentially a placeholder, as the legacy hardware didn't enforce strict page-level alignment. Given that our testing is on Apple Silicon, we are considering increasing kIOMinimumSegmentAlignmentByteCountKey to 16,384 (16 KB) to match the native page size. However, I have two specific questions regarding this: Stripe Size vs. Page Size: Our RAID stripe size is typically larger than 16 KB (e.g., 64 KB or 128 KB). Should we be aligning the system to the RAID stripe size for hardware efficiency, or is it more critical to stick to the 16 KB page size to optimize the IOMMU/DART mapping overhead in DriverKit? Recalibration: If we increase the alignment to 16 KB, should we also adjust the kIOMaximumSegmentByteCount to match (i.e., 16 KB), or is it better to keep it at 64 KB to allow fewer, larger segments per I/O? We suspect that the 38% gain we saw in 4 KB Random Reads might improve even further if we fix this alignment bottleneck. Looking forward to your thoughts. Best regards, Charles

I am creating UI elements with glass backgrounds such as: UIVisualEffectView(effect: UIGlassEffect(style: .regular)) And UIButtons such as: var buttonConfig = UIButton.Configuration.glass() This gives the glass a dark background and white tint/labels when the device interface settings are dark, and conversely light backgrounds with black tint/labels when the interface mode is light. Perfect! Now enter the UINavigationBar buttons. I've spent a day trying every configuration possible to make them match the rest of the UI. But they have a mind of their own. They will flash different colors when scrolling the content. They do not respect the user interface mode. Out of desperation, I tried adding my own glass UIVisualEffectView behind the navigation bar and and disabled the button glass background with: someBarItem.hidesSharedBackground = true Even though I don't like that design as much as the individual glass buttons, it at least lets me match the rest of the UI. Alas that setting makes the animation to the next screen visually buggy. Hard to describe, but it's not acceptable. The only thing it seems I can do is make the content view start below the navigation bar area. But then I completely lose the glass effect - though at least I can make them match the rest of the UI and the push/pop animation isn't buggy. I realize I can opt out of glass entirely, but I want to use glass. The problem isn't glass. The problem is the navigation bar does not respect the user interface mode or allow us to set the glass type. I get the system trying to make the glass more legible, but, the buttons that I can set with UIButton.Configuration.glass() and UIGlassEffect(style: .regular) are always legible regardless of the background color because the tint/label color is the opposite of button background color. I've been a full time iOS developer for 15 years, and this is most frustrating UIKit changes I've ever seen. It's a step backward when it's impossible to make the navigation bar match the rest of the UI. It's a step backwards when the navigation bar flickers and changes. All that we need is a glass property for the UINavigationBarItems or UINavigationBarAppearance that works like UIGlassEffect or UIButton.Configuration glass configurations. Or default behavior that just respects traitCollection.userInterfaceStyle or overrideUserInterfaceStyle to begin with. Dark UserInterfaceStyle example. The top buttons should match the bottom UI elements, but does not seem possible.

Hi all, I'm hitting a wall trying to enroll my personal Apple ID in the Apple Developer Program. My company Apple ID has been enrolled and active in the program for over a year. I now want to enroll my personal account as well so I can ship side projects under my own name. Both accounts belong to me. Both use the same iPhone, mac and the same phone number for 2FA. I'm not trying to run both signed in simultaneously, I just want both Apple IDs enrolled so I can switch between them when needed. Every time I try to enroll the personal account, it's rejected. The rejection doesn't give a specific reason (Your enrollment could not be completed.), but I'm fairly sure the conflict is around the shared phone number or device. I've reached out to Developer Support but haven't had luck getting through: Email support: over 10 days with no reply on my ticket Phone support: on hold for 3 hours before the call dropped automatically Posting here in case someone has been through the same setup. Specifically: Has anyone successfully enrolled two Apple IDs in the Developer Program where both accounts belong to the same person on the same device? Is the shared phone number actually the blocker, or could it be something else? Is there a recommended way to escalate Developer Support when tickets go unanswered? Any pointers appreciated.

Hi everyone, We are the engineering team behind an enterprise communications application for macOS. We are experiencing a critical crash on macOS 26 that did not occur on any previous macOS version. We are seeking clarification from Apple engineers or anyone who may have insight into this behaviour. Environment Architecturex86_64macOS26.4.1 (25E253)HardwareMac15,13 (MacBook Pro)ExceptionSIGILL / ILL_ILLOPCCrashed ThreadThread 0 (Main Thread)TriggerPlaying a notification sound via NSSound during an incoming call Crash Stack 0 caulk consolidating_free_map::maybe_create_free_node + 119 ← SIGILL 1 caulk tiered_allocator + 1469 2 caulk exported_resource::do_allocate + 15 3 AudioToolboxCore EABLImpl::create + 204 4 CoreAudio AUNotQuiteSoSimpleTimeFactory + 33267 8 AudioToolboxCore AudioUnitInitialize + 189 9 AudioToolbox XAudioUnit::Initialize + 19 10 AudioToolbox MESubmixGraph::initialize + 125 11 AudioToolbox MESubmixGraph::connectInputChannel + 1172 12 AudioToolbox MEDeviceStreamClient::AddRunningClient + 509 15 AudioToolbox AudioQueueObject::StartRunning + 194 16 AudioToolbox AudioQueueObject::Start + 1447 22 AudioToolbox AQ::API::V2Impl::AudioQueueStartWithFlags + 805 23 AVFAudio AVAudioPlayerCpp::playQueue + 354 24 AVFAudio AVAudioPlayerCpp::DoAction + 134 25 AVFAudio -[AVAudioPlayer play] + 26 26 AppKit -[NSSound play] + 100 27 Our App -[AudioHelper tryToStartSound:ofType:] + 569 28 Our App block_invoke + 59 Behaviour Difference Between macOS Versions The exact same code path that triggers this crash on macOS 26 works without any issue on macOS 14 and macOS 15 — no crash, no warning, no log output of any kind. The crash occurs inside Apple's private caulk memory allocator during CoreAudio audio engine initialisation, triggered by a call to [NSSound play]. The SIGILL / ILL_ILLOPC at maybe_create_free_node + 119 suggests a hard ud2 trap — an intentional abort guard inserted at compile time. This strongly suggests that something changed in macOS 26 within NSSound / CoreAudio / caulk that causes this code path to fail in a way it previously did not. Questions We have the following specific questions: Was there a deliberate threading policy change in NSSound / CoreAudio in macOS 26? Is the SIGILL in caulk::consolidating_free_map::maybe_create_free_node an intentional thread-affinity assertion introduced in macOS 26? Are there any other NSSound / AVAudioPlayer / AudioQueue APIs that have similarly tightened their requirements in macOS 26 that we should be aware of? Is there a migration guide, release note, or WWDC session that covers CoreAudio changes in macOS 26 that we may have missed? Has anyone else in the developer community encountered a similar SIGILL crash in caulk on macOS 26 during audio playback?