I would like to see an option to show live caption subtitles on Apple TV. So if I watch DAZN Sports it should generate subtitles via AI with settings enabled. This would give deaf people ability to watch sport with subtitles even it is not supported.

I’m encountering what appears to be a synchronization issue between the numbers displayed by the iOS Voice Control overlay and the targets Voice Control actually activates. Environment: iPhone 13 Pro Max iOS 26.6.1 React Native 0.86.3 Expo SDK 57.0.17 Fabric/New Architecture enabled The issue occurs on a tutorial screen containing several interactive elements. After the screen changes or elements become enabled, disabled, mounted, or unmounted, Voice Control displays numbered overlays that do not correspond to its current command mapping. For example: Enable Voice Control and say “Show numbers.” Navigate to the affected tutorial step. The visible overlay places number 5 on an interactive square. Say “Tap 5.” Instead of activating that square, Voice Control activates the “Skip Tutorial” button. If I say “Hide numbers” followed by “Show numbers,” the newly displayed numbers reflect the actual command mapping. This demonstrates that: Voice Control’s internal target mapping has updated correctly. The visible number overlay has retained an older mapping. Saying a displayed number can therefore activate a completely different control. The behavior is reproducible in an older build that predates our Voice Control-specific tutorial changes, so it does not appear to have been caused by those changes. Setting the Voice Control overlay to “None” also does not resolve the underlying synchronization issue. I found a nearly identical cross-framework report in Flutter: https://github.com/flutter/flutter/issues/183821 That report describes the number overlay showing one mapping after button enabled-state changes while “Tap N” uses a different mapping. It remains open and does not appear to have a published workaround. Questions: Is this a known iOS Voice Control issue? Is there a supported way for an app to notify Voice Control that it must recalculate and redraw its numbered overlay? Would posting a UIAccessibility layout- or screen-changed notification help, or does Voice Control maintain this overlay independently? Are there particular patterns involving enabled/disabled or dynamically mounted accessibility elements that applications should avoid? Is there any way for an application to inspect the target associated with a Voice Control overlay number? My understanding is that these numbers are not exposed through a public API. This issue is especially concerning because the visible overlay instructs the user to say a number that can activate an unrelated control. In this example, it can activate “Skip Tutorial.” I can provide screen recordings and a minimal reproduction if helpful.

。 2026年2月23日，我對部分錯別字及語句進行了修訂，並重新整理內容分段，期望能讓各位更易理解所述內容，謝謝各位。 一、申請事由 本人為香港視障用戶，長期使用iPhone的「旁白」及「放大模式」功能，發現系統中的放大手勢、焦點識別及彈窗返回邏輯存在諸多操作障礙。我已整理完整的改良方案及機器系統診斷檔案，並不希望僅作為一般問題記錄處理，懇請協助將此登記為正式功能申請，並轉交亞太區無障礙研發小組跟進。 致蘋果無障礙工程團隊的一封信 二、用戶意見反饋所面臨的困境 我與身邊許多同路人皆有一致感受：系統內許多無障礙邏輯實有相當大的改善空間，但每次經由官方管道反饋意見，最終大多石沉大海。負責接收意見的前線人員普遍缺乏無障礙領域的專業認知，無法準確傳遞我們所遇到的核心痛點，僅會將其視為一般使用問題歸檔，不會列為優先處理事項，自然無法傳達至具決策權的工程團隊及管理層。 很多時候，一個看似微小的邏輯調整，便能大幅改善全體視障用戶的使用體驗。然而團隊往往認為這些僅屬小眾用戶需求，不值得投入資源優化。但各位未必知曉，會主動花時間反饋問題的用戶，本來即屬小眾群體中的少數，每一則意見背後，代表的皆是成千上萬擁有相同困擾的使用者。 三、螢幕縮放手勢邏輯優化建議 關於螢幕縮放功能的手勢邏輯，我認為存在相當大的優化空間。目前iOS須以三指連點兩下才能開啟放大，此設計對於有手震、手指靈活性不足的用戶而言，門檻實在過高。三指同時點擊，根本無法精準對準欲放大的位置；拖動畫面時須三指同步移動，經常猶如打滑般，完全無法掌控畫面移動的幅度。只要其中一隻手指的指甲稍長，接觸螢幕不均勻，失誤率便會大幅上升；再者，對於手指不靈敏的人來說，這簡直是高難度的協調動作，極不人性化。 我知道iOS設有縮放控制器，可以單指點擊按鈕放大、拖動平移，但一旦鬆開手，畫面便會自動縮小，完全不符合日常使用習慣。再者，須按指定位置的放大按鈕，而螢幕上新增的浮動按鈕屬於懸浮式，有機會遮擋部分內容；在旁白場景下使用時，點擊時可能誤觸其他按鈕，這亦不甚人性化。反觀Android系統的放大邏輯則合理得多：任意位置單指連點三下即可開啟放大模式，單指接觸面積小，點擊位置的準確度大幅提升。開啟後以雙指捏合即可自由調整放大倍率，雙指一同拖曳即可平移畫面，即使手指離開螢幕，放大狀態仍會維持，不會自動退出。不論是操作難度或實用性，皆遠勝於iOS現有的放大邏輯操作手勢，確實亟需改善。 四、旁白快捷手勢與焦點識別的改良方案 4.1 擴充旁白可用的快捷手勢 旁白的快捷手勢數量亦有擴充之必要。目前旁白可用的手勢數量有限，許多常用功能須進入轉輪選單翻越數層方能使用，操作效率甚低。建議可參考Android的手勢設計，加入組合方向手勢，例如先向上再向下、先向下再向上、先向左再向右、先向下再向左等連續滑動手勢，每個組合均可讓用戶自訂對應的快捷功能，無須每次轉動轉輪挑選，單次手勢即可完成操作。 升級小橫條功能 參考現有螢幕底部中央指示小橫條的操作形式，進行功能擴充。新增兩組小橫條，可自訂的側邊虛擬橫條，置於畫面左側和右側。用戶對橫條進行短暫停留觸控，成功偵測後給予聲音或震動反饋，其後再向上、向下滑動不同長度，以觸發各項自定義快捷功能。 4.2 新增智能焦點自動合併功能 智能焦點合併功能亦是我們相當期待的一項優化。特別是第三方App，許多功能的標題與對應的開關皆分為兩個獨立焦點，旁白須掃描兩次才能讀完資訊再操作開關。自動合併功能可將具對應關係的標題與開關穩定合併為單一焦點，旁白朗讀一次即可直接控制開關狀態，減少所有介面多餘的滑動步驟。 五、系統開關顏色對比度的調整建議 系統控件的顏色對比度對低視力用戶至關重要。目前系統開關的開啟底色與滑動圓點顏色過於接近，對比度不足，開關的小圓點是白色，開啟的底色是綠色，關閉的底色是灰色，三種的顏色對比不明顯。低視力人士難以一眼分辨為開啟或關閉。建議將開啟的小圓點和狀態的底色改為高飽和度的深藍色，與關閉狀態的灰色形成強烈對比。 目前設定中的勾選圖標辨識度偏低，難以直觀分辨開關的啟用狀態。另外，在多選勾選的場景中，建議將選中的勾號改為粗體，或直接為選中項目加上深色底色，讓低視力用戶能快速判斷選擇狀態。 額外增加兩種優化方案：第一，新增獨立分頁，將所有已選取的選項統一收納於此頁面中；第二，令已勾選的項目自動排序至清單最上方，依序擺放。如此可方便低視力使用者一眼分清選取狀態，搭配旁白使用時亦可減少辨識耗時，提升操作順暢度。 六、原生系統鍵盤的功能改良建議 iOS原廠鍵盤存在數處使用上的不便，對視障人士及手部活動不靈活的用戶尤為困難，具體改良建議如下： 1. 容許用戶自行微調，調節鍵盤的高度，並加入鍵盤內置可固定使用的全螢幕文字編輯模式。許多第三方應用程式的輸入框面積狹窄，難以修改文字內容，統一內置鍵盤的全螢幕輸入能大幅提升編輯準確度，可選擇常開或手動切換。另外，希望新增專屬的黑色高對比鍵盤樣式，切換深色模式、開啟智慧型反轉時，所有程式統一調為黑色底色配白色文字，杜絕強制彈出白色鍵盤的情況，幫助低視力用戶清晰分辨文字。現時第三方Apps有些會強制彈出白色鍵盤。 2. 增設快捷操作手勢，長按空白鍵即啟動語音輸入，放開手指即時停止錄音，無須點擊麥克風圖示。 3. 優化iOS系統的語音輸入轉文字模組，升級中文語言模型，利用完整句子的前後語境進行語義邏輯推算，避免單獨辨識字音而產生大量同音字錯誤。透過上下文判斷詞彙的真實含義，自動修正同音錯字，大幅提高轉換精準度，尤其適合開啟旁白的視障用戶口述長篇文字、撰寫反饋意見的使用場景。 七、輔助取用模式的兼容性與功能優化 輔助取用模式的定位與兼容性亦有相當大的調整空間。目前開啟輔助取用模式後，許多旁白的原生手勢會直接失效，最常見者即為底部橫條上滑返回主畫面的手勢失效，此點務必優化兼容。同時，建議重新定位該模式的實用性。與其僅為放大介面，不如加入超級省電的選項，容許用戶自訂降低螢幕解析度與CPU更新率，再配合純黑色主題，並可選擇關閉圖片載入的開關。如此不僅能大幅提升電池續航，還能加快系統運行速度，對於舊機用戶、視障用戶及特殊族群而言，會比單純放大按鈕實用得多。 八、螢幕AI即時識別功能的升級方案 現有螢幕識別功能的升級，是解決第三方App無障礙問題的關鍵。目前許多第三方App的無障礙適配做得甚差，有些按鈕沒有焦點，導致無法點擊操作；按鈕沒有文字標籤、控件無法識別，單靠現有的螢幕識別功能難以應付。建議團隊研發更強大的螢幕即時AI分析功能，透過系統層級的AI，自動識別App中的按鈕、文字、圖片及各種控件，自動加上對應的標籤與可操作框架。若此技術能臻於成熟，便無須再依賴第三方開發者進行無障礙適配，單靠系統即可解決絕大部分App的無障礙問題，從根本上改善視障用戶使用第三方App的體驗。同時，可建立一個共用的按鈕標籤資料庫，透過AI自動修正、補全沒有標籤的按鈕，並支援全世界所有用戶雲端同步修正。 九、頁面返回與彈窗退出交互邏輯的優化 頁面返回與退出的邏輯，是長期以來的頭痛問題。開啟旁白後，絕大部分第三方App無法用手勢快速返回上一頁，必須逐一掃動，找到左上角那顆細小的返回按鈕才能操作，步驟繁瑣且難以定位。建議從兩方面著手改進：一是系統層面強制擴大返回按鈕的旁白焦點感應範圍，即使按鈕本身細小，焦點感應區仍擴大到周邊空白位置，方便直接點擊。 此外，所有關閉、取消這類按鈕的位置沒有統一規範，有時在左上角，有時在右上角，有時在底部，非常不人性化。同樣的問題也出現在彈窗、二級菜單及鍵盤的退出上。很多時候開啟旁白時，我們無法透過點擊空白區域退出彈窗或收起鍵盤，必須找到取消、關閉等按鈕才能操作，有時甚至會被困在頁面中。建議優化所有二級菜單與彈窗的交互邏輯，預設點擊空白區域即等同取消或關閉，解決使用者被圍困的問題。 十、繁體中文系統設置所有功能，文字說明的優化建議 繁體中文介面的翻譯與功能說明亦有優化之必要。目前設定中許多無障礙功能的標題與解釋皆甚模糊，容易令使用者混淆。舉例而言，旁白詳細程度中的「提示」功能，其作用為關閉多餘的新手引導播報，但目前的命名完全無法體現其用途，許多新用戶根本不知此功能為何。建議改為「新手提示」等更清晰的名稱，同時優化所有功能的說明文字，讓用戶一眼即明用途。同時，優化旁白的冗餘播報邏輯，當用戶關閉新手提示後，應儘量減少多餘的重複播報，提升操作效率。現時的繁體中文介面，關閉了新手提示，還是有很多多餘的播報。 設定佈局標題優化 系統設置，裏面。很多功能。拆分於不同分類頁面；抬起手機亮屏、點一下螢幕亮屏、自動調整螢幕亮度，等同屬螢幕喚醒與顯示的功能，亦分散於多個設定頁籤。使用者須穿梭多個頁面方能完成同類設定調整。 2. 設定項目垂直佈局空間浪費嚴重：現有設定頁面每個功能選項採用垂直堆疊排版，圖標、標題、說明文字上下排列，單一選項約佔六行高度，大幅消耗畫面空間。單頁可顯示的設定項目數量有限，使用者須頻繁上下滾動頁面尋找功能，大幅增加旁白導覽的操作步驟與時間。 改良建議 1. 按照功能使用場景與屬性重新規劃設定目錄架構，將同屬性的關聯功能整合至同一主題分頁，歸為一類，將所有螢幕喚醒、亮度調節相關開關集中於同一分頁，無須穿梭多個頁面切換開關。 2. 優化設定選項的排版邏輯，將圖標、標題、說明改為橫向排列：圖標固定於左側，標題與說明文字靠右側水平展示，壓縮單個選項的垂直高度，提升單頁資訊密度，讓同一畫面能顯示更多設定項目，減少滾動操作次數，優化旁白導覽的操作流暢度。 十一、建議在現有省電模式基礎上新增獨立的超級省電模式 。。 超級省電模式新增管控項目（標準省電模式未涵蓋）： 1. 動態內容全數暫停：動態圖標、動態圖案、GIF動畫等所有頁面動態影像停止播放。 2. 系統動畫全面停用：所有過場移動動畫、偏好交疊效果、淡出過場效果全數關閉。 3. 自動播放功能全關：訊息動畫效果、影片預覽自動播放、動態影像自動播放全部停用。 4. 畫面調色停用：「開啟減少明亮效果」、關閉原色調自動色彩適配功能。 5. 高耗電視覺架構停用：Liquid Glass相關視覺特效全數關閉。 6. 感應喚醒預設關閉：抬起手機喚醒功能預設停用。 7. App智能推薦全關：「在搜尋中顯示App」、從此App學習、App智能建議內容、App捷徑於搜尋/小工具/通知顯示等功能全部預設關閉。 在標準省電模式基礎上，進一步削減動態內容、視覺特效、智能推薦等多餘功耗，續航延長效果更為明顯，實現最佳省電化。 所有省電開關集中於同一控制面板，無須穿梭多層設定頁面；視障用戶透過旁白可快速檢視所有功能狀態，逐項調整，一目了然。預設極致省電組態，同時保留單項功能手動開啟權限，用戶可按自身使用場景自由組合，不強制全套捆綁套用。 視障用戶無須花俏的畫面特效，乾淨、簡潔、低干擾的系統環境才是核心訴求。超級省電模式可完全剔除多餘視覺元素干擾，讓旁白焦點更清晰、朗讀更連貫，無障礙體驗更佳。 大量多餘視覺運算與後台智能分析停止運作，大幅降低CPU與GPU負載，減少機身發熱與無故卡頓；對旁白等無障礙功能的運行穩定性提升尤其顯著，完全符合我們視障團體追求流暢穩定系統的核心需求。 十一、整體訴求總結 以上所述種種，絕非錦上添花的優化，而是真正能改變視障群體使用體驗的核心調整。前人種樹，後人乘涼，每一個細微的改動，都能讓許多視障人士更獨立、更方便地使用手機。期盼團隊能真正站在視障使用者的角度，從真實的操作困難出發，重視這些來自用戶的聲音。 申請人：來自中國香港的視障用戶

We have a password entry field with a "show password" button. The button effectively turns the "secure text entry" textfield into a non-secure text entry field allowing the user to view what they typed in. When VoiceOver is enabled, I am not including that button in the UI; it doesn't seem to make sense to me for the following reasons. If you properly test with the screen curtain, the functionality is useless. You don't see anything. I've tried to explain this to my accessibility team. It's also quite ridiculous to offer to show a blind user their password, I'm sure they'd love to see it, but they just can't. This would almost seem insulting as well. If by toggling that button, and turning a secure text entry into a non-secure text entry, now the app is literally speaking their password aloud. This seems like a security vulnerability to me. What if someone else overhears the password spoken aloud. The accessibility team is insisting that I need to include the "show password" button when VoiceOver is enabled. This is the response I received. "functionality should be the same for VI users as for sighted users. It may happen that a VI user wants to check what is typed into password field in order to correct mistakes". Again, I don't agree with that because functionality should not be the same. Functionality should be changed and altered as necessary to make the user experience as accessible as possible. And in this scenario, to me the functionality doesn't make sense at all in a VoiceOver setting. Any thoughts on this? Am I incorrect here? Are there benefits of including a "show password" button to a user utilizing VoiceOver? What should then the functionality be? Speak the password aloud? Thanks.

OK hello Apple developers, and whoever else is reading, I am a quadriplegic. This means I cannot use my fingers. So therefore I cannot pick up the phone. That means I cannot pick up the phone for Face ID which is biometric, fingerprint which is biometric, I believe the eye is biometric. So is the voice. That is how I have to login to my brokerage firms multiple bank account. Anything super secure I can use my voice as a password. It's super simple. Just add and the code and write it so therefore it is as simple as saying something to the effect of "hey seri my voice is my password. A few simple lines of code written by Apple expert this should not be hard at all and should be included in an update. Just think how would you use your phone if you could not pick it up. I cannot put Apple Pay i cannot secure on my phone because I cannot lock it because I cannot pick it up. Any help would be greatly appreciated

So using the developer website in Safari....produces this. How? How is this even possible? I know.... they used Chrome to test and develop with... ;) I am on the latest Safari. Sad.

We are seeing a hard main-thread abort on iOS 26 during cold launch when VoiceOver (or another accessibility client) is active. about 1–7 seconds after process start. The crashing thread essentially shows only main from the app; the fatal path is entirely in system frameworks. What happens is that UIAccessibility asks for an accessibility value, UIKit.axbundle handles it (on iOS 26.5 we exact-match-symbolicate this to -[_UITabButtonAccessibility accessibilityValue] + 120), then AXCoreUtilities safeSwiftValueForKey reflects a Swift object via Mirror / AttributeGraph. While copying an unowned field, the referent is already gone, so libswiftCore calls swift_abortRetainUnowned and the process dies. Not finding unowned in app source does not contradict this: the reflected object can live in system or SDK Swift state. OS versions in the corpus: iOS 26.5 (23F77), 26.6 (23G71), and 26.6.1 (23G83). All reports load UIKit.axbundle. Launch-to-crash gaps range from roughly 1.4s to 7.3s. Most 26.6 samples share UIKit.axbundle binary UUID 387c6473…; we did not have matching Device Support for that build locally. One iOS 26.5 sample has UIKit.axbundle binary UUID dca69975… and AXCoreUtilities 78a7c163…, both exactly matching local Device Support, so atos on that sample is trustworthy. On that iOS 26.5 sample (filename redacted), the symbolicated path is: VoiceOver / AX → UIAccessibility (_iosAccessibilityAttributeValue → _accessibilityAXAttributedValue → _accessibilityPotentiallyAttributedValueForNonAttributedSelector) → UIKit.axbundle -[_UITabButtonAccessibility accessibilityValue] + 120 → AXCoreUtilities (_AXSafeSwiftValueForKeyTm → safeSwiftValueForKey → _visitValueWithReflection) → AttributeGraph (AGTypeApplyFields2::Visitor::visit_field) → libswiftCore (swift_reflectionMirror_subscript → copyUnownedFieldContents → swift_unknownObjectUnownedLoadStrong → swift_abortRetainUnowned) → App: main only Frame 32 math: runtime 0x2be49b130, slide base 0x2be3cf000, offset 0xCC130 → _UITabButtonAccessibility accessibilityValue + 120. Questions for anyone hitting the same stack: 1.Is there already an Apple Feedback / radar for safeSwiftValueForKey + swift_abortRetainUnowned on iOS 26? crash_ios265_redacted.txt

To the Apple iOS Development and Accessibility Teams, I am writing to formally request the addition of a native Lisu keyboard to iOS. As Apple continues to expand its global accessibility and language support, adding the Lisu language would bridge a significant communication gap for a vibrant and growing community. About the Lisu People: The Lisu are a Tibeto-Burman ethnic group with an estimated population of over 1.4 million. They traditionally inhabit the mountainous regions of Myanmar (Burma), Southwest China (particularly the Yunnan and Sichuan provinces), Thailand, and the Indian state of Arunachal Pradesh. They possess a rich cultural heritage, passed down through generations via extensive oral traditions, songs, and clan histories. The Lisu Language and Fraser Script: The Lisu language is officially supported by the Unicode Consortium. The writing system, known as the Fraser script, was developed in 1914 and was officially added to the Unicode Standard in Version 5.2. Unicode Reference: The Lisu block is designated at U+A4D0 – U+A4FF. Official Chart: Unicode [Lisu Chart (PDF)] https://www.unicode.org/charts/PDF/UA4D0.pdf Current Industry StandardsOther major operating systems have already recognized the importance of supporting the Lisu community: Microsoft Windows: Currently comes with a pre-installed Lisu keyboard, allowing users to type seamlessly out of the box. Android (Google): The default Gboard natively supports the Lisu keyboard, offering full mobile typing capabilities for Android users. Currently, iOS users who speak and write in Lisu must rely on third-party workarounds, which often lack the security, privacy, and seamless integration of Apple’s native keyboards. By implementing the Lisu keyboard, Apple would greatly enhance the iOS experience for over a million people, allowing them to communicate natively on their iPhones and iPads.Thank you for your time, consideration, and ongoing commitment to making technology accessible to everyone. I look forward to seeing Lisu supported in a future iOS update. Sincerely, Si_Gwa

We are testing the new Declarative Device Management (DDM) App Settings configuration on macOS 27 Golden Gate to manage Accessibility permission for our applications as suggested by the apple team in https://developer.apple.com/forums/thread/839536. We created a Jamf Blueprint with a custom com.apple.configuration.app.settings declaration and configured the required Accessibility settings. After applying the Blueprint to the User channel, we now receive the consent prompt shown in the attached screenshot. However, the permission flow does not appear to work as expected. Our understanding is that, after the user clicks Allow in this consent prompt, the configured Accessibility permission should be applied to the application without requiring an additional Accessibility authorization prompt. Instead, after selecting Allow, we still receive the subsequent prompt, which asks the user to choose either Open System Settings or Deny. The DDM declaration appears to have been successfully deployed and is shown as active on the system. Could you please clarify the following? Expected consent behavior: After the user selects Allow in the DDM App Settings consent prompt, should the configured Accessibility permission become effective without any additional Accessibility prompts? Consent scope: We are observing an Allow / Not Allow consent prompt for each DDM App Settings declaration. Is user consent expected to be requested separately for each declaration, or should macOS consolidate the Accessibility settings from multiple declarations into a single consent request? Additional Accessibility prompt: Why does the application continue to receive the Accessibility permission alert with Open System Settings / Deny even after the user has selected Allow for the DDM declaration? User interaction: Is there any supported way for an organization to manage or suppress these additional prompts so that no further user interaction is required after the initial DDM consent? Our goal is to understand the expected macOS 27 behavior and determine the supported management configuration for applications that previously received Accessibility permission through the PPPC payload.

Our app is being killed by the watchdog on iPadOS 26 (iPad Pro 11, 3rd gen) when navigating between tabs after using search. The crash only occurs when AssistiveTouch is enabled — disabling it prevents the issue entirely. The crash stack shows the main thread blocked in CoreUI vector glyph rasterization (CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition:) triggered during a UINavigationController transition while the keyboard is being dismissed: UINavigationController _startCustomTransition → UIKeyboardSceneDelegate _restoreInputViewsWithId → UITextField resignFirstResponder → SwiftUI ViewGraphRootValueUpdater.render → UIButton layoutSubviews → UIImageView _setImage → CUINamedVectorGlyph _layerNamesForRenderingMode:inRendition: The termination reason: FRONTBOARD domain:10 code:0x8BADF00D "Failed to terminate gracefully after 5.0s" WatchdogEvent: process-exit WatchdogVisibility: Foreground Key observations: Only reproduces with AssistiveTouch enabled iPad Pro 11 (3rd gen), iPadOS 26 Our code is not on the crashing thread — it's entirely UIKit/CoreUI/SwiftUI framework code Similar to issues reported in thread/808808 (https://developer.apple.com/forums/thread/808808) and dotnet/maui#32365 (https://github.com/dotnet/maui/issues/32365) Is this a known issue with AssistiveTouch + UINavigationController transitions on iPadOS 26? Is there a recommended workaround?

Hello Albert! I am experiencing some strange bugs around DeviceActivityEvents (part of the DeviceActivity framework) on iOS 26 / iOS 26.1 / iOS 26.2 beta: When creating a DeviceActivityEvent we can assign a threshold and applicationTokens. The idea is, that after the user has spent said threshold on said apps, eventDidReachThreshold() is called. The property includesPastActivity is set to false. On iOS 26 however, it happens (quite reliably after updating to a new beta seed) quite often that eventDidReachThreshold() is called immediately (after a couple of seconds) instead of waiting for the threshold to be met. Is anyone else seeing similar issues on iOS 26 / iOS 26.1 / iOS 26.2 beta? Only workaround I have found is to ask users to revoke and re-grant Screen Time permissions. This only holds for about two weeks though or at most until the next iOS 26 beta update is installed, so it is not a permanent solution unfortunately. Feedback (incl. sysdiagnoses and sample project) is filed under: FB18061981 FB18927456 One of our users has filed their own feedback request as well: FB20817853 Thanks a lot for any help on this!

My app used 3rd party API to provide some services, but there's a possibility that those API use some other third party service and to approve my app for App Privacy Guidelines 5.1.1(i) - Legal - Privacy - Data Collection and 5.1.2(i) - Legal - Privacy - Data Use, developers must include third party API service name.

This is a test post for security research purposes, will be deleted immediately after. Please disregard.

When VoiceOver is enabled, it sometimes reads auto-generated image descriptions such as 'a blue and white logo on a white background' or 'warning icon, image error' instead of the custom accessibilityLabel we've set on the icons. How can we prevent VoiceOver from reading these image-specific descriptions and ensure it only reads our custom labels? Just like UIAccessibility.isVoiceOverRunning lets us check if VoiceOver is active, is there an equivalent API to detect whether Voice Control is currently enabled?

您好，我们是中国的一家软件开发公司。我们应用程序的底层框架基于美国开源社区的 XMPP 协议框架。它是一个国际开源项目，许多中国软件公司以开源框架为基础，在美国开源社区框架之上开发 UI 和替换功能。但是当我们需要将应用上传到应用商店时，会收到提示（拒绝 4.3A 应用垃圾邮件），因为中国目前没有独立开发这个框架的能力。因此，我们不得不承认，我们的 app 使用了美国开源社区的框架，因为中国的很多其他公司也都使用了美国开源社区的框架。这导致我们在将应用程序上传到应用商店时出现提示 （reject 4.3A application spam），因为其他公司在将其上传到应用商店时也使用相同的底层开源框架。这会导致我们公司在将此应用程序上传到应用商店时收到提示（拒绝 4.3A 应用程序垃圾邮件）。我们公司在这个 App 上花费了大量的精力和金钱，如果不允许中国公司上传到 App Store，就会被拒绝。使用来自美国的开源框架，这导致很多中国公司在后期无法使用美国的开源框架作为开发的基础。我们恳请贵公司为中国的小企业提供指导，并就我们未来的发展提供建议。谢谢。

With the declining literacy rates I think it would be incredibly valuable for apple to implement a separate keyboard experience for minors. One without auto or predictive text, swipe to text, or even potentially also voice memos. These are all very convenient features that I think could unfortunately contribute or even enable the literacy crisis as more and more children grow up and rely on technology. I also think bringing back the ‘look up’ tool on highlighted text into the main options would support and encourage more education (or even adding a thesaurus option as well) From: A Gen Z adult who grew up learning how to spell at the same time I learned how to text. Without relying on all of the convenience features that in turn can remove the mental friction that learning to fix your mistakes provides, my iPhone was teaching me how to spell with simple red lines that required me to interact with my spelling in order to correct my mistakes. Note: Autocorrect was still a feature at the time however was often turned off by most people because of text slang culture which coincidentally helped create more intentional spell check interactions. I believe the decision to turn off autocorrect should be considered a more conscious responsibility so it should not necessarily be left up to a child to decide for themselves.

Hi, I'm new to Full Keyboard Access, and I was wondering how people typically navigate UI components with an external keyboard. Do people usually use Tab/Ctrl+Tab, or are the arrow keys more commonly used?

If a user enables/disables Guided Access, they can modify the session settings to disable the top (sleep/wake) button. In Single App Mode (SAM), there is a payload option for disabling the sleep/wake button via Mobile Device Management (MDM). In Autonomous Single App Mode (ASAM), there doesn't appear to be any way to disable the top button. ASAM does not honor the Guided Access sessions settings, and there is no payload option in the MDM. This is a glaring issue especially when ASAM is marketed as the solution for apps in a medical setting where the app is trading hands from a medical professional to a patient. Our app is used during a lengthy procedure and does not function properly if the patient puts the iPad to sleep. We're stuck asking our medical professionals to put the iPad in Guided Access, but the user experience is clunky and would be much improved by implementing ASAM. Is there some little-known API for disabling the sleep/wake button during ASAM that I'm just missing?

Device iPhone 15 iOS Versions iOS 26.5 iOS 26.6 Summary: I found a reproducible issue with Guided Access on my iPhone 15. After disabling Guided Access, it cannot be enabled again for approximately 30–60 minutes. The problem exists on both iOS 26.5 and iOS 26.6. Steps to Reproduce: Enable Guided Access. Use Guided Access for approximately 5–10 minutes. Disable Guided Access. Wait 1–2 minutes. Try enabling Guided Access again. Expected Result: Guided Access should enable immediately every time. Actual Result Instead of enabling, the phone displays: "Guided Access Unavailable" After this message appears, Guided Access cannot be enabled again. I must wait approximately 30–60 minutes before the feature becomes available again. Frequency 100% I can reproduce this every time using the steps above. Troubleshooting Already Tried Restarted iPhone. Force restarted iPhone. Turned Guided Access off and on. Updated from iOS 26.5 to iOS 26.6. The issue still occurs. Questions: Can anyone reproduce this on iPhone 15 or other iPhone models running iOS 26.5 or iOS 26.6? Has anyone found a workaround?

I'm working on improving accessibility in a native macOS app and going through WCAG, but with so many success criteria it's hard to know where to focus for native Apple platform apps. 1. Does Apple recommend a specific subset or checklist of WCAG requirements for macOS and iOS? 2. If not, which criteria are generally considered essential, and how do developers typically validate them using Apple's accessibility tools and assistive technologies? I'm looking for a prioritized list of criteria that actually apply to native apps, rather than trying to implement every WCAG criterion individually.