With iPadOS 18, the UITabBar now defaults to the floating style. I successfully reverted the tab bar to its traditional style by overriding the UITabBarController's horizontalSizeClass property: self.tabBarController?.traitOverrides.horizontalSizeClass = .unspecified When I launch the app on my Mac using Apple Silicon, TWO tab bars appear: One appears at the bottom of the screen, like a traditional tab bar. The second tab bar is still embedded in the app toolbar in its floating style. Is this a bug? How do you ensure that overriding the horizontalSizeClass will remove/hide the floating tab bar when running an app on Apple Silicon? TIA! (Demonstrated on a test project)

I'm encountering a segmentation fault when using np.matmul with relatively small arrays on macOS 15.2. The issue only occurs in specific scenarios and results in a crash with the following error: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000110 Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault: 11 Full error log: Gist link The crash consistently occurs on a specific line where np.matmul is called, despite similar np.matmul operations succeeding earlier in the same script. The issue cannot be reproduced in a separate script that contains identical operations. When I build the NumPy wheel using OpenBLAS, this issue no longer arises, which leads me to believe that it is related to a problem with Accelerate. Environment NumPy Version: 2.1.3 Python Version: 3.12.7 OS Version: macOS 15.2 BLAS Configuration: Build Dependencies: blas: detection method: system found: true include directory: unknown lib directory: unknown name: accelerate openblas configuration: unknown pc file directory: unknown version: unknown lapack: detection method: system found: true include directory: unknown lib directory: unknown name: accelerate openblas configuration: unknown pc file directory: unknown version: unknown Compilers: c: commands: cc linker: ld64 name: clang version: 15.0.0 c++: commands: c++ linker: ld64 name: clang version: 15.0.0 cython: commands: cython linker: cython name: cython version: 3.0.11 Machine Information: build: cpu: aarch64 endian: little family: aarch64 system: darwin host: cpu: aarch64 endian: little family: aarch64 system: darwin

Hi everyone! I'm developing a system where an application running in a VM communicates with the host operating system's components using vsock sockets (VZVirtioSocketDevice in Virtualization.framework). Both systems are running macOS. There may be multiple guests, and the existing implementation for other OSes relies on VM's CID to differentiate them. In macOS, getting the CID from inside the guest VM is straightforward—it is returned by IOCTL_VM_SOCKETS_GET_LOCAL_CID. However, in macOS the regular vsock API is not available on the host side, replaced by Virtualization.framework. I could not find anything in the Virtualization.framework's documentation that could be used to query (or set?) the CID for the specific virtual machine instance (which is certainly possible on other platforms utilizing Virtio drivers, e.g. Linux/QEMU). Am I overlooking something?

It appears that there is a size limit when training the Tabular Classification model in CreatML. When the training data is small, the training process completes smoothly after a specified period. However, as the data volume increases, the following issues occur: initially, the training process indicates that it is in progress, but after approximately 24 hours, it is automatically terminated after an hour. I am certain that this is not a manual termination by myself or others, but rather an automatic termination by the machine. This issue persists despite numerous attempts, and the only message displayed is “Training Canceled.” I would appreciate it if someone could explain the reason behind this behavior and provide a solution. Thank you for your assistance.

Issue type: Bug TensorFlow metal version: 1.1.1 TensorFlow version: 2.18 OS platform and distribution: MacOS 15.2 Python version: 3.11.11 GPU model and memory: Apple M2 Max GPU 38-cores Standalone code to reproduce the issue: import tensorflow as tf if __name__ == '__main__': gpus = tf.config.experimental.list_physical_devices('GPU') print(gpus) Current behavior Apple silicone GPU with tensorflow-metal==1.1.0 and python 3.11 works fine with tensorboard==2.17.0 This is normal output: /Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/bin/python /Users/mspanchenko/VSCode/cryptoNN/ml/core_second_window/test_tensorflow_gpus.py [PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')] Process finished with exit code 0 But if I upgrade tensorflow to 2.18 I'll have error: /Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/bin/python /Users/mspanchenko/VSCode/cryptoNN/ml/core_second_window/test_tensorflow_gpus.py Traceback (most recent call last): File "/Users/mspanchenko/VSCode/cryptoNN/ml/core_second_window/test_tensorflow_gpus.py", line 1, in <module> import tensorflow as tf File "/Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/lib/python3.11/site-packages/tensorflow/__init__.py", line 437, in <module> _ll.load_library(_plugin_dir) File "/Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/lib/python3.11/site-packages/tensorflow/python/framework/load_library.py", line 151, in load_library py_tf.TF_LoadLibrary(lib) tensorflow.python.framework.errors_impl.NotFoundError: dlopen(/Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/lib/python3.11/site-packages/tensorflow-plugins/libmetal_plugin.dylib, 0x0006): Symbol not found: __ZN3tsl8internal10LogMessageC1EPKcii Referenced from: <D2EF42E3-3A7F-39DD-9982-FB6BCDC2853C> /Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/lib/python3.11/site-packages/tensorflow-plugins/libmetal_plugin.dylib Expected in: <2814A58E-D752-317B-8040-131217E2F9AA> /Users/mspanchenko/anaconda3/envs/cryptoNN_ml_core/lib/python3.11/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so Process finished with exit code 1

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?

Currently, I am working on an iOS app with a Deployment Target set to iOS 15.0, and macOS 12.0. The app is allowed to run on Macs with Apple Silicon. A customer with a Mac running macOS Monterey (12) is complaining that in the TestFlight app, they cannot install the app since it shows "Requires OS Update", even though the deployment target is smaller than the installed version of macOS 12. Are there any specifications available on which macOS version is required in order to use iOS apps on Silicon Macs?

Recently I started getting emails from AppStoreConnect when I submit new builds. The email states: ITMS-90863: Macs with Apple silicon support issue - The app links with libraries that aren’t present in macOS: /usr/lib/swift/libswiftHomeKit.dylib I can run this app on Apple Silicon from TestFlight or directly from Xcode and it runs just fine including all HomeKit functions. This app has been using HomeKit for several years now. This issue seems to be the same kind of this other about CloudKit, but with HomeKit libs: https://developer.apple.com/forums/thread/756325 Please, how it can be fixed? Many thanks.

Hello! I've been trying to run tensorflow on my MBA M3. I previously had an Intel Mac and was able to run tensorflow without any problem. I've been working on a personal project in a directory I made on my previous Mac, that I was running through Jupyter notebook. Now every time I try to run the code, the kernel will die and I'm unsure what to do. I tried following tutorials, but every tutorial I've seen has made me create a new environment to access Jupyter Notebook, but not letting me access notebooks and files that have already been created. I tried to run this following command in terminal and received the subsequent error back. python -m pip install tensorflow-metal ERROR: Could not find a version that satisfies the requirement tensorflow-metal (from versions: none) ERROR: No matching distribution found for tensorflow-metal I've installed miniforge, Xcode, and anaconda onto my computer already and wanted some assistance.

I am building and running a simple Open MPI C application. In order to run it, I configured the run process in this way:\ Edit Scheme -> Run -> Info -> Executable -> Other... -> /path/to/mpiexec Edit Scheme -> Run -> Arguments -> Arguments Passed On Launch -> -np 4 "$(BUILT_PRODUCTS_DIR)/$(EXECUTABLE_NAME)" Now, instead of the hardcoded "4" as the number of processes, I want to specify an environment variable (like the already existing BUILT_PRODUCTS_DIR and EXECUTABLE_NAME environment variables), so I enter in Environment Variables NUM_PROCS as Name and 4 as Value. Thus, I write in Arguments Passed On Launch the whole quoted string: "-np" "$(NUM_PROCS)" "$(BUILT_PRODUCTS_DIR)/$(EXECUTABLE_NAME)". And Xcode can't read the NUM_PROCS environment variable (despite I can easily read it in the C program by a getenv("NUM_PROCS")!), in fact, it runs the default number of processes of my system (12). I tried in a very large number the different ways of writing arguments (every string on a new line, with quotes, without quotes, ...), but none worked as I expected. M3 Pro, macOS Sequoia 15.0.1 Xcode 16.0

hi Question is in the title.. do we already know the length of the vectors? best regards

Hi community! It is known that application designed for iOS may be launched on MacOS with arm chip. With XCode this is simple, you just choose to launch on current machine (Designed for iPad). As I can see, some magic happens: some tool wraps myproj.app into another app, which contains WrappedBundle link and Wrapper subdirectory. Does anybody know how to invoke this wrapping tool via command line? I am using CLion as IDE for my personal preferences, and I want to build app with CLion and wrap the result with external tool into a MacOS-compatible app to test if it works for MacOS as well. In other words, having the myproj.app I want to run something like "magictool -wrap /path/to/myproj.app" Best regards!

I have an iOS/iPadOS app. When I run the app on Mac as a Designed for iPad app, Save button on the Share Sheet crashes the app. I want to share a view with ImageRenderer, but here's an even easier example where I am trying to share an SF Symbol as an image. ShareLink(item: Image(systemName: "swift"), preview: SharePreview(Text("PNG"), image: Image(systemName: "swift"))) Share button works. It opens Share Sheet. "Add to Photos" works. "Copy" works. I can paste the image file in Finder after I press "Copy". But when I press the "Save" button, my app crashes with the error: Thread 1: "-[NSItemProvider pathExtension]: unrecognized selector sent to instance 0x600001c1e290" How to fix this error? How to make saving the image work? Maybe I need additional permissions in plist? I already have "Privacy - Photo Library Additions Usage Description" and everything on iOS and iPadOS works without a problem.

Since I haven't heard so much as a peep from Apple on this, I thought I'd take a poll here on how long I could expect an easily reproducible (albeit possibly obscure) kernel panic to be fixed. I was under the impression that kernel panics were a big deal but it's been almost 2 months since I updated from macOS 14 to macOS 15.0 dev beta 7 / public beta 5 when I originally came across and reported a panic triggered while playing StarCraft II. I've been able to consistently trigger panics playing certain (maybe all) Co-op maps in SC2 and since my first report Aug 22, I've filed 8 additional bug reports, each automatically generated after hitting yet another panic. (I'm not sure exactly who is able to view these but for what it's worth, these are the reports I've filed so far: FB14886510, FB14905773, FB14960435, FB15304609, FB15391195, FB15467943, FB15468127, FB15491485, FB15491684.) A few other people have reported the issue to SC2's developer, Blizzard, and apparently Blizzard has acknowledged they're aware of the problem so it's safe to rule out the possibility of a hardware defect or other issue specific only to my computer. The logs point the blame at the AppleDCP driver, although I suppose the problem could technically be in the DCP firmware instead. Regardless, Apple's code is clearly at fault here. I'll admit the importance of a video game isn't exactly like keeping the power on at a hospital but I don't know why it would be deemed particularly unimportant either. At 53 days in, am I wrong to expect this to have been fixed by now or is Apple really being that slow?

I developed my app with React-Native-CLI, version 0.67.2. I use Xcode 16 on MacOS Sequoia 15.0.1 It builds and runs fine on any simulator, iOS 17 or iOS 18. As soon as I build it for my iPhone 12 iOS 17.6.1 or archive, it throws this error "Command PhaseScriptExecution failed with a nonzero exit code" at the last time. It actually starts the Metro. I made my iPhone into developer mode. Paired it with MacOS. The thing I don't get why it doesn't work on my iPhone when it works fine on simulators. It doesn't even archive. Anyone encountered something like this in the past?

After building the app for TextFlight, I uploaded it. After that, I initially received the following message via email. "ITMS-90899: Macs with Apple silicon support issue - The app isn‘t compatible with the provided minimum macOS version of 11.0. It can run on macOS 12.0 or later. Please specify an LSMinimumSystemVersion value of 12.0 or later in a new build, or select a compatible version in App Store Connect." So I added "LSMinimumSystemVersion" to info.plist, increased the version, and uploaded it again. Next "ITMS-90863: Macs with Apple silicon support issue - The app links with libraries that aren’t present in macOS: /usr/lib/swift/libswiftCloudKit.dylib @rpath/libswiftCloudKit.dylib" I received an issue email like the above. The app has supported Mac (Designed by iPad) so far. This time, this issue occurs after building in Xcode 16.0 / MacBook OS 14.6.1. The app being built supports at least iOS 14. We cannot uncheck it because we must support "Mac (Designed by iPad)" in the future. This issue did not occur in the initial upload and distribution. It occurred after deleting all files in the ~/Library/Developer/Xcode/DerivedData path and rebuilding the project. Is this an Xcode bug that will be fixed in the next update? Or is there a separate solution?

hello, i wrote a method with Neon for accelerate my code.. I don't have the expected result only simples instructions and, or, shift... on 64bits no gain speed. nada :-( i dont understand... how programm this method for speed? original code : unsigned long long RXBitBoard::get_legal_moves(const unsigned long long p_discs, const unsigned long long o_discs) { const unsigned long long inner_o_discs = o_discs &amp; 0x7E7E7E7E7E7E7E7EULL; /* direction W */ unsigned long long flipped = (p_discs &gt;&gt; 1) &amp; inner_o_discs; flipped |= (flipped &gt;&gt; 1) &amp; inner_o_discs; unsigned long long adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &gt;&gt; 1); flipped |= (flipped &gt;&gt; 2) &amp; adjacent_o_discs; flipped |= (flipped &gt;&gt; 2) &amp; adjacent_o_discs; unsigned long long legals = flipped &gt;&gt; 1; // /* direction _E*/ // flipped = (p_discs &lt;&lt; 1) &amp; inner_o_discs; // flipped |= (flipped &lt;&lt; 1) &amp; inner_o_discs; // // adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &lt;&lt; 1); // // flipped |= (flipped &lt;&lt; 2) &amp; adjacent_o_discs; // flipped |= (flipped &lt;&lt; 2) &amp; adjacent_o_discs; // // legals |= flipped &lt;&lt; 1; // trick /* direction _E */ flipped = (p_discs &lt;&lt; 1); legals |= ((flipped + inner_o_discs) &amp; ~flipped); /* direction S */ flipped = (p_discs &gt;&gt; 8) &amp; o_discs; flipped |= (flipped &gt;&gt; 8) &amp; o_discs; adjacent_o_discs = o_discs &amp; (o_discs &gt;&gt; 8); flipped |= (flipped &gt;&gt; 16) &amp; adjacent_o_discs; flipped |= (flipped &gt;&gt; 16) &amp; adjacent_o_discs; legals |= flipped &gt;&gt; 8; /* direction N */ flipped = (p_discs &lt;&lt; 8) &amp; o_discs; flipped |= (flipped &lt;&lt; 8) &amp; o_discs; adjacent_o_discs = o_discs &amp; (o_discs &lt;&lt; 8); flipped |= (flipped &lt;&lt; 16) &amp; adjacent_o_discs; flipped |= (flipped &lt;&lt; 16) &amp; adjacent_o_discs; legals |= flipped &lt;&lt; 8; /* direction NE */ flipped = (p_discs &gt;&gt; 7) &amp; inner_o_discs; flipped |= (flipped &gt;&gt; 7) &amp; inner_o_discs; adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &gt;&gt; 7); flipped |= (flipped &gt;&gt; 14) &amp; adjacent_o_discs; flipped |= (flipped &gt;&gt; 14) &amp; adjacent_o_discs; legals |= flipped &gt;&gt; 7; /* direction SW */ flipped = (p_discs &lt;&lt; 7) &amp; inner_o_discs; flipped |= (flipped &lt;&lt; 7) &amp; inner_o_discs; adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &lt;&lt; 7); flipped |= (flipped &lt;&lt; 14) &amp; adjacent_o_discs; flipped |= (flipped &lt;&lt; 14) &amp; adjacent_o_discs; legals |= flipped &lt;&lt; 7; /* direction NW */ flipped = (p_discs &gt;&gt; 9) &amp; inner_o_discs; flipped |= (flipped &gt;&gt; 9) &amp; inner_o_discs; adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &gt;&gt; 9); flipped |= (flipped &gt;&gt; 18) &amp; adjacent_o_discs; flipped |= (flipped &gt;&gt; 18) &amp; adjacent_o_discs; legals |= flipped &gt;&gt; 9; /* direction SE */ flipped = (p_discs &lt;&lt; 9) &amp; inner_o_discs; flipped |= (flipped &lt;&lt; 9) &amp; inner_o_discs; adjacent_o_discs = inner_o_discs &amp; (inner_o_discs &lt;&lt; 9); flipped |= (flipped &lt;&lt; 18) &amp; adjacent_o_discs; flipped |= (flipped &lt;&lt; 18) &amp; adjacent_o_discs; legals |= flipped &lt;&lt; 9; //Removes existing discs legals &amp;= ~(p_discs | o_discs); return legals; } my neon code const uint64x2_t pp_discs = vdupq_n_u64(p_discs); const uint64x2_t oo_discs = vdupq_n_u64(o_discs); const uint64x2_t inner_oo_discs = vdupq_n_u64(o_discs &amp; 0x7E7E7E7E7E7E7E7EULL); //horizontals directions -1, +1 static const int64x2_t shift_1 = {-1, 1}; static const int64x2_t shift_2 = {-2, 2}; uint64x2_t flipped = vandq_u64(vshlq_u64(pp_discs, shift_1), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_1), inner_oo_discs)); uint64x2_t adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_1)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_2), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_2), adjacent_oo_discs)); uint64x2_t legals = vshlq_u64(flipped, shift_1); //verticals directions -8 , +8 static const int64x2_t shift_8 = {-8, 8}; static const int64x2_t shift_16 = {-16, 16}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_8), oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_8), oo_discs)); adjacent_oo_discs = vandq_u64(oo_discs, vshlq_u64(oo_discs, shift_8)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_16), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_16), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_8)); //diagonals directions -7 , +7 static const int64x2_t shift_7 = {-7, 7}; static const int64x2_t shift_14 = {-14, 14}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_7), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_7), inner_oo_discs)); adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_7)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_14), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_14), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_7)); //diagonals directions -9 , +9 static const int64x2_t shift_9 = {-9, 9}; static const int64x2_t shift_18 = {-18, 18}; flipped = vandq_u64(vshlq_u64(pp_discs, shift_9), inner_oo_discs); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_9), inner_oo_discs)); adjacent_oo_discs = vandq_u64(inner_oo_discs, vshlq_u64(inner_oo_discs, shift_9)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_18), adjacent_oo_discs)); flipped = vorrq_u64(flipped, vandq_u64(vshlq_u64(flipped, shift_18), adjacent_oo_discs)); legals = vorrq_u64(legals, vshlq_u64(flipped, shift_9)); return ((vgetq_lane_u64(legals, 0) | vgetq_lane_u64(legals, 1)) &amp; ~(p_discs | o_discs)); } i even wrote a interleave version I can expect a speed gain, no?

I have an Intel based Macbook Pro, which I use for iOS development. Recently I have the need to test my apps on M-series Apple Silicon based simulator images (specifically, 13 inch versions of iPads) which have no "A" series equivalent (iPad Air 13, iPad Pro 13, etc). I have "created" simulators for these devices in Xcode Simulators and Devices, but they do never appear under the File > Open Simulator menu. I have confirmed that creating a new simulator with any A-class device does not exhibit this issue. Interestingly, these device types do NOT appear under the same "Device Type" menu when attempting to create a "New Simulator" from within the Simulator itself. Creating a Simulator in "Device and Simulators" The same menu from inside the "Simulator" app - missing M-class devices: Can anyone confirm, preferably with a link to the documentation, that this is intended behavior? Apple expects us to support M class devices, on still-supported Intel devices, without access to appropriate simulators? Or is this just my machine? System: 16-inch, 2019 MacBook Pro Sonoma 14.0 Xcode 15.4 (15F31d) Thank you

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)

I want to get MacOS Version from Objective-C build for iOS Apps to run on Apple Silicon Mac. Because AppStore In-App Purchase on Apple Silicon Mac had issues on MacOS version 13.0 and was fixed at version 13.3.1. I need to know the exact version of the MacOS to prevent users from buying In-App Purchases. I found that I can get iOS version that the app is emulating on and assume MacOS version from iOS version. But I think it's not 100% guaranteed way, because no documentation says anything about it. Is there a way to get MacOS Version in iOS Apps running on Apple Silicon Mac?