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/

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

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.

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

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

Hello, I am interested in using jax-metal to train ML models using Apple Silicon. I understand this is experimental. After installing jax-metal according to https://developer.apple.com/metal/jax/, my python code fails with the following error JaxRuntimeError: UNKNOWN: -:0:0: error: unknown attribute code: 22 -:0:0: note: in bytecode version 6 produced by: StableHLO_v1.12.1 My issue is identical to the one reported here https://github.com/jax-ml/jax/issues/26968#issuecomment-2733120325, and is fixed by pinning to jax-metal 0.1.1., jax 0.5.0 and jaxlib 0.5.0. Thank you!

what is the diff between INST_ALL and Instructions(FIXED_INSTRUCTIONS)? also CORE_ACTIVE_CYCLE VS Cycles(FIXED_CYCLES)

Hi Apple Engineers, I am experiencing a potential memory management bug with CoreML on M1 Mac (32GB Unified Memory). When processing long video files (approx. 12,000 frames) using a CoreML execution provider, the system often completes the 'Analysing' phase but fails to transition into 'Processing'. It simply exits silently or hits an import error (scipy). However, if I split the same task into small 20-frame segments, it works perfectly at high speeds (~40 FPS). This suggests the hardware is capable, but there is an issue with memory fragmentation or resource cleanup during long-running CoreML sessions. Is there a way to force a VRAM/Unified Memory flush via CLI, or is this a known limitation for large frame indexing?

Hello, I am currently working on a research project under ENINCA Consulting, focused on advanced diagnostic tools for pseudorandom number generators (structural metrics, multi-seed stability, cross-architecture reproducibility, and complementary indicators to TestU01). To validate this diagnostic framework, I prototyped a small non-linear 64-bit PRNG (not as a goal in itself, but simply as a vehicle to test the methodology). During these evaluations, I observed something interesting on Apple Silicon (Mac M1): • bit-exact reproducibility between M1 ARM CPU and M1 Metal GPU, • full BigCrush pass on both CPU and Metal backends, • excellent p-values, • stable behaviour across multiple seeds and runs. This was not the intended objective, the goal was mainly to validate the diagnostic concepts, but these results raised some questions about deterministic compute behaviour in Metal. My question: Is there any official guidance on achieving (or expecting) deterministic RNG or compute behaviour across CPU ↔ Metal GPU on Apple Silicon? More specifically: • Are deterministic compute kernels expected or guaranteed on Metal for scientific workloads? • Are there recommended patterns or best practices to ensure reproducibility across GPU generations (M1 → M2 → M3 → M4)? • Are there known Metal features that can introduce non-determinism? I am not sharing the internal recurrence (this work is proprietary), but I can discuss the high-level diagnostic observations if helpful. Thank you for any insight, very interested in how the Metal engineering team views deterministic compute patterns on Apple Silicon. Pascal ENINCA Consulting

Hi all, I'm trying to install the Xcode 26 beta on Tahoe (M4 Mac mini). I tried the latest beta 6 both the universal and the apple silicon version, but at startup the system says the app is corrupted and will be deleted. I tried this multiple times - always with a fresh download. Then I downloaded the beta 5, which told me at startup that there is no macOS SDK available and then Xcode also quits. I want to update/test my macOS apps for the upcoming Tahoe and want to adapt for the new design. On my Mac is the Xcode version 16.4 installed and this is working correctly. In the last years I started with earlier versions of Xcode betas, but this year I'm a little bit more late. Are there any steps I missed or is this a known issue yet? I had never before so much trouble installing any beta. What can I do? Best regards, Jürgen Terpe

Hi, I am curious about if hyperthreading is enabled/disabled on my macbook pro M1 or M4. Howto figure out? I am using macOS 15.5. Further, I develop a multi-threaded audio sequencer that creates threads per instrument. I use vector operations to increase performance. I recognized lowering synchronization rate from 250 Hz to 60 Hz gives additional performance advantages. Howto programmatically check if Hyperthreading is enabled/disabled and howto enable/disable it programmatically? After some research I found sysctl() and nvram SMTDisable=%01. https://support.apple.com/en-us/101870 Can anyone provide me an Objective C example? regards, Joël

The attached file bellow contains the full error error I clone this repo to my mac, change team id and group, and run it in Xcode: https://github.com/protonpass/ios-pass There's no issue when I ran it with the Debug configuration, but when I go to Product > Scheme > Edit Scheme and change the iOS target build configuration to Release then I got that error above. I have tried Archive and export the ipa, verify that the provisioning profile contains my Mac UDID, but when double clicking the ipa to install, I also got the error This app cannot be installed because its integrity could not be verified.

I am having issues deploying my iOS app, that uses ShazamKit, to get working on a Mac with Apple silicon. When uploading the archive to App Store Connect I do get ITMS-90863: Macs with Apple silicon support issue - The app links with libraries that aren’t present in macOS: /usr/lib/swift/libswiftShazamKit.dylib Is ShazamKit not supported for iOS apps that can run on Macs with Apple silicon? Or is there something I should fix in my setup / deployment?

I am worried that Rosetta 2 will eventually be removed. I rely on it to run x86-64 Docker containers as well as Windows games through the Game Porting Toolkit. I also use CrossOver very often, which relies on Rosetta. I also use an old version of MuseScore that needs it, and every now and then, I download a legacy Intel Mac app. Thus, I'm worried that Apple will no longer offer it for download in future macOS versions. Are there any plans to remove Rosetta? Since Rosetta is only installed on demand, I have a slight bit of reassurance that it might be offered for download indefinitely, since most casual users naturally won't install it in the future as most general consumer apps are compiled natively for ARM, and the on-demand install cuts down on the bloat included with macOS by default. I hope Rosetta could be offered indefinitely, since many pro-users and gamers rely on it very often, even 10 years from now when Intel Macs are completely unsupported. If Rosetta is removed, I might have to switch back to Windows for many tasks, so I really hope for the continued offering of Rosetta.

Investigating a kernel panic, I discovered that Apple Silicon Panic traces are not working with how I know to symbolicate the panic information. I have not found proper documentation that corrects this situation. Attached file is an indentity-removed panic, received from causing an intentional panic (dereferencing nullptr), so that I know what functions to expect in the call stack. This is cut-and-pasted from the "Report To Apple" dialog that appears after the reboot: panic_1_4_21_b.txt To start, I download and install the matching KDK (in this case KDK_14.6.1_23G93.kdk), identified from this line: OS version: 23G93 Kernel version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:04 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T8122 Then start lldb from Terminal, using this command: bash_prompt % lldb -arch arm64e /Library/Developer/KDKs/KDK_14.6.1_23G93.kdk/System/Library/Kernels/kernel.release.t8122 Next I load the remaining scripts per the instructions from lldb: (lldb) settings set target.load-script-from-symbol-file true I need to know what address to load my kext symbols to, which I read from this line of the panic log, after the @ symbol: com.company.product(1.4.21d119)[92BABD94-80A4-3F6D-857A-3240E4DA8009]@0xfffffe001203bfd0->0xfffffe00120533ab I am using a debug build of my kext, so the DWARF symbols are part of the binary. I use this line to load the symbols into the lldb session: (lldb) addkext -F /Library/Extensions/KextName.kext/Contents/MacOS/KextName 0xfffffe001203bfd0 And now I should be able to use lldb image lookup to identify pointers on the stack that land within my kext. For example, the current PC at the moment of the crash lands within the kext (expected, because it was intentional): (lldb) image lookup -a 0xfffffe001203fe10 Which gives the following incorrect result: Address: KextName[0x0000000000003e40] (KextName.__TEXT.__cstring + 14456) Summary: "ffer has %d retains\n" That's not even a program instruction - that's within a cstring. No, that cstring isn't involved in anything pertaining to the intentional panic I am expecting to see. Can someone please explain what I'm doing wrong and provide instructions that will give symbol information from a panic trace on an Apple Silicon Mac? Disclaimers: Yes I know IOPCIFamily is deprecated, I am in process of transitioning to DriverKit Dext from IOKit kext. Until then I must maintain the kext. Terminal command "atos" provides similar incorrect results, and seems to not work with debug-built-binaries (only dSYM files) Yes this is an intentional panic so that I can verify the symbolicate process before I move on to investigating an unexpected panic I have set nvram boot-args to include keepsyms=1 I have tried (lldb) command script import lldb.macosx but get a result of error: no images in crash log (after the nvram settings)

Today, I submitted the following proposal to Apple through the Feedback Assistant app. I'm not confident in how I phrased it—I'd appreciate any thoughts or feedback from fellow developers. Proposal: "Apple Silicon.app" for macOS with Apple Silicon – Enhancing Performance and Swap Memory Control This suggestion has been machine translated into English, so there may be some discrepancies. If you need the actual text, please feel free to reply to this or ask at the email address below. <mail address> If the author of this proposal is to be credited, I would appreciate being listed under the nickname “DiamondGotCat,” where possible. Summary: - Currently, Apple Silicon-equipped Macs have many system-level features locked down or restricted. - This proposal suggests a new application that enables certain advanced controls for power users. - Tentatively named "Apple Silicon.app", the name may be subject to change if a more suitable alternative arises. - I propose this application be added as a pre-installed utility on compatible systems: macOS (M-series), iPadOS (A-series and M-series), and iOS (iPhones with Apple-designed A5 and newer chips, provided the latest OS is available for them). Overview: This proposal introduces "Apple Silicon.app", a new system-level utility designed to offer power users greater flexibility and control over Apple Silicon behavior, as part of a broader feature update for Apple devices. I propose that Apple Silicon.app be automatically installed as a pre-installed application on Apple Silicon devices (Mac, iPad, iPhone, and select Vision devices) that support upcoming major system updates. Suggested Features of Apple Silicon.app: 1. Performance Core Control To describe this functionality, the following terminology will be used: - P-cores: Performance cores - E-cores: Efficiency cores I understand that Apple Silicon emphasizes energy efficiency, but I believe there are users—myself included—who prioritize maximum performance regardless of power usage. Therefore, I propose that the app offer a drop-down menu with the following six modes for performance core usage: A. Automatic (Recommended) – Default macOS behavior; automatically switches between P/E cores based on workload. B. Performance Priority – Prioritizes P-cores for high-demand tasks, restricts E-cores. Ideal for developers, video editors. C. Power Saving – Uses E-cores only whenever possible; limits P-core usage. Great for battery saving. D. P-Core Exclusive Mode – User-defined processes always run on P-cores. Suitable for benchmarks or low-latency tasks. E. E-Core Exclusive Mode – Prioritizes background tasks and thermal efficiency. F. Manual Assignment (Advanced) – Users can manually assign P/E cores per application in a dedicated settings screen. Additionally, I propose the following optional checkbox settings: - Thermal Safety Mode: Automatically switches from P- to E-cores when system heat exceeds a threshold. - Restore Core Settings on Wake: Remembers P/E settings after sleep/wake. - Power Source Adaptive Mode: Switches to power-saving on battery, and performance mode when plugged in. 2. Swap Memory Configuration The app should also enable user-level control over swap memory (i.e., using part of the SSD as virtual memory). Currently, macOS manages swap space automatically with no user customization available. I propose the ability to manually configure the swap system with the following options: - Enable Manual Configuration: Checkbox to switch from automatic to manual control. - Swap Size: Adjustable in GB units, allowing users to allocate desired swap capacity. 3. Other Settings At this point, these are the core features I propose. If additional useful features exist that align with this concept, I welcome further suggestions or expansion. As users—at least speaking for myself—we look forward to such customization options becoming available.

Hello, I have an iOS app that is recording audio that is working fine on iPads/iPhones. It asks for microphone permission and after that recording works. I installed the same app on my M3 MacBook via TestFlight since iPad apps are supposed to work without a change that way. The app starts fine and everything, but it never asks for Microphone permission, so I can't record. Do I need to do something to make this happen (this is not macCatalyst, its running the arm64 iPhone binary on macOS) thanks