Overview

Hello App Review Team, We respectfully ask for your assistance regarding our app review status. Our submission was re-submitted on April 29, 2026, and it has now been waiting for review for more than 12 days without any update or response. In addition, we have already been working through the review process for this app on this developer account for almost 4 months. We carefully addressed all previous review feedback and submitted the required fixes, but the review process continues to experience very long delays. This situation is now seriously impacting our planned product launch, business operations, and partner commitments. We sincerely ask if the App Review Team could please help: Review the current submission status Escalate the case internally if possible Help move the review process forward Reference Information: Case Number: 102877213113 Submission ID: 68850cef-1651-40c8-b717-7916b679a467 We would greatly appreciate any assistance or update regarding this matter. Thank you very much.

Setting massProperties on a USDZ-loaded entity corrupts its transform (position/scale → NaN) Category: RealityKit / visionOS Environment: visionOS 26.x Summary: Modifying PhysicsBodyComponent.massProperties at runtime on an entity loaded from a .usdz file silently corrupts the entity's transform. The translation and scale components become NaN, while rotation remains valid. The corruption occurs during the next RealityKit scene update cycle (e.g., during an await suspension on the main actor). Steps to Reproduce: Author a .usda file with a RigidBody component including valid m_mass and m_inertia values Load the entity at runtime via Entity(named: "MyEntity.usdz", in: bundle) Read the existing PhysicsBodyComponent, modify massProperties, and set it back: if var physics = entity.components[PhysicsBodyComponent.self] { physics.massProperties = .init( mass: 1.944, inertia: SIMD3<Float>(0.013, 0.026, 0.016), centerOfMass: (position: .zero, orientation: .init()) ) entity.components.set(physics) } Add the entity to the scene Perform any await call (e.g., TextureResource(contentsOf:)) that yields to the main actor, allowing a RealityKit scene update to run Expected: The entity retains its position and scale with the updated mass/inertia values. Actual: The entity's transform becomes corrupted: Transform( scale: SIMD3<Float>(nan, nan, nan), rotation: simd_quatf(real: 1.0, imag: SIMD3<Float>(0.0, 0.0, 0.0)), // ← fine translation: SIMD3<Float>(-nan, -nan, -nan) ) Additional findings from investigation: The entity's physics mode does not matter — corruption occurs even when the entity is .kinematic Creating a new PhysicsBodyComponent(...) and replacing the existing one also triggers the bug Modifying other properties on the same component (linearDamping, angularDamping, material, mode) does not cause corruption — only massProperties triggers it The parent entity's transform remains valid The computed mass/inertia values themselves are valid (finite, positive) The corruption is silent — no error, no warning, no crash from RealityKit itself Workaround: Author mass and inertia values directly in the .usda file and do not modify massProperties at runtime: def RealityKitStruct "massFrame" { float3 m_inertia = (0.02, 0.02, 0.038) float m_mass = 2.5 def RealityKitStruct "m_pose" { } } Other PhysicsBodyComponent properties (damping, material, mode) can safely be modified at runtime.

Hello everyone, My app has been stuck in “In Review” for around 10 days without any update. I have not received any rejection, metadata request, or additional information request from the review team. The app is simply remaining in review with no movement. What worries me the most is that I have already contacted the App Review Team multiple times through App Store Connect, but I still have not received any response. Is anyone else experiencing the same situation recently? Have you found any effective way to speed up the review process? Thank you very much.

(Note: I don't need DTS support. This is not a DTS issue, and the standard responses aren't relevant to the situation. I would ask that DTS not respond in lieu of the developer support official) Yesterday, a poster in this forum wrote about his experience waiting several months to get approved to have his apps notarized. He had hit the "status code 7000; Team ID not configured for notarization" block. An Apple Developer Support account responded to him saying they would help the poster. After a month of waiting and praying for Developer Support to approve my Team ID for notarization, and no progress via the official channels, I am rolling the dice that asking Developer Support here will get my account approved or at least moved forward. I just can't wrap my head around why it takes so long to allow a Team ID to submit apps for notarization. My Team ID is V67NRZ84A2, and my support ticket is 102874600970. Spending months and months developing an app, paying the Developer Support annual fee, and then having to sit on your hands for months while your app gathers dust due to the Status Code 7000 bottleneck is very demoralizing. Again, not a DTS issue. The official channels 100% do not work. Developer Support did respond to a poster yesterday, so this is the pathway I'm hoping will lead to my Team ID getting permission to notarize apps. As it stands, no other method is leading to the problem getting resolved.

Hey team, This is a weird one, when Siri + "On-Screen Actions" are enabled in the Apple TV settings (General Settings), LazyVStack experiences severe main-thread hangs and very high CPU usage. The issue only occurs when Siri + On-Screen Actions are enabled in Apple TV device settings (General Settings). Disabling On-Screen Actions completely resolves the issue. The issue has been verified on multiple Apple TV devices, running tvOS 26.3, 26.4 and 26.5. The behavior was not observed in Simulators, only on an actual device. This seems to be caused by some type of accessibility overlap with SwiftUI. Running the below code with "On-Screen Actions" enabled in the Siri settings will demonstrate a complete hang of the CPU at 100% struct TestData { let id = UUID() var title: String } struct TestView: View { @State private var test: [TestData] = [] var body: some View { ScrollView { LazyVStack { ForEach(self.test, id: \.id) { data in Button { } label: { Text(data.title) } } } } .task { var arr: [TestData] = [] for _ in 0..<30000 { let data = TestData(title: "Title") arr.append(data) } self.test = arr } } } Already submited a bug report FB22758928

Context We're handling App Store subscriptions on the server side using App Store Server Notification v2. Our pipeline currently identifies each event by transactionId and originalTransactionId. A few notes about our client: Our app is built with Flutter and uses the standard in_app_purchase plugin layer to drive App Store purchases (StoreKit 1 under the hood). We have not migrated to StoreKit 2 on the client yet. We have not been setting SKPayment.applicationUsername on outgoing purchases, so every transaction we've ever produced has appAccountToken: null in its v2 notification. This question is purely about what the server-side notification can tell us, given the current client state above. What we're trying to figure out A user can resubscribe to an expired subscription in two different places: In-app — the user opens our app and re-purchases through our normal in-app purchase flow. App Store — the user goes to Settings → Apple ID → Subscriptions and resubscribes from the system UI, without ever returning to the app. Both paths trigger a SUBSCRIBED notification (subtype RESUBSCRIBE) with structurally identical payloads as far as we can tell — same shape for data.transactionInfo, data.renewalInfo, etc. From the notification alone we can't decide which path produced it. The reason this matters: in our system, the two paths require different business handling: In-app path: the user may have signed in to a different business account in our app. The new subscription should be attributed to whoever paid in the app just now, not to the previous owner of originalTransactionId. App Store path: there is no in-app signal, so the business owner can only be inferred from the previous originalTransactionId mapping. If we get it wrong, the subscription's entitlement ends up on the wrong business account. What we do today Because we can't tell the paths apart from the notification, we defer processing for a few minutes and check whether an in-app order for the same transaction has arrived in the meantime: If an in-app order shows up → it's the in-app path; attribute to the in-app account. If nothing shows up after the delay → assume App Store path; fall back to the previous owner mapping. This works but adds latency to entitlement activation and forces us to build a deferred-retry queue with idempotency against the in-app callback path. Possible direction: appAccountToken / applicationUsername We noticed that v2 notifications carry transactionInfo.appAccountToken, and the docs suggest that StoreKit 1's SKPayment.applicationUsername (when it's a valid UUID) is mirrored into this field. In theory, if we start setting it on every in-app purchase from the Flutter client, the field could double as a path discriminator on the server: appAccountToken != null → in-app path (only the app can set it), and we even get the business user id for free appAccountToken == null → App Store path (no UI to populate it) But we have some open questions before committing to this direction: Questions Is there an existing signal in ResponseBodyV2 / JWSTransactionDecodedPayload / JWSRenewalInfoDecodedPayload that distinguishes these two paths, that I might be missing? Can the same distinction be obtained via getAllSubscriptionStatuses / getTransactionHistory / any other Server API endpoint? Is applicationUsername (StoreKit 1) still a reliable way to populate appAccountToken on v2 notifications today? Specifically: Are there format constraints beyond "valid UUID" that cause Apple to drop the value? Any known differences between sandbox and production in how it's mirrored? Does the App Store path ever strip or overwrite a previously-set value when the same originalTransactionId is reused? For existing subscriptions where applicationUsername was never set (which is all of ours today, since we've never polient), is there any way to retroactively distinguish the in-app vs App Store path? Or is timing-based deferred matching theonly option for that cohort, even after we start setting the value on new purchases? If neither (1) nor (2) is currently possible, is the timing-based heuristic we use today the pattern Apple expects developers to follow, or is there a recommended approach we're missing? A small suggestion, if it turns out there's no existing way If the information genuinely isn't exposed today, it might be worth surfacing a salesChannel-style field on the transaction, similar to what Google Play Developer API exposes on Order.salesChannel (IN_APP, PLAY_STORE, etc.). That would let server-side handlers route each event to the correct business owner immediately, regardless of whether appAccountToken was set, and would also cover legacynt never had a chance to populate it. Thanks — happy to share sample payloads or more detail if helpful.

Hi, I have been using Testflight iOS app to test my apps before releasing to production. Over the past few weeks, I am unable to install any of my apps through Testflight. I also don't get any email notification that my app is live on Testflight. This is really important and it would be really helpful if I can find any solution to this. Thank you so much.

I submitted the application with my DUNS number on May 8, 2026, and today is already May 11, 2026. After submitting the form, it said the process would take about 1 day, but quite a bit of time has already passed and I still have not received organization status. I also have not received any emails from Apple. Could there possibly be some issue that I am not aware of?

While testing Flutter applications on macOS 26 beta with Xcode 26 beta, iOS builds consistently fail during Flutter.framework codesigning with: "resource fork, Finder information, or similar detritus not allowed" Investigation suggests newer Xcode beta versions now reject additional extended attributes beyond com.apple.FinderInfo during codesigning. Flutter tooling currently removes only: xattr -r -d com.apple.FinderInfo Replacing it with: xattr -cr successfully resolves the issue. Environment: macOS 26.4.1 beta Xcode 26.4.1 beta Apple Silicon (ARM64) Flutter 3.41.9 Flutter issue: https://github.com/flutter/flutter/issues/186372 Apple Feedback Assistant report: FB22756923 Interested to know whether other developers on Xcode 26 beta are seeing similar stricter codesigning validation behavior.

Hi, Can someone help me with this issue I'm having with my app's IAP functionality? When you click on the unlock Premium button on the pop-up window, it should trigger the purchase action. However, there is an error when a user clicks on the button; this error appears as " Product Not Found." Please check App Store Connect Configuration". Has anyone faced this issue before, and how was it resolved? My backend code is right, and the IAP configuration in App Store Connect is right and approved, including the Agreement.

Hello everyone: I paid the $99 requested to publish an app on Saturday around 3 PM (Paris time). They asked me for my French ID card shortly after, around 5 PM (Paris time). I sent it around 8 PM (Paris time), but I haven't heard back since. I emailed support around 10 AM (Paris time). Still no response. Can you help me?

Hello, I am unable to install my app from TestFlight even though the build appears valid and is in internal beta testing. The build was uploaded successfully to App Store Connect and shows as Testing / Internal Testing. The build metadata looks valid: processingState: VALID internalBuildState: IN_BETA_TESTING qcState: BETA_INTERNAL_TESTING usesNonExemptEncryption: false minOsVersion: 15.0 deviceFamilies: IPHONE supportedArchitectures: arm64 However, TestFlight installation fails, and the App Store Connect API returns: ENTITY_UNPROCESSABLE.BETA_CONTRACT_MISSING Beta contract is missing for the app. My App Store Connect agreements are all active. I checked Business > Agreements and both Paid Apps Agreement and Free Apps Agreement are Active. Bank accounts, tax forms, and compliance also appear Active. This also happens with a newly created app and a fresh build, so it looks like the TestFlight beta contract may be missing or detached on Apple’s backend. Has anyone seen this before, or is there a way to force App Store Connect to refresh the TestFlight beta contract state?

Hello, I submitted a request for Family Controls (Distribution) approval, and it has now been over 12 days without any update on the status. I understand that review times can vary, but I wanted to check if this delay is expected or if there’s anything I might need to do on my end to help move the process forward. Could anyone from the Apple team or the community provide insight into: Typical processing times for Family Controls distribution requests Whether delays beyond a few days are common Any steps I should take to follow up or expedite the review For reference: Status: Submitted Submission time: April 29, 2026 Any guidance would be greatly appreciated. Thank you!

Since 28 April, we have seen some bizarre behaviour where iOS 26.3 and 26.4 are intermittently not loading some CSS and JS resources from our CDN. This is only reproducible when our CDN has HTTP/3 enabled. When reproduced in the Simulator, Safari's HAR shows that it is not even attempting to request those resources; it does not appear to be a network issue. Oddly enough switching to a different CDN with HTTP/3 enabled appears to resolve the issue. As far as I can tell, this hasn't been reported on the Webkit tracker; we'd be happy to provide Apple with additional data in a formal bug report but it would be helpful to know what data would be useful to provide.

Hello, I'm hoping someone from the App Review team can look into this situation, which has specific context that I believe makes it worth a careful look. Thank you in advance for your time. I'm hoping someone from the App Review team can look into this situation, which I believe has specific context that makes it worth a careful look. My app YADA: You've Already Met (App ID: 6759586097) has been in "Waiting for Review" since Wednesday May 6 at 7:44 PM ET - now over 96 hours. I have an open support case (20000112508151) filed Friday with no response yet. I'm not writing simply to flag the wait - I want to explain why this submission deserves a thoughtful second look on the merits. When YADA was submitted for TestFlight beta review, it was flagged under Guideline 4.3(b) for the same reason as the App Store rejection. I appealed, explained the differentiating mechanic, and an Apple reviewer evaluated the argument and approved the app for external testing. That approval is on record. I'm asking for consistency with that prior decision. YADA's core mechanic is genuinely unlike any dating app currently on the App Store. A user privately adds someone they already know to a list. That person receives no information about who added them. A match is only revealed when both people have independently and privately added each other. If the feeling isn't mutual, nothing is ever disclosed. There is no browsing of strangers, no algorithmic recommendations, no swiping, and no rejection possible because neither party knows they've been added until both have added each other simultaneously. Critically, YADA does not ask users to declare their gender or sexual preferences - because the mechanic doesn't require it. This makes YADA the only interest-discovery platform on the App Store that works entirely without those declarations, which creates a uniquely safe experience for LGBTQ+ users and young people who are not ready to publicly disclose their orientation. No equivalent experience exists on the App Store. The App Store rejection also included 5.1.1 and 2.1 issues, both of which I fully resolved - redesigning the contacts permission flow with a proper in-app explanation screen and directly answering Apple's question about data handling - with a new build submitted alongside my Resolution Center reply. I'm not asking for special treatment. I'm asking for the opportunity to have the full argument evaluated by a reviewer with the time to consider it, consistent with how the TestFlight review was handled. Support case: 20000112508151. App ID: 6759586097. Submission ID: abdf8b5b-5ea0-46a4-8a0b-fb58320fa701. Thank You

Hello, I'm reaching out regarding my app AUREX (App ID: 6761672161), which has been in "Waiting for Review" status for 17 days with no movement or communication from App Review. Submission details: App: AUREX AI — Investment Portfolio & Crypto Tracker Version: 1.0 (Build 17) Status: Waiting for Review since April 24, 2026 Category: Finance Support Case: 20000111960192 (opened 13 days ago, no response received) Context: All agreements, tax, and banking information are active. There are no messages in the Resolution Center, no warnings, and no visible issues in App Store Connect. The build was uploaded successfully and no further action appears to be required on my side. I understand that review times can vary and that the queue may currently be experiencing higher-than-usual volume. I'm not trying to escalate — I simply want to confirm whether: There is any specific issue or blocker with this submission Any additional information or documentation is required from my side Or whether the app is simply still pending reviewer assignment I would sincerely appreciate it if someone from the App Review team could take a look. Thank you very much for your time.

Bonjour a tous : J'ai payé Samedi à environ 3h PM (Paris) les 99 $ demandé pour publié une APPS, il m'ont demandé très peut de temps après ma carte d'identité Française vers 05h PM (Paris), je l'ai envoyé vers 20 Heure (Paris), hors depuis je n'ai aucun retour. J'ai envoyé un E-mail au support vers 10h AM (Paris). Hors depuis aucun retour, pouvez-vous m'aidé ?

Hello Everyone, Like probably several other Enterprise customers and more, we have been bitten by a bug with regards to VPN and Endpoint Security and the new M5 / M5 Pro SoCs shipping in the latest MacBook devices. I have raised the following feedback IDFB22753954 (which itself references an internal issue I believe, if we need to mark it as a dupe: 172793638 ). The technical sequence leading to the crash is as follows I believe: The macOS system process neagent successfully initializes the GlobalProtect network extension. The GP Network extension transitions from an 'inactive' state to a 'running' state. As network traffic begins flowing through the extension, a critical flaw in the macOS kernel's memory allocation (specifically related to the Apple Network Extension framework) is triggered. This memory management failure at the kernel level results in a kernel panic at an unpredictable point during packet processing. Because this is a core operating system vulnerability, any third-party application or security solution that leverages Apple's Network Extension framework is susceptible to these crashes. This has been confirmed across multiple vendors within the cybersecurity industry from what I understand. Crashes_M5Pro_1.txt Thank you in advance for your help! Kind Regards, Goffredo

I cant sign up for an Apple Developer Accnt. Error Screenshot attached

Hi everyone, I am working on an iOS app with a subscription-based model, and I need some clarification regarding App Store Review Guideline. The app allows one account holder to manage access for multiple people under the same account. Each person may need subscription-based access to certain digital features within the app. In this scenario, the subscription requirement is not limited to a single user under one Apple ID. The account holder may add multiple members/dependents, and access may vary based on the subscription status associated with those people. My question is: If the subscription is managed through our backend and the app locks or unlocks digital features based on that subscription status, would Apple consider this a violation for not using In-App Purchase? I would like to understand whether Apple expects In-App Purchase to be implemented in this type of multi-person subscription model, even when the subscription is managed at the account/member level rather than as a simple single-user plan. Any guidance or experience with similar review scenarios would be helpful. Thanks.