Overview

Hi, my app has been stuck in Waiting for Review for 18 days. I contacted you via your contact us link a week ago, and haven't heard back. Overall I'm very disappointed by your inability to communicate The app ID is 6758786767

Will I be able to download and run Xcode 26.3 on a new MacBook Air with an M5 chip? If yes, what memory size is recommended? 16, 24 or 32 GB ?

Hi Im creating an app with Alarmkit, the idea is to have the hardware buttons react like they do in Alarmclock with a snooze or if the buttons can just mute without intent. right now, hardware button end and dismisses the Alarm. its instinct to click that button. apple needs to update or do something.

Posting this wondering anyone from App Review may be able to help. I submitted two builds for External TestFlight builds. My iOS build got approved within a day, but my tvOS version is still stuck in "waiting for review" for four days now. Wondering if there's anything I can do, perhaps remove from review and re-upload a new build or will this effectively remove me from a queue? Many thanks in advance. I'm unable to find a submission ID for this as I assume they're not available for TestFlight reviews?

Hello, My app, Beezzy - Agenda Digital, had an Expedited Review request approved recently (confirmation received via email). However, the status remains stuck in 'Waiting for Review' for an unusual amount of time, even for an expedited process. This update is critical for our operations and addresses urgent fixes. Has anyone else experienced a delay between the expedited approval and the actual 'In Review' transition lately? Is there any additional step required from the developer side to trigger the priority queue? App ID: 6751509489 Thank you for any guidance.

I am testing my app in iOS 26.4 beta and emojis are rendering as squares with ? in the middle . I tested a very simple Text("👾") and I get the same results. It is working fine in 26.3.

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Imran

描述：低等级会员在 7 天免费期内订阅了高级会员 预期：低级会员的 7 天免费试用结束，高级会员直接扣费生效，苹果的升级通知如下： { "extra_info": { "quantity": 1, "expiresDate": 1754627893000, "purchaseDate": 1754623693000, "transactionId": "2000000979349440", "offerDiscountType": null, "originalTransactionId": "2000000979347229", // 升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "decodedPayload": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "2000000979347229" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 228000, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1754623696459, "storefront": "CHN", "environment": "Sandbox", "expiresDate": 1754627293000, "purchaseDate": 1754623693000, "storefrontId": "143465", "transactionId": "2000000979349440", "appTransactionId": "704742096472000913", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "2000000107917134", "originalPurchaseDate": 1754623472000, "originalTransactionId": "2000000979347229", "subscriptionGroupIdentifier": "21729756" } } 异常 case：苹果通知升级到高级会员且继续剩余试用时间，例如：低等级会员7 天免费试用期剩余 4 天，升级到 4 天的高等级会员的免费试用，收到的通知消息如下： "extra_info": { "quantity": 1, "expiresDate": 1773109207000, "purchaseDate": 1772708455000, "transactionId": "550002836609836", "offerDiscountType": "FREE_TRIAL", "originalTransactionId": "550002832625469", //升级前后没有变化 "subscriptionGroupIdentifier": "21729756" }, "purchase_type": "upgrade", "decodedPayload": { "signedTransactionInfo": {}, "orgin_sku_name": "unlimited.minutes.per.year.v3", "payment_platform": "app_store", "decodedPayload_Renew": { "productId": "unlimited.minutes.per.year.v3", "autoRenewStatus": 1, "originalTransactionId": "550002832625469" }, "decodedPayload_Trans": { "type": "Auto-Renewable Subscription", "price": 0, "bundleId": "ai.plaud.ios.plaudzh", "currency": "CNY", "quantity": 1, "offerType": 1, "productId": "unlimited.minutes.per.year.v3", "signedDate": 1772708460325, "storefront": "CHN", "environment": "Production", "expiresDate": 1773108607000, "offerPeriod": "P7D", "purchaseDate": 1772708455000, "storefrontId": "143465", "transactionId": "550002836609836", "appTransactionId": "705330723507531368", "offerDiscountType": "FREE_TRIAL", "transactionReason": "PURCHASE", "inAppOwnershipType": "PURCHASED", "webOrderLineItemId": "550001244481732", "originalPurchaseDate": 1772507407000, "originalTransactionId": "550002832625469", "subscriptionGroupIdentifier": "21729756" } } 请问是苹果的会员试用的策略发生了变化吗

It doesn't show any files, only warning or errors for me. Same behavior with @

I have opened a developer account couple of month ago, and enrolled successfully. Did the app store connect and put the app for testing. The company decided to change legal entity, and thus, I had to create a new developer account. So, I have enrolled to a new developer account. My enrollment is pending for almost 3 weeks, while I do not understand what is the status. I have tried sending emails to support and also calling support, but no success. What can I do?

Hi everyone, I submitted a new version (1.4) of my app,last Wednesday at 9:02 AM. It has been in the "Waiting for Review" status for over 5 days now. My previous updates were usually processed within 24-48 hours, so I’m concerned if there might be an issue with this specific build or if there's a general delay in the review queue. Has anyone else experienced similar delays recently? Should I continue to wait, or is it time to contact the App Review team directly?

Hello, I have a question regarding how prorated refunds are reflected when a user upgrades a subscription. From my understanding, when a user upgrades to a higher-tier subscription, the remaining value of the current subscription is refunded as a prorated amount, typically represented as REFUND_PRORATED or PRORATED_CREDIT. However, when reviewing the available transaction history and refund-related data (including the App Store Server API and transaction history endpoints), I cannot find any field or record that clearly indicates: the actual prorated refund amount, or the credit applied when upgrading to another subscription In other words, while the concept of REFUND_PRORATED seems to exist conceptually, I cannot identify where the actual prorated value or credit applied to the upgrade is exposed in the transaction or refund history. My questions are: Is there any way to retrieve the actual prorated refund or credit amount when a user upgrades a subscription? Is this information available through the App Store Server API (e.g., Get Transaction History) or any other API endpoint? If not, is there any recommended method to determine how much of the previous subscription was credited toward the upgraded subscription? Any clarification would be greatly appreciated. Thank you for your help.

Hello, I’m implementing VoIP calling in an iOS application using PushKit (VoIP pushes) together with CallKit. The standard call flow works correctly: Happy scenario User A initiates a call. Server sends a VoIP push to User B. User B’s device receives the push and reports the incoming call using CallKit. User B answers the call. However, I would like clarification about non-happy scenarios and when it is acceptable to use VoIP pushes to update or stop a CallKit ringing state. Apple documentation warns that VoIP pushes must be used only when they result in a call-related action, so I want to ensure the following cases are compliant. Scenario A — Caller Cancels Before Answer User A calls User B. Server sends a VoIP push to User B. User B’s device starts ringing via CallKit. Before User B answers, User A cancels the call. Question: Is it acceptable to send another VoIP push to User B indicating that the call has been cancelled so the device can: stop the CallKit ringing UI end the call optionally mark it as missed or cancelled Or should this state change be handled using a regular remote push or another signaling mechanism instead of VoIP push? Scenario B — Callee Rejects the Call User B rejects the call from CallKit. The server must inform User A that the call was rejected. Question: Is it acceptable to send a VoIP push to User A to update the CallKit state and terminate the outgoing call UI? Scenario C — Multiple Devices per User User B may be logged in on multiple devices. User A calls User B. VoIP push is sent to all devices of User B. One device answers. Question: Is it acceptable to send a VoIP push to the remaining devices instructing them to: stop ringing end the CallKit incoming call UI Or is there a recommended alternative pattern for this case? Main Question Aside from the initial incoming call VoIP push, in which situations is it considered acceptable to send additional VoIP pushes to terminate or update CallKit state (cancelled, rejected, answered on another device)? The goal is to remain compliant with PushKit policies, particularly the guidance that VoIP pushes should only be used when they result in a call-related user action. Any guidance on the recommended architecture for these cases would be greatly appreciated. Thank you.

So if I create an Alias of a folder in Finder and hand the alias to my app (I also moved the alias file to a new folder, but I did not move the original folder)...so then my app resolves the alias using: NSURL +URLByResolvingAliasFileAtURL: What happens? The resolved URL points to a completely different folder. Well not completely different. It resolves to a folder that happens to share same last path component as the original folder...but this folder is inside the same parent folder the alias file is in. It does not resolve to the original folder I created the alias of. So then once my app touches the alias with +URLByResolvingAliasFileAtURL: the alias now resolves to this new (wrong) location (even in Finder). Couple details: My app is not sandboxed. I have permission to access the original folder in my app (but even if I didn't the alias shouldn't be mutated just by merely resolving it). Only seems to happen if the folder I move the alias to happens to contain a sibling folder that has the same title as the original folder. Like it's just deleting the last path component of the alias and then appending the last path component of the original filename and just going with that. I hope that makes sense. I tried creating the alias myself using -bookmarkDataWithOptions: and going the other way (to Finder) but Finder must be resolving the alias using a different API because it resolves to the original location as expected.

I am working on an e-commerce app (retail/marketplace) that allows users to place orders for both free and paid products. After receiving a DeclaredAgeRange API response — retrieved via the Family Controls / Screen Time framework — indicating that a user is a minor, I want to understand the recommended approach for handling payment flows. Specifically, is it necessary to block payments for users identified as minors via DeclaredAgeRange, even though our app uses server-side encrypted card processing rather than Apple In-App Purchases (StoreKit)? Any guidance on best practices or App Store policy requirements for this scenario would be greatly appreciated.

I've run into what appears to be a bug in PDFKit's radio button serialization. When creating a radio button group with PDFAnnotation, only the first annotation added via page.addAnnotation() gets a correct /AS entry in the written PDF — all other annotations always get /AS /Off, regardless of buttonWidgetState. Minimal reproduction func makeRadioButton(optionId: String, isSelected: Bool) -> PDFAnnotation { let ann = PDFAnnotation(bounds: CGRect(x: 0, y: 0, width: 20, height: 20), forType: .widget, withProperties: nil) ann.widgetFieldType = .button ann.widgetControlType = .radioButtonControl ann.fieldName = "Choice" ann.buttonWidgetStateString = optionId ann.buttonWidgetState = isSelected ? .onState : .offState return ann } let pdf = PDFDocument() let page = PDFPage() pdf.insert(page, at: 0) // Intend to select B page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) _ = pdf.dataRepresentation() // Result: /AS is /Off for all three — B is not selected in the PDF What I observed Selecting A (first annotation added): /AS /A written correctly works Selecting B or C: /AS /Off for all buttons Additionally, dataRepresentation() corrupts the in-memory state as a side effect: buttonWidgetState of the selected annotation is .onState before the call and .offState after. Root cause During serialization, dataRepresentation() internally calls setButtonWidgetState:.onState on each annotation in turn to generate appearance streams. This triggers PDFKit's radio-group exclusivity logic, which silently clears all other annotations — so by the time /AS is written, only the first annotation's selection survives. Workaround It took a while to track this down, so I'm documenting the workaround here in case it helps others. Add the annotation that should be selected first via page.addAnnotation(): // Add selected annotation first page.addAnnotation(makeRadioButton(optionId: "B", isSelected: true)) page.addAnnotation(makeRadioButton(optionId: "A", isSelected: false)) page.addAnnotation(makeRadioButton(optionId: "C", isSelected: false)) Tested on macOS 26.3 / Xcode 26.3. Filed as Feedback FB22167174. Full code including workaround is here: radio_bug_swift.txt Has anyone else hit this? Is there a cleaner method I'm missing?

I think I’ve discovered a quantum paradox in the enrollment process. On February 3rd, I paid for my membership. Since then, my account has been in a "Schrödinger's State": It exists (because the payment was successful and my ID was verified weeks ago) It doesn't exist (because it’s still stuck on "Pending" and I can't access any developer tools) It’s been 31 days, and the box is still closed. But I really hope not many people are in this situation, has anyone else faced something similar? How did you resolve it? I’d love to finally start publishing…

I too have been in "waiting in review" for longer than expected. What is the normal time for a review?

Hello, I’m working on an iOS app where we have integrated ActivityKit to support Live Activities. Our app currently supports iOS 16.x and above, and we do not have an Apple Watch app or watchOS support. However, we noticed that when a Live Activity starts on the iPhone, it automatically appears on the Apple Watch as well. Since our app is not designed for Apple Watch, we would like to prevent the Live Activity UI from appearing on the watch. My questions: Is there any way to disable or prevent Live Activities from showing on Apple Watch via code? Are there any configuration options in ActivityKit or Widget configuration that can restrict Live Activities to iPhone only? Our current setup: Minimum iOS version: 16.x Using ActivityKit for Live Activities No watchOS target in the app Any guidance or recommended approach would be greatly appreciated. Thanks

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