Hello , We are planning to deploy an 8-node Mac Studio M5 Ultra cluster for distributed AI computing and would appreciate technical guidance on the recommended architecture, Thunderbolt 5 connectivity, and software configuration. I have reviewed Apple's WWDC26 demonstration of distributed inference and training using MLX, which features four Mac Studios. We would like to understand how best to extend this architecture to eight nodes. We would appreciate guidance on the following: Cluster Architecture and Thunderbolt 5 Connectivity Is it possible to configure all eight Mac Studios as a single distributed AI compute cluster using MLX? What Thunderbolt 5 topology is recommended for eight nodes: ring, partial mesh, or another configuration? Our proposed design includes 14 Thunderbolt 5 cables. Can all 14 be effectively utilized, or would a different cabling arrangement be more appropriate? Is there a recommended port-to-port cabling diagram or reference architecture for an eight-node configuration? Can multiple Thunderbolt 5 links between neighboring Macs be utilized to improve communication performance? Are there example configuration files, commands, or implementation guides for establishing and validating an eight-node cluster? Networking and Storage Is it appropriate to use Thunderbolt 5 for inter-node communication while using a separate 10GbE network and shared NAS for model and dataset storage? Are there any configuration considerations when using both network types simultaneously? My primary concern is establishing the correct Thunderbolt 5 topology and software architecture before implementation, particularly whether the proposed 14-cable arrangement is appropriate for eight nodes. Any guidance, reference architecture, cabling examples, or links to relevant technical documentation would be greatly appreciated. Thank you.

Environment: Mac mini, Apple M2 Pro (Mac14,12), macOS 27.2 (26B123). coremltools 9.0, mlprogram, iOS17 target. Disclosure. I used AI to find and triage this: to bisect the model, isolate the pattern and draft this post. The reproducer and every result above were run on the machine described. Summary. I load the model with computeUnits = .cpuAndNeuralEngine. If the program slices a concat's output along the last axis (slice_by_index) and then joins the slice with other tensors (concat or stack), the Neural Engine compiler refuses the program. MLModel still loads without an error, but runs every operation on the CPU. On a large model, a streaming speech encoder, this costs: a load of 20 s to 6 minutes, at every launch; 1.1 to 1.8 GB of extra memory, because the weights are copied to float32; inference about 15 times slower. MLComputePlan puts 0 of the model's 1,674 operations on the Neural Engine. If the program computes the same values without slicing the concat, the compiler accepts it, and the whole model runs on the Neural Engine. The pattern is common. It is the cache update of a streaming convolution: next_cache = concat(cache, x)[..., -K:]. Reproducer. The script needs coremltools 9.0. It writes refused.mlpackage, or fixed.mlpackage with --fix: import sys import numpy as np import coremltools as ct from coremltools.converters.mil import Builder as mb from coremltools.converters.mil.mil import types from coremltools.converters.mil.mil.passes.pass_pipeline import PassPipeline N, C, T, K = 24, 1024, 7, 8 # layers, channels, new frames per step, cached frames FIX = "--fix" in sys.argv rng = np.random.default_rng(0) W = [(rng.standard_normal((C, 1, K + 1)) * 0.1).astype(np.float16) for _ in range(N)] @mb.program(input_specs=[mb.TensorSpec(shape=(1, N, C, K), dtype=types.fp16), mb.TensorSpec(shape=(1, C, T), dtype=types.fp16)], opset_version=ct.target.iOS17) def prog(cache, x): v = mb.transpose(x=cache, perm=[1, 0, 2, 3]) outs, h = [], x for i in range(N): c = mb.slice_by_index(x=v, begin=[i, 0, 0, 0], end=[i + 1, 1, 0, 0], end_mask=[False, False, True, True], squeeze_mask=[True, False, False, False]) # [1, C, K] new = mb.concat(values=[c, h], axis=-1) # [1, C, K+T] if FIX: # the same values, without cutting the concat o = mb.concat(values=[mb.slice_by_index(x=c, begin=[0, 0, T], end=[1, C, K]), h], axis=-1) else: # the next cache: the last K columns of the concat (start 7, width 8) o = mb.slice_by_index(x=new, begin=[0, 0, T], end=[1, C, T + K]) outs.append(o) h = mb.conv(x=new, weight=W[i], groups=C, pad_type="valid") # [1, C, T] return mb.transpose(x=mb.stack(values=outs, axis=0), perm=[1, 0, 2, 3]), h pipe = PassPipeline.EMPTY # keep the ops as written pipe.append_pass("common::dead_code_elimination") m = ct.convert(prog, convert_to="mlprogram", minimum_deployment_target=ct.target.iOS17, pass_pipeline=pipe, compute_precision=ct.precision.FLOAT32) m.save("fixed.mlpackage" if FIX else "refused.mlpackage")How to see the failure. Start the log, then load each model with .cpuAndNeuralEngine: log stream --level info --predicate 'process == "ANECompilerService"'refused: the log shows allocation hint propogation fails …, MirInfo propogation fails … and Calling ANE compiler done ret(22). The model then runs on the CPU, and MLComputePlan shows no Neural Engine operations. fixed: the log shows ret(0), and the model runs on the Neural Engine. With private data logging on, the compiler names the operation: allocation hint propogation fails in y and MirInfo propogation fails in y/src, then Compiler internal error: Graph traversal failure (target h14g). Here y is the concat that joins the slice, and y/src is the slice. What causes the failure. I changed one property at a time. The compiler fails only when all four conditions hold: a slice_by_index slices a concat's output along the last axis; the slice starts at an offset that is not a multiple of 8 elements (here 7); the slice's width is a multiple of 8 but not of 32 (here 8); a concat or stack then joins the slice with other tensors. These cases compile: starts 0, 8, 16, 24 and 32, and widths 1, 2, 4, 9, 12, 31, 32, 33 and 64. The result does not depend on the number of channels (1 to 1,024), the number of layers or slices (2 to 24), or the weights. Slicing the inputs instead (--fix) compiles. I applied the rewrite to a real model that has this pattern in 24 layers. On the CPU, its outputs are identical to the original's. On the Neural Engine, its word error rate is the same as the original model's on the CPU. Questions. Is this a known limitation of the M2-generation (h14g) compiler, or a bug? Other reports describe similar "propogation" or register-allocation failures on M2- and M3-family chips, with streaming encoders that compile on M5. Could Core ML report the refusal instead of silently loading the model on the CPU? Today the only signals are the log and the memory footprint. Core ML does not cache the failed compile, so every launch repeats it. Is there a recommended way to write a streaming cache update for the Neural Engine?

I’m developing an ARM64-native Wine + FEX compatibility runtime on Apple Silicon, without relying on Rosetta 2. According to the August 2026 Wine-devel discussion, the following entitlement is intended to be available to free developer accounts: com.apple.developer.cross-architecture-support-unmanaged However, I have encountered the following issues: My Xcode Personal Team does not offer a “Cross-architecture Compatibility Framework” capability. Certificates, Identifiers & Profiles is inaccessible to my free developer account. I cannot obtain a provisioning profile authorizing this entitlement. I contacted Apple Developer Support. They explained that entitlement requests generally require an Apple Developer Program Account Holder, but were unable to confirm whether this particular entitlement is currently requestable or where to request it. Could an Apple engineer clarify: Is the unmanaged entitlement currently available to free Personal Teams? What is the official App ID, provisioning profile, and code-signing procedure? Does this entitlement require additional approval from Apple? If it is unavailable, is there an officially supported alternative for development of an ARM64-native Wine loader? My goal is to use the native macOS cross-architecture features while keeping SIP and other security protections enabled. Relevant Wine-devel discussion: https://list\.winehq\.org/hyperkitty/list/wine\-devel%40list\.winehq\.org/thread/CKG5CEN2BE5VRXZ7O7NX4YUSBH3247WH/ Thank you.

Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.

Hello, I recently submitted an enhancement request through Feedback Assistant requesting official native macOS support for Genshin Impact. Feedback ID: FB25106712 I am an Apple Developer Beta tester, a Mac user, and a passionate gamer. I regularly test macOS developer beta releases and provide feedback on performance, stability, compatibility, and the overall system experience. I also genuinely enjoy testing games on Mac and seeing what Apple Silicon is capable of. I have personally tested games such as Wuthering Waves, Cyberpunk 2077, and Minecraft on Mac, and my experience with them has been extremely positive. Wuthering Waves in particular runs very smoothly and seamlessly on my Mac. These experiences have made me feel that the capability for excellent gaming on Apple Silicon is already there. The larger limitation, in my experience, is the availability of native support. As a major HoYoverse fan, Genshin Impact is one of the games I would most like to experience and test natively on macOS. At present, Mac users have to rely on third-party workarounds such as PlayCover, compatibility solutions, or cloud gaming rather than having an officially supported native client. I would really like to see Apple work with HoYoverse to bring Genshin Impact natively to macOS, properly optimized for Apple Silicon and Metal. I would also be very happy to test such a release across macOS versions and provide detailed feedback on performance, graphics, stability, thermals, controller support, and the overall gaming experience. Could this enhancement request be brought to the attention of the appropriate Apple team, or is there an appropriate channel through which I can provide further feedback regarding this request? Thank you for your time.

We have developed an IOPCIFamily based custom KEXT to communicate with Thunderbolt interface storage device. This KEXT is working fine with Apple machines with Intel CPUs in all types of machines (iMac, iMac Pro and MacBooks). We tested this KEXT with Apple Silicon M1 machine where we are observing crash for the very first command we send to the Thunderbolt device. We observed that there is difference in number of bits in Physical Address we use for preparing command PRPs. In Intel machines we get 28-Bit Physical Address whereas in M1 we are getting 36-Bit address used for PRPs. We use inTaskWithPhysicalMask api to allocate memory buffer we use for preparing command PRPs. Below are the options we have used for this: options: kIOMemoryPhysicallyContiguous | kIODirectionInOut capacity: 16kb physicalMask: 0xFFFFF000UL (We want 4kb aligned memory) According to below documentation, we have to use inTaskWithPhysicalMask api to get memory below 4gb. https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/KernelExtensionsandDrivers/KernelExtensionsandDrivers.html#//apple_ref/doc/uid/TP40001064-CH227-SW1 Some devices can only handle physical addresses that fit into 32 bits. To the extent that it is possible to use 64-bit addresses you should do so, but for these devices, you can either use IODMACommand or the initWithPhysicalMask method of IOBufferMemoryDescriptor to allocate a bounce buffer within the bottom 4 GB of physical memory. So just want to know what's the difference between Intel and ARM64 architecture with respect to physical memory access. Is there any difference between byte order for physical memory address..?? Crash log is given below: panic(cpu 0 caller 0xfffffe0016e08cd8): "apciec[0:pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x00020000 linkcdmsts=0x00000800 (ltssm 0x11=L0)\n" Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 20C69 Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASEARM64T8101 Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34 Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536 iBoot version: iBoot-6723.61.3 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x000000000dbfc000 KernelCache base: 0xfffffe0014c00000 Kernel slide: 0x000000000e73c000 Kernel text base: 0xfffffe0015740000 Kernel text exec base: 0xfffffe0015808000 machabsolutetime: 0x12643a9c5 Epoch Time: sec usec Boot : 0x5fe06736 0x0009afbc Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x5fe067fd 0x0006569d CORE 0 recently retired instr at 0xfffffe0015971798 CORE 1 recently retired instr at 0xfffffe0015972c5c CORE 2 recently retired instr at 0xfffffe0015972c5c CORE 3 recently retired instr at 0xfffffe0015972c5c CORE 4 recently retired instr at 0xfffffe0015972c60 CORE 5 recently retired instr at 0xfffffe0015972c60 CORE 6 recently retired instr at 0xfffffe0015972c60 CORE 7 recently retired instr at 0xfffffe0015972c60 Panicked task 0xfffffe166ce9e550: 75145 pages, 462 threads: pid 0: kernel_task Panicked thread: 0xfffffe166d053918, backtrace: 0xfffffe306cb4b6d0, tid: 141 lr: 0xfffffe0015855f8c fp: 0xfffffe306cb4b740 lr: 0xfffffe0015855d58 fp: 0xfffffe306cb4b7b0 lr: 0xfffffe0015977f5c fp: 0xfffffe306cb4b7d0 lr: 0xfffffe0015969914 fp: 0xfffffe306cb4b880 lr: 0xfffffe001580f7e8 fp: 0xfffffe306cb4b890 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc20 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc90 lr: 0xfffffe0015ff03f8 fp: 0xfffffe306cb4bcb0 lr: 0xfffffe0016e08cd8 fp: 0xfffffe306cb4bd60 lr: 0xfffffe00166bc778 fp: 0xfffffe306cb4be30 lr: 0xfffffe0015f2226c fp: 0xfffffe306cb4be80 lr: 0xfffffe0015f1e2f4 fp: 0xfffffe306cb4bec0 lr: 0xfffffe0015f1f050 fp: 0xfffffe306cb4bf00 lr: 0xfffffe0015818c14 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleEmbeddedPCIE(1.0)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.IODARTFamily(1)[88B19766-4B19-3106-8ACE-EC29201F00A3]@0xfffffe0017890000->0xfffffe00178a3fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff com.apple.driver.AppleT8103PCIeC(1.0)[35AEB73B-D51E-3339-AB5B-50AC78740FB8]@0xfffffe0016e04000->0xfffffe0016e13fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.AppleEmbeddedPCIE(1)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.ApplePIODMA(1)[A8EFA5BD-B11D-3A84-ACBD-6DB25DBCD817]@0xfffffe0016b0c000->0xfffffe0016b13fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff dependency: com.apple.iokit.IOThunderboltFamily(9.3.2)[11617399-2987-322D-85B6-EF2F1AD4A794]@0xfffffe0017d80000->0xfffffe0017e93fff Stackshot Succeeded Bytes Traced 277390 (Uncompressed 703968) ** System Information: Apple Silicon M1 BigSur 11.1 Model: Macmini9,1 Any help or suggestion is really appreciated. Thanks

I'm writing GPU compute kernels (parallel prefix-sum and histogram) that rely on threadgroup-address-space atomics specifically atomic_fetch_add_explicit on a threadgroup atomic_uint, with memory_order_relaxed. Setup: Device: Apple M5, macOS 26.5 Toolchain reports MSL 4.0 / AIR 2.8 (i.e. the "Metal 4.0" feature level) Note: I'm generating AIR (Apple IR) directly rather than emitting MSL source this is through a custom compute backend (Julia's Metal.jl), not the standard MSL front end. What I observe: These threadgroup atomics compile and produce correct results, and give a meaningful speedup over a non-atomic (scan-based) fallback. I've validated correctness across a 256-bin histogram and a full multi-pass radix sort no mismatches. The question: Some capability checks gate threadgroup atomic support behind Metal 4.1, and my device reports 4.0 yet they clearly work. So: Are relaxed integer threadgroup atomics (atomic_fetch_add on threadgroup atomic_uint, relaxed ordering) officially supported on the Metal 4.0 feature set for current Apple Silicon, or is this unsupported behavior that happens to work? Is there a specific MSL version or GPU family that is the true minimum for these operations? Does the answer differ at the AIR / feature-set level (what I'm targeting) vs. the MSL front end, given I'm feeding AIR to the compiler directly? I ask because a downstream library is (reasonably) hesitant to enable this path unless it's officially supported rather than relying on undefined behavior. Any authoritative guidance or a pointer to the relevant feature-set/GPU-family documentation would be hugely appreciated. Thanks!

When I opened an Intel-based app in the macOS 27 beta, a prompt informed me that apps requiring Rosetta will not work in the next OS release (macOS 28). It also prompted me to install Rosetta to continue using the app in macOS 27. After installing, I began wondering if there is a way to remove Rosetta via Settings. Since it is now treated as an optional feature, shouldn't we be able to uninstall it similar to how command line tools are managed? Does anyone know of a method to completely remove Rosetta once it has been installed? (PS: This post was rewritten using Siri AI)

Can't able to run the Create ML for training and I upgraded to MacOS 26.3 beta and I have tried older and newer

Hello, We have received reports from a few of our customers that they received a notification from macOS that our app 24 Hour Wallpaper would not be compatible with future macOS versions. As I understand it from public documentation, this alert shows if an app or any of its components are still using Intel x86 code. However our app has supported Apple Silicon from day one and has no intel-only components. I confirmed that the customers had not elected to run the app using Rosetta accidentally, and that they were running current versions that support Apple Silicon. Beyond what is already written here: https://support.apple.com/en-us/102527 Can anyone be very specific about what actually triggers this alert? Are there known instances of the alert showing erroneously? Thank you, -josh

I'm testing IPhone and iPad Apps on Apple Silicon Macs. When I purchase In-app product in the app on Apple Silicon Mac, the payment receipt is not created, so the purchase fails. In console log, it says it doesn't have permission to write to the file. storekitagent [6913DE38_SK1] Error writing receipt (5095 bytes) to file:///Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “sandboxReceipt” in the folder “StoreKit”" UserInfo={NSFilePath=/Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x14202c920 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} The App is using Original API for In-App Purchase written in Objective-C. When I purchase in-app product, the app calls SKPaymentQueue::addPayment. And then it gets paymentQueue:updatedTransactions callback with SKPaymentTransactionStatePurchased. This means that the payment was successful. But the receipt is not created so I can't continue the after process. I'm testing with sandbox in-app purchase. I have tested several times and confirmed that on macOS Monterey 12.2 the receipt is created successfully, but on macOS Ventura 13.2 the receipt isn't created. I think there is something to do with macOS version. Does anyone have any solutions? Here is a very similar thread on apple developer forum. (And there too has no anwsers)  https://developer.apple.com/forums/thread/719505

We recently started working on getting an iOS app to work on Macs with Apple Silicon as a "Designed for iPhone" app and are having issues with speech synthesis. Specifically, voices retuned by AVSpeechSynthesisVoice.speechVoices() do not all work on the Mac. When we build an utterance and attempt to speak, the synthesizer falls back on a default voice and says some very odd text about voice parameters (that is not in the utterance speech text) before it does say the intended speech. Here is some sample code to setup the utterance and speak: func speak(_ text: String, _ settings: AppSettings) { let utterance = AVSpeechUtterance(string: text) if let voice = AVSpeechSynthesisVoice(identifier: settings.selectedVoiceIdentifier) { utterance.voice = voice print("speak: voice assigned \(voice.audioFileSettings)") } else { print("speak: voice error") } utterance.rate = settings.speechRate utterance.pitchMultiplier = settings.speechPitch do { let audioSession = AVAudioSession.sharedInstance() try audioSession.setCategory(.playback, mode: .default, options: .duckOthers) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) self.synthesizer.speak(utterance) return } catch let error { print("speak: Error setting up AVAudioSession: \(error.localizedDescription)") } } When running the app on the Mac, this is the kind of error we get with "com.apple.eloquence.en-US.Rocko" as the selectedVoiceIdentifier: speak: voice assgined [:] 2023-05-29 18:00:14.245513-0700 A.I.[9244:240554] [aqme] AQMEIO_HAL.cpp:742 kAudioDevicePropertyMute returned err 2003332927 2023-05-29 18:00:14.410477-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.412837-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.413774-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.414661-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.415544-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.416384-0700 A.I.[9244:240554] Could not retrieve voice [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null) 2023-05-29 18:00:14.416804-0700 A.I.[9244:240554] [AXTTSCommon] Audio Unit failed to start after 5 attempts. 2023-05-29 18:00:14.416974-0700 A.I.[9244:240554] [AXTTSCommon] VoiceProvider: Could not start synthesis for request SSML Length: 140, Voice: [AVSpeechSynthesisProviderVoice 0x6000033794f0] Name: Rocko, Identifier: com.apple.eloquence.en-US.Rocko, Supported Languages ( "en-US" ), Age: 0, Gender: 0, Size: 0, Version: (null), converted from tts request [TTSSpeechRequest 0x600002c29590] <speak><voice name="com.apple.eloquence.en-US.Rocko">How much wood would a woodchuck chuck if a wood chuck could chuck wood?</voice></speak> language: en-US footprint: premium rate: 0.500000 pitch: 1.000000 volume: 1.000000 2023-05-29 18:00:14.428421-0700 A.I.[9244:240360] [VOTSpeech] Failed to speak request with error: Error Domain=TTSErrorDomain Code=-4010 "(null)". Attempting to speak again with fallback identifier: com.apple.voice.compact.en-US.Samantha When we run AVSpeechSynthesisVoice.speechVoices(), the "com.apple.eloquence.en-US.Rocko" is absolutely in the list but fails to speak properly. Notice that the line: print("speak: voice assigned \(voice.audioFileSettings)") Shows: speak: voice assigned [:] The .audioFileSettings being empty seems to be a common factor for the voices that do not work properly on the Mac. For voices that do work, we see this kind of output and values in the .audioFileSettings: speak: voice assigned ["AVFormatIDKey": 1819304813, "AVLinearPCMBitDepthKey": 16, "AVLinearPCMIsBigEndianKey": 0, "AVLinearPCMIsFloatKey": 0, "AVSampleRateKey": 22050, "AVLinearPCMIsNonInterleaved": 0, "AVNumberOfChannelsKey": 1] So we added a function to check the .audioFileSettings for each voice returned by AVSpeechSynthesisVoice.speechVoices(): //The voices are set in init(): var voices = AVSpeechSynthesisVoice.speechVoices() ... func checkVoices() { DispatchQueue.global().async { [weak self] in guard let self = self else { return } let checkedVoices = self.voices.map { ($0.0, $0.0.audioFileSettings.count) } DispatchQueue.main.async { self.voices = checkedVoices } } } That looks simple enough, and does work to identify which voices have no data in their .audioFileSettings. But we have to run it asynchronously because on a real iPhone device, it takes more than 9 seconds and produces a tremendous amount of error spew to the console. 2023-06-02 10:56:59.805910-0700 A.I.[17186:910118] [catalog] Query for com.apple.MobileAsset.VoiceServices.VoiceResources failed: 2 2023-06-02 10:56:59.971435-0700 A.I.[17186:910118] [catalog] Query for com.apple.MobileAsset.VoiceServices.VoiceResources failed: 2 2023-06-02 10:57:00.122976-0700 A.I.[17186:910118] [catalog] Query for com.apple.MobileAsset.VoiceServices.VoiceResources failed: 2 2023-06-02 10:57:00.144430-0700 A.I.[17186:910116] [AXTTSCommon] MauiVocalizer: 11006 (Can't compile rule): regularExpression=\Oviedo(?=, (\x1b\\pause=\d+\\)?Florida)\b, message=unrecognized character follows \, characterPosition=1 2023-06-02 10:57:00.147993-0700 A.I.[17186:910116] [AXTTSCommon] MauiVocalizer: 16038 (Resource load failed): component=ttt/re, uri=, contentType=application/x-vocalizer-rettt+text, lhError=88602000 2023-06-02 10:57:00.148036-0700 A.I.[17186:910116] [AXTTSCommon] Error loading rules: 2147483648 ... This goes on and on and on ... There must be a better way?

Metal GPU Driver Crash on M5 Pro + macOS 26.5 — kIOGPUCommandBufferCallbackErrorOutOfMemory with <2GB working sets Summary The Metal driver AGXMetalG17X 351.2 on macOS 26.5 (25F71) for the M5 Pro chip crashes with kIOGPUCommandBufferCallbackErrorOutOfMemory (00000008) when running LLM inference workloads with working sets as small as ~1.5GB, despite 24GB of unified memory being available and Apple Diagnostics confirming the hardware is fully functional. This affects multiple tools: MLX, llama.cpp (Metal backend), and native apps using Metal for inference. System Component Value Model MacBook Pro (Mac17,9) Chip Apple M5 Pro (applegpu_g17s) GPU Cores 16 RAM 24 GB LPDDR5 macOS 26.5 (25F71) Metal Metal 4 GPU Driver AGXMetalG17X 351.2 Xcode 26.5 (17F42) Reproduction MLX (Python) pip install mlx mlx-lm python -m mlx_lm.generate \ --model mlx-community/Qwen2.5-3B-Instruct-4bit \ --max-tokens 10 \ --prompt "Hello" Expected: Normal text generation Actual: Crash with: libc++abi: terminating due to uncaught exception of type std::runtime_error: [METAL] Command buffer execution failed: Insufficient Memory (00000008:kIOGPUCommandBufferCallbackErrorOutOfMemory) llama.cpp brew install llama.cpp llama-cli --model model.gguf --prompt "Hello" --n-predict 20 --n-gpu-layers 99 Expected: Fast GPU generation Actual: Process hangs indefinitely Test Results Tool Model Peak Memory Result MLX Qwen2.5-0.5B-4bit 0.36 GB ✅ Works MLX Qwen2.5-1.5B-4bit 0.98 GB ✅ Works MLX Qwen3-1.7B-4bit 1.01 GB ✅ Works MLX Qwen2.5-3B-4bit ~1.5 GB ❌ Metal OOM crash MLX Qwen3-4B-4bit ~2.1 GB ❌ Metal OOM crash MLX Qwen3-8B-4bit ~4.5 GB ❌ Metal OOM crash llama.cpp Qwen2.5-0.5B GGUF ~0.5 GB ❌ Hangs with GPU llama.cpp Qwen2.5-0.5B GGUF ~0.5 GB ✅ Works with CPU only Key Evidence Hardware is healthy — Apple Diagnostics passed all tests Basic Metal works — matmul, array ops work fine CPU inference works — llama.cpp with -ngl 0 runs correctly The error is NOT about actual memory exhaustion — kIOGPUCommandBufferCallbackErrorOutOfMemory means the kernel rejects the Metal memory commit, not that physical memory is full. The system reports 17.76GB available for Metal working set. Crash Log Extract Thread 31 Crashed: 0 libsystem_kernel.dylib __pthread_kill + 8 1 libsystem_pthread.dylib pthread_kill + 296 2 libsystem_c.dylib abort + 148 3 Metal MTLReportFailure.cold.1 + 48 4 Metal MTLReportFailure + 576 5 Metal -[_MTLCommandBuffer addCompletedHandler:] + 104 ... Exception Type: EXC_CRASH (SIGABRT) Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 Related Issues ml-explore/mlx#3586 — Metal compiler regression on macOS 26.5 ml-explore/mlx#3534 — M5 float32 precision issue ml-explore/mlx#3568 — M5 random divergence ml-explore/mlx#3539 — Metal residency OOM (M4 Max) Request Please investigate the AGXMetalG17X driver for M5 Pro on macOS 26.5. The driver appears to incorrectly reject Metal memory commits for LLM inference workloads, even when the working set is well within the system's reported limits (1.5GB requested vs 17.76GB available). Happy to provide full crash logs, sysdiagnose archives, or run additional tests.

I've been testing Apple Silicon devices in their desktop configurations on the Mac Studio and now retired Mac Pro and it seems like they're greatly bottlenecked by their clock speeds. For reference here's my testing results. Testing Results: Mac Studio M2 Max • 32GBs RAM • 30 core GPU • 1TB Storage CPU Utilization • 60% • 20W CPU Temperature • 47ºC GPU Utilization • 100% • 20W GPU Temperature • 55ºC Fan Speed • 50% Workload Duration • 2hrs Another point is that the clock speed on the M2 Max's CPU is 3.5 GHz and on the GPU it is 1.44 GHz at max performance. Which the Mac Studio has no trouble pushing. My question is how do I push those clock speeds higher? Cause 1.44 GHz at 55ºC is evidence for extensive headroom. I'm sure there are tools internally for testing the upper limits of the silicon, but it makes no sense why it would be set so low the Mac Studio is at no worries of melting. Is there any way to push the performance of my Mac Studio? FB22713867 - Possibilities of Overclocking Apple Silicon

We're developing a Mac App Store application that embeds the V8 JavaScript engine (via Electron). The application has shipped successfully on macOS 15.x with the following entitlements: com.apple.security.app-sandbox = true com.apple.security.cs.allow-jit = true com.apple.security.cs.allow-unsigned-executable-memory = true com.apple.security.cs.disable-library-validation = true On macOS 26 Tahoe, the exact same signed binary crashes deterministically within ~1.5 seconds on Apple Silicon with EXC_BREAKPOINT (SIGTRAP), ESR 0xf2000000. The crash is in V8's background JIT compilation thread when it attempts to manage memory page protections (transitioning pages between Read-Write and Read-Execute states via mprotect). The crash does not occur in these configurations: macOS 26 + App Sandbox + Intel x86_64 — works macOS 26 + Hardened Runtime (no sandbox) + ARM64 — works macOS 15.x + App Sandbox + ARM64 — works This appears to be a regression in how the XNU kernel handles mprotect calls for sandboxed processes on ARM64 under macOS 26, specifically in the context of the allow-jit entitlement. Has the behavior of allow-jit changed in macOS 26 with respect to runtime code generation memory management on ARM64? Is there a new API or entitlement that V8-style JIT engines should use instead of mprotect-based RW↔RX page transitions?

We probably triggered a bug within Rosetta: https://github.com/docker/desktop-feedback/issues/230

I’m working on an iOS workspace with: a static library project: M800SDK a test app project: TestAppObj I was able to build M800SDK for iOS Simulator on Apple Silicon as a simulator static library, and I also verified the architectures in the produced .a file. However, when I link the app target against that simulator build and try to build TestAppObj for iOS Simulator, I get the following linker errors: Undefined symbols for architecture arm64: _OBJC_CLASS_$_TokenMngr clang++: error: linker command failed with exit code 1 Additional context: The library links and works correctly when building the app for a physical iPhone. And the public header TokenMngr.h is found correctly by the app target. The app target is compiled as Objective-C++ where needed. The library is linked in the app target under “Link Binary With Libraries”. Could you help me understand: Is it possible to run on iOS Simulator ? the recommended way to package and consume this library for iOS Simulator on Apple Silicon? Also I am aware i can also build the library for : Any iOS Simulator Device (arm64, x86_64) And specify that on Build Phases in Link : Link Binary With Libraries adding the .a Before i do that i ensure the .a is arm64, x86_64 using the command : lipo -info libM800SDK.a end it returns : Architectures in the fat file: libM800SDK.a are: x86_64 arm64 However, even after confirming those architectures and linking the library to the app target, the app still does not link correctly for iOS Simulator. In some cases, Xcode reports errors suggesting that the build is targeting iOS Simulator, but that one of the linked binaries was built for iPhoneOS instead. This is where I am confused: I understand that lipo -info only shows the CPU architectures present in the library, but not whether a given arm64 slice was built for iPhoneOS or for iOS Simulator

According to the release notes for macOS Tahoe 26.4 beta, a warning dialog should appear when launching apps that require Rosetta 2, informing users that these apps will stop working in a future macOS release. However, on my MacBook Air M1 running Tahoe 26.4 Beta 4 (25E5233c), no such warning appears when launching Intel (x86_64) apps. Test case: VLC media player Downloaded from the official VLC website: https://www.videolan.org/vlc/ Selected the Intel 64-bit version (vlc-3.0.21-intel64.dmg) Copied VLC.app to /Applications Code signature verified: Identifier: org.videolan.vlc Format: Mach-O thin (x86_64) Team ID: 75GAHG3SZQ Timestamp: June 2024 Flags: hardened runtime Notarization: accepted (Notarized Developer ID) spctl --assess --verbose /Applications/VLC.app → accepted, source=Notarized Developer ID Launched VLC.app — no Rosetta deprecation warning appeared System log findings: The following entry was repeated many times in the system log: Sandbox: oahd-helper deny(1) file-read-data /usr/libexec/rosetta/oahd-helper This suggests that oahd-helper is being blocked by the Sandbox from reading its own binary, which may be preventing the warning dialog from appearing. My questions: Is this a known bug in Beta 4? Does the absence of a warning mean the app will continue to work in macOS 28 and beyond? Should I file a Feedback report for this? Any insights would be appreciated. Thank you. Environment: Device: MacBook Air 2020 M1 OS: macOS Tahoe 26.4 Beta 4 (25E5233c) Test app: VLC 3.0.21 Intel 64-bit (org.videolan.vlc, Team ID: 75GAHG3SZQ) Source: https://www.videolan.org/vlc/

What is the proper way to pass arguments to printf with multiple variables using ARM64 Apple Silicon? Example: fOutputStr: .asciz "Element[%d] = %d\n" // formated output string for an output of: Element[4] = 9 This code (see below) works on Raspberry Pi 5, on my Mac Studio, I am getting this output, Element[9] = 1871655168 What do I need to do to use printf from an assembly language call with multiple variables? I am using the following code. ` .align 2 // memory alignment model for 64-bit ARMc #if defined(APPLE) .global _main // Provide program starting address to linker Mac OS _main: #else .global main // Raspian and Linux main: #endif // stack frame work setup START stp x29, x30, [sp, -16]! str x20, [sp, -16]! mov x29, sp // stack frame work setup END // setup printf call #if defined(APPLE) adrp x0, fOutputStr@PAGE add x0, x0, fOutputStr@PAGEOFF #else ldr x0, =fOutputStr #endif mov w1, #4 mov w2, #9 print_brk: #if defined(APPLE) stp X0, X1, [SP, #-16]! stp X2, X3, [SP, #-16]! bl _printf ldp X2, X3, [SP], #16 ldp X0, X1, [SP], #16 #else bl printf #endif done: // closing stack frame work ldr x20, [sp],16 ldp x29, x30, [sp],16 // exit mov w0, wzr ret .data .align 4 // intArrayPtr: .word 3,7,5,2,4,8 // word, each value is offset by 4 fOutputStr: .asciz "Element[%d] = %d\n" // formated output string

Hi, I'm building ANF (Autonomous Native Forge) — a cloud-free, 4-agent autonomous software production pipeline running on local hardware with local LLM inference. No middleware, pure Node.js native. Currently running on NVIDIA Blackwell GB10 with vLLM + DeepSeek-R1-32B. Now porting to Apple Silicon. Three technical questions: How production-ready is mlx-lm's OpenAI-compatible API server for long context generation (32K tokens)? What's the recommended approach for KV Cache management with Unified Memory architecture — any specific flags or configurations for M4 Ultra? MLX vs GGUF (llama.cpp) for a multi-agent pipeline where 4 agents call the inference endpoint concurrently — which handles parallel requests better on Apple Silicon? GitHub: github.com/trgysvc/AutonomousNativeForge Any guidance appreciated.