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.

com.apple.main-thread 0 StarMaker 0x5c40854 _isPlatformVersionAtLeast.cold.2 + 4425680980 1 StarMaker 0x526d278 -[FPRScreenTraceTracker displayLinkStep] + 191 (FPRScreenTraceTracker.m:191) 2 QuartzCore 0xbe924 CA::Display::DisplayLinkItem::dispatch(CA::SignPost::Interval<(CA::SignPost::CAEventCode)835322056>&) + 64 3 QuartzCore 0x9bf38 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 880 4 QuartzCore 0xaf770 CA::Display::DisplayLink::dispatch_deferred_display_links(unsigned int) + 360 5 UIKitCore 0x7dee4 _UIUpdateSequenceRunNext + 128 6 UIKitCore 0x7d374 schedulerStepScheduledMainSectionContinue + 60 7 UpdateCycle 0x1560 UC::DriverCore::continueProcessing() + 84 8 CoreFoundation 0x164cc __CFMachPortPerform + 168 9 CoreFoundation 0x460b0 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION + 60 10 CoreFoundation 0x45fd8 __CFRunLoopDoSource1 + 508 11 CoreFoundation 0x1dc1c __CFRunLoopRun + 2168 12 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 13 GraphicsServices 0x1498 GSEventRunModal + 120 14 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 15 UIKitCore 0x46e54 UIApplicationMain + 336 16 StarMaker 0x50c965c main + 18 (main.m:18) 17 ??? 0x19a9dae28 (缺少) Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x27d30 zorro::KbLog::Loop() + 88 (kblog.cc:88) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19a4e4 zorro::ZkbLog::Loop() + 157 (zlog.cc:157) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8 Thread 0 libsystem_kernel.dylib 0x67f4 __semwait_signal + 8 1 libsystem_c.dylib 0xc7e4 nanosleep + 220 2 ZorroRtcEngineKit 0x1eb0f8 std::__Cr::this_thread::sleep_for(std::__Cr::chrono::duration<long long, std::__Cr::ratio<1l, 1000000000l>> const&) + 198 (pthread.h:198) 3 ZorroRtcEngineKit 0x19c4d8 zorro::QosManager::Loop() + 966 (string:966) 4 ZorroRtcEngineKit 0x286e8 <deduplicated_symbol> + 4667967208 5 libsystem_pthread.dylib 0x444c _pthread_start + 136 6 libsystem_pthread.dylib 0x8cc thread_start + 8

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!

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.