The appeals process for when your Apple Developer account is in Pending Termination status doesn't work. The re-instate developer account form is very clear it shouldn't be used if it's pending. But the form for "I would like to appeal an app rejection or app removal" which is the correct form for pending state. Gives the error "There are no apps associated with this team." we do have apps associated. There could be thousands of developer accounts that weren't able to file an appeal correctly because of this bug. "If you would like to appeal this termination decis ion to the App Review Board, you must do so within 30 calendar days. When submitting your appeal, be sure to select "I would like to appeal an app rejection or app removal" from the drop-down menu on the Contact the App Review Team page and provide a written statement that includes the following:" Apple is very clear which to use.

Hello, We are currently developing an application that uses the Host-based Card Emulation (HCE) entitlement to enable corporate access functionality. With this entitlement, we have successfully established HCE communication and can interact with our access control systems to unlock doors. Our question is related to improving the user experience: We would like this access functionality to work without requiring the app to be in the foreground, as this adds friction for users during entry. Specifically, we would like to know: Is it possible for our app to coexist with Apple Wallet as the default contactless app, so that: Our app handles NFC interactions for corporate access (e.g., opening doors). Apple Wallet remains the default for payments. If that coexistence is not possible, and our app is set as the default contactless app, Will the system still need to launch our app into the foreground to complete a transaction (e.g., to emulate the NFC card)? Or is there a way to trigger HCE responses in the background (e.g., using a background process or service extension)? Any guidance on how to configure the app for optimal background access behavior, while maintaining compatibility with Wallet, would be greatly appreciated. Thank you in advance.

Hi everyone, I'm trying to delete an App ID from Certificates, Identifiers & Profiles on the Apple Developer portal, but I'm getting the following error: "The App ID 'XXXXXXX' appears to be in use by the App Store, so it can not be removed at this time." Here's my situation: The app was never published to the App Store — it was only created in App Store Connect (no builds were ever submitted for review, and it was never in a "Ready for Sale" state). I have already removed the app from App Store Connect via "Remove App" in App Information. The app is no longer visible in my App Store Connect dashboard. It has been over 48 hours since I removed the app from App Store Connect. Despite this, the Identifiers page still shows the error above when I attempt to delete the corresponding App ID. What I've tried: Confirmed the app no longer appears in App Store Connect (including checking "Removed Apps" filter) Waited over 48 hours for the system to propagate Cleared browser cache and retried My goal: I need to release this Bundle ID so it can be registered under a different Apple Developer account. Questions: Is there an additional waiting period beyond 48 hours before the App ID can be deleted? Is there a way to force-release this App ID, or do I need to contact Apple Developer Support directly? Has anyone experienced this same issue with an app that was never published? Any guidance would be greatly appreciated. Thank you! Environment: Apple Developer Program (Organization account) App was created in App Store Connect but never submitted for review Platform: iOS

There seems to be a lack of clarity about how this Siri AI rollout is working. Does the indexing have anything to do with getting taken off the waitlist, or are they completely separate? Also, what is the expected wait time and has anyone gotten the new Siri after the initial wave of approvals (after 4 hours after the keynote)? The waitlist is extremely slow compared to the initial Apple Intelligence waitlist from a couple of years ago.

version: iOS 17+ When requesting Photo Library access on iOS, the system displays a standard permission dialog. I just wanna save a image to user's photo library. Is it possible to replace or customize this system permission popup with a fully custom-designed UI? If customization is not allowed, is the recommended approach to first present a custom explanatory popup or screen and then trigger the system permission dialog?

I’ve found nothing about the waitlist, like when are there expected openings, how does an opening occur, and do I need to do anything else except join the waitlist? It’s been indexing for the same amount of time that I’ve been waiting for Siri, so is that a factor?

I was really considering this IDEA ONLY ANDROID HAS that Apple doesn’t tell me what you think ? I think the iOS system in the iPhones and iPad should be able to let you change your ((Fronts))because this whole just changing it into bold or the size is kind of boring it gets old so if you can reach back to me that would be nice thanks . phone number 702-559-5550

I create a Live Activity remotely via push-to-start, then use its per-activity token (Activity.pushTokenUpdates) so my server can send update/end pushes. To make sure I'm not missing tokens, I observe Activity.activityUpdates and prime from the Activity.activities snapshot at launch and on sceneWillEnterForeground, then subscribe each activity's pushTokenUpdates and POST the token to my server. This works reliably while the app is running or backgrounded/suspended — the system wakes it and I capture the token. The problem is the user force-quit case (swiped from the App Switcher, never reopened): Push-to-start still creates the Live Activity and it renders correctly on the Lock Screen. But pushTokenUpdates never fires, so my server never receives the per-activity token and can't update or end that activity. A backgrounded (not force-quit) app, as a control, captures the token every time. So it seems specific to user-termination rather than all "not running" states. I understand force-quit apps generally aren't granted background runtime — I'm trying to confirm whether that applies here and what the right pattern is. What's the recommended approach? Specifically: Is there any supported way to get the per-activity token to my server while the app stays force-quit — e.g. from the widget extension (does it have any access to Activity.pushToken, or only ActivityViewContext?) or a Notification Service Extension? 2. If not, is setting stale-date on the start push the intended way to let the card expire gracefully when it can never be ended via push? 3. Is there a better pattern for keeping a push-started Live Activity correct when the app is never relaunched?

Hi all :) I tried to raise this in the group lab and was pointed here. I’m seeing a flat per-app memory ceiling of about 6 GB on iPhone, even on devices with more physical RAM and with com.apple.developer.kernel.increased-memory-limit. Measured with os_proc_available_memory() plus task_vm_info.phys_footprint, the total process budget stays around 6144 MB on both: iPhone 16 Pro Max, 8 GB RAM iPhone 17 Pro Max, 12 GB RAM This came up while running Gemma 4 multimodal support in mlx-swift-lm (PR #343). The model loads at about 4.4 GB resident, leaving roughly 1.7 GB for inference/prefill. Reducing a GPU buffer cache from 512 MB to 64 MB recovered enough headroom to avoid jetsam and allowed a full image + video + audio multimodal test to complete, so the measurement seems to reflect a real per-process limit rather than free system memory. I re-measured the ceiling on the 12 GB phone with these capabilities: increased-memory-limit only: ~6144 MB increased-memory-limit + extended-virtual-addressing: ~6144 MB, no change increased-memory-limit + increased-debugging-memory-limit: ~6656 MB I have also observed that 12 GB iPad devices expose more memory to an app than 12 GB iPhone devices but I didn't measure specifically and no longer have the device to hand. Is the ~6 GB per-process tier on Pro iPhones expected, even with increased-memory-limit? Is there any supported way for a shipping app to access more of the available RAM on 12 GB iPhone models? FB23183521

1. System/device combinations where the issue does not occur: Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max 2. System/device combinations where the issue does occur: System versions: Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340) Simulator: iOS 26.0 (23A339) Device models: Physical device: iPhone 12 Reproducible in Safari, WKWebView, and UIWebView: Yes Actual behavior In WebView (and identically in Safari): Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected. After the keyboard appears, the visualViewport position changes. Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned: When scrolling down, the position looks correct. When scrolling up, the header/footer are visibly offset. Steps to reproduce Focus an input field → the keyboard appears Dismiss the keyboard Observe that visualViewport.offsetTop remains >0 (does not reset to zero) position: fixed header/footer elements are misplaced relative to the screen Expected behavior After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0. When scrolling upward, fixed elements should remain correctly positioned within the layout viewport. Minimal reproducible demo A simple HTML file containing: A header and footer with position: fixed An input element to trigger the keyboard <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" /> <title>H5 吸顶吸底页面 Demo</title> <style> * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: Arial, sans-serif; height: 2000px; /* 设置内容高度 */ background-color: #f0f8ff; /* body 背景浅蓝色 */ padding-top: 120px; /* 预留 header 高度 */ padding-bottom: 60px; /* 预留 footer 高度 */ overflow-x: hidden; } /* 吸顶 Header */ header { position: fixed; top: 0; left: 0; width: 100%; height: 120px; background-color: #ff6b6b; /* 红色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 24px; font-weight: bold; z-index: 1000; } /* 吸底 Footer */ footer { position: fixed; bottom: 0; left: 0; width: 100%; height: 60px; background-color: #4ecdc4; /* 青绿色 */ display: flex; align-items: center; justify-content: center; color: white; font-size: 18px; font-weight: bold; z-index: 1000; } /* 输入框样式 */ .input-container { margin: 100px auto; width: 80%; max-width: 600px; text-align: center; } input[type='text'] { padding: 12px; font-size: 16px; border: 2px solid #ddd; border-radius: 8px; width: 100%; box-sizing: border-box; } input[type='text']:focus { outline: none; border-color: #4ecdc4; } </style> </head> <body> <!-- 吸顶 Header --> <header>吸顶 Header (120px)</header> <!-- 主体内容 --> <div class="input-container"> <input type="text" placeholder="请输入内容..." /> </div> <!-- 吸底 Footer --> <footer>吸底 Footer (60px)</footer> </body> </html>

vesion: iOS 17+ When requesting Photo Library access on iOS, the system displays a standard permission dialog. And I just wanna save a image to user's photo library. Is it possible to replace or customize this system permission popup with a fully custom-designed UI? If customization is not allowed, is the recommended approach to first present a custom explanatory popup or screen and then trigger the system permission dialog?

I am experiencing random Wi-Fi and Bluetooth disconnections while using iOS 27. Both Wi-Fi and Bluetooth disconnect unexpectedly, then reconnect automatically a few seconds later. I have seen many similar reports on Reddit, so this does not seem to be an isolated issue. I have already submitted a report through Feedback Assistant with the feedback ID FB23121586. I hope this issue can be fixed soon, because it is really stressful when playing online games on my iPhone and worrying that the connection might suddenly drop. :(

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

Family.app keeps crashing whilst I am using Xcode 27 beta The app is very simple with just a small number of views. That's all I can say really This is the first part of the crash report output. Multiline Translated Report (Full Report Below) Process: Family [3026] Path: /Volumes/VOLUME/*/Family.app/Family Identifier: com.apple.family Version: 1.0 (1) Code Type: ARM-64 (Native) Role: Background Parent Process: launchd_sim [2846] Coalition: com.apple.CoreSimulator.SimDevice.5FAFAC9B-97A4-4FC8-ADF3-4A8C694BF68D [1639] Responsible Process: SimulatorTrampoline [1008] User ID: 501 Date/Time: 2026-06-09 20:14:55.5737 +0100 Launch Time: 2026-06-09 20:14:45.2448 +0100 Hardware Model: Mac16,12 OS Version: macOS 26.5.1 (25F80) Release Type: User BlockQuote

All of these issues appear when the search controller is set on the view controller's navigationItem and the search controller's searchBar has its scopeButtonTitles set. So far the following issues are affecting my app on iOS/iPadOS 26 as of beta 7: When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .integratedButton, and the searchBarPlacementAllowsToolbarIntegration is set to false (forcing the search icon to appear in the nav bar), on both iPhones and iPads, the scope buttons never appear. They don't appear when the search is activated. They don't appear when any text is entered into the search bar. FB19771313 I attempted to work around that issue by setting the scopeBarActivation to .manual. I then show the scope bar in the didPresentSearchController delegate method and hide the scope bar in the willDismissSearchController. On an iPhone this works though the display is a bit clunky. On an iPad, the scope bar does appear via the code in didPresentSearchController, but when any scope bar button is tapped, the search controller is dismissed. This happens when the app is horizontally regular. When the app on the iPad is horizontally compact, the buttons work but the search bar's text is not correctly aligned within the search bar. Quite the mess really. I still need to post a bug report for this issue. But if issue 1 above is fixed then I don't need this workaround. When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to .stacked, and the hidesSearchBarWhenScrolling property of the navigationItem is set to false (always show the search bar), and this is all used in a UITableViewController, then upon initial display of the view controller on an iPhone or iPad, you are unable to tap on the first row of the table view except on the very bottom of the row. The currently hidden scope bar is stealing the touches. If you activate and then cancel the search (making the scope bar appear and then disappear) then you are able to tap on the first row as expected. The initially hidden scope bar also bleeds through the first row of the table. It's faint but you can tell it's not quite right. Again, this is resolved by activating and then canceling the search once. FB17888632 When the scopeBarActivation of UISearchController is set to .onSearchActivation, the preferredSearchBarPlacement of the navigationItem is set to integrated or .integratedButton, and the toolbar is shown, then on iPhones (where the search bar/icon appears in the toolbar) the scope buttons appear (at the top of the screen) the first time the search is activated. But if you cancel the search and then activate it again, the search bar never appears a second (or later) time. On an iPad the search bar/icon appears in the nav bar and you end up with the same issue as #1 above. FB17890125 Issues 3 and 4 were reported against beta 1 and still haven't been fixed. But if issue 1 is resolved on iPhone, iPad, and Mac (via Mac Catalyst), then I personally won't be affected by issues 2, 3, or 4 any more (but of course all 4 issues need to be fixed). And by resolved, I mean that the scope bar appears and disappears when it is supposed to each and every time the search is activated and cancelled (not just the first time). The scope bar doesn't interfere with touch events upon initial display of the view controller. And there are no visual glitches no matter what the horizontal size class is on an iPad. I really hope the UIKit team can get these resolved before iOS/iPadOS 26 GM.

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

I'm facing a persistent location error on real iOS device: Error Domain=kCLErrorDomain Code=1 The operation couldn’t be completed. (kCLErrorDomain error 1.)

I’m seeing a regression in Xcode 26.4 where Interface Builder will not allow connecting IBOutlets or IBActions. Symptoms: The usual gutter circle/dot does not appear next to IBOutlet / IBAction in the code editor Because of this, I cannot: drag from storyboard → code drag from code → storyboard The class is valid and already connected to the storyboard (existing outlets work) Assistant Editor opens the correct view controller file Important: The exact same project, unchanged, works perfectly in Xcode 26.3. I can create and connect outlets/actions normally there. ⸻ Environment Xcode: 26.4 macOS: 26.4 Mac Mini M4 Pro 64G Ram Project: Objective-C UIKit app using Storyboards This is a long-running, ObjC, project (not newly created) ⸻ What I’ve already tried To rule out the usual suspects: Verified View Controller Custom Class is correctly set in Identity Inspector Verified files are in the correct Target Membership Verified outlets are declared correctly in the .h file: @property (weak, nonatomic) IBOutlet UILabel *exampleLabel; Opened correct file manually (not relying on Automatic Assistant) Tried both: storyboard → code drag code → storyboard drag Tried using Connections Inspector Clean Build Folder Deleted entire DerivedData Restarted Xcode Updated macOS to 26.4 Ran: sudo xcodebuild -runFirstLaunch Confirmed required platform components installed Reopened project fresh ⸻ Observations In Xcode 26.4 the outlet “connection circles” are completely missing In Xcode 26.3 they appear immediately for the same code Existing connections still function at runtime — this is purely an Interface Builder issue ⸻ Question The gutter circles appearance has always been flaky in Xcode over the 13+ years I've been using it but now with 26.4 they have completely disappeared. Has anyone else seen this in Xcode 26.4, or found a workaround? At this point it looks like a regression in Interface Builder, but I haven’t found any mention of it yet.

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

I am not sure this is the best place for this but ... I've got an M1 iPad Pro, an M1 Max 2021 MacBook Pro and an iPhone 15 Pro Max all of which have the x27 operating systems installed since release on 8 June (9 June for me). It has be 48h or a bit more since the installs completed and both the iPhone (with 260GB of data and apps) and iPad (with about 200GB of data) are still indexing heavily and using power like crazy. The iPad has been on charge and WiFi for almost that entire time. Likewise, the Mac has been on and connected to WiFi for the whole time. All 3 devices say that Settings/Siri/New Siri has "Joined Waiting List". Everything I have seen online so far indicated that should take 1-2 hours or maybe 4 hours. I've tried turning Siri off for a while and then back on. I've tried changing the language and location of the device to English US/United States and the Siri language to English US but it has had no effect. I'm concerned the devices are stuck in a loop. Has anyone else had these issues so far and if so, how have you corrected them. Alternatively, should I assume this is normal (hasn't been for previous major betas) and leave them do their thing?