App Store Connect displays the In-App Purchases and Subscriptions section on your app's version page when your app has an In-App Purchase or subscription with a Ready to Submit status. To locate the In-App Purchases and Subscriptions section: In Apps, select the app you want to view. In the sidebar, select the app version. On the version page, scroll down to the In-App Purchases and Subscriptions section. For more information, see Submit an In-App Purchase.

General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

Hi Apple team, We’re evaluating how we generate appAccountToken for in-app purchases. For privacy and security reasons, rather than using a stable UUID associated with an account across all purchases, we’re considering generating a different opaque value for each purchase/context. Internally, our backend would maintain the mapping needed to associate each value with the correct customer account and, potentially, additional purchase context. In other words, the same customer account may result in different appAccountToken values across separate purchases, while our backend can still deterministically resolve each token to the correct account. We’d like to confirm: Does Apple expect or recommend that appAccountToken remain stable for the same app account across purchases? Are there any concerns with this approach for non-subscription / one-time purchases, assuming we maintain the account association on our backend? Our goal is to avoid exposing a stable account-correlatable identifier while still maintaining reliable server-side attribution. Thanks!

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Hi everyone, I'm investigating an issue related to StoreKit 1 receipt validation and would appreciate any insight from Apple engineers or developers who have encountered this before. Environment StoreKit 1 Consumable In-App Purchase iOS 16 / iOS 17 / iOS 18 (observed on multiple versions) Receipt validation performed on our server Receipt is read from the app bundle after the transaction completes Issue Occasionally, after a purchase succeeds and the transaction reaches the SKPaymentTransactionStatePurchased state, the App Receipt exists and can be decoded successfully, but the receipt contains: { "receipt": { ... "in_app": [] } } The in_app array is completely empty. As a result, our server cannot find the purchased product in the receipt and cannot complete receipt validation. Questions I'd like to understand under what circumstances Apple may return an App Receipt where receipt.in_app is empty. Specifically: Is it expected behavior that receipt.in_app can be empty after a successful consumable purchase? Could this happen if the app reads the receipt before the receipt has been updated? Is there any possibility that calling finishTransaction: before reading the receipt could cause the purchase record not to appear in receipt.in_app? If receipt synchronization is delayed, what is Apple's recommended approach? Wait and retry? Issue an SKReceiptRefreshRequest? Or validate using another mechanism? Are there any documented scenarios where Apple intentionally returns an empty in_app array? Additional Information The transaction state is Purchased. The purchase callback is received successfully. We have confirmed that the receipt file exists. The issue occurs only occasionally and cannot be reproduced consistently. Most purchases contain the expected in_app entry. Any clarification about the expected behavior of the App Receipt or recommended best practices would be greatly appreciated. Thank you!

Hello, Our first release was rejected under Guideline 2.1(b) because subscriptions were unavailable during App Review. We have been unable to reproduce the issue and would appreciate guidance on further diagnostics. Review environment App version: 1.0.0 (9) Device: iPad Air 11-inch (M3) OS: iPadOS 27.0.1 Internet connection: Active, according to the review message The app integrates StoreKit through RevenueCat and offers three auto-renewable subscriptions. We verified that : The Paid Apps Agreement, banking information, and tax forms are active. All three subscriptions and their subscription group are included in the submission. The subscriptions are available in all countries and regions. The submitted build uses the RevenueCat App Store SDK key, rather than a Test Store key. We tested subscription loading 15 times across two networks, including on iPad. Prices loaded successfully, and we completed a sandbox purchase that unlocked Premium. Additional diagnostics on an iPad Air 11-inch (M3) simulator running iPadOS 26.5 returned all three products both through a direct StoreKit Product.products(for:) request and through RevenueCat. No local StoreKit configuration file was attached. We have not reproduced the exact iPadOS 27.0.1 review environment. The simulator runtime is unavailable through our installed Xcode. The rejection message states that subscriptions were unavailable, but does not identify whether product retrieval failed, the subscription options were missing, or a purchase attempt failed. We are asking App Review for those details and a retry. We were wondering: What additional diagnostics would help investigate product availability failures that occur only during App Review? Are there sandbox account or storefront conditions we should test beyond successful product loading and sandbox purchases? Is there a recommended way to collect useful StoreKit error information from a review session when the failure cannot be reproduced locally? Thanks !

I previously responded to thread 840483, but Apple Support staff have not responded. I've also responded in App Review and created a support email, but the response times have been inadequate, and in the email thread it seems that the responding agent(s) did not read or understand the context of the issue, so I'll make this post in the hope that someone from Apple Support can assist. Guideline 2.1(b) rejection, with no way to submit the in-app purchase and the version together. I’m hitting the same deadlock described in thread link text, and I’ve added my case because it looks systemic, not a one-off setup error. My situation New app, iOS 1.0. One non-consumable in-app purchase (Pro Unlock). All metadata, price, availability, and the App Review screenshot are complete, and its status is Ready for Review. Rejected first under 2.1 (information needed), then, after I resubmitted, under 2.1(b): the in-app purchase “has not been submitted for review.” Apple’s instruction was to submit the purchase and upload a new binary. What I can’t do Adding the purchase for review creates a stand-alone Draft Submission that says: “Unable to Submit for Review. To submit your items for review, add an app version for the selected platform.” The version is never offered, and Submit stays disabled. The app version is held by the rejected submission, where the only option is Resubmit. That sends the version alone, which is what caused the rejection. The version page doesn’t show an “In-App Purchases and Subscriptions” section, so there’s nowhere to attach the purchase, contrary to what Apple’s help pages describe. I uploaded a new build, attached it to the version, deleted the stale draft, and tried every Add for Review path I could find. The result is the same. Why this isn’t acceptable App Review’s own message tells developers to do something that App Store Connect currently doesn’t allow. Everything Apple needs to see this is on Apple’s side: the account shows a configured purchase, a version in a rejected submission, and a draft that cannot be submitted. The state is visible without any information from me, yet the response so far is a rejection that repeats an instruction I can’t carry out. Each rejection costs developers days. What I’m asking Apple to do Attach the in-app purchase to the existing submission for the version, or Release the version from the rejected submission, so a single new submission can contain both. Acknowledge whether this is a known App Store Connect issue, and when it will be fixed. Other, older threads reporting similar issues and no posted solution include: link text link text link text I’ve also contacted Developer Support and replied in the Resolution Center. Could an Apple staff member look at this thread and my submission (ID ef48c4f6-1ad2-46d8-bb95-46c20bffc82a)? To anyone else with the same problem: please say so, and describe whether you found any workaround that didn’t require recreating your product IDs.

I’m testing In-App Purchases in the sandbox on a real iPhone. Auto-renewable subscriptions work correctly with the same app build, bundle ID, and sandbox tester account: com.aifalling.sides.vip.monthly com.aifalling.sides.vip.yearly However, a non-consumable product can’t be purchased: Product ID: com.aifalling.sides.vip.onetime App Store Connect IAP Apple ID: 6794812888 Type: Non-Consumable Status: Ready to Submit Bundle ID: com.aifalling.sides The native StoreKit payment request fails immediately with: The purchase identifier was invalid. The wrapper reports error code 700605. I verified the non-consumable product through the App Store Connect API: Product ID exists and is returned by the API One localization exists: zh-Hans A price schedule is configured, including a base territory and prices Availability includes China (CHN) and many other territories availableInNewTerritories is true I waited more than one hour after the latest metadata changes I completely removed the app, rebuilt/reinstalled the custom development build, and retried The same signed build can successfully purchase the two auto-renewable subscriptions This is the first non-consumable IAP type for this app. The app and IAPs have not been submitted for App Review yet because I’m trying to complete sandbox testing first. Does a non-consumable IAP require any additional App Store Connect setup or association that an auto-renewable subscription doesn’t require for sandbox testing? Is Ready to Submit sufficient for sandbox testing of a non-consumable product in this situation? Any guidance would be appreciated.

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?

Hello, We are investigating a discrepancy during an auto-renewable subscription test in Apple’s Sandbox. We would appreciate guidance on read-only diagnostics that preserve the original attempt. Environment: A development-signed, unpublished QA app on a physical iPhone, separate from our production app. A monthly auto-renewable subscription. The original purchase flow uses RevenueCat. The Apple purchase sheet displayed “Environment: Sandbox” and indicated that no charge would occur. Observed behavior: After entering the Sandbox account password, the tester reported seeing a purchase-completion message. The app subsequently displayed a cancellation message. We did not capture a verified StoreKit success transaction, so we cannot establish that the purchase actually completed. The dedicated QA RevenueCat project showed no purchases or subscriptions, and no actual purchase webhook arrived. The next day, subscription management for the same Sandbox account showed no subscription for this QA app. Read-only investigation: RevenueCat’s purchase and subscription queries returned HTTP 200 with empty results and no additional page. We updated the same app, retaining its bundle identifier and installation, with a native StoreKit diagnostic. Enumerating StoreKit.Transaction.all completed normally with zero results. There were no unverified results, filtered-out transactions, timeouts, or count limits. This diagnostic did not invoke purchase, synchronization, or transaction-finishing operations. One earlier restore attempt also returned no purchase. We have not made another purchase, cleared purchase history, or recreated the Sandbox account. We understand that an empty result in this app context does not prove that no transaction exists anywhere in Apple’s systems. No transaction identifier or signed transaction has been recovered. Questions: What read-only checks can distinguish an incomplete or cancelled purchase from an account/environment mismatch or a transaction-delivery issue? Is there a supported way to investigate the original attempt without a transaction identifier and without making another purchase? Which existing device logs or diagnostic captures would be useful? If investigation requires identifiers or unredacted diagnostics, what private Apple reporting channel should we use? Our goal is to investigate the original attempt while preserving purchase history and leaving production untouched. Thank you.

Hi everyone! We've received a rejection under Guideline 5.6 — Developer Code of Conduct for the second time, with the wording "the app contains features that appear to have been intentionally hidden during the review process." Apple doesn't specify the exact reason, and we are not hiding anything from review. About the app: Flutter, iOS, distributed on the Russian App Store; Self-care audio content: meditations, practices, audio readings based on date of birth; All content (texts, audio, prices) comes from our server, identical for all users, and there is no separate review mode; Part of the content is paid; payment happens inside the app through the YooKassa SDK (card, SberPay, SBP) — there are no Apple In-App Purchases yet; One section is locked with a "Coming Soon" label — it is not finished and is closed to all users; On launch, the app checks its version against the server and, if the version is outdated, asks the user to update; In the latest build we removed iPad support — the app is iPhone-only. We submitted the first build by mistake without any notes for the reviewer and without a test account — that may be where this started. The second time, both the notes and the test account were included. Has anyone else received this kind of rejection — what turned out to be the actual cause? We'd be grateful for any experience you can share.

Issue: Since Sept 10, 2026, my existing, already-approved auto-renewable subscription group cannot be submitted for review. This is not a new group: all 9 subscriptions in it show Approved, and my app has been live since July 2026. How it started: I changed only the introductory offer (7-day to 14-day free trial) on the monthly products. What App Store Connect shows now: The group is marked “Prepare for Submission” with the banner “Your first subscription group must be submitted with a new app version.” The Draft Submission contains only the group, and Submit for Review is disabled with: “New subscription groups must be submitted with an auto-renewable subscription from within that group.” “Add for Review” is greyed out on every one of the 9 subscriptions, so there is nothing to add to the draft. Impact: I can’t sell a subscription on any tier or billing period, and it has now been 6 weeks of lost revenue. Not the app binary: Builds 497 and 501 were both approved within hours, with no effect on the group’s status. What I’ve already tried, without success: Attaching each subscription individually, with all metadata and review screenshots complete. A forced re-save (editing a description, saving, reverting and saving again) to clear a stale validation state. Removing and re-adding the draft submission. Deleting and re-creating the introductory offer. Resubmitting the app. Accepting the latest agreements (all show Active). Support status: Developer Support case 102961055291, opened Sept 12. I’ve provided screen recordings and screenshots. I was told the case would go to engineering, but in six weeks I haven’t had a reply from an engineer, a name or a timeline. Two older threads describe the same stuck state and say it needed an Apple-side reset: 844425 and 818349. https://developer.apple.com/forums/thread/844425 https://developer.apple.com/forums/thread/818349 Has anyone seen this resolved without Apple resetting it? And if an Apple engineer sees this, could the case be routed to the team that can reset the subscription group’s submission state?

Good day to you, Our app BaanHost (Apple ID 6811541016, iOS, version 1.2.0) has been in "Waiting for Review" since 15 October 2026. This is our first release on the App Store. What happened: 15 October: App Review asked us to confirm the prices of our 20 auto-renewable subscriptions. We confirmed the same day that all prices are correct, and we resubmitted. Since then the submission has stayed in "Waiting for Review". We can no longer reply to the earlier message. 24 October: we requested an expedited review, and the request was approved ("We'll expedite review for BaanHost"). The status still has not changed. Is there anything else we need to do, or could someone from App Review please check this submission? Thank you, Kenny, Developer of BaanHost app

My app has been rejected twice under Guideline 2.1(b) because its In-App Purchases did not load during review. Both reviews used an iPad Air 11-inch (M3); the latest was on iPadOS 27.0.1. The reviewer's screenshots show the app's fallback state, which appears when StoreKit 2's Product.products(for:) returns none of the products. I can't reproduce it The same build loads all four products with their prices in every test I've run: TestFlight on iPhone and iPad (iPadOS 27.0), with a US account Run from Xcode with StoreKit Testing disabled, using a brand-new US sandbox account and a fresh install Starting offline and then reconnecting Signed out of the sandbox With In-App Purchases restricted in Screen Time Setup Four non-consumables, $0.49 USD, available in all countries, with localizations and review screenshots Submitted together with the app version (status: Waiting for Review) Paid Apps Agreement, banking and tax all active I've worked through Technote TN3186 (Troubleshooting In-App Purchases availability in the sandbox) Code Loading is a single call, retried a few times, and the user can tap Try Again: let products = try await Product.products(for: productIDs)Questions Is there anything that can stop products from being returned in the App Review environment but not in the sandbox? Is there a way to check what the review environment sees? Any help is appreciated.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

Our universal-purchase app (iOS + macOS, StoreKit 2) offers a 14-day trial as a non-consumable priced ¥0/free in all storefronts (approved, available everywhere), plus a paid non-consumable unlock. Since late September we have 3 separate Apple Accounts (Japan storefront) where the iPhone purchase flow fails: Product.products(for:) returns the product, the App Store purchase sheet appears with the correct product and account. After confirming, the sheet shows "支払いを完了できませんでした" (Payment could not be completed). No .success result. Redeeming a FREE one-time offer code for the paid non-consumable (via the apps.apple.com/redeem URL) fails the same way on the same iPhones. The very same Apple Account, same day, on the Mac app: both the ¥0 purchase and the offer code succeed immediately, and the entitlement then shows up on the iPhone through Transaction.currentEntitlements. OS correlation so far: iOS 27.0.1: fails (2 accounts) iOS 26.7.1: fails (1 account) iOS 26.6.2: succeeds Sales and Trends shows 9 iPhone + 1 iPad successful trial purchases between Sep 26 and Oct 12, so this is not account- or product-specific. The accounts have valid payment methods (paid purchases in other apps work), no Screen Time restrictions, not Ask to Buy. Filed as FB25186860 with a sysdiagnose. Has anyone else seen free purchases failing on 27.0.1 / 26.7.1? Any known workaround besides directing users to the Mac app?

Hello, I have 2 subscription group. Each group have different plans and promotional offer. I was set 1 month free promotional offer in all plans. While I subscribe any plan IAP sheet is not showing 1 month free promotional offer. I already used with new sandbox account. How can I get promotional offer in IAP sheet?

Hi everyone, I'm an individual developer with a sole proprietorship registered in Poland. I'm a citizen of Belarus, I live in Poland with permanent residence and I'm a Polish tax resident. The problem is that in App Store Connect the Country of citizenship field in my W-8BEN form is set to Poland and I can't change it. I tried resetting the tax questionnaire, didn't help. I don't want to submit the form with wrong info, so my Paid Apps agreement is stuck in Pending User Info since September 23. My bank account has been stuck in Processing since the same day too. What I've done so far: Sep 23 wrote to Developer Support (case 102973741691), on Sep 25 they told me to contact Finance Sep 26 opened Finance case 22490850, followed up on Oct 5, 12 and 19, also sent an official extract from the Polish business register that shows my citizenship. No reply at all Oct 12 wrote to Developer Support again, nothing Oct 16 called support, they said someone would help me within a week, nobody contacted me Did anyone have the same issue with the citizenship field? How did you get it fixed? Thanks

Hello, Our first app, Gaft (Apple ID 6798040496), version 1.0, was submitted for review on October 13, 2026 together with its first in-app purchases (two auto-renewable subscriptions and one consumable). It is still in Waiting for Review. An expedited review was approved on October 19, and we contacted Developer Support on October 20 (case 103002520980), but there is no reply and no change in status yet. Is anything needed from our side? Thank you for your help.

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

We are stuck in a review rejection loop regarding In-App Purchases (IAP) and Subscriptions, and we need advice on how to break out of it. The Background: A few weeks ago, we submitted a companion app that included IAPs and auto-renewable subscriptions. The App Review team rejected the build because the app forced users to create an account (using an OTP verification system) to access or view the IAPs, which prevented the reviewers from testing the purchase flow properly. What We Did: Because building a comprehensive guest checkout flow would take too long for our current launch timeline, we decided to completely remove all IAP and subscription features from this version. We did the following: • Removed all IAP/subscription code, UI elements, and references from the source code binary. • Deleted the IAP and subscription products inside App Store Connect (they are no longer attached to the version submission). • Submitted a new build along with a supporting video demonstrating the updated user flow. The Current Loop: App Review continues to reject our new submissions. However, the rejection reason has flipped: they are now claiming they cannot locate the IAP and Subscriptions that were previously there. It seems the review team is stuck looking at old metadata or cached project states, even though the binary and App Store Connect configuration have zero traces of IAP left. Has anyone experienced a similar "ghost" IAP rejection? How can we force App Review to recognize that this is now a strictly free app so we can get out of this rejection loop? Thank you!

We are stuck in a review rejection loop regarding In-App Purchases (IAP) and Subscriptions, and we need advice on how to break out of it. The Background: A few weeks ago, we submitted a companion app that included IAPs and auto-renewable subscriptions. The App Review team rejected the build because the app forced users to create an account (using an OTP verification system) to access or view the IAPs, which prevented the reviewers from testing the purchase flow properly. What We Did: Because building a comprehensive guest checkout flow would take too long for our current launch timeline, we decided to completely remove all IAP and subscription features from this version. We did the following: • Removed all IAP/subscription code, UI elements, and references from the source code binary. • Deleted the IAP and subscription products inside App Store Connect (they are no longer attached to the version submission). • Submitted a new build along with a supporting video demonstrating the updated user flow. The Current Loop: App Review continues to reject our new submissions. However, the rejection reason has flipped: they are now claiming they cannot locate the IAP and Subscriptions that were previously there. It seems the review team is stuck looking at old metadata or cached project states, even though the binary and App Store Connect configuration have zero traces of IAP left. Has anyone experienced a similar "ghost" IAP rejection? How can we force App Review to recognize that this is now a strictly free app so we can get out of this rejection loop? Thank you!