Over the years there have been quite a lot of posts here like yours. Few of the posters return to describe the final outcome. I do wonder what that means. Maybe they got reinstated and were too lazy to come back and tell us. Or maybe their forum accounts got terminated too. Probably the most important lesson is to not have a single source of income. Don't put all your eggs in one basket. One bit of advice from my own career: if a friend invites you to a party full of people you don't know, don't waste your time trying to chat up his sister. Seek out the other bored-looking men and express an interest in their boring jobs. Yes I'm talking about accountants and lawyers. Get their business cards. Then when someone tries to sue you for infringement, or Apple terminates your membership without warning, you can find the card of some really smart professional who can give you great advice - for free over a beer.

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.

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?

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.)

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.

Port number?

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.

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

Yes. See other threads.

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

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.

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

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.

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?

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?