Post

Replies

Boosts

Views

Activity

Proposing Expressive Siri Offload via Private Cloud Compute (PCC) for 8GB Devices (Feedback ID: FB23178983)
Hi everyone, With the initial rollout of the iOS 27 Beta, the advanced configuration sliders for the new, highly expressive Siri voice models are currently hidden/disabled on devices operating under an 8GB RAM threshold. While the local AFM 3 Core Advanced engine is memory-gated to 12GB+ hardware due to local footprint constraints, this creates a significant barrier for users who rely on next-generation vocal expressivity and fluid dictation features for accessibility. To address this, I have filed a formal feature request (FB23178983) asking Apple to route the expressive Siri framework through Private Cloud Compute (PCC) on 8GB devices (like the iPhone 15 Pro or base iPhone 16 models). By utilizing server-side rendering over secure, stateless cloud nodes, Apple could easily deliver these vital accessibility configurations without exhausting the local 8GB memory footprint. I’m curious if other accessibility testers and auditors on this board are looking for this exact routing path? If you or your users rely on advanced speech synthesis features and are currently locked out by the local RAM gate, please consider filing a duplicate request or adding your diagnostic logs to FB23178983 to help increase visibility with the Core Accessibility and Software Architecture triage teams. Looking forward to hearing your thoughts and experiences with the current voice-indexing behaviors on 8GB hardware!
4
1
2.4k
1d
Proposal: Integrate ChromeOS & Natural Neural Voices into iOS VoiceOver for 8GB+ Hardware (FB24788469)
Feedback Assistant ID: FB24788469 (Cross-reference: Complementary to third-party TTS framework initiatives logged in FB23666342) Overview With the continued evolution of on-device machine learning and Apple Silicon's unified memory architecture, I propose that Apple evaluate expanding the native VoiceOver speech library in the upcoming iOS 28 cycle to incorporate lightweight, natural acoustic and neural voice models—specifically the profiles utilized across ChromeOS, Android, and CNET accessibility pipelines (including the natural Google Assistant voice profile). Hardware Feasibility & RAM Footprint • Demonstrated Efficiency on 8GB Systems: In real-world desktop testing across both an ASUS laptop and an HP laptop configured with 8GB of RAM, these voice profiles operate with near-instantaneous responsiveness, zero audio stutter, and negligible memory overhead. • Client-Side Execution Proof: In testing with NonVisual Desktop Access (NVDA)—an open-source Windows screen reader for blind and vision-impaired users—these voices run client-side using Google's WebAssembly (WASM) text-to-speech engine via background Chromium runtimes. Even during heavy UI tree navigation and multitasking, the 8GB systems run effortlessly without memory pressure warnings, UI latency, or process termination. • Viability Across 8GB & 12GB Apple Silicon: Apple Silicon devices leverage high-bandwidth unified memory and dedicated Neural Engine cores. Compiling or running these lightweight neural acoustic models via Core ML on all 8GB and 12GB devices running iOS 28—as well as future hardware generations—leaves substantial headroom for foreground apps without risking memory eviction. Technical & Practical Justification 1. Prosody and Auditory Fatigue: Modern neural synthesis captures natural cadence, warmth, and contextual phrasing, substantially reducing listening fatigue during multi-hour screen reading sessions compared to older formant or diphone synthesizers. 2. Deterministic On-Device Latency (Sub-50ms): Screen reader users require immediate auditory feedback when navigating character-by-character or word-by-word. Running these models locally on-device guarantees the sub-50ms response times essential for VoiceOver, with zero network latency and complete offline reliability. 3. Cross-Platform Continuity & Inter-Platform Synergy: Blind and low-vision users who switch between desktop environments (such as Windows with NVDA or ChromeOS) and iOS benefit greatly from vocal consistency across their workflows. Furthermore, given Apple's established collaboration with Google regarding foundational AI models, exploring speech asset licensing or compiling these lightweight voice packages into native iOS speech audio units represents a logical, accessible extension of existing synergy. Proposed Solution Provide downloadable, on-device voice packages for these high-efficiency neural and ChromeOS-style profiles directly within: Settings > Accessibility > VoiceOver > Speech > Voice in iOS 28. It would be greatly appreciated if I could get community feedback. If posting in a language other than English, I'll use Gemini to translate it into English and post the translation for English speakers as a reply to this post. Also, if you want to check out my posts on Acapela's voice library integration, and my Expressive Siri posts, check out the links below and give me your thoughts on them as well. This post will be cross-linked on those as well, creating a closed triangular circuit. Expressive Siri Link: https://developer.apple.com/forums/thread/834920 Acapela Voice Library Integration Link: https://developer.apple.com/forums/thread/837701
0
0
237
1d
Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing:
Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing Associated Feedback Feedback Assistant Ticket: FB23666342 1. The Core Proposal On behalf of the assistive technology and screen-reader community, I am requesting the native system-level integration of the comprehensive Acapela Voice Library into iOS and macOS. This library should be added as a native synthesizer tier alongside existing options like Eloquence. Additionally, we request cross-pipeline voice compatibility, allowing the Siri assistant to utilize configured VoiceOver voice assets, and allowing VoiceOver to utilize Expressive Siri neural models. 2. Structural UI Layout Concept To maintain system cleanliness while maximizing user choice, we propose grouping the Acapela catalog exactly like the current native Eloquence implementation: A main, expandable heading titled Acapela inside the Speech rotor settings. Under this heading, voices should be strictly categorized by global regional dialects (including English U.S., English UK, Australia, India, Scotland, and all other languages offered to AT vendors). This deployment must include all specialized character profiles (such as the Little Creature variant) and their pediatric/child voices catalog. 3. Addressing Ear Fatigue and Equity While parametric synthesizers are excellent for high-speed text scanning, extended multi-hour document audits cause severe cognitive ear fatigue due to compressed, robotic waveforms. Integrating the full Acapela catalog—including both 22kHz HQ (High Quality) profiles for natural reading stamina and 22kHz CO (Colibri/Compact) profiles for rapid responsiveness—allows blind and low-vision power users to pick their preferred acoustic texture. Natively licensing this library eliminates the unfair financial barrier of third-party lifetime licensing fees, creating true out-of-the-box system equity. If you want to check out my post on expressive Siri, see below. Link: https://developer.apple.com/forums/thread/834920
0
0
783
Jul ’26
iPhone 16 pro still says "Indexing in progress" after 29 hours. Anyone experiencing this as well?
"On an iPhone 16 Pro running iOS 27 Developer Beta 1, the system search index has remained stuck on 'Indexing in progress' for 29 hours following Siri app access approval at 3 PM yesterday. The local file system is unburdened—there are no complex media or custom font directories present, and third-party app assets are strictly isolated within standard sandboxed containers. This indicates that the Beta 1 indexing persistence is an architectural logic stall or an authentication validation loop triggered by the waitlist activation token, rather than a storage-volume bottleneck."
3
2
573
Jun ’26
Proposing Expressive Siri Offload via Private Cloud Compute (PCC) for 8GB Devices (Feedback ID: FB23178983)
Hi everyone, With the initial rollout of the iOS 27 Beta, the advanced configuration sliders for the new, highly expressive Siri voice models are currently hidden/disabled on devices operating under an 8GB RAM threshold. While the local AFM 3 Core Advanced engine is memory-gated to 12GB+ hardware due to local footprint constraints, this creates a significant barrier for users who rely on next-generation vocal expressivity and fluid dictation features for accessibility. To address this, I have filed a formal feature request (FB23178983) asking Apple to route the expressive Siri framework through Private Cloud Compute (PCC) on 8GB devices (like the iPhone 15 Pro or base iPhone 16 models). By utilizing server-side rendering over secure, stateless cloud nodes, Apple could easily deliver these vital accessibility configurations without exhausting the local 8GB memory footprint. I’m curious if other accessibility testers and auditors on this board are looking for this exact routing path? If you or your users rely on advanced speech synthesis features and are currently locked out by the local RAM gate, please consider filing a duplicate request or adding your diagnostic logs to FB23178983 to help increase visibility with the Core Accessibility and Software Architecture triage teams. Looking forward to hearing your thoughts and experiences with the current voice-indexing behaviors on 8GB hardware!
Replies
4
Boosts
1
Views
2.4k
Activity
1d
Proposal: Integrate ChromeOS & Natural Neural Voices into iOS VoiceOver for 8GB+ Hardware (FB24788469)
Feedback Assistant ID: FB24788469 (Cross-reference: Complementary to third-party TTS framework initiatives logged in FB23666342) Overview With the continued evolution of on-device machine learning and Apple Silicon's unified memory architecture, I propose that Apple evaluate expanding the native VoiceOver speech library in the upcoming iOS 28 cycle to incorporate lightweight, natural acoustic and neural voice models—specifically the profiles utilized across ChromeOS, Android, and CNET accessibility pipelines (including the natural Google Assistant voice profile). Hardware Feasibility & RAM Footprint • Demonstrated Efficiency on 8GB Systems: In real-world desktop testing across both an ASUS laptop and an HP laptop configured with 8GB of RAM, these voice profiles operate with near-instantaneous responsiveness, zero audio stutter, and negligible memory overhead. • Client-Side Execution Proof: In testing with NonVisual Desktop Access (NVDA)—an open-source Windows screen reader for blind and vision-impaired users—these voices run client-side using Google's WebAssembly (WASM) text-to-speech engine via background Chromium runtimes. Even during heavy UI tree navigation and multitasking, the 8GB systems run effortlessly without memory pressure warnings, UI latency, or process termination. • Viability Across 8GB & 12GB Apple Silicon: Apple Silicon devices leverage high-bandwidth unified memory and dedicated Neural Engine cores. Compiling or running these lightweight neural acoustic models via Core ML on all 8GB and 12GB devices running iOS 28—as well as future hardware generations—leaves substantial headroom for foreground apps without risking memory eviction. Technical & Practical Justification 1. Prosody and Auditory Fatigue: Modern neural synthesis captures natural cadence, warmth, and contextual phrasing, substantially reducing listening fatigue during multi-hour screen reading sessions compared to older formant or diphone synthesizers. 2. Deterministic On-Device Latency (Sub-50ms): Screen reader users require immediate auditory feedback when navigating character-by-character or word-by-word. Running these models locally on-device guarantees the sub-50ms response times essential for VoiceOver, with zero network latency and complete offline reliability. 3. Cross-Platform Continuity & Inter-Platform Synergy: Blind and low-vision users who switch between desktop environments (such as Windows with NVDA or ChromeOS) and iOS benefit greatly from vocal consistency across their workflows. Furthermore, given Apple's established collaboration with Google regarding foundational AI models, exploring speech asset licensing or compiling these lightweight voice packages into native iOS speech audio units represents a logical, accessible extension of existing synergy. Proposed Solution Provide downloadable, on-device voice packages for these high-efficiency neural and ChromeOS-style profiles directly within: Settings > Accessibility > VoiceOver > Speech > Voice in iOS 28. It would be greatly appreciated if I could get community feedback. If posting in a language other than English, I'll use Gemini to translate it into English and post the translation for English speakers as a reply to this post. Also, if you want to check out my posts on Acapela's voice library integration, and my Expressive Siri posts, check out the links below and give me your thoughts on them as well. This post will be cross-linked on those as well, creating a closed triangular circuit. Expressive Siri Link: https://developer.apple.com/forums/thread/834920 Acapela Voice Library Integration Link: https://developer.apple.com/forums/thread/837701
Replies
0
Boosts
0
Views
237
Activity
1d
Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing:
Feature Request: Native Acapela Voice Library Integration & Cross-Pipeline Voice Sharing Associated Feedback Feedback Assistant Ticket: FB23666342 1. The Core Proposal On behalf of the assistive technology and screen-reader community, I am requesting the native system-level integration of the comprehensive Acapela Voice Library into iOS and macOS. This library should be added as a native synthesizer tier alongside existing options like Eloquence. Additionally, we request cross-pipeline voice compatibility, allowing the Siri assistant to utilize configured VoiceOver voice assets, and allowing VoiceOver to utilize Expressive Siri neural models. 2. Structural UI Layout Concept To maintain system cleanliness while maximizing user choice, we propose grouping the Acapela catalog exactly like the current native Eloquence implementation: A main, expandable heading titled Acapela inside the Speech rotor settings. Under this heading, voices should be strictly categorized by global regional dialects (including English U.S., English UK, Australia, India, Scotland, and all other languages offered to AT vendors). This deployment must include all specialized character profiles (such as the Little Creature variant) and their pediatric/child voices catalog. 3. Addressing Ear Fatigue and Equity While parametric synthesizers are excellent for high-speed text scanning, extended multi-hour document audits cause severe cognitive ear fatigue due to compressed, robotic waveforms. Integrating the full Acapela catalog—including both 22kHz HQ (High Quality) profiles for natural reading stamina and 22kHz CO (Colibri/Compact) profiles for rapid responsiveness—allows blind and low-vision power users to pick their preferred acoustic texture. Natively licensing this library eliminates the unfair financial barrier of third-party lifetime licensing fees, creating true out-of-the-box system equity. If you want to check out my post on expressive Siri, see below. Link: https://developer.apple.com/forums/thread/834920
Replies
0
Boosts
0
Views
783
Activity
Jul ’26
iPhone 16 pro still says "Indexing in progress" after 29 hours. Anyone experiencing this as well?
"On an iPhone 16 Pro running iOS 27 Developer Beta 1, the system search index has remained stuck on 'Indexing in progress' for 29 hours following Siri app access approval at 3 PM yesterday. The local file system is unburdened—there are no complex media or custom font directories present, and third-party app assets are strictly isolated within standard sandboxed containers. This indicates that the Beta 1 indexing persistence is an architectural logic stall or an authentication validation loop triggered by the waitlist activation token, rather than a storage-volume bottleneck."
Replies
3
Boosts
2
Views
573
Activity
Jun ’26
Status of FB23,024,971
I submitted FB23,024,971 and I was wondering what its status was? The report detailed the indexing and Siri mode focus trap bugs.
Replies
0
Boosts
1
Views
70
Activity
Jun ’26