“Account Locked”

Hi Apple Developer Community, Since March 16, 2026, our integration with the Apple Ads Campaign Management API (v5) is returning 403 Forbidden on all GET requests to the custom-reports endpoint, while POST requests to create reports continue to work without any issues. Environment API Version: v5 Base URL: https://api.searchads.apple.com/api/v5/ Authentication: OAuth 2.0 (Bearer token — token generation works fine) API User Role: API Account Manager What's broken GET /api/v5/custom-reports/63638557 → 403 Forbidden The response is raw HTML from Apple's gateway, not a JSON API error: 403 Forbidden 403 Forbidden Apple This indicates the request is being blocked at the reverse proxy / infrastructure level and never reaches the API application layer. A proper API-level authorization error would return JSON with messageCode and message fields. What still works POST creates report successfully POST /api/v5/custom-reports → 200 OK Response: { data: { id: 63638557, name: Impression_Share_Report_2026-03-22

We made an update of one of our games with the Declared Age Range framework, and one of the users contacted us, asking how could he confirm his age to access the app's features. Meaning that isEligibleForAgeFeatures returned true on his device. According to documentation: Use isEligibleForAgeFeatures to determine whether associated laws or regulations may apply to your app based on the person’s location and account settings. This property returns true when your app needs to support Age Assurance for the current user. As far as we know, the laws are not applied anywhere yet. So, why did isEligibleForAgeFeatures return true?

Hi Apple Developer Support, We are reaching out to request guidance on a testing constraint we have encountered related to iOS Universal Links and Associated Domains entitlements. As part of aligning with updated recommendations from our authentication provider, we have transitioned our mobile apps to use HTTPS redirect callbacks (Universal Links) instead of custom URI schemes. This works as expected in production and on real physical devices. However, we are encountering a significant issue in our cloud-based device testing environment. When our testing platform re-signs the app to run it on their infrastructure, the re-signing process strips the Associated Domains entitlement from the app bundle. As a result, iOS no longer honors our Universal Links, which breaks the authentication redirect flow — the callback cannot route back into the app after the user authenticates. We have identified a potential workaround that would involve disabling app re-signing in the testing platform, but this requires provisioni

Hello everyone, I recently submitted my iOS app for review, but it was unfortunately rejected under Guideline 2.1(a) - Performance - App Completeness. For context, my app is a healthcare application built with Ionic. According to the App Review team's message, they found the app to be incomplete. They stated they were unable to review the app because they couldn't get past the login screen. The Root Cause: Upon investigating, we discovered the issue is related to IP Geo-blocking. Because the app handles sensitive healthcare data, our API provider strictly blocks all network traffic originating from outside of Italy to legally comply with European GDPR regulations. Since the App Review team tests from the US, their requests are being entirely blocked by the firewall, causing the login to fail and the app to look broken on their end. What I have verified so far: I have provided valid demo account credentials in the App Store Connect App Review Information section. I have tested the app thoroughly on ph

**Environment Platform:** iOS Distribution: TestFlight Product type: Consumable In-App Purchase Account used for testing: Real Apple ID (not Sandbox) StoreKit: StoreKit 1 iOS version: iOS 17+ (also reproduced on earlier versions) Issue Description We are encountering an issue when testing consumable in-app purchases in a TestFlight build using a real Apple ID. Under normal circumstances, consumable products should be purchasable repeatedly. However, in TestFlight, after a successful purchase flow, the same product may become unavailable for repurchase, and the transaction appears to be stuck, even though: • finishTransaction: is correctly called • The transaction state is .purchased • No pending transactions are left in the payment queue Once this happens, subsequent purchase attempts result in behavior similar to a non-consumable product (e.g. “already purchased” or no purchase UI shown).

Hello, I am experiencing a persistent TestFlight installation issue affecting multiple unrelated apps under the same Apple Developer account. For all affected apps: Builds upload successfully to App Store Connect Processing completes normally Builds appear in TestFlight Internal and external testing can be enabled Public links generate correctly However, when attempting to install the app via TestFlight, the installation fails with the error: “The requested app is not available or doesn’t exist.” This occurs: For internal testers For external testers Across different Apple IDs Across different devices With newly created apps After incrementing build numbers After re-uploading builds After signing out/in of TestFlight After regenerating provisioning profiles After creating entirely new app entries The issue currently affects: • TubeChat AI – Apple ID 6752591427 • Vibex – Apple ID 6756860663 • vigilAI – Apple ID 6757738356 Since multiple unrelated apps are impacted in the same way, this appears to be a