Area: Software Update Type of Feedback: Application Bug Description Device: iPhone 13 Pro running iOS 26 Build environment: Xcode 16.4 Problem description: When a text field has secureTextEntry = YES and Password Autofill / Passkeys is active, the autofill panel is not included in the rect reported from the keyboard notifications (UIKeyboardFrameEndUserInfoKey or others). As a result, when calculating the offset to move the screen up and reveal the hidden input field, the field is not displayed correctly because the reported keyboard height is smaller than the actual visible height. Observed behavior: This only occurs on devices running iOS 26 built with Xcode 16.4. On previous versions of iOS, with the same settings (secureTextEntry and Autofill active), the rect correctly includes the autofill panel height, and the UI works as expected. I tested with both UIKeyboardDidShowNotification and UIKeyboardWillChangeFrameNotification, and in both cases the behavior is the same: the height is incorrect (smaller than expected with the autofill panel). What I expect / questions: That UIKeyboardFrameEndUserInfoKey (or the related notification) correctly reports the total area covered by the keyboard, including any password autofill panel, when secureTextEntry is active. That the new behavior in iOS 26 be documented if this omission is intentional, or otherwise considered a bug if it is not. If there is any official workaround suggested by Apple for developers affected by this issue while a fix is provided. Thank you for your support.

Hi everyone, I’m testing an iPhone app called Steady through TestFlight and would love honest feedback. Steady is built for the moment right before someone acts on an urge they may regret. The core idea is to create a short pause before action, then let the user log what happened so they can spot patterns over time. Use cases could be things like sending a text you shouldn’t, reacting too fast, opening something you wanted to avoid, or other impulsive moments. I’m mainly looking for feedback on three things: Does the concept feel useful in real life? Is the flow clear or confusing? What feels unnecessary or missing? TestFlight link: https://testflight.apple.com/join/YsnDsGR5 Appreciate any honest feedback.

Hi, I'v got the error by using NEHotspotConfiguration to connect a wifi spot but get:NEHotspotConfigurationErrorDomain code=8. I hope to get the same result as when scanning the code with the system camera. A pop-up window will appear, and I just need to click "Join" to successfully connect. Here's the logs: [OneAppWifi][iOS] handleCheckWifiEnabled start (iOS 12+) [OneAppWifi][iOS] handleCheckWifiEnabled pathUpdateHandler status=satisfied [OneAppWifi][iOS] handleConnectWifi start, ssid=OPPO Find X6 Pro, pwd=len=16, authType=Optional("sae"), hidden=false [OneAppWifi][iOS] handleConnectWifi cancelPendingConnection before new request ssid=OPPO Find X6 Pro [OneAppWifi][iOS] cancelPendingConnection called, errorCode=nil, currentSsid=nil [OneAppWifi][iOS] cancelPendingConnection silent cancel, just clear pendingConnectResult [OneAppWifi][iOS] handleConnectWifi apply completion with error, domain=NEHotspotConfigurationErrorDomain, code=8, userInfo=["NSLocalizedDescription": internal error.] [OneAppWifi][iOS] resolveNEError NEHotspotConfigurationErrorDomain code=8 [OneAppWifi][iOS] resolveNEError systemConfiguration / internal, map to connection_failed [OneAppWifi][iOS] handleConnectWifi resolved as failure errorCode=Optional("connection_failed") for ssid=OPPO Find X6 Pro [OneAppWifi][iOS] firePendingResult value=["success": false, "errorCode": Optional("connection_failed")], currentSsid=Optional("OPPO Find X6 Pro")

Problem: When the screen is locked, an incoming call does not initiate the launch of the Flutter application required for audio and video communication through Jitsi Meet. In the unlocked state, the application functions correctly. The current implementation does not have a mechanism for activating the Flutter engine when receiving a call via CallKit while the screen is locked. Although CallKit UI displays the call acceptance interface and the audio session is configured, the Flutter application remains in a suspended state, making it impossible to connect to the media server. Audio session activated using didActivateAudioSession method.

There is a long-standing, structural issue with the iPadOS Korean IME when using a hardware keyboard. The IME forcibly intercepts the " (quote) keydown event and injects Unicode smart/curved quotes (“ or ”) directly into the text field. This hardcoded behavior ignores both: User Settings: The global "Smart Punctuation" toggle in [Settings > General > Keyboard] is completely ignored. Developer APIs: Setting UITextInputTraits.smartQuotesType = .no on a UITextView or UITextField has absolutely no effect when the Korean keyboard is active. Steps to Reproduce: Set smartQuotesType = .no on a standard UITextView. Connect a hardware keyboard. Switch input language to English -> Press the quote key. (Result: ASCII straight quote " - Correct behavior) Switch input language to Korean -> Press the quote key. (Result: Unicode curved quote “ - Incorrect behavior) Impact on Developers & Users: Because the OS IME forcefully injects the curved Unicode character before the app can process the raw key event, developers building code editors, markdown editors, or specific word processors (like Google Docs) cannot prevent this behavior. We cannot provide a standard text-editing experience for Korean users without forcing them to manually toggle their keyboard language to English just to type a straight quote. Expected Behavior: The Korean hardware keyboard IME must respect UITextInputTraits.smartQuotesType and the global OS toggle. Please provide a mechanism for developers and users to bypass this forced CJK typography rule.

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.