I just verified Sure, it links to Apple when you visit it. You have no idea what happens when I visit it, or when someone from China or Iran visits it, or anything else. This is called a "supply chain attack". It's a real thing.

Your problem isn't completely clear to me; are you sure you posted the correct numbers? The range of an 8-bit integer is 0 to 255. When those values are scaled to a floating-point value such as a colour component in the range 0.0 to 1.0, then 255 needs to map to 1.0. So you need to divide by 255, not 256. Does that explain what you are seeing?

Check the App Receipt, or use the equivalent StoreKit 2 features, to see what in-app purchases they have made. Do you need to do this check on the device or on your server (or both)? In order to track the paid features (i.e. unlimited token usage) I am using device ID in the database That was never a good idea. What "device ID" specifically are you trying to use?

What bug was that specifically? FB12798615 Here's the body of the bug report: Regarding the list of APIs for which a declared reason will shortly be required, as described at https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api I note that no C++ functions are included in this list. For example, libc++'s std::filesystem::last_write_time., std::filesystem::space_info, etc. I can see a couple of possible reasons for this: (a) You've overlooked these functions and they should be included. (b) Because these functions are actually thin wrappers around C APIs such as stat(), you consider that the inclusion of stat() (etc.) in that list extends to these C++ functions. If (b) applies, this is going to cause problems because many non-timestamp-related std::filesystem functions actually call stat(), ignoring the returned timestamps. For example, simply checking if a file exists using std::filesystem::exists() calls stat. You don't want to be rejecting an app that calls std::filesystem::exists() by sending the developer a message telling them that they are using stat(), that will just cause a lot of confusion for everyone.

can I force a 5-star review to allow users to use the app's features? Of course not. WTF?

I'll update here if I get a reply. My bug report has now been closed: "we believe this issue is resolved". Of course they don't tell me what the resolution actually is; the web page hasn't been changed, it still doesn't contain any C++ functions in the list, nor is there a reason code for using stat() to retrieve non-timestamp file information.

Does anyone know if this affects TestFlight? Anyone filed a bug yet?

Yes. See other threads.

Only you know what encryption algorithms, if any, you are using within your app.

This forum is a joke Yes; there are lots of things wrong with it. It is also Apple's forum, and I'm actually surprised that threads like this exist at all. Apple do delete threads that they don't like, but apparently not these ones. Strange. You should assume that the posts that you see are the ones the Apple want you to see, and that others have been deleted.

Port number?

Example please? Say you've got a class Foo whose instances needs to do something when the app enters/leaves the background. So you add enterBackground and leaveBackground methods to Foo. Those need to be called from the appropriate app delegate methods. But the Foo instances spread around your app are members of other classes that are themselves members of other classes. In order to call Foo's enterBackground and leaveBackground methods, all of those parent classes need to have enterBackground and leaveBackground methods which are called by their parents and which call their children. If you add a Foo somewhere new, you have to add "plumbing" through all of its parent classes to the top of your object hierarchy so that its enterBackground and leaveBackground methods can be called. It's better not to do this, and to find some other way of connecting the Foo instances to the events. The NotificationCenter is an example of another way. It is not without its problems though; for example, unit testing is more difficult when a class has "back door" interfaces such as listening to global notifications.

how one is expected to do this I believe you're expected to not do it. This is not a viable business model for an app. (IMO.)

I doubt this is possible in any practical way. Have you seen any other apps that do this? Have you considered how to comply with money laundering regulations around the world?

Do you need the FAISS GPU functionality? I would imagine that getting its CPU code to work should be relatively easy. Combining Swift and C++ is easier than it used to be.