Have you created test users in those other countries for testing?

It sounds like you are mimicking malware behaviour. Sometimes they write an executable to disk only long enough to run it and then delete it right away. Maybe file a DTS ticket with Apple. There may be a way to exempt your build cache from those malware scans.

Are you using a Retina display? Most drawing logic assumes a retina display. You will often see graphics artifacts on non-retina display. Maybe use a DTS ticket instead of just filling a bug.

Have you looked at the performance information from Capture GPU Frame? No. I'm a total GPU newbie. My knowledge of SIMD computing dates from before GPUs were popular. Unfortunately, I don't think you get the fine grained stats on Intel/Discrete that are available on A10X and newer SOCs. If you expect the code to live into the Apple Silicon era, exploring performance on a modern iPad might not be a waste of time. This code might never actually be deployed on Intel. Apple Silicon, on iOS or macOS, is all I care about. I will definitely look at GPU performance when I have this running on iOS. But for now, it still a proof of concept to just get the logic implemented on Metal. I'm using the OpenCL code as a path of least resistance to port to Metal. Also, would OpenCL be using both CPU and GPU while Metal is only using GPU?  I don't think so. This code has the ability to use either, but I think it has to be one or the other. I think it is just a side effect of using this older 2014 machine. I think OpenCL is optimized for it more than it is for the 2017. On the newer machine, Metal does much better. OpenCL still wins 90% of the time, but sometimes Metal wins on the 2017.

It sounds like something in your build process is creating these files with the quarantine bit set. An easy test would be to manually remove any quarantine bit immediately after creating the file and see if that fixes the problem. Apple has some plans for requiring all executables to be signed in the future. I don't know all the details on this because I develop higher-level apps. But from what I understand, they will accept signed apps. They don't have to be notarized. So in addition to removing the quarantine bit, also make sure they are signed. You can do that in the build process without doing a full notarization. If the executable is signed with no quarantine bit, then I would expect the Gatekeeper to just ignore it.

I think everything is layers now. The "modern" way to do this would be to use Swift UI. Can you try a little demo in Swift UI to see if you get the same effect? What you describe is pretty common when doing tiled layers on purpose. You have to fudge the bounds of each tile a bit so it overlaps the other tiles. Perhaps Apple isn't doing that. On the bright side, it is nice to see Apple suffer from the same bugs. I think what causes this is Apple trying to efficiently manage the the zooming by only rendering the parts of the view that are necessary. Those "standard AppKit" ways are likely to break because AppKit is going away. Have you tried using a magnification factor instead?

So, Etresoft if you are still listening and inclined please test with using Safari as the source application which is providing an rtf text selection.... I was only testing the functionality of NSPasteboard itself. In a service context, my app just reads from a selected path in the Finder. I thought that the system integration could explain the problem. If this is really a Safari problem, then my suggestion would be to add HTML to your data types. RTF is pretty ubiquitous on macOS, but isn't the future. There is no guarantee that new code is going to support RTF like it has in the past. It does still say "NeXT", after all. I do happen to have another service that extract links for pasting into Apple Support Communities. When I select a link (which is rich text) in Safari and use this service, I get an error. It seems like Safari is advertising this data, but not providing it. I tried changing this service to accept either "web content" or "URLs" but Safari won't provide any data. I think it is a Safari bug. When I try the same operation in Google Chrome, my service isn't even listed. I guess Chrome isn't advertising this data. That's one way to handle it. I'll go ahead and file a bug report on it. If you do too, that will be two.

I did find some dates that are now including milliseconds, but only in and undocumented field for the receipt file. If @depth42 is using the receipt file data for the "original purchase date" (not receipt download date), then that might explain it. Unfortunately this has never been exposed publicly through the receipt file format, though it is publicly exposed through the server-side receipt validation API. The original purchase date is documented and is documented to be in both methods.

When parsing receipts from the Mac App Store, we have been seeing ones with milliseconds and ones without. Even in the same receipt, there are dates with and dates without. However we do not understand the pattern behind this.  We also have more than twenty customers reporting this problem, and counting. No one else is reporting a problem with this. Which fields, specifically, are showing milliseconds? In the receipt specification page that you posted, there is one field, "Subscription Expiration Date" that is documented as being in milliseconds. Is that the only field where you are seeing this? Or are there others?

Try recompiling that old app using Xcode 12 on macOS 10.15 and run again. Using an old binary doesn't get to the issue. I don't have 10.15 available just right now. But I built it on Xcode 12.2 and tested on Big Sur and it works fine. I tested that build in a 10.15.7 VM and it worked fine there too. Those two cases where you are having problems are when the OS launches your app. It uses the bundle ID to find the app. So, if you are testing this on your development machine, there is no way to tell which executable it might run. If you have some old, buggy version that doesn't read RTF properly, it could be camped out on that version. You might be able to circumvent that by manually launching the app first and then trying the service. But the idea test for anything that integrates with OS services is a fresh install of the OS in a VM.

The RFC 3339 does include an optional milliseconds. However, I just tried this with my own app using the App Store sandbox and a free app on the production sandbox. The date fields on both receipts do not have milliseconds. It seems like a change on this scale would break an awful lot of apps. I'm looking into supporting the milliseconds field, but I see no evidence that this is an emergency. Could there be some other explanation for what you are seeing?

I just tried an old app I have that reads rich text from files via the Services menu. It works fine. Maybe setup a virtual machine and test it there.

Why not just delete the files? Why go through Python? Full Disk Access is tricky. If I understand your description, I'm surprised it worked in Catalina. I have an app that uses Full Disk Access and launches a helper tool to analyze hard drive storage. I used to have option to run the helper as root if the user wanted that. But there was some funky behaviour between a root-owned process being run from a user space process with Full Disk Access. In short, Full Disk Access simply didn't work in that configuration. I even tried giving the helper Full Disk Access, but it didn't work. In my case, I didn't really need root, just I just omit that option on Catalina and later. I'm afraid I don't have a good solution for you. You could get rid of the Python stuff, or maybe add yet another helper to do the deletion from an agent in user space. You can just pass the paths and then put the user in charge of deleting the files, via a script or similar.

Does anybody have an idea what could suddenly be going wrong with the installation from the Mac App store? That is the initial setup where the App Store installs the receipt. There are a number of things that could cause such a problem. The only time I've encountered it is in development when I'm trying to run developer signed versions or I've screwed up the receipt validation logic. Possible external factors could be various "security" or "clean up" apps. They can wreak havoc with signatures, the operating system, or networking. If you can get any of them to contact you directly instead of leaving one-star reviews, you could inquire about what 3rd party system modifications they have installed. Just remember that most of them likely have no idea what software they have installed. They may need help.

Just to follow up. I worked on the code and got it to the point where OpenCL was only about 3 times as fast as Metal. I was doing these tests on my 2014 MacBook Pro, usually with integrated graphics, running 10.16. When I tried it on my 2017 MacBook Pro, with both discrete and integrated graphics, the difference in performance was much smaller. I was also using an older version of the underlying PROJ library for comparison. Most of the overall GPU speedup I was seeing was due to the newer, slower version of PROJ. Metal still runs at about half the speed of OpenCL, but I guess I can live with this. I have learned a few things about Metal optimization. I tried 3 different optimization schemes: 1) Use buffers big enough for all threads so I don't have to worry about reduced efficiency or boundary checks. 2) Use loops in the Metal code to avoid per-pixel threads that are supposedly less efficient. 3) Using private buffers with blits. None of these optimization strategies yielded any improvement. Using private buffers imposed another 50% speed reduction. I think I will go ahead and file a DTS ticket. It should be faster than this, shouldn't it?