Hi Apple team, Our latest version of Dora - AI Video Generator (Apple ID: 1604739131) has been sitting in “In Review” for a while now, and I wanted to check if something’s wrong with the submission. We submitted it on Oct 14, 2026 at 10:32 AM, and it’s still not done. Our updates usually get through in a day or two, so this is way out of the ordinary for us. If there’s an issue on our end, just let us know and we’ll fix it right away. If not, we’d really appreciate any help moving the review along. Thanks so much for your help! Best, Smart Widget Labs Team

Hi there! i have a similar issue as this guy (Link), but on my iPhone 14 Pro running iOS 16.4 (20E5229e). Without really using the wallet, it accounts for a huge portion of battery usage (see below). Does anyone of you have a similar issue?

Since iOS/iPadOS 27.0, saving a PDF with PDFDocument.dataRepresentation() produces a corrupt file when a page contains a PDFAnnotation subclass that overrides draw(with:in:) and draws a 16-bits-per-component image. The same code works correctly on iOS 26.4. Filed as FBxxxxxxxx. What happens: The annotation is written with /AAPL:AKExtras, and its appearance (/AP) references an image XObject declared as /BitsPerComponent 16 (RGB). The image stream contains only half of the required data (8-bpc worth). Example: 1429 x 2021 image. Required: 17,328,054 bytes. Actual: 8,664,027 bytes. Adobe Acrobat reports "Insufficient data for an image". Other viewers read the 8-bpc data as 16-bpc, so the drawing is squeezed into the upper half of the page and the lower half is empty. In PDFKit, colors may turn black. The problem is in the writing step: a PDF written on iOS 27.0 is broken everywhere, while a PDF written on iOS 26.4 opens correctly on iOS 27.0. How to reproduce: Create a 16-bpc image with UIGraphicsImageRenderer (preferredRange = .extended, or the default format on a wide-color device). Add a PDFAnnotation subclass whose draw(with:in:) draws that image with context.draw(cgImage, in: bounds). Call dataRepresentation() and reopen the result. Current workaround: Create the image with an 8-bpc standard-range format before drawing it in the annotation: let format = UIGraphicsImageRendererFormat.preferred() format.preferredRange = .standard // 8 bpc, sRGB let renderer = UIGraphicsImageRenderer(size: size, format: format) With this, the declared bit depth and the data length match, and the PDF is valid on iOS 27.0. However, this gives up 16-bpc / wide-color output, so I would prefer a solution that keeps the original image quality. Possibly related: FB24882188 / FB24843022 (iOS 27 regression in PDFAnnotation subclasses that override draw(with:in:)). Questions: Does anyone know a way to avoid this issue without downgrading the image to 8 bpc? For example, a different way to create or attach the annotation appearance so that PDFKit on iOS 27 writes the 16-bpc data correctly. Has anyone else seen this, or confirmed whether it is fixed in a later iOS 27 release?

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

My last two approved versions of my app are showing "Ready for Distribution" in App Store Connect, but none of the storefronts lets the user gets the latest update. Here's what happened 0.13.1 (build 49) was approved on 13 October. The release type was “Automatically release after approval”. The state is READY_FOR_SALE with downloadable = true, and no phased release is set. 0.13.2 (build 50) was approved on 18 October with the same release type. It is also Ready for Distribution. The App Store and Apple’s public lookup API (itunes.apple.com/lookup?bundleId=…) still return 0.11.0 (released 3 October, minimum iOS 17.6). I checked the US, IN, GB, CA, AU, DE, SG and AE storefronts. It is not a device issue. iPhones on iOS 18.2 and iOS 27 also show 0.11.0 as the latest version. Impact Our iOS users cannot get the new version. The in-app update prompt sends them to a store page that offers only 0.11.0. We had to turn off open challenge events that need the new version, so users cannot join them. This release introduces new in-app purchases, including an annual plan with a free trial, so the delay also affects our revenue. The app ID is 6760958527. I opened Apple Developer Support case 102996444113 and have not had a reply yet. Has anyone seen a release stay stuck like this for days? Is there anything on the developer side that I should check or try? I would be grateful for any pointers.

Hi Apple engineers and developers, I am developing a consumer digital-wellbeing app called Ghostie and am trying to determine the correct Apple-supported architecture for its iOS version before continuing implementation. Ghostie's core functionality is to let the user temporarily disconnect selected third-party apps from the Internet while keeping the rest of the device online. For example: WhatsApp: blocked Instagram: blocked Slack: blocked Maps: remains online Banking: remains online Music: remains online On Android, this is implemented using VpnService with per-app traffic handling. For iOS, I have been researching Network Extension, including: NEFilterDataProvider / NEFilterControlProvider content-filter-provider NETunnelProvider / packet-tunnel-provider per-app VPN configurations Apple's current documentation appears to indicate restrictions around per-app configurations and content filtering on iOS, including managed/supervised-device requirements in certain cases. My question is specifically about a normal consumer application distributed through the App Store, where the user owns and controls their personal device and Ghostie is not an MDM/enterprise product. Is there currently an Apple-supported API, entitlement, or Network Extension architecture that would allow Ghostie to: identify selected installed third-party apps; prevent those selected apps from establishing network connections; leave all other apps' network connectivity unaffected; and allow the user to turn this blocking on and off from Ghostie? If this is not possible for an ordinary consumer App Store application, could an Apple engineer please confirm which specific iOS restriction prevents it and whether there is any alternative supported architecture? I am trying to establish the technically and commercially viable architecture before implementing the iOS version. Thank you!

Our app submission has stayed in "In Review" for 13 days. App Store Connect shows no messages or information requests. App: Moonbase Apple ID: 6749696944 Version: iOS 01.72 Submission ID: 07aa173f-9001-4368-9d57-168d4d3c6027 Submitted: Sep 30, 2026 Support case 102991282893, opened Oct 9, no reply yet We've provided a demo account and review notes in App Review Information. Can App Review confirm the submission is progressing, or tell us what you need from us? Thank you.

I have Xcode 27.1. When I open the Developer Documentation window, it only has the 27.0 APIs. While running Xcode 27.1 if I go to Xcode -> Settings -> Components -> Developer Documentation -> Info, the info window shows the Xcode version as 27.0 and the Developer Documentation Version as 10M13950. Xcode -> About Xcode definitely shows version 27.1. It's very difficult trying to work on iPhone Duo support when the developer documentation doesn't show any of the iOS 27.1 APIs. Is there any way to get the proper documentation loaded?

Feedback submitted: FB24460699 The sample projects are attached to the feedback report. Environment:iOS27 Beta6; iPhone 17Pro Problem:I have encountered a consistently reproducible third-party custom keyboard layout issue in iOS 27.0 beta 1 through beta 6. The custom keyboard initially appears correctly. If I switch apps while the text input remains focused and the keyboard remains visible, and then return to the host app, the system adds a 17-point area above the custom keyboard extension. Steps to reproduce Install and enable a third-party custom keyboard. Switch to the sample custom keyboard and open the host app so that the text editor in the center receives focus. Do not dismiss the keyboard or remove focus from the editor. Return to the Home Screen or switch to another app. Return to the host app. A new blank area now appears above the custom keyboard content. I tested both a system-determined extension view height and an extension view explicitly constrained to 180 points. Both configurations produce exactly the same change. After the foreground transition, the following extension-side values remain unchanged: view.bounds inputView.bounds extension.window.bounds view.safeAreaInsets, which remains {0, 0, 0, 0} The requested 180-point extension height Only the system keyboard frame received by the host app increases by 17 points. I also drew a rounded pink boundary inside the transparent extension root view. When the issue occurs, the new area appears outside that boundary. I tested several third-party keyboards and reproduced the issue with all of them. This suggests that the behavior is caused by iOS rather than by my app. Questions On iOS 27, is it expected behavior for a custom keyboard to gain a 17pt top area after its host app returns from the background? If this is a system issue, is there any workaround that can be used until it is fixed?

Tools are worthless if the service isnt being done.Review of an app is needed but not when it takes over a month to get a response. 17 phone calls over 5 different case numbers and no reply. Absolutely insane

Hi everyone, I'm building a tvOS app that shows analog VU meters for the music playing, in the style of vintage hi-fi amplifiers and tape decks. It works well with local and network files played through AVAudioEngine, where I can tap the signal and measure real levels. With Apple Music, though, there's no way to get even basic level information. The content is DRM-protected, SystemMusicPlayer and ApplicationMusicPlayer render audio outside the app's audio graph, and MusicKit has no metering API. My current workaround is to analyze the song's 30-second preview and replay its level envelope in a loop. It looks plausible, but it isn't in sync with the actual music. I filed FB25234486 asking for a read-only metering API on MusicPlayer, similar to what AVAudioPlayer already offers: let rms = musicPlayer.averagePower(forChannel: 0) // dBFS let peak = musicPlayer.peakPower(forChannel: 0) // dBFS This wouldn't expose any audio samples: just one RMS and one peak value per channel, at a low, capped rate (around 30 Hz). Those numbers can't be turned back into audio, so content protection wouldn't be weakened, and the values could be computed inside the system's playback process. It would make a number of use cases possible: VU and peak meters, audio-reactive visualizers, ambient lighting synced to the music (HomeKit, smart lights), loudness displays, and accessibility features such as visual feedback of the music for hard-of-hearing users. If you need this too, please file your own feedback and mention FB25234486. Duplicate reports help Apple gauge demand. And if anyone has found a supported way to get playback levels from MusicKit today, I'd love to hear about it. Thanks!

Hi everyone, The app was submitted for review 10 days ago, and since then, its status has remained "Waiting for Review" with absolutely no movement. Current situation: App Name: Complex S.I.L.A App ID: 6818184948 Platform: iOS Status: Waiting for Review Waiting time: 10 days No updates or requests for additional information from Apple We understand that review times can vary, but 10 days without any activity seems unusually long. Has anyone experienced similar delays recently? Is there anything we can do to get the submission reviewed? If an Apple engineer or forum moderator could check whether the submission is stuck or requires any action from our side, we would really appreciate it. Thanks in advance!

After updating an internal test app through TestFlight, newly started Live Activities sometimes fail to render. Activity.request succeeds, but the Dynamic Island shows an empty tappable area and the Lock Screen shows no Live Activity. Rebooting the device restores rendering. Is there a supported way to recover from this state without asking the user to reboot? Configuration Device: iPhone18,1 OS for the captured reproduction: iOS 27.0.1 (24A446) Distribution: TestFlight, internal testers only. This app bundle is not published on the App Store. We have reproduced the issue with builds made using both Xcode 26 and Xcode 27. Deployment target: iOS 17.0 The widget extension contains an ActivityConfiguration for Live Activities only, with no Home Screen widgets. Our QA team also reported similar symptoms after app updates on iOS 17.4.1 (iPhone 15 Pro Max) and iOS 26.5 (iPhone 11). We do not have diagnostic logs from those devices, so we cannot confirm that they have the same underlying cause. Bundle identifiers below have been consistently replaced with com.example.internalapp and com.example.internalapp.widgets for this public post. Steps to reproduce Install a build of the app containing the Live Activity widget extension. Update to a newer build through TestFlight. After the update completes, launch the app and start a Live Activity using Activity.request(attributes:content:pushType: nil). Check the Dynamic Island and Lock Screen. This is intermittent: it has happened after several app updates, but not every update. In the captured reproduction, the activity was started about two minutes after installation completed. Expected and observed behavior We expect the Live Activity to render on the Dynamic Island and Lock Screen, with taps opening the app through its widgetURL. Instead: Activity.request succeeds and liveactivitiesd starts the activity. The Dynamic Island has an empty tappable area and the Lock Screen shows nothing. Tapping the empty area opens the app without the activity's widgetURL. Updating the activity's content does not restore rendering. After rebooting, newly started Live Activities render normally. QA has also seen rendering recover after an undetermined wait without rebooting. Relevant diagnostic observations The following is an abbreviated, redacted excerpt from a locally collected sysdiagnose. Times are JST (UTC+09:00), on 2026-10-18. Ellipses indicate omitted fields; the activity identifier has also been redacted. During installation, runningboardd records a RBSPreventLaunchLimitation covering the app and its extensions. While installation is still in progress, chronod ignores the widget extension: 22:38:45.295 runningboardd ... RBSPreventLaunchLimitation ... ... com.example.internalapp.widgets ... com.example.internalapp ... 22:38:45.549 chronod [com.apple.chrono:extensions] Ignoring restricted or unknown extension com.example.internalapp.widgets 22:38:47.178 installcoordinationd -[IXSCoordinatedAppInstall setComplete:] ... com.example.internalapp ... complete! 22:38:47.292 chronod [com.apple.appinstallation:TransactionLog] com.example.internalapp ... applicationsDidInstall When a Live Activity is started later, chronod repeatedly reports zero extensions for the app's container: 22:40:41.221 liveactivitiesd [com.apple.activitykit:activityManager] Starting activity: id: <activity-id>; ... state: active ... 22:40:41.254 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:53.543 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: activityRendererInitiated 22:40:55.707 chronod [com.apple.chrono:descriptor] Reloading descriptors for 0 extensions in container com.example.internalapp with reason: reload descriptors requested by client The installation logs also show the widget extension's provisioning profile being found and its data container being created. These observations suggest that extension discovery may not have recovered after the installation restriction was lifted, but we have not established the root cause. We noticed a potentially related watchOS WidgetKit report referencing FB24619522. Its author reported that their issue was resolved with watchOS 27.0 / iOS 27.0; we do not know whether our Live Activity issue is related. Questions Is there a supported API or recovery procedure that makes the system rediscover the Live Activity extension after an app update? Are there known TestFlight installation or extension configuration conditions that could explain this sequence? Which additional ActivityKit/WidgetKit diagnostics would help distinguish an app configuration issue from a system extension discovery issue? The full sysdiagnose is being kept out of this public post because it contains device and account diagnostics.

I’m seeing a reproducible iPhone Duo Simulator boot failure in Xcode 27.1. Environment Xcode 27.1 / 27A9275 macOS Tahoe 26.6.2, then 26.7.1 Apple silicon Mac iPhone Duo / V68 / iPhone19,4 iOS 27.1 Simulator Runtime builds 24A94232 and 24A94425 Failure Running: xcrun simctl bootstatus -b terminates with: Status=3, isTerminal=YES Data Migration Failed Fresh Duo devices reproduced the failure on both runtime builds. During fresh migrations, DataMigrator logged: Reporting migration failure due to migration progress window incident On one fresh-device run, all 35 recorded migration plugins completed successfully, but the aggregate migration result was false and no failed-plugin identifier was exposed. I also tested: brand-new Duo simulator data restarting the correct CoreSimulatorService explicitly selecting runtime 24A94425 updating macOS from 26.6.2 to 26.7.1 An ordinary iPhone simulator on iOS 27.0 works on the same Mac. The failure occurs before any application is installed or launched. Feedback filed: FB25221101 Has anyone else seen this with the iPhone Duo Simulator in Xcode 27.1?

Hello, I started writing my app on Xcode 26 and everything worked super smoothly. A build would take less than a minute and would immediately open the app on my iPhone 13 Pro. After updating to XCode 27 a build would still finish in the same amount of time, but it would only open the app maybe once out of 10 attempts, most of the time though nothing happens. No matter how long I wait, if I disconnect, reconnect, unlock my phone, it seems like xcode doesn't even notice. I display the build time inside the app and when I manually open the app I can see that it's from the last time the build successfully launched the app automatically. So it's stuck somewhere between building and loading it onto my phone I assume. I recently updated my phone to an 18 Pro and the issue persists. Connection is via USB-C cable. Anyone have any suggestions what might be wrong? Thank you!

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

We're working on an iOS app distributed through the App Store and installed on an MDM-enrolled device. Our MDM server uses InstallApplication to take management of the already-installed and running app. On iOS 27 betas 3 and 4, processing this command causes iOS to terminate the app and its extensions with SIGKILL. The same flow and MDM payload work without terminating the app on earlier iOS versions (iOS <=26). Environment OS: iOS 27 betas 3 and 4 Does not happen: iOS 26 or iOS 16.7.15 Device: iPhone SE 2nd Gen Enrollment: MDM-enrolled device Distribution: App Store app App state: Already installed and running when management is requested MDM command: InstallApplication Minimal MDM command The MDM server sends an InstallApplication command for the already-installed app: Attributes = { Removable = false; }; ChangeManagementState = Managed; Identifier = "APP_BUNDLE_ID"; InstallAsManaged = true; ManagementFlags = 1; RequestType = InstallApplication; We also tested the equivalent command using iTunesStoreID = APP_STORE_ID instead of Identifier, and removing InstallAsManaged. The targeted running app was terminated in the same way. Steps to reproduce Install and launch the App Store app as an unmanaged app. Enroll the iPhone in MDM. While the app is running, send the MDM InstallApplication command to take management of the existing installation. Observe the unified logs for mdmd, appstored, manageddeviced, installcoordinationd, and runningboardd. The issue can also be reproduced by initiating the same server-side flow while the app is already in the background. iOS 27 log sequence The command is accepted and appstored starts the managed-app tasks. manageddeviced then attempts to mark the app as managed using a null persona (this differs from iOS <26): The running app has a valid persona. After the failed mapping, installcoordinationd explicitly asks RunningBoard to terminate the app to disassociate that persona: After termination, removing the valid persona also fails. The managed-app task later reports success despite the mapping failures and termination. Earlier iOS comparison As an example, on iOS 16.7.15, using the same MDM command, **iOS routes the request through dmd with persona: default. The app remains alive and receives managed-app change notifications. Expected The existing installation becomes managed without terminating the running app, consistent with the behavior on earlier iOS versions. Actual manageddeviced tries to associate the app with persona (null) and fails with MIInstallerErrorDomain Code 191. That failure causes installcoordinationd to request termination of the app and its extensions to disassociate their valid persona. runningboardd terminates them with SIGKILL (isUserKill=0). The subsequent removal of the only valid persona fails with Code 242, although the managed-app task later reports success. Documentation checked The payload follows the documented InstallApplication flow for taking management of an existing app: Apple Docs WWDC26 app MDM updates We have not found a malformed field that explains the iOS 27-only failure. More info Detailed logs and additional info can be found on the Feedback report.

i have a question about the iOS 27, is there an exact date yet for iOS 27 with the new features like Siri AI and everything else, is there a date when iOS 27 comes out in Europe with the new Siri AI?

We went through Apple's CarPlay documentation and, based on what we found, CarPlay provides templates for both Navigation and Audio, and our app has entitlements for both. One thing we would like to confirm before proceeding with implementation is whether a single app can expose both Navigation and Audio experiences in CarPlay, using both entitlements. Specifically, can the same CarPlay app provide a navigation experience (e.g., using CPMapTemplate) while also exposing an Audio/"Now Playing" experience, or does Apple expect these experiences to be implemented as separate apps or otherwise treated as separate CarPlay experiences? We'd also like to confirm whether CarPlay now allows an app to display a split-screen interface with navigation/map content on one side and audio controls or "Now Playing" controls on the other side. If so, is this something a single app with both Navigation and Audio entitlements can implement? The documentation explains the available templates and entitlements, but we couldn't find explicit guidance on whether the same app can leverage both Navigation and Audio experiences or whether these can be presented together in a split-screen layout. We'd like to clarify this before implementing the "Now Playing" screen, to ensure our approach aligns with Apple's CarPlay requirements and guidelines.

The following question was asked in the Oct 13 iPhone Duo group lab: when you unfold iPhone Duo after you’ve scrolled down, does UIKit keep the position or should we re-anchor ourselves? The answer was various scroll views like collection views and text views will handle this for you to keep visible items visible, which also works when resizing the window on iPad. This is not working for me with a simple UICollectionView. What do I need to do to obtain this behavior? class ViewController: UIViewController, UICollectionViewDataSource { override func viewDidLoad() { super.viewDidLoad() let layout = UICollectionViewFlowLayout() layout.itemSize = CGSize(width: 80, height: 80) layout.minimumInteritemSpacing = 8 layout.minimumLineSpacing = 8 layout.sectionInsetReference = .fromLayoutMargins let collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout) collectionView.translatesAutoresizingMaskIntoConstraints = false collectionView.backgroundColor = .systemBackground collectionView.dataSource = self collectionView.insetsLayoutMarginsFromSafeArea = true collectionView.register(UICollectionViewCell.self, forCellWithReuseIdentifier: "Cell") view.addSubview(collectionView) NSLayoutConstraint.activate([ collectionView.topAnchor.constraint(equalTo: view.topAnchor), collectionView.leadingAnchor.constraint(equalTo: view.leadingAnchor), collectionView.trailingAnchor.constraint(equalTo: view.trailingAnchor), collectionView.bottomAnchor.constraint(equalTo: view.bottomAnchor) ]) } func collectionView(_ collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int { 5000 } func collectionView(_ collectionView: UICollectionView, cellForItemAt indexPath: IndexPath) -> UICollectionViewCell { let cell = collectionView.dequeueReusableCell(withReuseIdentifier: "Cell", for: indexPath) var content = UIListContentConfiguration.cell() content.text = String(indexPath.item) content.textProperties.alignment = .center cell.contentConfiguration = content var background = UIBackgroundConfiguration.clear() background.backgroundColor = .secondarySystemBackground cell.backgroundConfiguration = background return cell } } Run the app on iPhone Duo Scroll down to cell 100 on the outer display Unfold the device Expected: It should stay scrolled to item 100 Actual: It scrolled down to item 225 (or more accurately, the content offset did not change, more content was added higher up with the contentSize shrinking due to the expanded width) In the past I've put so much work into trying to maintain the expected scroll position for orientation changes on iPhone and iPad/Mac Catalyst resize events, it's surprisingly incredibly hard to get working in every scenario, so I am SUPER interested to learn the system can do it for us!