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?

I want to be able to disable all liquid glass effects from my Navigation bar, and it's bar buttons. But I still want to be able to have the liquid glass effect on my UITabbar. Is there a way to disable glass effects from navbar and still retain them all for tabbars using UIKit?

We are 25 days into "Waiting for Review" with no movement, no messages, and no Resolution Centre activity. Submitted 16 February. Apple ID: 6758049144 This is a finance category app used by regulated financial advisers in the UK. The delay is now directly affecting live paying customers operating under FCA compliance obligations. We have confirmed everything on our side is in order. This is not a metadata issue or an incomplete submission. Has anyone from the App Review team seen this? And has anyone here successfully broken a delay of this length - what actually worked?

Hello everyone, I am seeking some guidance on how to break out of what appears to be an automated App Review rejection loop. My app has been rejected three times in a row for the exact same reason, and my replies in the Resolution Center seem to be getting ignored. The Issue: My app is named Linkwise (associated with my web platform, linkwise.app). I am being rejected under Guideline 4.1(c) - Design - Copycats. The rejection message specifically states: "The app's icon and name contain an icon, brand, or product name that belongs to the following developer: Linkwise." The bizarre part is that I am the developer of Linkwise. I am being accused of impersonating my own brand and product. Submission Details: App Name: Linkwise Submission ID: fa557f1b-3724-4e01-aa85-bf05ced4801f Version: 1.0.1 Review Device: iPhone 17 Pro Max What I've Tried: I have replied to the rejection message in App Store Connect three times explaining that I am the owner of the Linkwise brand and domain. Despite this, I keep receiving the exact same copy-pasted template response. It feels like a human is not actually reading the appeals. My Questions: How can I escalate this past the initial review tier to someone who can read the context? Has anyone else experienced being rejected for copying themselves? What specific "documentary evidence" does App Review usually want in this scenario to prove I own my own name? Would my domain registration receipt for linkwise.app be sufficient, or do they require formal trademark documentation? Any advice on how to get this in front of a real person would be greatly appreciated. Thank you!

In App Store Connect I've uploaded a new build about 11 hours ago and but I'm unable to distribute the App to my tester groups - including internal. The internal group is grayed out. I am able to Select an External group but they actually do not receive any email notification nor do they see any update within their TestFlight App. I've attempted to upload the build a few times, including old builds which had been distributed in the past to no avail. I'm not able to distribute to any tester group, please advise.

Greetings! I'm facing a problem handleling full keyboard access in my app. This is a simpler version of the code: struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } .navigationTitle("Title n stuff") .padding() } } And the focus behaves as expected and the important thing, we can access que button on the right side of the screen But as soon as we introduce the scrollview, the right side button is unaccessible, since when we hit tab we go back to the back button in the nav stack header. struct PrimerTest: View { @FocusState private var focusedImage: Int? var body: some View { ScrollView { VStack(alignment: .leading, spacing: 20) { Link("Go to google or smth", destination: URL(string: "https://google.com")!) .font(.headline) Text("First text") Text("Second text") HStack { Text("Label") .accessibilityHidden(true) Spacer() Button("Play") { print("Im a button") } } Text("Selecciona un perfil con el teclado (Tab):") .font(.caption) .foregroundColor(.secondary) HStack { ForEach(0..<5, id: \.self) { index in Image(systemName: "person.circle.fill") .resizable() .frame(width: 30, height: 30) .focusable(true) .focused($focusedImage, equals: index) .foregroundStyle(focusedImage == index ? Color.blue : Color.gray) .scaleEffect(focusedImage == index ? 1.2 : 1.0) .animation(.easeInOut, value: focusedImage) .accessibilityHidden(true) } } } } .navigationTitle("Title n stuff") .padding() } } I've tried all the things I found online and none achieves an acceptable behavoir, I've seen ppl saying this issue has been fixed in ipados with the focusSection modifier, but I have not seen any fix fot this issue in ios.

Dear Apple, while implementing Declared Age Range API in my app, I've noticed a mistake in documentation: the isEligibleForAgeFeatures property is marked 26.0+ in documentation, but 26.2+ in Xcode, which ultimately leads to inability to use it with OS below 26.2. Moreover, I'm thoroughly confused by this quote from documentation: This flag returns true on iOS and iPadOS based on a person’s eligibility and always returns false on macOS. It leads me to two questions: Is it possible to use Declared Age Range API for macOS apps? Will it be possible to use it in future? Will there be any changes regarding this matter in a meantime (especially after Jan 1st)? If yes - when should we expect these changes? If no - why this API declares macOS 26+ support alongside iOS/iPadOS, if it simply doesn't work for macOS now? As of now, my iOS app works flawlessly with given API (on iOS 26.2) while macOS app returns isEligibleForAgeFeatures = false and requestAgeRange request always throws AgeRangeService.Error.notAvailable. Also, does it mean that one should not use isEligibleForAgeFeatures boolean while implementing Declared Age Range API for apps below iOS 26.2 (I mean 26.0+)? Or implementing given API for iOS 26.2+ is a sufficient way to go? So shouldn't the whole API be marked as 26.2+? The minimum iOS version in my app is 16.0 and minimum macOS version is 13.0 anyway, so the significant part of users is left out of these updates, but the main goal here is legal compliance.

I changed something with Bundle Identifier... since then I cannot trust the certificate anymore on iPhone. It just won't show up. I reinstalled new profile, new bundle id, completely reinstalled iPhone... created new certificates, downloaded... nothing... I thinks it needs internet connection, but connection works just fine Unable to Verify App An internet connection is required to verify trust of the developer "Apple Development: My Name (22YBQVQJZK). This app will not be available until verified. this makes me crazy.. I lost like 5 hours on this.. still it does not work... Apple Intelligence tried like everything .. didn't help

I am referencing: https://developer.apple.com/documentation/foundation/pausing-and-resuming-uploads Specifically: You can’t resume all uploads. The server must support the latest resumable upload protocol draft from the HTTP Working Group at the IETF. Also, uploads that use a background configuration handle resumption automatically, so manual resuming is only needed for non-background uploads. I have control over both the app and the server, and can't seem to get it to work automatically with a background url session. In other words, making multiple requests to get the offset then upload, easy but I am trying to leverage this background configuration resume OS magic. So anyone know what spec version does the server/client need to implement? The docs reference version 3, however the standard is now at like 11. Of course, I am trying out 3. Does anyone know how exactly this resume is implemented in iOS, and what exactly it takes care of? I assumed that I can just POST to a generic end point, say /files, then the OS receives a 104 Location, and saves that. If the upload is interrupted, when the OS resumes the upload, it has enough information to figure out how to resume from the exact offset, either by making a HEAD request to get the offset, or handle a 409. I am assuming it does this, as if it doesn't, the 'uploads that use a background configuration handle resumption automatically' is useless, if it just restarts from 0. Note, of course making individual POST/HEAD/PATCH requests manually works, but at that point I'm not really leveraging any OS auto-magic, and am just consuming an API that could really implement any spec. This won't work in the background, as the OS seems to disallow random HTTP requests when it wakes the app for URLSession background resumes. As of right now, I have it 'partially' working, insofar as the app does receive the 104 didReceiveInformationalResponse url delegate call, however it seems to then hang; it stops sending bytes, seemingly when the 104 is received. However, the request does not complete. In other words, it doesn't seem to receive a client timeout or otherwise indicate the request has finished. Right now, I am starting a single request, POSTing to a /files end point, i.e. I am not getting the location first, then PATCHing to that, as if I do that, the OS 'automatic' resuming fails with a 409, i.e. it doesn't seem to make a HEAD request and/or use the 409 offset correction then continue with the PATCH. Any idea what could be going on?

When setting the language in iOS/macOS to German (or other languages with “,” decimal separator) and number format to “1.234.567,89” in iOS 26.2, 26.3 and 26.4 Beta, Safari inserts the wrong decimal separator in elements. It should use the local German decimal separator comma “,” instead it uses the english/international period “.” Here is a screenshot of iOS 26.2 when visiting a website with just 2 number inputs in Safari: <input type="number"> <input type="number" value="5.6"> It behaves the following way: On the first input, enter a number with decimals like “12,34”, clicking “,” on the onscreen-keyboard, a “.” instead of a “,” is added. The number then is formatted in international/English: “12.34”. The input set programatically shows the right decimal separator for German: "5,6". But deleting the “,” and pressing “,” on the onscreen-keyboard again adds a dot instead of a comma and shows the number in international/english: “5.6”. The same issue also happens on desktop Safari on MacOS 26.2 and newer and iOS apps using webviews, also since iOS 26.2. How to use the correct decimal separator in html number inputs for the user selected language in iOS/macOS on iOS 26.2 and newer versions? Is this maybe a bug? This was working correctly for iOS 26.1 and older:

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 &gt; General &gt; Deployment Info &gt; 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, 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?