Even writing a file to the Containers tmp folder is marked as quarantine. This is using C style fopen()/fclose() calls. Then I open and copy the contents to another file in the same Containers folder (since tmp file will be removed). So both files end up with quarantine flag set. This all worked perfectly fine in macOS 11-13. So this is something that changed in macOS 14. I used to be able to sign app locally, and all would work.

-march=native is a pretty bad compile setting. You really aren't being specific then about the architecture. And for simd-based libraries you need to enable that too (-mavx2, -msee4.2, etc). I was using that arch that on Windows, and then the compiler uses whatever the SIMD architecture is of the machine that you compile upon. So I'd get AVX-512 code that would then crash on newer machines that omit that support. If you're running the Intel code emulated on Rosetta2, then you can expect a 2x slowdown there. Also note for Intel apps to run under Rosetta2, had to disable avx, and drop to SSE4.2. Also had to drop f16 support since neither of these are supported.

The "Enter Fullscreen" menu item somehow disappears in some builds - could be Release builds. So not sure what is going on here.

Workaround for now is to make the app single-windowed with Window. Also openURL when using WindowGroup just makes a new Window when I really don't want it to.

So "delete" key does back, and "shift+delete" key does forward with no way to override or block this. Then my users lose all context, since the opening page is an empty splash screen that they're not supposed to be able to return to in the history.

So in 4 years, still don’t have functionality of a basic NS/UITableView. Seems there is time to add massive new features but not fix the basic one here. Have a NavigationSplitView with a List, and keyboard commands to advance the list when the list is collapsed or not. When not collapsed the selection happily scrolls off screen which is not acceptable. Arrow keys properly scroll the list to the selection, but that is built-into List. Looks like I have to rewrite to a (limited to 10 item VStack, ScrollView, and ScrollViewProxy) as a workaround. But my list is a flattened list of files. How about a List.scrollToSelection() call? No Apple samples of a real basic UI using SwiftUI, just recipe books with fixed count elements.

You are sending an srgb format and specifiying a linear colorspace. bgra8unorm means the data is typically stored gamma space. bgra8unorm_srgb converts to linear on reads and would match your color space.

I'm not writing Natvis presently, but I have written some in the past. It was EASTL that has the natvis file for all of it's STL data structures. And Xcode has hidden away all of their STL visualizers in fast C++ land, and stripped all the python. And I've also had to write lldb python to fix debugging some of my C++ structs. Both are painful, so no one writes them or puts them out on GitHub. But I feel like the more options that Xcode can import the better, and natvis seems to have won. If you can point me to anyone doing lldbinit files for their projects then I'd be surprised. Will write this up as an FA post.

SwiftUI focus doesn't make any sense to me either. I'm just trying to have keys route properly on a NavigationSplitView. The detail view is a WKWebView and can respond to most keys, but then the list items don't advance off up/down arrow. And the web pages cmd+S (search) doesn't work if the listView is the focus. So the whole firstReponder model really doesn't work. I'm happy to always focus the WKWebView, but then I need the arrows to advance the list without the error "bonk".

Seems this isn't supported. So then would need to ship loose-packed metal files in a bundle or archive them myself.

spirv-cross MSL output is converting SPIRV IL which is completely different than the MSL that will result from DX IL conversion. You have to pick whether you want debugging of quite unreadable transpiled MSL from spirv-cross with all comments stripped, or whatever shader converter generates (probably not even debuggable MSL). HLSL -> DXC -> DXIL -> metal-shaderconverter -> metallib (containing Metal IL)

You are precompiling shaders to a specific metal version, and then that should be compatible with all newer versions of Metal and MSL. There are support checks, and availability macros and weak symbols so you can call ahead to newer functionality but have a minspec for iOS/macOS.

These are errors. And I have warnings as errors on as well. And also xcode reports stale errors in the issue list. The app should not have launched. This is a workspace building several projects into an app, but it’s like Xcode doesn’t care if one of the projects fails. And sometimes it cares about errors that were already fixed until I “clean build folder”. This is mostly a C++ lib linking to ObjC++.

You're supposed to just run each algorithm per row, and then take the smallest one. There's little point in using one algorithm for the entire image. PNG lets you store the lossless algorithm type as the first byte of each row. I've always used my own png code instead of Apple's.

https://feedbackassistant.apple.com/feedback/13203125