Really, for how long will apps continue to get stuck in the 'review queue'? This is demoralizing and bad for organizations and developers behind these projects. Our app has been stuck in the 'waiting for review' zone for over 3 weeks+ now, and despite several emails, nothing has been done. No feedback whatsoever. Are we going to get a reply? Is this just an Apple thing, like work culture?

Dear Apple Customer Support, I’m developing a new Swift iPadOS app and I want the app to run in landscape only (portrait disabled). In Xcode, under Target > General > Deployment Info > Device Orientation, if I select only Landscape Left and Landscape Right, the app builds successfully, but during upload/validation I receive this message and the upload is blocked: “Update the Info.plist: Support for all orientations will soon be required.” Could you please advise what the correct/recommended way is to keep an iPad app locked to landscape only while complying with the current App Store upload requirements? Is there a specific Info.plist configuration (e.g., UISupportedInterfaceOrientations~ipad) or another setting that should be used? Thank you,

Hello, My app, Beezzy - Agenda Digital, had an Expedited Review request approved recently (confirmation received via email). However, the status remains stuck in 'Waiting for Review' for an unusual amount of time, even for an expedited process. This update is critical for our operations and addresses urgent fixes. Has anyone else experienced a delay between the expedited approval and the actual 'In Review' transition lately? Is there any additional step required from the developer side to trigger the priority queue? App ID: 6751509489 Thank you for any guidance.

In my tabview i set a safeAreaBar topPanel, under i have contentview. That ignore safeArea.top so feed go under. What is the best Way to have a the first post in content appear under (under the bottom) if the safeareabar. I use list with foreach. Do we measure the height or is it some smart tips?

From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway. There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others). Any change App Attest can be used in by a notification service extension?

When using the .glassEffect modifier on a button in swiftui combined with the .interactive() modifier, the button continues to show the interactive animation even when it’s covered by another element. Example: ZStack { Button { print("Button overlayed by ZStack") // Does not trigger, but interactive animation still plays } label: { image } .glassEffect(.regular.interactive()) Rectangle().fill(.black.opacity(0.7)) } This occurs with overlays, ZStacks, and even if the overlay is a button. Example below: EDIT: It seems like rocketsim's gif recording doesnt show the bug for some reason... really strange... Edit 2: reuploaded gif, recorded as mp4 and converted to gif seems to have worked... Feedback ID: FB22054300 I've attached this sample app to my feedback ticket to help with debugging the issue. It doesn't look like I can share it in this post though.

Hi， Apps crashed when GCDAsyncSocket closeWithError，since iOS 16 。 Crash stack like this： Hardware Model: iPhone10,1 Code Type: ARM-64 (Native) Parent Process: [1] Date/Time: 2022-06-09 08:59:02.201 +0800 OS Version: 16.0 (20A5283p) Report Version: 104 Last Exception : 0 libsystem_platform.dylib 0x000000021bc1f08c 0x000000021bc19000 + 24716 1 libsystem_platform.dylib 0x000000021bc19898 0x000000021bc19000 + 2200 2 CoreFoundation 0x00000001a4dfa3e0 CFSocketInvalidate + 132 3 CFNetwork 0x00000001a5667830 _CFNetworkErrorGetLocalizedDescription + 307856 4 CoreFoundation 0x00000001a4d55f4c CFArrayApplyFunction + 72 5 CFNetwork 0x00000001a56453ac _CFNetworkErrorGetLocalizedDescription + 167436 6 CoreFoundation 0x00000001a4d5d118 0x00000001a4d49000 + 82200 7 CoreFoundation 0x00000001a4dfa718 CFSocketInvalidate + 956 8 CFNetwork 0x00000001a5651e84 _CFNetworkErrorGetLocalizedDescription + 219364 9 CoreFoundation 0x00000001a4d631d4 0x00000001a4d49000 + 106964 10 *** 0x000000010c1bc490 -[GCDAsyncSocket closeWithError:] + 260 11 *** 0x000000010c1c0b54 -[GCDAsyncSocket doReadEOF] + 360 12 *** 0x000000010c1bf1fc __69-[GCDAsyncSocket setupReadAndWriteSourcesForNewlyConnectedSocket:]_block_invoke + 88 13 libdispatch.dylib 0x00000001a4a330f4 0x00000001a4a2f000 + 16628 14 libdispatch.dylib 0x00000001a4a36584 0x00000001a4a2f000 + 30084 15 libdispatch.dylib 0x00000001a4a49b04 0x00000001a4a2f000 + 109316 16 libdispatch.dylib 0x00000001a4a3a684 0x00000001a4a2f000 + 46724 17 libdispatch.dylib 0x00000001a4a3b2f8 0x00000001a4a2f000 + 49912 18 libdispatch.dylib 0x00000001a4a45ebc 0x00000001a4a2f000 + 93884 19 libsystem_pthread.dylib 0x000000021bc210a8 _pthread_wqthread + 288

We have a VPN app that uses NEPacketTunnelProvider with includeAllNetworks = true. We've encountered an issue where push notifications are not delivered over Wi-Fi while the tunnel is active in a pre-MFA quarantine state (tunnel is up but traffic is blocked on server side), regardless of whether excludeAPNS is set to true or false. Observed behavior Wi-Fi excludeAPNS = true - Notifications not delivered Wi-Fi excludeAPNS = false - Notifications not delivered Cellular excludeAPNS = true - Notifications delivered Cellular excludeAPNS = false - Notifications not delivered On cellular, the behavior matches our expectations: setting excludeAPNS = true allows APNS traffic to bypass the tunnel and notifications arrive; setting it to false routes APNS through the tunnel and notifications are blocked (as expected for a non-forwarding tunnel). On Wi-Fi, notifications fail to deliver in both cases. Our question Is this expected behavior when includeAllNetworks is enabled on Wi-Fi, or is this a known issue / bug with APNS delivery? Is there something else in the Wi-Fi networking path that includeAllNetworks affects beyond routing, which could prevent APNS from functioning even when the traffic is excluded from the tunnel? Sample Project Below is the minimal code that reproduces this issue. The project has two targets: a main app and a Network Extension. The tunnel provider captures all IPv4 and IPv6 traffic via default routes but does not forward packets — simulating a pre-MFA quarantine state. The main app configures the tunnel with includeAllNetworks = true and provides a UI toggle for excludeAPNS. PacketTunnelProvider.swift (Network Extension target): import NetworkExtension class PacketTunnelProvider: NEPacketTunnelProvider { override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let settings = NEPacketTunnelNetworkSettings(tunnelRemoteAddress: "127.0.0.1") let ipv4 = NEIPv4Settings(addresses: ["198.51.100.1"], subnetMasks: ["255.255.255.0"]) ipv4.includedRoutes = [NEIPv4Route.default()] settings.ipv4Settings = ipv4 let ipv6 = NEIPv6Settings(addresses: ["fd00::1"], networkPrefixLengths: [64]) ipv6.includedRoutes = [NEIPv6Route.default()] settings.ipv6Settings = ipv6 let dns = NEDNSSettings(servers: ["198.51.100.1"]) settings.dnsSettings = dns settings.mtu = 1400 setTunnelNetworkSettings(settings) { error in if let error = error { completionHandler(error) return } self.readPackets() completionHandler(nil) } } private func readPackets() { packetFlow.readPackets { [weak self] packets, protocols in self?.readPackets() } } override func stopTunnel(with reason: NEProviderStopReason, completionHandler: @escaping () -> Void) { completionHandler() } override func handleAppMessage(_ messageData: Data, completionHandler: ((Data?) -> Void)?) { if let handler = completionHandler { handler(messageData) } } override func sleep(completionHandler: @escaping () -> Void) { completionHandler() } override func wake() { } } ContentView.swift (Main app target) — trimmed to essentials: import SwiftUI import NetworkExtension struct ContentView: View { @State private var excludeAPNs = false @State private var manager: NETunnelProviderManager? var body: some View { VStack { Toggle("Exclude APNs", isOn: $excludeAPNs) .onChange(of: excludeAPNs) { Task { await saveAndReload() } } Button("Connect") { Task { await toggleVPN() } } } .padding() .task { await loadManager() } } private func loadManager() async { let managers = try? await NETunnelProviderManager.loadAllFromPreferences() if let existing = managers?.first { manager = existing } else { let m = NETunnelProviderManager() let proto = NETunnelProviderProtocol() proto.providerBundleIdentifier = "<your-extension-bundle-id>" proto.serverAddress = "127.0.0.1" proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs m.protocolConfiguration = proto m.localizedDescription = "TestVPN" m.isEnabled = true try? await m.saveToPreferences() try? await m.loadFromPreferences() manager = m } if let proto = manager?.protocolConfiguration as? NETunnelProviderProtocol { excludeAPNs = proto.excludeAPNs } } private func saveAndReload() async { guard let manager else { return } if let proto = manager.protocolConfiguration as? NETunnelProviderProtocol { proto.includeAllNetworks = true proto.excludeAPNs = excludeAPNs } manager.isEnabled = true try? await manager.saveToPreferences() try? await manager.loadFromPreferences() } private func toggleVPN() async { guard let manager else { return } if manager.connection.status == .connected { manager.connection.stopVPNTunnel() } else { await saveAndReload() try? manager.connection.startVPNTunnel() } } } Steps to reproduce Build and run the sample project with above code on a physical iOS device. Connect to a Wi-Fi network. Set excludeAPNS = true using the toggle and tap Connect. Send a push notification to the device to a test app with remote notification capability (e.g., via a test push service or the push notification console). Observe that the notification is not delivered. Disconnect. Switch to cellular. Reconnect with the same settings. Send the same push notification — observe that it is delivered. Environment iOS 26.2 Xcode 26.2 Physical device (iPhone 15 Pro)

Hello Apple Developer Community, I'm seeing a persistent crash in my iOS app reported via Firebase Crashlytics. The issue only started appearing on devices running iOS 26.3.0 and above (the crash does not occur on lower iOS versions, and it's unrelated to my app's version number). Key points: My app does NOT use any Text-to-Speech (TTS) features whatsoever. No AVSpeechSynthesizer, no Speech framework, no related APIs called from our code. My app is primarily written in Objective-C (with some Swift components possibly via dependencies). The crash stack is entirely within Apple's private TextToSpeech framework, specifically in ausdk::BufferAllocator::instance(). I suspect it might be indirectly triggered by a third-party ad SDK (e.g., Google Mobile Ads, AppLovin, etc.) that could be loading or interacting with accessibility features in the background — but this is just a hypothesis, as I have no direct evidence yet. Here is one representative crash log: Crashed: com.apple.root.user-initiated-qos.cooperative 0 TextToSpeech 0x6bb00 ausdk::BufferAllocator::instance() + 99800 1 TextToSpeech 0xf8c60 ausdk::BufferAllocator::instance() + 677688 2 TextToSpeech 0xf8c60 ausdk::BufferAllocator::instance() + 677688 3 TextToSpeech 0x1a0b9c ausdk::BufferAllocator::instance() + 1365620 4 libswift_Concurrency.dylib 0x628b4 swift::runJobInEstablishedExecutorContext(swift::Job*) + 288 5 libswift_Concurrency.dylib 0x63d28 swift_job_runImpl(swift::Job*, swift::SerialExecutorRef) + 156 6 libdispatch.dylib 0x13f48 _dispatch_root_queue_drain + 364 7 libdispatch.dylib 0x146fc _dispatch_worker_thread2 + 180 8 libsystem_pthread.dylib 0x137c _pthread_wqthread + 232 9 libsystem_pthread.dylib 0x8c0 start_wqthread + 8 The crash occurs on a background cooperative queue (Swift Concurrency). Questions: Has anyone else seen crashes inside ausdk::BufferAllocator::instance() in TextToSpeech on iOS 26.3.0+ even without using TTS in their app? Could a third-party ad SDK be causing the TextToSpeech framework to load unexpectedly (e.g., via accessibility preloading)? Is this a known bug in iOS 26's Spoken Content / Speak Selection features? Any workarounds or fixes from Apple? Any insights, similar reports (especially from Objective-C based apps), or advice would be greatly appreciated! Thanks!

Hello, We're seeing a high rate of providerDidReset callbacks in production across a large user base (iOS 16, 17, 18, and 26). I'd like to understand both the correct way to handle this delegate method and strategies to reduce its frequency. Background The callback occurs across all iOS versions we support and is not isolated to a specific device or region. The callback can occur in any app state (foreground, background, inactive), however it is most dominant in the background state — particularly during VoIP push notification handling. The callback is more prevalent during long app sessions — for example, when the app has been running continuously for a day or overnight. We do not call CXProvider.invalidate() anywhere in our codebase explicitly. After providerDidReset fires, subsequent transactions fail with CXErrorCodeRequestTransactionErrorUnknownCallUUID (error code 4). Re-initializing the provider via initializeProvider() resolves this error. Our Implementation We use a singleton proxy class (CallKitProxy) that owns the CXProvider. Below is a simplified version — some logging and non-essential parts have been removed for brevity. @objcMembers public final class CallKitProxy: NSObject { private var cxProvider: CXProvider? private let cxCallController: CXCallController private let cxCallObserver: CXCallObserver private override init() { cxCallObserver = CXCallObserver() cxCallController = CXCallController() super.init() initializeProvider() cxCallObserver.setDelegate(self, queue: nil) } private func initializeProvider() { let configuration = providerConfiguration() cxProvider = CXProvider(configuration: configuration) cxProvider?.setDelegate(self, queue: nil) } private func providerConfiguration() -> CXProviderConfiguration { let soundName = SharedUDHelper.shared.string(forKey: .pushNotificationSoundNameForCall) let sound = CallNotificationSounds(name: soundName ?? "ringtoneDefault") let configuration = CXProviderConfiguration() configuration.supportsVideo = true configuration.maximumCallsPerCallGroup = 1 configuration.maximumCallGroups = 1 configuration.supportedHandleTypes = [.phoneNumber, .generic] configuration.iconTemplateImageData = UIImage( named: "callkit_mask", in: .main, compatibleWith: nil )?.pngData() configuration.ringtoneSound = sound.name return configuration } public func requestTransaction( action: CXCallAction, completion: @escaping (Error?) -> Void ) { let transaction = CXTransaction(action: action) cxCallController.request(transaction) { error in completion(error) } } } extension CallKitProxy: CXProviderDelegate { public func providerDidReset(_ provider: CXProvider) { // End any active calls, then re-initialize the provider initializeProvider() } } Questions 1. Is re-initializing the provider inside providerDidReset the correct approach? The documentation states that providerDidReset signals the provider has been reset and all calls should be considered terminated. Should we be calling CXProvider.invalidate() on the old instance before creating a new one? Or is assigning a new CXProvider to cxProvider (which releases the old instance) sufficient? 2. What could be causing providerDidReset to fire so frequently, and how can we reduce it? We're particularly concerned about cases triggered during VoIP push handling in the background and inactive states. Are there known conditions — such as provider configuration changes, app lifecycle events, or system memory pressure — that commonly trigger this callback? And are there any recommended patterns to make the provider more resilient in these scenarios? Thank you.

Hi! We’ve had Live Caller ID Lookup in production for a while. We’re seeing backend RPS on our /queries endpoint much higher than our expected incoming call volume. While testing with Console.app during an incoming call, it looks like iOS may still hit our service even when the caller number is already in the user’s Contacts - but I’m not 100% sure from logs alone. Can you confirm: Does iOS invoke Live Caller ID Lookup (i.e. call /queries) for every incoming call, including calls from saved Contacts? If yes, is this simply expected framework behavior? Thanks!

I was having an issue with the new xcode and was forced to to go back to to Xcode 26.0.1. ( I need iOS simulators for mobile testing and as Developer I know is using this version with no problems). I've always install xcode from the app store with no issue so installing from Apple Dev was something new for me so So I did the following downloaded Xcode 26.0.1 Extracted it from Xzip added the extracted Xcode version to the applications folder click the Xcode icon Expected result I was expecting to see text i could install Xcode version Actual Result Xcode opened Asked me to create a project When project was created I saw Question. What did I do wrong? How do I fix it?

The documentation for isEligibleForAgeFeatures states: Use this property to determine whether a person using your app is in an applicable region that requires additional age-related obligations for when you distribute apps on the App Store. But what does "region" mean? Is this going to return true if the user has downloaded the app from the US App Store? Or will it go further and geolocate the user and identify them as being within a particular relevant state within the US?

Hello iOS developer community, I submitted an app on App Store Connect on February 4, 2026, but I don't understand why, as of today (March 2, 2026), its status is still "Waiting for Review." I have emailed Developer Support but only received the following automated reply: "Thanks for submitting your support request. We’ve received your support request and will get back to you as soon as possible. Your case ID is 102824763035." It has been over ten days, and I still haven’t received any official follow-up or updates from Apple regarding this issue. What should I do now?

If an iPhone receives an incoming call with some partial sip content (for example it contains a name but not an image, or vice versa) and if there is an app enabled for Live Caller ID Lookup, and the result of that lookup supplies data not in the sip (i.e. the lookup returns an image, but not a name, or vice versa). Then could the OS combine data from both sources, or is whatever is returned from the LCIDL what gets displayed in the call screen. I suppose that is the case but just want to enquire to make sure. Thank you

Please include the line below in follow-up emails for this request. Case-ID: 11089799 When using AVSpeechUtterance and setting it to play in Mandarin, if Siri is set to Cantonese on iOS 18, it will be played in Cantonese. There is no such issue on iOS 17 and 16. 1.let utterance = AVSpeechUtterance(string: textView.text) let voice = AVSpeechSynthesisVoice(language: "zh-CN") utterance.voice = voice 2.In the phone settings, Siri is set to Cantonese

Hi everyone, I’ve filed a Feedback report (FB20986470) for a serious issue affecting the Call Directory database when add phone numbers for call blocking. When adding blocking numbers to a Call Directory extension, the system’s CallKit database (/private/var/mobile/Library/CallDirectory/CallDirectory.db) becomes corrupted. The reload call (reloadExtensionWithIdentifier) fails with error code 11 when the system tries to insert blocking entries, and the Console app on macOS shows the following errors: database corruption page 2265525 of /private/var/mobile/Library/CallDirectory/CallDirectory.db at line 81343 of [f0ca7bba1c] database corruption at line 79387 of [f0ca7bba1c] Error Domain=com.apple.callkit.database.sqlite Code=11 "sqlite3_step for query 'INSERT INTO PhoneNumberBlockingEntry (extension_id, phone_number_id) VALUES (?, (SELECT id FROM PhoneNumber WHERE (number = ?))), (?, (SELECT id FROM PhoneNumber WHERE (number = ?))),...)'" After this happens, CallKit becomes fully corrupted on the device and no further numbers can be added, even after: Disabling and re-enabling the extension Restarting the device (either force or soft restart) Reinstalling the app Waiting for a couple of minutes after this issue happens (that CallKit could possibly self-recovered) I also tested other call-blocking apps, and they all fail with the same error. The only thing that recovers the system is a full “Reset All Settings.” This issue has been reported by many users of my app, across multiple iOS versions and devices. Similar related issue reported by another developer: https://developer.apple.com/forums/thread/806129 Steps to Reproduce: Enable the Call Directory extension from a call-blocking app. Add and reload blocking numbers (a few thousand entries). Perform multiple reloads between additions. Check the Console, the corruption errors appear. From this point, all insert attempts fail system-wide. Expected Result: Entries should be inserted successfully, or the system should self-recover without persistent corruption. Actual Result: sqlite3_step fails with Code=11, and the Call Directory database remains corrupted until the user resets all settings. Additional Notes: All numbers are sorted and deduplicated before insertion. Happens intermittently after multiple reloads. The system log always shows internal database failure. Environment: Device: iPhone 16 Plus iOS 18.2 Beta (23C5027f) Xcode 16.1 (17B55) Attachments (included in Feedback FB20986470): sysdiagnose captured immediately after the failure (with Phone app General Profile) It seems like a system-level corruption affecting all Call Directory extensions once it occurs.

I'm working on an app that syncs with Apple Health events. Every time an event occurs, the app should send a notification. The problem occurs when the app is backgrounded or force-closed; it can no longer send local notifications, and because these events can occur at any time, scheduled notifications can't be used. I'm just wondering if anyone's found a creative way around this. I know we can't override system behaviour, I'm just thinking of other alternative solutions for the matter.

Platform UIKit iOS UIActivityViewController Environment Device (issue reported): iPhone 16 iOS Version: 26.2 App Type: UIKit / Swift (standard modal presentation of UIActivityViewController) Summary When presenting UIActivityViewController to share a CSV file, the share sheet does not allow vertical scrolling, making lower actions (including Save to Files) unreachable. The same flow works correctly when sharing a PDF, and the issue cannot be reproduced on other test devices. Steps to Reproduce Launch the app and log in Navigate to More → Reports Tap Export Report Choose Export Report (CSV) Observe the share sheet Expected Result The user should be able to vertically scroll the share sheet All share actions (including Save to Files) should be reachable Actual Result Share sheet opens but vertical scrolling is disabled Lower options (including Save to Files) are not reachable No crash or console errors

Hello everyone, I’m running into an issue where a partial sheet repeatedly presents and dismisses in a loop. Setup The main screen is presented using fullScreenCover From that screen, a button triggers a standard partial-height sheet The sheet is presented using .sheet(item:) Expected Behavior Tapping the button should present the sheet once and allow it to be dismissed normally. Actual Behavior After the sheet is triggered, it continuously presents and dismisses. What I’ve Verified The bound item is not being reassigned in either the parent or the presented view There is no .task, .onAppear, or .onChange that sets the item again The loop appears to happen without any explicit state updates Additional Context I encountered a very similar issue when iOS 26.0 was first released At that time, moving the .sheet modifier to a higher parent level resolved the issue The problem has now returned on iOS 26.4 beta I’m currently unable to reproduce this in a minimal sample project, which makes it unclear whether: this is a framework regression, or I’m missing a new presentation requirement Environment iOS: 26.4 beta Xcode: 26.4 beta I’ve attached a screen recording of the behavior. Has anyone else experienced this with a fullScreenCover → sheet flow on iOS 26.4? Any guidance or confirmation would be greatly appreciated. Thank you!