Hello Apple Team, I’ll be attending the Battery and Performance Optimization Lab this Thursday, and I’d like to prepare as thoroughly as possible to get the most value from the session. I’m particularly interested in understanding what I can do beforehand to identify optimization opportunities in my app and arrive with useful performance measurements and actionable questions. I would appreciate your guidance on a few areas: Xcode configuration: Are there specific build settings, diagnostic options, profiling configurations, or performance-related settings I should enable or review before the lab? Performance measurement: Which Instruments templates, metrics, or profiling workflows would you recommend using beforehand to establish a meaningful baseline for CPU usage, memory, energy consumption, and battery efficiency? Preparation: What measurements, diagnostic reports, or reproducible test scenarios would be most useful to bring so we can spend more time investigating optimization opportunities rather than establishing a baseline? Technical resources: Are there specific WWDC sessions, documentation, or technical concepts you recommend reviewing to better understand how iOS manages energy consumption, background execution, and performance? Prioritization: What are the most important things developers should understand before attending this lab, particularly when optimizing an application that performs continuous on-device processing and audio playback? iPhone Duo testing: Will the engineering team have iPhone Duo demonstration or development units available during the lab for testing and profiling applications on actual hardware? My app includes Duo-specific multitasking and display adaptations, and I’d particularly value the opportunity to evaluate performance, battery efficiency, and resource usage on the device. My goal is to arrive with a well-profiled application, a clear understanding of its current performance characteristics, and enough preparation to make the session as technically productive as possible. Thank you for your guidance. I’m looking forward to learning from the team on Thursday!

Since iOS/iPadOS 27.0 (also macOS 27.0), saving a PDF with PDFDocument.dataRepresentation() (or write(to:)) writes every stream whose raw length is 0 as an empty indirect object: 6 0 obj endobjThat object is null, not a stream. When it is referenced from a page's /Contents array, Adobe Acrobat/Reader renders the whole page blank. Browser PDF viewers tolerate it, so the corruption is easy to miss. qpdf --check reports empty object treated as null and ignoring non-stream in an array of streams. No edits are needed to trigger it. Zero-length content streams are legal and fairly common; for example, PDFs generated by TallComponents PDFKit.NET contain a << /Filter /FlateDecode /Length 0 >> content stream on every page. In our case users sign such documents in an iPad app (custom PDFAnnotation) and we upload the result of dataRepresentation(); on iPadOS 27 every one of them opens blank in Acrobat. Minimal repro (builds a 1-page PDF whose /Contents is [text stream, zero-length stream], then re-serializes it): import PDFKit func minimalPDF() -> Data { let objects = [ "<< /Type /Catalog /Pages 2 0 R >>", "<< /Type /Pages /Kids [3 0 R] /Count 1 >>", "<< /Type /Page /Parent 2 0 R /MediaBox [0 0 595 842] /Resources << /Font << /F1 5 0 R >> >> /Contents [4 0 R 6 0 R] >>", "<< /Length 36 >>\nstream\nBT /F1 24 Tf 72 700 Td (Hello) Tj ET\nendstream", "<< /Type /Font /Subtype /Type1 /BaseFont /Helvetica >>", "<< /Length 0 >>\nstream\n\nendstream", // legal zero-length stream ] var pdf = "%PDF-1.7\n", offsets: [Int] = [] for (i, body) in objects.enumerated() { offsets.append(pdf.utf8.count) pdf += "\(i + 1) 0 obj\n\(body)\nendobj\n" } let xref = pdf.utf8.count pdf += "xref\n0 \(objects.count + 1)\n0000000000 65535 f \n" offsets.forEach { pdf += String(format: "%010d 00000 n \n", $0) } pdf += "trailer\n<< /Size \(objects.count + 1) /Root 1 0 R >>\nstartxref\n\(xref)\n%%EOF\n" return Data(pdf.utf8) } let saved = PDFDocument(data: minimalPDF())!.dataRepresentation()! print(String(decoding: saved, as: UTF8.self).contains("obj\nendobj") ? "BROKEN: null object written" : "OK")iOS 18.1: OK (PDFKit re-renders the page through Quartz). iOS 27.0 (24A5370g) / macOS 27.0 (26A428): BROKEN. With CG_PDF_VERBOSE=1 CoreGraphics logs writeStream: Failed to get data from stream. What triggers it: only the raw (encoded) length being 0. It happens with or without /Filter /FlateDecode, for a single /Contents stream, and for a zero-length Form XObject. A FlateDecode stream holding an 8-byte compressed empty payload (decoded length 0) is written correctly, so it is not about the decoded data. Where it seems to come from: iOS 27 introduced a structure-preserving serializer in CoreGraphics (CG::PDFDocumentSerializer). Its writeStream emits N 0 obj, asks for the stream's raw bytes, and when that returns NULL it logs the error above, skips the dictionary/stream/endstream, but still emits endobj. A legal empty stream returns NULL there, so it is treated as a read failure. Workaround we ship: after dataRepresentation(), find the empty objects (N G obj immediately followed by endobj) that are referenced from a page's /Contents, and append an incremental update that redefines them as << /Length 0 >>\nstream\n\nendstream, with a new xref section and a trailer whose /Prev points at the original startxref. The original bytes are untouched, so signatures/annotations written by PDFKit stay as they are, and files from iOS 18 (which contain no such objects) are returned unchanged. Filed as FB25282060. If you hit this too, please file a duplicate referencing that number. Possibly related iOS 27 save-path regressions: https://developer.apple.com/forums/thread/851708 (16-bpc annotation images truncated).

Adding my case to this thread. Two apps, both first-time submissions: YAA (delivery app) YAA PRO (courier companion app) Submitted: 14 October 2026 Status: "Waiting for Review" for twelve days, never entered review. On 26 October I cancelled both submissions and resubmitted them, after noticing that my Free Apps agreement only became effective on 19 October — five days after the original submission. My DSA trader status was also incomplete at first and is now active. It is now 28 October and both are still "Waiting for Review", around 50 hours after resubmission. I have an open case with Developer Support, no reply yet. Two questions for the thread: Has anyone confirmed whether cancelling and resubmitting resets your position in the queue? I may have made things worse. Has anyone whose agreement became effective after their submission date seen that cause a delay? Both apps are blocked identically, which makes me think it is not app-specific. Good luck to everyone else waiting.

Hi everyone, I'm experiencing a significant difference in SwiftUI layout behavior between the iPhone Duo simulator and a physical iPhone Duo. I've already adjusted my layout to work correctly in the simulator, but the same app behaves differently on the actual device. 1. Folded Simulator: The tab bar is positioned on the right side, as expected for iPhone Duo. The view respects the right-side layout, and scroll views extend naturally behind the tab bar, behaving as expected. Physical device: The tab bar appears at the bottom, like a regular iPhone, instead of on the right. The view is also cropped on the right side. 2. Unfolded Simulator: The tab bar and navigation view both appear correctly. Physical device: The tab bar remains at the bottom, even in landscape orientation, instead of using the expected Duo layout. The main content also starts from the bottom of the navigation view, resulting in an incorrect layout. The most confusing part is that the layout works correctly in the simulator but not on the physical device. Has anyone encountered this behavior on a physical iPhone Duo? Could this be related to the iOS version, SDK version, SwiftUI's automatic tab bar adaptation, or a device-specific bug? I'd appreciate any insights, especially from developers who have tested their SwiftUI apps on actual iPhone Duo hardware. Environment: Xcode version: 27.1 iOS SDK: 27.1 Physical device iOS version: 27.2 Thanks!

Really disappointed after raising expedited review , its been 7 days and there is no update on the progress made so far.

Is there a process or Apple contact for requesting expedited review of In-App Event assets? My major update with iPhone Duo support is already approved and live, but the associated In-App Event and creative assets are still pending review. I know it’s the weekend, but I’m hoping to have the event live by Tuesday, October 27, at 9 AM PDT, to coincide with the launch. Thank you so much!

Hello, I'm hitting a persistent CKQuerySubscription save failure on the public database in my Production CloudKit container. I want to flag this is NOT the iOS 26.4 silent-push regression resolved in 26.4.1 (I've confirmed it manifests differently and on devices that predate that bug). App: Win 10 Min (com.luiz.PandaApp) Container: iCloud.com.luiz.PandaApp Current shipping version: 3.2.1 build 420 (approved 2026-05-19) Public database THE ERROR (captured from CKError.userInfo) CKErrorCode 12 (badRequest) CKInternalErrorDomain code 2006 ("BadSyntax") ServerErrorDescription: "attempting to create a subscription in a production container" Execution time per failed attempt: 45-90ms (gateway-level rejection, not data validation). CODE let subscription = CKQuerySubscription( recordType: "GuardianRequest", predicate: NSPredicate(format: "guardianRecordName == %@", me), subscriptionID: "guardian-incoming-(me)", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.shouldSendContentAvailable = true subscription.notificationInfo = info try await container.publicCloudDatabase.save(subscription) The .save() throws every time. REPRODUCES ACROSS iPhone on iOS 26.4.2 (i.e., has the 26.4.1 CloudKit regression fix) iPhone on iOS 18.6.x (predates the 26.4 regression entirely) Multiple distinct Apple IDs / userId hashes Fresh installs via TestFlight Updated installs from production CONSISTENTLY: USER_ERROR / BAD_REQUEST. Same error every time. WHY THIS ISN'T THE iOS 26.4 REGRESSION (Thread 820562) That regression caused silent notifications to be DROPPED client-side AFTER successful subscription creation. Our failure is SubscriptionCreate itself being rejected by the CloudKit server before any subscription exists. Different layer, different symptom. iOS 18.6.x devices also fail (they never had the 26.4 token-validation regression code). CLOUDKIT CONSOLE LOGS (sample request UUIDs Apple engineers can lookup) EB30E9D0-8C97-4685-BD16-3E79B3328D6F (2026-05-17 8:08 UTC) EEAA0606-5B50-4640-A950-EEA33B790B8E (2026-05-17, captured in-app) EB4C90CE-9172-4942-B00F-DE4A28388FBA (2026-05-19 7:18 UTC, iOS 18.6.x) F2DF69D9-2339-437A-B59B-7FBD4D57442F (2026-05-19 7:51 UTC, iOS 26.4.x) CloudKit Console → Production → Subscriptions: 0 entries despite 70+ attempts since 2026-05-11. WHAT I'VE VERIFIED / TRIED Schema: GuardianRequest.guardianRecordName and GuardianResponse.requesterRecordName both have QUERYABLE indexes in the Production schema (confirmed in Console). Field types: all STRING. aps-environment entitlement: "production" (changed from "development" in build 420; no change in error pattern). Push Notifications capability: enabled on App ID in Developer Portal AND in Xcode Signing & Capabilities for the main app target. UIBackgroundModes: includes "remote-notification". Re-deployed Production schema from Development on 2026-05-19 (Console reported "no changes"; failure pattern unchanged). Tried with and without info.desiredKeys = []. RecordQuery operations on the same fields and record types in the same container succeed consistently. QUESTIONS Is there a known infrastructure issue affecting public database CKQuerySubscription creation that is distinct from the iOS 26.4 regression (thread 820562)? Is there a per-container configuration that may be in an unexpected state, and if so what should I check? Are there workarounds beyond schema redeployment that have helped other developers in similar situations? Thanks for any guidance.

Im going to start posting daily updates of app review status just to count emails and phone called. hours on hold today=6 number of "senior advisors" that emailed back=4 Emails sent=31 Phone calls=47 change=0 Status= waiting for review

I’m building a personal iPhone app that organizes my music library. When I tap an album in my app, I want Apple’s Music app to open directly to that album’s page in Library, showing the tracks synced from my computer. My app can already read the albums and their tracks using MusicKit. I’ve tried normal Apple Music sharing links, but those open the catalog version of the album. I need the page I see when I find the album through Library in the Music app. Starting or changing playback is fine, but the album page must appear. Only starting the music or opening Now Playing would not be enough. Is there a supported API or link format that can do this? A documentation link or a small code example would be helpful.

What's the best practices to adopt iPhone Duo for a production UIKit app? What few things we need to consider during the development? "As long as we use auto layout, it should be fine" is this correct term for iPhone Duo? Meaning, as long as our app use proper auto layout, our app should be able to support iPhone Duo properly.

I have an App where I use the UISheetPresentationController to present a menu as a "drawer" (like the "FindMy" or "Maps") App. Because the sheet is presented over a map, I made the sheet semi-transparent/blurry, so the Map shines through, which looks nice. The sheet is using a UITableView with the "insetGroup" style, so the table cells have the nice rounded borders and there are margins to the sheet borders. When running the App on the iPhone Duo (Simulator) on the outer display, the tableView does no longer respect the "insetGroup" style, it is rendered like it would have the "plain" style, which destroys everything that look good. No rounded borders, no margins. However if I opt-out of the automatic "vertical toolbar behavior" (overriding preferredVerticalBarBehavior so it returns "disabled"), then everything looks great again, however then the sheet content might overlap with the sidebar icons and camera because it now covers the whole area up to the right screen border. Is this supposed to be this way (if yes, why?), is there a way to fix this, or do we have to wait for a bugfix within iOS 27.1? The tableview still claims to have the "insetGrouped" style, just it does not render this way. I did not see any similar issues under other circumstances. Only UISheetPresentationController seems to be affected by this. Is there a way to correctly detect if the App is running on an iPhone Duo, so we could use this detection to add workarounds for such issues?

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

Saving any CKQuerySubscription to the private database fails in the Production environment with CKError 12 (badRequest): “attempting to create a subscription in a production container”. The same subscriptions save fine in Development. The schema, including the needed QUERYABLE index, has been deployed to Production. This looks like the same issue as FB22867235 and Developer Forums thread 826814. Container: iCloud.com.darkstardev.chorecalendar Environment: Production (TestFlight build 0.2 (5)) Device / OS: iPhone18,2, iOS 27.0.1 App: Core Data with NSPersistentCloudKitContainer (private and shared stores), sharing a zone with CKShare Database: privateCloudDatabase of the share owner’s account Zone: the Core Data share zone, com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 Subscription: CKQuerySubscription on recordType CD_Mark predicate CD_status == "waiting" options .firesOnRecordCreation and .firesOnRecordUpdate zoneID set to the share zone Schema: CD_Mark has a QUERYABLE index on CD_status in Production, which I verified in the CloudKit Console. All three notificationInfo variants fail the same way in Production. All three succeed in Development: An alert with titleLocalizationKey, alertLocalizationKey and alertLocalizationArgs ["CD_kidName", "CD_choreName"] A plain alert with titleLocalizationKey and alertLocalizationKey, without args A silent subscription with shouldSendContentAvailable = true and desiredKeys Because even the silent subscription is refused, the cause isn’t the alert configuration. Production refuses CKQuerySubscription creation for this container. Steps to reproduce: Install the TestFlight build, signed in as the share owner. Create and share a family record through NSPersistentCloudKitContainer. Turn on the in-app setting that saves the subscription. Expected: the subscription is saved, and a push arrives when a participant creates or updates a waiting CD_Mark record. Actual: all three saves fail. Error text: “Error saving record subscription with id check-ins-com.apple.coredata.cloudkit.share.7653A214-0824-4D0D-BC02-4270E0826376 to server: attempting to create a subscription in a production container” (CKError 12). Already tried: Deploying the schema from Development to Production. Turning the setting off and on again a day later.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

Updated my iOS apps for the Duo, partially rewriting the interface to better match the Duo and I am a bit puzzled - lets say it this way - that AppStore doesn't show the submitted Duo Screenshots nor the announced ">ready for Duo" badge. Am i the only one - or did I miss something or is it still not rolled out?

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

Our app's first version (1.0.0) was submitted on October 1 and has been in "Waiting for Review" ever since, with no change in status and no messages in App Store Connect. What we've done so far: Confirmed that all agreements are active and there are no pending action items in App Store Connect Sent a status inquiry through Contact Us on October 15. A case was opened, but there's been no reply. Tried to reach Developer Support by phone, but couldn't get through because call volume was too high. It's a free app for a local church congregation. If something on our side is blocking the review, we'd be glad to fix it. Could someone from App Review take a look, or tell us whether the submission needs to resubmitted? We also have a newer version (1.3.x) ready on TestFlight. If it would help, we're happy to replace the submitted build with it. Should we keep 1.0.0 in the queue or resubmit with the newer build? App: New York Chinese SDA Church (Apple ID 6816789535), version 1.0.0. Status inquiry case: 102997976922

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

I submitted my app for review on October 13, and it has been waiting for review ever since. I have already requested an expedited review and contacted Apple Developer Support, but nothing has changed and I have not heard back yet. I worked really hard to build the app and this wait is very discouraging. Please someone help! Submission ID is: 4356e8f3-612d-4faa-b871-ff1c9fef6bdf App ID: 6799765037

Hey Apple Developer Relations, App Review Team, and anyone else reading this,I wanted to share what’s been going on with my app because I’m honestly stuck and not sure what else to do.I’m an indie developer working on Marque: Car Collection — my first iOS app. I paid for the Developer Program, spent a lot of time getting everything ready, fixed the issues from the previous rejection, and submitted a new build.It’s been over a week now and I still have no idea what’s happening with it.Quick timeline: Oct 6: My previous submission got rejected under Guideline 5.1.2(i) (App Tracking Transparency). Oct 14: I submitted a fixed build, version 1.1.0 (24), with an updated ATT implementation, revised App Privacy details, and detailed notes explaining the changes. Since then (11 days as of Oct 25): It’s been sitting in “Waiting for Review” and hasn’t even moved to “In Review.” I’ve contacted Developer Support and asked on the forums, but I haven’t gotten any real answers. No one has asked for more information, explained what’s going on, or given me any idea when the review might actually start.I get that reviews can take longer sometimes, especially with a first app, subscriptions, or privacy-related stuff. I’m not asking anyone to just approve it without looking at it.What bothers me is the complete lack of communication. Right now I have no way of knowing: whether my build is just waiting in the normal queue or if something’s wrong with it when I can realistically plan a launch if there’s any point in contacting support again since I haven’t gotten a useful response so far I’m still paying for the Developer Program, but I have zero visibility into what’s happening with my submission.Apple holds developers to high standards. It would be nice to get at least basic transparency in return.So I have a few straightforward questions: Why has my corrected build been stuck in “Waiting for Review” for 11 days? Is there any way to confirm it’s properly in the queue and not stuck because of some technical or admin issue? Why hasn’t my support request gotten a real response? Is there an escalation path for indie developers when a submission just sits there with no explanation? If Apple can’t provide a status update, what options do developers have when they’re paying for the program but can’t get any information about their release? I’d really appreciate it if someone from Developer Relations or App Review could take a look and give me some kind of explanation (or point me to someone who can).I’d also be interested to hear from other developers who’ve dealt with similar long waits in “Waiting for Review,” especially with first apps.The issue isn’t just that the review is taking longer than expected. It’s that when something seems off, there’s almost no way to figure out what’s actually going on.Indie developers put a lot of time, money, and effort into building for Apple’s ecosystem. Clear communication shouldn’t be this hard.Thanks for reading. Marque Development Team