Overview

Environment: iPadOS 27 Beta (Developer Beta) iPad with Bluetooth Classic (iAP2/ExternalAccessory) + BLE active session App uses UIKit, WKWebView, scene-based lifecycle Problem: When the user invokes the new Siri AI by long-pressing the power button while our app is in the foreground with an active Bluetooth Classic session, we observe: No scene lifecycle callbacks fire — no sceneWillResignActive, no sceneDidEnterBackground, nothing. We confirmed by logging every UISceneDelegate method. Main thread / data processing threads are starved for ~2 seconds, causing a backlog of incoming Bluetooth data. Our real-time data processing latency jumps from ~105ms to over 2,300ms within 2 seconds of Siri activation. CADisplayLink / requestAnimationFrame callbacks show a ~935ms gap coinciding with the Siri overlay appearance, then irregular intervals afterward. The Bluetooth Classic transport (ExternalAccessory/iAP2) remains physically connected throughout — the issue is purely host-side processing starvation. What we've ruled out: BLE link degradation: firmware-side diagnostics confirm 100% data delivery, 0 lost packets during the incident Memory pressure from our app: our process memory stays flat; system-available memory drops ~14 units externally Questions: Is the absence of sceneWillResignActive when Siri AI activates on iPadOS 27 intended behavior, or a beta bug? The new UIApplication.systemPrefersReducedResourceUsage property (iPadOS 27 beta) — is this intended to signal system overlays like Siri consuming resources? Does the corresponding systemPrefersReducedResourceUsageDidChangeNotification fire when Siri activates? Are there recommended patterns for apps with real-time Bluetooth data processing to maintain thread priority during system overlays? We currently use default QoS for our data processing dispatch queues. The processing starvation causes the waveform display to degrade (appears as a connectivity issue to the clinician) even though the wireless link is healthy. We need either: A notification that a system overlay is active, so we can adjust our UI accordingly Guidance on maintaining processing priority during Siri AI activation Any community insight on workarounds would be highly appreciated. Thanks.

I'm seeing a regression in SwiftUI Charts on iOS 27 beta 1. Any view placed inside a BarMark's overlay annotation no longer receives the size of the parent BarMark. It collapses to zero, so any content sized from geo.size (e.g. a Rectangle meant to fill the bar) renders empty or incorrectly. Expected: The GeometryReader reports the BarMark's rendered width/height, and the Rectangle fills the BarMark (this is the behavior in iOS 26 and earlier). Actual: On iOS 27 beta 1, geo.size is effectively zero, so the overlay content has an extremely small size. I suspect this could be a small bug with the new ContentBuilder / ViewBuilder changes but that's just a hunch. Here's a code sample which reproduces the issue. // MARK: - Mock Data Models struct ScheduleSeries: Identifiable { let id = UUID() let data: [ScheduleItem] } struct ScheduleItem: Identifiable { let id = UUID() let startDate: Date let startHour: Double let endHour: Double let secondaryText: String? } // MARK: - Minimal Reproducible Example struct ContentView: View { // Generate two consecutive days for the mock data let mockSchedule: [ScheduleSeries] = [ ScheduleSeries(data: [ ScheduleItem( startDate: Date(), startHour: 9.0, endHour: 11.5, secondaryText: "Morning Event" ), ScheduleItem( startDate: Calendar.current.date(byAdding: .day, value: 1, to: Date())!, startHour: 13.0, endHour: 16.0, secondaryText: "Afternoon Event" ) ]) ] var body: some View { VStack(alignment: .leading) { Text("FB: Annotation Sizing Bug") .font(.headline) .padding(.bottom, 8) Text("Expected: The gray Rectangle should stretch to fill the BarMark.\nActual: GeometryReader/Annotation fails to size to the parent BarMark.") .font(.caption) .foregroundColor(.secondary) .padding(.bottom) Chart(mockSchedule) { series in ForEach(series.data, id: \.startDate) { element in BarMark( x: .value("Day", element.startDate, unit: .day, calendar: .current), yStart: .value("Start", element.startHour), yEnd: .value("End", element.endHour), width: .ratio(0.99) ) .annotation(position: .overlay, alignment: .topLeading) { item in ZStack { VStack(alignment: .leading, spacing: 0) { // BUG DEMONSTRATION: // This GeometryReader and Rectangle previously filled the BarMark, but in Xcode 27 it does not GeometryReader { geo in Rectangle() .fill(Color.black.opacity(0.15)) .frame(width: geo.size.width, height: geo.size.height) } } .foregroundColor(.white) .font(.caption2) } } } } .chartYScale(domain: 0...24) // Lock the Y-axis to a 24-hour scale } .padding() } } Environment: Xcode 27 beta 1 / iOS 27 beta 1 Reproduces on device and Simulator Worked as expected on iOS 26 and earlier Here's what the issue looks like in our app with zero code changes: iOS 26 iOS 27 I've filed a feedback report (FB23016343) with a sample project attached. Has anyone else hit this, or found a workaround for sizing overlay annotation content to a BarMark in iOS 27? Thanks!

On Mac Catalyst 26, a Button bar item in a bottom toolbar look squished. This happens only when the "Mac Catalyst Interface" option is set to "Optimize for Mac". When it is set to "Scale to match iPad", the buttons look fine. For example, in the screenshots below, the text button should say "Press Me", instead of "…" A simple reproducible snippet and a screenshot below. The toolbar button comparison between "Scale to match iPad" and "Optimize for Mac" are shown. Optimize for Mac Scale to match iPad import SwiftUI struct ContentView: View { @State private var selectedItem: String? = "Item 1" let items = ["Item 1", "Item 2"] var body: some View { NavigationSplitView { List(items, id: \.self, selection: $selectedItem) { item in Text(item) } .navigationTitle("Items") } detail: { if let selectedItem = selectedItem { Text("Detail view for \(selectedItem)") .toolbar { ToolbarItemGroup(placement: .bottomBar) { Text("Hello world") Spacer() Button("Press Me") { } Spacer() Button { } label: { Image(systemName: "plus") .imageScale(.large) } } } } else { Text("Select an item") } } } }

Dear Apple, I am trying good to find things that can be upgraded, and trust me here, the MagSafe 4 (or keep its name MagSafe 3 if you want) will be truly amazing. Adding a yellow to mimic macOS window controls will be amazing, and exactly how apple want things to be, they want it to feel like 1 ecosystem, where everything is in sync together. I gave the code in the other post, and here it is again, please really take this in for macOS 27. I tried installing the beta on a separate APFS volume on my Mac, but since I have no other backup device, I decided to stop. I would love to send feedback through feedback assistant, but since im not running beta, I shouldn't really use it, so here I am. Here is some code to help with this: (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) #include <stdbool.h> #include <stdint.h> typedef enum { MODEL_AIR, MODEL_PRO } MacModel; typedef enum { LED_OFF, LED_SOLID_AMBER, LED_SOLID_YELLOW, LED_SOLID_GREEN, LED_PULSING_AMBER, LED_PULSING_YELLOW } LEDState; uint32_t current_cycle_seconds = 0; MacModel get_mac_model(void); uint8_t get_battery_soc(void); uint8_t get_charge_limit(void); uint32_t get_charger_wattage(void); bool check_hardware_faults(void); void apply_led_hardware_state(LEDState state, bool pin_high); void update_magsafe_led(void) { MacModel model = get_mac_model(); uint8_t soc = get_battery_soc(); uint8_t limit = get_charge_limit(); uint32_t wattage = get_charger_wattage(); bool overcharge_fault = (soc > (limit + 2)); bool critical_error = check_hardware_faults() || overcharge_fault; bool slow_charger = false; if (model == MODEL_AIR && wattage < 30) { slow_charger = true; } else if (model == MODEL_PRO && wattage < 70) { slow_charger = true; } LEDState normal_state; if (soc >= 90 || soc >= limit) { normal_state = LED_SOLID_GREEN; } else if (soc >= 50) { normal_state = LED_SOLID_YELLOW; } else { normal_state = LED_SOLID_AMBER; } LEDState active_state = normal_state; bool should_pulse = false; if (current_cycle_seconds < 10) { if (critical_error) { active_state = LED_PULSING_AMBER; should_pulse = true; } else if (slow_charger) { active_state = LED_PULSING_YELLOW; should_pulse = true; } } bool led_pin_high = true; if (should_pulse) { if (current_cycle_seconds % 2 != 0) { led_pin_high = false; } } apply_led_hardware_state(active_state, led_pin_high); current_cycle_seconds++; if (current_cycle_seconds >= 20) { current_cycle_seconds = 0; } } (THIS CODE IS TO SHOW THE BASE OF THE IDEA, PLEASE DONT COPY-PASTE, DOUBLE CHECK IT FIRST. Consider that I didn’t code this myself, I got help. Don’t expect any code from me to be mine) This should show: Pulsing Amber for critical issues Pulsing yellow for slow chargers, under 30w for Macbook air and if under 70w for Macbook pro. ( can be edited in the future for the leaked MacBook ultra) Pulses for 10 seconds, and shows the light of the battery percentage for 10 seconds. Amber: 0-50% battery Yellow: 50-90% battery Green: 90%+ battery or reached charging limit. This will also be very useful if there is a slider to customize what range should be amber, yellow and green. Why? Turning MagSafe into a real dashboard that is more useful than charging or charged, will make it amazing, covering a bit of the price hikes the world is facing. Other than that, apple always wanted things to be as useful as possible. If MagSafe now has what I mentioned, from a glance from afar, people will know their SoC. Please take this in consideration, and I already appreciate the work done on it if it's being tested. I am pretty sure there will be high interest in the topic. Thanks to whoever is working to it, and hope it come alongside macOS 27. Another person suggested MagSafe turned green when reached charging limit, and it happened in macOS 26. May mine be considered too? Trust me, it will be worth it, making MagSafe from just a wire to a smart dashboard. I know apple care about this, and let MagSafe be an upgrade, covering the price hikes and shortages. Thank you very much, and im sure you will do it to make MagSafe the best charger ever. Many thanks, Alyaman

In the Swift docs, it says cancellation uses a cooperative model, which I understand as that all jobs (ie function calls) need to handle cancellation manually even if the task containing them got cancelled. I am assuming this is still the case even with using the SwiftUi.task? The documentation for it should include a reference for how cancellation works to be complete.

StoreKit 2 returns zero subscription products in Sandbox/TestFlight — FB24199369 I’m experiencing an issue where StoreKit 2 returns zero subscription products in both Sandbox and TestFlight for my iOS app. App: Bundle ID: com.sleeplessnight.naengbiseo Subscription group: Naengbiseo Premium Product IDs: naengbiseo_premium_monthly naengbiseo_premium_yearly Although the production app uses RevenueCat, I reproduced the same issue in a separate minimal native SwiftUI app using StoreKit 2 directly, with no RevenueCat, Expo, React Native, or other third-party SDK involved. Native StoreKit 2 call: let products = try await Product.products(for: [ "naengbiseo_premium_monthly", "naengbiseo_premium_yearly" ]) Current native test result: STOREKIT_COUNTRY_CODE: KOR STOREKIT_STOREFRONT_ID: 143466 DIRECT_STOREKIT_COUNT: 0 Returned products: None Test environment: Physical iPhone StoreKit Configuration: None Sandbox Apple Account signed in Storefront: KOR In-App Purchase capability enabled Correct Bundle ID and Product IDs I have rechecked the following configuration: The subscriptions are available in the test storefront Subscription pricing is configured Subscription localization is configured Paid Apps Agreement, banking, and tax information are active App ID has In-App Purchase enabled The App Store/TestFlight build has the expected Bundle ID, provisioning, and signing configuration I also created a StoreKit Configuration file using “Sync this file with an app in App Store Connect”. The sync completed, but the resulting configuration contained: products: [] subscriptionGroups: [] The same subscriptions also fail to load in TestFlight. The subscription products currently show Rejected in App Store Connect because the associated app version was rejected. App Store Connect states that the subscriptions were returned because the associated app was rejected and will remain Rejected until resubmitted for review. However, App Review also stated: “In-App Purchase products do not need prior approval to function in review.” I have reviewed TN3186 and have not found a remaining developer-side configuration issue that explains why Product.products(for:) returns zero products. Since the issue reproduces in a minimal native StoreKit 2 app, this does not appear to be caused by RevenueCat or another third-party SDK. Feedback Assistant: FB24199369 Could an App Store Commerce / StoreKit engineer advise whether there is any remaining developer-side configuration that could cause this, or whether the subscription catalog / app association may need to be reprocessed on Apple’s side? Thank you.

Organization enrollment was denied with the standard "for one or more reasons" template, no reason given. Background: Apple's D-U-N-S lookup returned a number for my company and Apple emailed confirming I could enrol with it. Enrollment then rejected that same number as a branch record. D&B turned out to have two records for the company, a headquarters record at a former address and a branch record at the current one, following a relocation. I ran a D&B correction case, submitted the requested documents, and the records were consolidated. Corrected details went to Apple. I had also sent verification documents to Developer Support and receipt was confirmed. The denial came after all of that. Individual enrollment also would not complete during the same period. What I'm trying to find out: Anyone had this generic denial after fixing a D-U-N-S issue, and did a later resubmission succeed? Does an open organization enrollment block individual enrollment on the same Apple Account? Any route to getting the actual reason? Support says they can't see it. How long to wait before resubmitting, and same Apple Account or fresh?

On iOS, ScreenCaptureKit terminates an SCStream when the app is backgrounded unless the app declares UIBackgroundModes: screen-capture. The delegate reports SCStreamError code -3824 (SCStreamError.Code.missingBackgroundMode). Adding screen-capture to UIBackgroundModes - the value Apple's own iOS 27 ScreenCaptureKit sample code declares - makes App Store Connect reject the upload: error: exportArchive Invalid Info.plist value. The Info.plist key UIBackgroundModes contains an invalid value: 'screen-capture'. So the app cannot be distributed at all, not even to TestFlight internal testers. We have ruled out simply keeping the process alive: running a continuous silent AVAudioEngine under the audio background mode keeps the app running but does not prevent -3824, which is consistent with the framework performing an explicit background-mode check rather than the stream dying from process suspension. One observation that may explain why this has gone unnoticed: Apple's sample is installed directly from Xcode and therefore never passes through App Store Connect's upload validation, so a mismatch between the sample's Info.plist and App Store Connect's allowlist would not be visible when testing the sample internally. My question is which of these three describes the actual status of screen-capture for third-party iOS apps: (1) App Store Connect's allowlist has not yet been updated for iOS 27, and this will resolve on its own. (2) screen-capture requires an entitlement or a specially provisioned profile we have not requested. If so, which one, and how is it requested? (3) screen-capture is restricted to Apple's own or system applications and is not available to third-party App Store apps by design. I could not find screen-capture documented on the general UIBackgroundModes page, which is why I cannot tell these apart. Filed as FB24169650. Device: iPhone 16 Pro, iOS 27.0 Built against the iOS 27 SDK, deployment target 17.0.

I've been trying for months to get Gemini 3.5 Flash to work with Xcode 27 Beta (1-3) agentic coding but have failed. Xcode currently uses Gemini CLI v0.42.0 from last year, so it can't call Gemini 3.5 Flash even though all that needs to change is a few characters in the API call. Gemini users are currently forced to choose between 3.1 Pro and 3.1 Flash Preview--both weren't the best choices two months ago, but with the release of 3.6 Flash which is better at coding that 3.1 Pro and miles cheaper, these choices are now unsuitable for any serious workload. I live in Hong Kong, where OpenAI and Anthropic services aren't offered, so Google is the only (native) AI provider for Xcode agentic coding. The cost issue from funneling all the work into 3.1 Pro is terrible especially with some agent bugs that have yet to be ironed out. Given Apple's close partnership with Google on AI, I'm genuinely surprised that after 4 Betas we're still using a Gemini CLI from 2025 that forces users to choose between two very unappealing models. Xcode is basically forcing Google users to switch to OpenAI/Anthropic. Questions: I'd like to know if this will be fixed soon and whether Google users should expect slower updates (i.e. be forced to use older models). Does anyone know of any workarounds?

I’m experiencing what appears to be a team/account-level TestFlight backend issue, and it is currently blocking my development workflow. Team ID: TJ6F83PA4W What happened All existing TestFlight builds across my apps suddenly became Expired / unavailable. This happened across the developer team rather than to one particular app or build. I then uploaded a completely new build to determine whether the previous builds had simply been reset or invalidated. Test app: RESON | See the frequency. Apple ID: 6799940431 Version: 1.0.0 Build: 2 The new build: Uploaded successfully Processed successfully Appears normally in TestFlight Shows a fresh 90-day testing period Has an active Install button But installation immediately fails with: Could not install RESON | See the frequency. The requested app is not available or doesn’t exist. So this does not appear to be normal build expiration. A completely new and successfully processed build is also affected. Troubleshooting / support I have already opened an Apple Developer Support case: Case ID: 20000133520102 I’ve contacted Developer Support multiple times by email and also requested/spoken through phone support, but the issue remains unresolved and is now blocking my TestFlight workflow. I have intentionally not started changing certificates, provisioning profiles, Bundle IDs, or repeatedly uploading replacement builds because the symptoms affect the entire team and appear to occur at the TestFlight distribution stage. I’ve also seen reports from other developers describing similar symptoms, including references to BETA_CONTRACT_MISSING / missing Beta Contract backend state. I cannot confirm that this is the cause on my account, but the symptoms appear similar. Question for Apple / other developers Has anyone experienced this exact combination? All TestFlight builds unexpectedly expire → new builds process successfully → builds appear available for 90 days → installation fails with “The requested app is not available or doesn’t exist.” If someone from App Store Connect / TestFlight engineering sees this, could you please advise whether the Beta Contract / TestFlight distribution provisioning state for the Developer Team needs to be checked or re-provisioned server-side? Any confirmed workaround or escalation path would be greatly appreciated.

Hello App Review team, Our first submission has been in "Waiting for Review" for nine days and has never entered "In Review." There are no messages in Resolution Center and no requests for additional information. App name: Farm Tech Ready Apple ID: 6796078026 Platform: iOS Version / Build: 1.0 Submitted: August 3, 2026 at 1:16 PM Status inquiry filed via Contact Us: August 10, 2026 This is a free educational self-assessment tool published under a University of Wisconsin-Madison team account for agricultural producers. No user accounts, no data collection, no in-app purchases. Could someone confirm whether this submission is queued correctly or whether something is blocking it from entering review? Thank you.

Summary: The "In-App Purchases or Subscriptions" selection section does not appear on my app version page, so I cannot attach my first In-App Purchase to my build. This has caused four consecutive Guideline 2.1(b) rejections. Setup: App: Qmetra IQ (Apple ID 6791254506, Bundle ID com.vibecode.qmetraiq.londa9) First app release, never published App version 1.0, current build 1.0.1 (2) Non-consumable IAP: com.vibecode.qmetraiq.londa9.results (Apple ID 6792799431) IAP status: Ready to Submit App Review screenshot for the IAP: uploaded (1242×2688) Paid Apps Agreement signed, banking and tax complete, no open items under Business What I see: On the version page, the "In-App Purchases or Subscriptions" heading exists, but contains only an informational message ("...add an app version to your submission so the items are reviewed together..."). There is no button, link, checkbox, or "+" to select the IAP. The submission draft panel contains only the app version, with no way to add the IAP. Opening the draft from the IAP page shows only the IAP, with the warning "Cannot be submitted for review — add an app version for the selected platform", and the "Submit for Review" button greyed out. What I have tried: Removed the previous rejected submission from review, then rechecked the version page — section still absent Assigned a fresh build (1.0.1 build 2) and saved Re-saved the IAP metadata Resubmitted the app version alone — rejected again under 2.1(b) Replied in the review thread twice — no resolution Rejection reason each time: "one or more of the In-App Purchase products have not been submitted for review." Could an Apple staff member please forward this to App Store Connect Support or engineering so the In-App Purchase can be moved to In Review manually? Several older threads describing this exact bug were only resolved that way. Happy to share more details privately if needed. Thank you.

I paid the membership fee but my account is not enabled for app store connect yet. I tried calling customer support, waited on the line for 3 hours but no one picked it up. Is there anyone here who can help?

Has anyone else been experiencing unusually long app submission review times?We submitted our app for review almost a week ago (6 days) and the status is still "waiting for review". It's never taken this long before. Wondering if anyone else is experiencing unusally long wait times due to their review team being backed up, or if something unusual is up with our app...

The Wait time for an app to get on the store is CRAZY. I have waited for months to get an app reviewed and completed to live. Its a bad experience with the app store no wonder a lot of people shay away from this. Even when you call support they say sorry nothing we can do. The last review correction and re-upload has been there for ever 10 days and the App is suppose to be live by now. How do you seek help if there is no one that can help?

Hi Apple Developer Community, I’m preparing an iOS app called Titech for App Review. The app is intended for clinic/business users and provides preliminary AI-generated cosmetic analysis and preview guidance based on user-submitted face photos. The app is not intended to provide medical advice, diagnosis, or treatment decisions, and users are told to consult qualified experts before acting on any recommendation. We have received multiple App Review rejections and I would appreciate guidance on whether our current approach is aligned with Apple’s expectations. Current issues raised by App Review: Guideline 2.1 - Information Needed Apple asked for more information about how the app uses face data, including: What face data is collected How it is used, stored, retained, deleted, and shared Whether it is shared with third parties Where this is explained in the privacy policy Exact privacy policy text about face data We updated the app and privacy policy to explain that: Users voluntarily upload front, left-side, and right-side face photos Photos may be sent to our backend and processed by OpenAI through the OpenAI API Face ID/fingerprint data is not collected Uploaded face photos and generated preview images are deleted after the active session ends The app does not sell face data or share it with advertisers/data brokers Guideline 2.1(b) - Information Needed Apple asked about the business model and whether users access paid content. Our app does not currently include paid digital content, subscriptions, credits, or in-app purchases. Access is controlled by a registration code for clinic/business users and App Review only. Guideline 2.3.3 - Accurate Metadata Apple said the screenshots did not show the current version of the app in use. We replaced the screenshots with updated iPhone and iPad screenshots showing: Clinic access Consent and face-data disclosure Photo capture AI-generated analysis Recommendations Side effects page Generated preview flow My questions: For apps using user-submitted face photos with a third-party AI API, is it enough to clearly disclose OpenAI processing in the consent screen and privacy policy, or should this also be repeated elsewhere in the app flow? For face photos that are deleted after the active session ends, what wording does Apple generally expect around retention and deletion? Since the app is clinic/business access only and does not sell digital content, is a registration code acceptable if we clearly explain that it is not a paid digital unlock? Are there any additional App Review notes or privacy policy sections that developers usually include for apps involving face photos and AI-generated preliminary recommendations? For metadata, should the screenshots avoid login/consent screens entirely, or is it acceptable to include them as long as most screenshots show core app functionality? Any advice from developers who have passed review with apps involving user-uploaded face photos, AI analysis, or cosmetic/health-adjacent recommendations would be very helpful. Thank you.

Hi, I'm hoping someone from App Review can help, as email support has not resolved this. We publish digital magazine apps where each new issue is sold as a separate in-app purchase. Two of our IAPs have now been stuck in "Waiting for Review" / "In Review" for 3-4 weeks, well beyond the normal 24-48 hour turnaround we've seen on previous submissions. Because of this, we are currently unable to sell our product to paying customers. Readers cannot purchase the current issues at all. This is actively affecting live revenue, not just a delayed update. We've already sent two emails to Developer Support with no meaningful response beyond being asked to keep waiting, and a Contact Us request through App Store Connect has not moved things forward either. Could someone from App Review please look into why these specific IAP submissions have been stuck for so long, and help move them forward? I'm happy to provide the App ID / bundle ID and IAP product IDs privately to a verified Apple team member. Thank you for any help you can offer.

Hi Everyone, I really hate to be that guy but I was wondering if anyone else has been waiting as long as I have to get their app reviewed? I have an app that I put up for review July 30th and now we're on the 12th day waiting. (By the way, if you are an apple employee and you happen to see this message and want to help, the app is called Sudoku Every Day - Paper & Pen and the submission ID is f6750769-9018-4236-b413-ea07bc05d907). I know they are experiencing a backlog right now, and I've been patient understanding that. I guess I'm just a little frustrated because I see people on social media who supposedly put their app in after me that have already been approved, although I get that that's just random luck of the draw probably. Do you all think it's possible my app is stuck though? Should I request an expedited review? I kind of don't want to do that just because I bet everyone is doing that with the backlog and I don't believe I qualify for it. I do have a big update ready since I've added a lot of variants to my app in the last few weeks. That's ready to go but that's not really time critical ..... Another thing I was wondering is could this have something to do with the fact that I first tried to submit it after building in Xcode 27 beta? The beta builds kept getting auto-rejected so I had to eventually submit a build that I made on another computer (MacOS 26.6/Xcode 26.6) to get it to be accepted into review but that was the 6th build. Is there a chance my previous builds getting auto-rejected put me on some slow train to app review? Just curious to hear others experiences. If you made it all the way to the end of this, thanks for reading! -E

Title: In-App Purchases Stuck on “Ready for Review” After App Submission I’m running into an issue in App Store Connect with several consumable In-App Purchases. I have four IAPs that currently show Ready for Review: MetaOp 250k Burst (Free Tier) MetaOp 250k Burst (Paid Tier) MetaOp 500k Burst (Free Tier) MetaOp 500k Burst (Paid Tier) I previously added these IAPs to a submission and later removed them. I have now submitted the app version again, and the app itself is showing Waiting for Review, but these four IAPs are still listed under Drafts as Ready for Review. The issue is that I cannot select them from the In-App Purchases list or attach them to the current submission. They also did not move into the submitted review package when I submitted the app. Has anyone seen this behavior before? Is there a way to reset these IAPs back to Prepare for Submission, or otherwise attach/submit them separately without withdrawing the app version that is already Waiting for Review?

Hello, Our first app submission has been in "Waiting for Review" since Aug 4 with no status change (7 days). Submission ID: ff94d9d2-355f-4e9d-80ec-754d2f115a1f We got rejected due to metadata changes required and we are way behind of our release timeline. The App Review Information section includes a demo account for the business panel, and the customer side is usable without login. Any information about the status would be appreciated. Thank you.