OK. I think I figured it out. Table view cells have some hard-coded padding you can't avoid. I don't think that is necessarily a bad thing. I've never noticed this. I think it would only be a problem if you had some large image that you wanted to bleed right to the edge. You might be able to fix it by manually hacking the frame of the cell. Table views, at least on the Mac, are just really tricky this way. I think an iOS table view could probably go right to the edge with no problem. Maybe look for some Apple demos. They tend to all do the same thing with a sidebar of images that go right to the edge. In your example, I was able to hack it to get it to the edge. I turned off content insets for the clip view and manually set them to negative values. Even then I could only hack the left inset. The right one is for the scroll bar and that is automatically adjusted. This would really only be an issue if you wanted a table view that consisted entirely of full-width images. In my app, I do something similar to what you are doing with the background. The trick is, I'm using a custom row view, like this: (NSTableRowView *) tableView: (NSTableView *) tableView   rowViewForRow: (NSInteger) row This view does go to the edge.

I don't see any problem. You can't just look at characters. Those are always supposed to be concatenated. You have to look at tags. When you find a start tag, then you start collecting characters. You append all the characters together until you get to that start tag's end tag. And if you find a new tag before you get to the end tag, well then you've got a new tree. You will have to connect the characters for the inner tag. Then, when you get back to the outer tag, you'll start a new text node (assuming you want to do everything correctly).

Who is "you"? In most cases, Apple doesn't respond in these forums. They do sometimes, but not often. I can assure you there is no "partnership' with Electron. Visual Studio Code is Microsoft's product. You would have to ask Microsoft about it. I'm not sure what you are asking for in terms of "some alternative compatible".

Does the Feedback assistant ever solved any problem you have reported? Sometimes So I'm just wondering if this is the kind of support I must expect by using apple's services. It sounds about right. Your bugs aren't being ignored, it is just that Apple runs at a massive scale. They have over a billion devices in use. The only definitive advice I can give is to never wait for bugs to be fixed. The best I have ever seen was getting a bug fixed in about 3 months. If you find a bug, write a bug report, but also write a workaround. If this bug only exists in a beta build, then, if you're really lucky, you may be able to pull out your workaround before the OS version is released. But in most cases, the workaround will be permanent.

Can you explain this in more detail? Big Sur adds a few new defaults that are likely to break apps or make them look horribly ugly. This table style is one of them. I haven't noticed any difference between 12.1 and 12.2. It kind of sounds like you have some auto layout problem instead. Those can be tricky to debug, especially in TableView, and especially on Big Sur. It is easier to develop on Catalina and then use Big Sur only for testing. You have to hack your way around some of those new default settings though. It can be ugly.

No one can tell you ahead of time if an app will be approved for the Mac App Store. You haven't been very clear about how this file is being opened. Does the user specify the file? If so, you should be OK. When there is clear "user intent" then you can almost always open a file for reading. If the app opens the file on its own, then that's a whole different story. At the most pedantic level, the file system is "not an API" and you can't make any assumptions about it or rely on it. You mentioned using System Preferences > Privacy and/or a runtime prompt. You are on shaky ground here. App Review expects an app to run and provide value to the user when run all by itself. But that I mean, if your app asks for access to the desktop, the App Reviewer will deny that access and most likely reject the app. Asking for any kind of special access is a red flag. Requiring any privileges in System Preferences is a hard no.

your OpenCL kernel is doing 8X more work (float8 vs float), which means you have 8X the number of threads in metal.  I didn't write the OpenCL version. I'm pretty sure it isn't doing 8x the amount of work. I assume one of the many glue functions is doing the math somewhere. One of my experiments did include trying to do more work inside this function in a loop. It didn't have any effect. Metal doesn't seem to have a float8 or a float16 anyway. Although these are equivalent now, my experience has been that Metal is more sensitive to the use of shared (threadgroup) memory than OpenCL was for me. So I am pretty sure that if you first loaded from global (device) to shared (threadgroup) memory, then did the math, that this would be faster. So something simple like this at the top of the kernel: I'm still not sure what you are saying here. For one thing, the new forums automatically use markdown, so you either have to use a code tag or escape any underscores. Also, as I mentioned before, my SIMD and 3D experience predates Metal, OpenCL, and OpenGL. Most of the discussions involving Metal assume that someone is 1) writing a game, 2) has used Metal on iOS, 3) has used OpenGL or OpenCL, DirectX, etc. I don't meet any of those assumptions. For example, the word "global" doesn't appear in Apple's Metal Shading Language Specification. I know what it means in other contexts, but not here. I assume you mean it is the same as "device". For example, I do know what "shading" means in a 3D context, but I'm also pretty sure that I will never actually perform that operation. I have very specific goals for this project. I did try all of this with private buffers, but that had no effect. I will definitely still be using Metal, but not for any calculations. I need more precision than it provides and I can't catch up in software, even with Metal. I can use it for sampling, resizing, and filtering images. Next year I might do some actual 3D drawing.

Am I thinking correctly?  I doubt it. Developer ID is for distribution outside of the Mac App Store. There is no such thing as "interim" distribution or anything. It is Mac App Store, using Apple's download and licensing ecosystem, or Developer ID, using your own download and licensing system. If you are targeting the Mac App Store, then don't worry about Developer ID at all. However, if you do intend to distribute the software yourself using Developer ID, then don't spend too much time with codesign and spctl. Those may be useful debugging tools, but, in most cases, you shouldn't bother. Just build your app in Xcode, archive, and update. Wait 5 minutes. You'll get a notification that your app is notarized. Then, you can "export" your notarized app from the organizer. Zip up that app and post it on your web site. Then download it and try to run. That is the one and only way to test notarization.

What happens if you use a Developer ID certificate?

Yes. Apple Developer site, which you are currently on.

It sounds like you want an audio unit. See the documentation here - https://developer.apple.com/documentation/audiounit?language=objc: I don't know if it is possible to do what you are asking. Generally speaking, it probably would not work for other apps. You could release an app of your own with your own audio units. But you probably cannot interfere with other apps' audio processing. At least, that's my guess.

1) you are doing 8X the work per thread in the OpenCL code What do you mean? I wonder if you made them really equivalent (meaning unrolled 8-way in your metal kernel) what that would do Sorry, not following here. 2) coalesce the read from global memory into shared. ??? Not a clue. Only other thing I could imagine that would make metal slower here is how you are compiling - if you are turning on fast math for example for the transcendental in openCL but using higher precision in the metal kernel. What higher precision? I've abandoned this idea because I decided that metal's limited precision was unacceptable. I did a brief experiment trying to do double-precision in software, but it is way too slow for the GPU to make up the difference.

I'm still interested in a non-Homebrew solution if such a thing is available. Never found one There is nothing special about Homebrew. It is just a bunch of people who, for some reason, hack up Linux build scripts for free to work on a Mac so you don't have to. It looks like you found a bug in their scripts. You should probably contact them about it and submit a fix. I'm not sure if they will accept your fix or not. Python can get really complicated.

I've spend a fair amount of time trying to find a way for an app to modify the main menu (the File Edit ... Help - of the menu bar) of *any* other app. As far as I know, Apple won't let an app do that. Can someone confirm ? I don't know about Apple "letting" an app do that. I have no idea how an app would do that in any kind of reliable method. You would have to do all kind of crazy hacks and even then it probably wouldn't work on anything past 10.8. And getting it to work on Catalina, Big Sur, Apple Silicon? Not a chance! As for App Review, they are very particular about "your app". They require that "your app" conforms to the App Store guidelines. One thing they most certainly will never do is run some other app. They only look at your app and your app's menus. Furthermore, modifying some other app's menu, even if you could do it, would almost certainly be impossible from the sandbox. Have you actually tried this? In the sandbox? If you can make it work, then don't waste your time on the Mac App Store. Write it up as a security bug and go after the bug bounty. Because if you can make that work, especially from the sandbox, you would really get Apple's attention. They would want to shut that down in a hurry. Even if you truly believe in the impossible and get it released in the Mac App Store, you won't made one penny. But as a security bug, faking out menus across the operating system, with a sandbox escape, that's got to be worth 5 figures at least.

If you are using Homebrew, it is most definitely a Homebrew problem. You don't believe me? Install it without Homebrew.