Overview

After my beta internal testers receive the App Store Connect invitation and tap to accept, the TestFlight email with download link is taking DAYS to arrive. Apple, you need to look at the provisioning servers. This experience can deter Apple developers.

Le build iOS via EAS échoue systématiquement lors de la phase Xcode. Bien que les capacités Family Controls et App Groups soient activées sur le portail Apple Developer et configurées dans le app.json, les profils de provisionnement générés par EAS sont rejetés par Xcode car ils ne contiendraient pas les droits nécessaires. Configuration du projet : Targets (4) : App principale + 3 extensions (ShieldConfiguration, ShieldAction, ActivityMonitorExtension). Capabilities requises : Family Controls (Development), App Groups. EAS CLI Version : 18.0.6 (et versions antérieures testées). Erreur Xcode récurrente : error: Provisioning profile "[expo] com.*****.*** AdHoc 177230..." doesn't support the Family Controls (Development) capability.. error: Provisioning profile "... AdHoc ..." doesn't include the com.apple.developer.family-controls entitlement.. Ce qui a déjà été tenté (sans succès) : Configuration app.json : Ajout manuel des entitlements pour le bundle principal et configuration du plugin react-native-device-activity. Nettoyage Credentials : Suppression totale des profils et des identifiants sur le site Expo.dev ET sur le portail Apple Developer. +1 Forçage Sync : Utilisation de eas build --clear-cache et réponse "No" à la réutilisation des profils existants. Observation étrange : Le terminal indique souvent ✔ Synced capabilities: No updates, alors que les droits viennent d'être modifiés sur le portail Apple. Sur le portail Apple, les profils affichent pourtant bien "Family Controls (Development)" dans les capacités activées. Je met en piece jointe un des profiles.

Description: I am developing a digital well-being application using the Screen Time API (FamilyControls, ManagedSettings, and DeviceActivity). I am encountering a critical issue where the ApplicationToken provided by the system to my app extensions suddenly changes, causing a mismatch with the tokens originally stored by the main application. The Problem: When a user selects applications via FamilyActivityPicker, we persist the FamilyActivitySelection (and the underlying ApplicationToken objects) in a shared App Group container. However, we are seeing frequent cases where the token passed into: ShieldConfigurationDataSource.configuration(shielding:in:) ShieldActionDelegate.handle(action:for:completionHandler:) ...does not match (using ==) any of the tokens previously selected and stored. IOS version: 26.2.1

Hi, I am submitting auto-renewable subscriptions for the first time for a brand new iOS app (never approved before). Setup: App ID has In-App Purchase capability enabled Subscriptions created under a subscription group All metadata (pricing, localization, availability) completed Subscriptions currently show In Review Testing via TestFlight build Bundle ID matches App Store Connect Using react-native-iap (StoreKit under the hood) When calling: await getSubscriptions({ skus }) I consistently get: products fetched: 0 ProductsUnavailableError Also, the app version page does not show the “In-App Purchases and Subscriptions” section. Question: For a brand new app, will StoreKit return empty products while the first subscriptions are in review? Do the first subscriptions need to be approved and/or attached to a new app version before they become available in TestFlight sandbox? Thanks for any clarification.

Hello, I am planning to distribute my iOS app as an Unlisted App. I would like to confirm the following: If users access the standard App Store URL in the format below: https://apps.apple.com/app/idXXXXXXXXXX Will users be able to reach the Unlisted app’s App Store product page via this URL? Or is the specific Unlisted distribution link generated by App Store Connect required for access? My goal is to ensure that in-app update guidance directs users to the correct App Store page. Thank you for your support.

I found an issue related to Gmail and Email apps. When I try to fetch text using controller.textDocumentProxy.documentContext, it works fine every time in my original app and in the Messages app. However, in Gmail or Email apps, after pasting text, controller.textDocumentProxy.documentContext returns nil until the pasted text is edited. The same scenario works correctly in Messages and my original app. i'm trying it from my keyboard extension and my keyboard builded bases on KeyboardKit SDK when i jump to text Document Proxy it's referring me to UITextDocumentProxy

Hello, We're seeing a high rate of providerDidReset callbacks in production across a large user base (iOS 16, 17, 18, and 26). I'd like to understand both the correct way to handle this delegate method and strategies to reduce its frequency. Background The callback occurs across all iOS versions we support and is not isolated to a specific device or region. The callback can occur in any app state (foreground, background, inactive), however it is most dominant in the background state — particularly during VoIP push notification handling. The callback is more prevalent during long app sessions — for example, when the app has been running continuously for a day or overnight. We do not call CXProvider.invalidate() anywhere in our codebase explicitly. After providerDidReset fires, subsequent transactions fail with CXErrorCodeRequestTransactionErrorUnknownCallUUID (error code 4). Re-initializing the provider via initializeProvider() resolves this error. Our Implementation We use a singleton proxy class (CallKitProxy) that owns the CXProvider. Below is a simplified version — some logging and non-essential parts have been removed for brevity. @objcMembers public final class CallKitProxy: NSObject { private var cxProvider: CXProvider? private let cxCallController: CXCallController private let cxCallObserver: CXCallObserver private override init() { cxCallObserver = CXCallObserver() cxCallController = CXCallController() super.init() initializeProvider() cxCallObserver.setDelegate(self, queue: nil) } private func initializeProvider() { let configuration = providerConfiguration() cxProvider = CXProvider(configuration: configuration) cxProvider?.setDelegate(self, queue: nil) } private func providerConfiguration() -> CXProviderConfiguration { let soundName = SharedUDHelper.shared.string(forKey: .pushNotificationSoundNameForCall) let sound = CallNotificationSounds(name: soundName ?? "ringtoneDefault") let configuration = CXProviderConfiguration() configuration.supportsVideo = true configuration.maximumCallsPerCallGroup = 1 configuration.maximumCallGroups = 1 configuration.supportedHandleTypes = [.phoneNumber, .generic] configuration.iconTemplateImageData = UIImage( named: "callkit_mask", in: .main, compatibleWith: nil )?.pngData() configuration.ringtoneSound = sound.name return configuration } public func requestTransaction( action: CXCallAction, completion: @escaping (Error?) -> Void ) { let transaction = CXTransaction(action: action) cxCallController.request(transaction) { error in completion(error) } } } extension CallKitProxy: CXProviderDelegate { public func providerDidReset(_ provider: CXProvider) { // End any active calls, then re-initialize the provider initializeProvider() } } Questions 1. Is re-initializing the provider inside providerDidReset the correct approach? The documentation states that providerDidReset signals the provider has been reset and all calls should be considered terminated. Should we be calling CXProvider.invalidate() on the old instance before creating a new one? Or is assigning a new CXProvider to cxProvider (which releases the old instance) sufficient? 2. What could be causing providerDidReset to fire so frequently, and how can we reduce it? We're particularly concerned about cases triggered during VoIP push handling in the background and inactive states. Are there known conditions — such as provider configuration changes, app lifecycle events, or system memory pressure — that commonly trigger this callback? And are there any recommended patterns to make the provider more resilient in these scenarios? Thank you.

Hi there, I am trying to use the agentic coding with the new Xcode update, however the "Intelligence" tab is not coming up on the left hand side of my Xcode settings. I've ensured I have macOS greater than 26, I've got Apple Intelligence and Siri enabled. I've shut down and restarted Xcode and my computer. Still, the option is not available. Can anyone help?

I'm trying to understand the terminology around forward vs backward references in CloudKit. Say I have two record types: User LeaderboardScore (a score belongs to a user) The score record stores a user reference: score["user"] = CKRecord.Reference( recordID: userRecordID, action: .deleteSelf ) So: LeaderboardScore → User The user record does not store any references to scores From a data-model perspective: Is this considered a forward reference (child → parent)? Or a back reference, since the score is "pointing back" to its owner? My use case is having leaderboard in my app and so i have created a user table to store all the users and a score table for saving the scores of each user of the app.

As stated in the title, my device is M4 macmini, running macOS 26, with Xcode version 26.1. The error message is ": retrying debugserver without secure proxy due to error: Error Domain=com.apple.dtdevicekit Code=811 UserInfo={NSUnderlyingError=0xc42b07930 {Error Domain=com.apple.dt.MobileDeviceErrorDomain Code=-402653150 UserInfo={MobileDeviceErrorCode=, com.apple.dtdevicekit.stacktrace=, DVTRadarComponentKey=261622, NSLocalizedDescription=}}, NSLocalizedRecoverySuggestion=Please check your connection to your device., DVTRadarComponentKey=261622, NSLocalizedDescription=}, the official documentation does state that debugging is supported for devices running at least iOS 15. However, my 2019 MacBook Pro, with macOS 15.7.2 and Xcode 26.1 installed, can debug iOS 12 devices normally. The product manager has asked me to identify the issue, but I am at a loss. If anyone can provide a solution or confirm that support for iOS 12 is no longer available, we would be very grateful. Additionally, iOS 13 devices can all be debugged normally

Issue from App Review: My app shows a custom explanation screen before triggering the system location permission dialog. This screen explains why location access is needed. It includes: A “Continue” button → triggers the system permission dialog A “Not Now” button → dismisses the explanation and delays the permission request Apple states that: “The user should always proceed to the permission request after the message.” They are asking me to remove the exit button from the pre-permission message. My Questions Is it now against policy to include a “Not Now” option in a pre-permission explainer screen? Are we required to immediately show the system permission dialog after any pre-permission explanation? What is the recommended UX pattern if the feature depends on location but I don’t want to force the permission immediately at launch? Would it be compliant to: Remove the “Not Now” button, OR Remove the custom pre-prompt entirely and rely only on the system dialog? The feature in question requires location to function properly, but I want to implement it in a user-friendly way that respects user choice and avoids unnecessary denial rates. If anyone has recently resolved a similar 5.1.1(iv) issue, I’d really appreciate hearing how you handled it. Thank you in advance for your help!

Hi everyone, My iOS app “TaskCal: Task Manager” (version 1.2.8) has been stuck in “Waiting for Review” for more than 3 weeks, and I’m not sure what else I can do at this point. Here are the key dates (GMT+8): Jan 30, 2026 – Version 1.2.3 was approved and marked “Ready for Distribution”. Jan 31 – Feb 8, 2026 – I submitted version 1.2.8 multiple times. Several submissions were later marked as “Removed” in App Store Connect. Feb 9, 2026, 12:39 AM – I submitted version 1.2.8 again. This submission has been in “Waiting for Review” ever since. Today is Mar 3, 2026 (Taipei time) – The status is still “Waiting for Review” with no change. Because of this, I contacted Apple Developer Support multiple times through Contact Support. I only received one reply, on Feb 21, 2026, which said: Hello Alan, Thank you for reaching out to Developer Support about your app, “TaskCal: Task Manager.” I understand that you’re concerned. After reviewing your app’s submission history, I can confirm that your apps is still in the “Waiting for Review” status as of February 8th 2026. To address your concern about the duration of your of the review, I’ve contacted the review team to bring this to their attention. At this time, there’s no further action required from your end. If the review team needs any additional information to complete the review, they’ll reach out to you directly. We appreciate your patience during this process. Your case number is 20000107493507. Stephanie Developer Support Since then, there has been no visible progress and no follow‑up messages. The App Review page still shows: Version: iOS 1.2.8 Status: Waiting for Review Case ID: 20000107493507 I completely understand that review times can vary, but: My previous version (1.2.3) was reviewed and approved normally. This is a relatively small productivity app with no major policy changes. It’s been over 3 weeks in “Waiting for Review” for this specific submission, with multiple earlier submissions of the same version being “Removed” without clear explanation in the UI. My questions: Is there anything I may have done wrong in the submission process (for example, causing multiple “Removed” submissions) that could block or delay this review? Is there any other official channel I can use to get more clarity beyond contacting Developer Support (which only confirmed that it’s “Waiting for Review”)? Has anyone here experienced a similar long “Waiting for Review” state recently, and if so, how was it resolved? I’m worried that there might be some issue with this build or with my account that I’m not seeing in App Store Connect. At the same time, I don’t want to keep canceling and re‑submitting if that could make the situation worse. Any advice from Apple or other developers who have gone through something similar would be greatly appreciated. Thank you, Alan

Dear App Review Team, I hope you are well. I am writing to respectfully follow up on my recent submission (Dev ID: 1770951123), which has now been in “Waiting for Review” status for approximately 12+ days. Currently, four of my applications are in a similar state, including one update for an app that was previously approved without issue. Given my past experience, reviews have generally been completed within a reasonable timeframe. While I fully understand that review times may vary depending on workload, the extended duration in this case has raised some concern. I previously submitted an expedited review request and opened a support case (Case ID: 102832785901). However, I have not yet received any response regarding the status of the review or the case. To better understand the situation, I would sincerely appreciate clarification on the following points: Whether there are any issues or flags currently preventing the review process from proceeding Whether any additional information or documentation is required from my side Or whether the submission is simply pending assignment to a reviewer I completely understand that the App Review team may be experiencing a high volume of submissions. Nevertheless, given the duration and the number of affected apps, I would be very grateful if someone could kindly review my case and advise on the current status. Thank you very much for your time and assistance. I look forward to your response. Kind regards, Lovesoft

Hello Apple Developer Support, My app has been stuck in “Waiting for Review” since February 9. I have submitted multiple inquiries without receiving any response. This delay has now become extremely concerning. If there is an issue with the submission, I would appreciate clear communication. If there are review delays, transparency would help us plan accordingly. I respect the review process, but the lack of updates after this amount of time is frustrating. I would sincerely appreciate clarification on the status. Apple ID: 6755156178 Thank you.

Hello Apple Developer Support, My app has been stuck in “Waiting for Review” since February 7, and I have submitted multiple inquiries without receiving any response. This delay has now become extremely concerning. Missing a planned launch due to an indefinite review timeline is very difficult for independent developers. If there is an issue with the submission, I would appreciate clear communication. If there are review delays, transparency would help us plan accordingly. I respect the review process, but the lack of updates after this amount of time is frustrating. I would sincerely appreciate clarification on the status. I kindly ask for a specific and personalized response regarding my case, as my previous inquiries received only general or automated replies without addressing the actual issue. Apple ID: 6758804549 Thank you.

Of all the reasons I thought I might be rejected, I never thought this might be a possibility! "The usefulness of the app is limited by the minimal functionality it currently provides. " My app lets you track where you are in TV shows - you can add a show, tag shows (which appear as tabs), expand a show's seasons, mark an episode as watched, tap an episode to view its summary, and (if you have It installed) open the episode in Callsheet. You can also get a notification when a new season of a show drops. **Does anyone have experience with dealing with this kind of rejection? ** I'm wondering if they are dealing with an onslaught of "vibe coded" apps and are being more liberal with this rejection (this is not vibe coded!). The whole point of this app is that I didn't want a cluttered app with recommendations and other nonsense - I specifically wanted a simple, clean UI. https://tvnext.app Thanks, Damian App Id: 6757971087

We are an App Developer for past 16 years so have seen a lot happen with App Review over the years (even back when 2 month review times were the norm). However, we have all come to expect app review to take only 48 hours typically. We submitted several macOS Tahoe updates in Feb all approved within 24 to 48 hours, but 2 updates submitted on 25th Feb are stuck in 'waiting for review'. Very strange indeed and checking this forum, it seems many other devs are having the same issue, but from way earlier than us. Is this a known issue currently? I suspect their are different app review queues by region and maybe even app category and popularity of the app, but even accounting for all that, this is unusual. There seems to be no logic to which apps are approved same day vs those kept stuck in 'waiting for review'.

Our app with Apple ID 6757327542 has actually been approved on Feb 3rd, but we made small additional changes before launch and resubmitted. It has been in status "Waiting for Review" since then, with no official reply for the support request. (Case ID: 102831397885) Thanks!

Hello everyone, I’m currently experiencing significantly longer than usual review times and wanted to check if others are seeing similar delays recently. Here’s the timeline of my submissions so far: [Feb 5] Initial submission (Submit #1) [Feb 10] Sent expedited review request #1 [Feb 11] Canceled and resubmitted (Submit #2) [Feb 21] Canceled again → Uploaded new build → Resubmitted (Submit #3) [Feb 24] Sent expedited review request #2 My apple ID: 6757330278 The app has remained in “Waiting for Review” for an unusually long period across multiple submissions. Even after submitting two expedite requests, there hasn’t been any updates or response yet. What’s confusing is that I see other apps getting approved during the same timeframe, so I’m unsure whether this is: A broader review backlog A regional queue issue Or something specific to my account/app I’m just hoping to understand whether this is a widespread situation at the moment. If anyone has experienced similar delays recently, I’d really appreciate hearing about your timeline or any insights you may have. Thanks in advance, and good luck to everyone currently in review 🙏

I’ve been going back and forth on this review feedback for quite a while, and I’m still unclear what specific change is needed. I’ve already made multiple updates to make everything more visible and obvious for the end user, but the app continues to be rejected .