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, 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!

Up until some point relatively recently, I have been able to use Safari's web inspector to connect to the iOS simulator in order to debug our web application in development at http://localhost:8088. Now, the web inspector still OPENS, but it opens in a broken state. The context is available to select from Safari's "Develop" menu: Develop > "iPhone 16 Pro (Simulator)" > "localhost - login". It appears under the Safari heading if I have navigated to the web app in the browser, or under the Expo heading if I am accessing it through the webview in our React Native wrapper app. When I select it, the web inspector window does appear. However, once it opens, the Elements pane is empty, the Console pane is empty, expressions entered into the console are not evaluated, there's no content in Sources, Network, Storage, etc. Important notes: This broken state happens at http://localhost:8088 as well as http://127.0.0.1:8088, and it seems that the insecure context is the issue. The web inspector DOES work for HTTPS sites. If I navigate to, e.g., https://example.com in the simulator and connect the web inspector, everything works fine. The web inspector also works fine in Safari on macOS (OUTSIDE the simulator) when accessing non-HTTPS sites. It's only a problem for non-HTTPS sites when connecting to the simulator. A coworker has the same problem, so it is not isolated to my machine. I would enable TLS locally as a workaround, but this web app is very complex, and I know from experience that it is very difficult for various reasons to set it up properly for our project in development, and it will take significant non-trivial work to do so. So... Why is this happening? Is this expected behavior? Is there a way that I can debug my site on localhost without HTTPS?

I have an iOS app with App Groups. The app uses the CallKit extension for call block functionality. All data is stored in UserDefaults(suiteName:) and FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: ). I am planning to transfer this app to a different Apple Developer account and would like to clarify how App Groups behave after the transfer: Will my main app Target and CallKit Extensions keep access to the same AppGroups containers with the new Team ID? I will recreate the same AppGroups container identifiers on a new account but my concern is about Team ID change, that can lead to loss access to original containers and all data from previous Team ID. I need to clearly understand whether the app can continue accessing the existing App Group container after the Team ID changes, or if I must manually back up data before transfer and restore all data after transfer completed. As long as the App Group still exists on the original developer account and the user has not updated the app, will the app continue to function normally and access the original App Group container? If I delete the App Group identifiers from the original developer account and recreate it on the new account: 3.1. Will this immediately apply for existing installed apps? 3.2. Or will the impact only occur after submitting and installing a new app version signed with the new Team ID?

Hi all, I’m facing a device-specific issue in a live production iOS app distributed privately via the App Store . The app crashes immediately after login on one client’s iPhone, while the same account works fine on other devices. There’s no crash log generated in Analytics, and the app just pops to the home screen. Environment: App: Production app on App Store iOS version: 26.3 Devices: Only one device exhibits the crash; other iPhones work fine Login flow: App calls an API and writes the response to a local SQLite database immediately after login Distribution: App Store (Privately). The user is install via the redemption codes. Observations: All users on the problematic device crash immediately after login. The crash does not occur on any other devices, including the same iOS version. The client had already uninstalled and reinstalled the app via App Store cloud download, but the crash persisted. No crash log appears in Analytics or Xcode (process just terminates). Device restart had not been attempted before reinstall. App does not use Keychain tokens; local DB is only SQLite in the app sandbox. Hypotheses so far: Corrupted binary or cached app installation on that device SQLite database corruption or write failure Device-specific OS/environment issue (temp files, file locks, provisioning) iOS watchdog silently terminating the app during post-login DB write Language / region differences unlikely Questions: Is it possible for a device to retain a corrupted app binary or cached installation even after uninstall + cloud download reinstall from the App Store? Can uninstalling, restarting the device, and reinstalling guarantee a fresh binary and sandbox? Are there any known iOS behaviors where a local SQLite write could trigger an instant crash on one device only, without generating crash logs? Any other suggestions for diagnosing this device-specific post-login crash in a live production environment? Thanks in advance for any guidance — this issue is affecting a client’s live usage, and we’d like to understand the root cause and best way to resolve it safely.