I wonder if this is really just a bug, or whether there is some good reason why the compiler thinks it needs to copy the copy-on-write array in that one case.

I continue to find the many posts like this absolutely terrifying. The message from Apple is don't become dependant on your income from the App Store, as we could turn it off at an moment without properly explaining why, or giving enough detail for you to investigate the accusation. For how long could you live off your savings, wife's earnings, etc. if this happened to you? If the answer is "not long enough", then stop working on your Apple apps until you've built up a portfolio of income from other sources.

Does it mean I can use any of them in my iOS app legally? Yes. Does it involve font license issue? No. (Huh?) What else should I pay attention to use system fonts legally? Err... not much? What exactly is your concern?

I think this is somehow related to the thread stack size. Yes, that would be my guess. That's a lot of stack.

I believe that sRGB IEC61966-2.1 is “normal” sRGB, which is surely the default for PNG files. I’m sure it will be fine. If the icon looks right when, for example, you see it on the App Store Connect web interface, then it will look OK on the devices.

Your code says: roundingMode: .up So it rounds up from 75.2 to 76. Where is the confusion?

To give the software a life-expectancy beyond my own, I have now updated the program as a Gradle build and placed it on Github Hmm, what is github's policy when the account holder dies? as soon as it moves to another Mac, I get the ugly message: "GS_MV" is damaged I think the first thing you need to do is to check if the "damaged" copy actually does differ from your working original. How did you copy it? Try scp or rsync. Maybe copy it back again and then compare with cmp, or compute checksums, or something. Does it mean that I have to pay a ransom to Apple No.

Don't worry about it, unless you see some consequences. I believe that the map is caching its decompressed maps tiles, but will discard them if there is memory pressure.

If you just create the .dmg, and then try to install from it, does it work as expected?

The problem is I can't redraw the whole offscreen texture every frame while panning because for performance reasons Redrawing everything every frame is how most 3D apps work. If you can do that, then you don’t need your offscreen texture. How many triangles do you need to draw? Have you characterised where the performance bottleneck is?

I think there are different build settings for the “” (user) and the <> (system) include search paths. You need to set the latter.

When you also lose files and see post which "Posted 4 years ago" with zero comments on it... sad. Yes, it’s sad. But there are other threads about recovering lost files, including this recent one: https://developer.apple.com/forums/thread/725966

There are about 16651560 Vertices on the screen. In that case, I suggest that you do some pre-processing on the CPU: When you're zoomed out and the entire image is visible, use Douglas-Peucker line simplification, or similar, to reduce the number of vertices. When you're zoomed in, use some sort of spatial index to send only the vertices that are on the screen. (I.e. "tile" your input vertices, not your output.) You'll end up with some sort of multi-resolution data structure. Note it's easy to over-engineer this (I've done that). The GPU is fast. You only need to do some crude CPU pre-processing to get the number of vertices down to something tractable. Also: is the very large number of vertices because you want smooth curves made from very short straight segments? If so, consider storing fewer vertices and using the GPU to draw the curves; search for "GPU quadratic bezier".

Cache the buffers.

The flag will be something like --std=c++23 - maybe it's just not exposed in the build settings GUI? Let us know if you can get it to work, I've not tried it.