Because the app is available to download for free, Apple will not take a percentage of the "in-game-currency" revenue, correct or did I misread? No, that's not correct. Apple take commission on all in-app purchase transactions. The only case where Apple don't take commission is when you are selling things that are non used within the app - for example, physical goods that are sent to the user, as in a supermarket or food delivery app. But in those cases, you need to provide your own payment processing; you can't use In-App Purchase. You may want to argue that "tipping other users" falls outside the "used in the app" definition. I don't know about that. It may depend on what the other users are doing that deserved tipping. For example, I guess you can tip your Uber driver and not pay Apple. But it is that aspect that matters, not whether the app is initially free or paid. Note that in many cases the commission will be 15%, not 30%. “On the iOS, iPadOS, watchOS, and macOS App Store, Apple charges a 30% fee for apps and in-app purchases. However, the fee doesn't apply to free apps.” Where does that quote come from? Do read your developer agreement! It has all the answers.

It's not actually an invoice but a Payment Receipt (because, as others have noted, an invoice would go in the opposite direction) No, both invoices and receipts are generated by the supplier and given to the customer. We are the suppliers, Apple is the customer.

Is changing these lines of code to include "void" the best solution? Yes. Or remove -Werror.

I think you should be considering DynamoDB vs. “MemoryDB for Redis”. The important question is whether DynamoDB is fast enough for you - are you trying to update the positions of things in real-time? And you’ll also need to consider cost. DynamoDB is not particularly difficult to use, but you will have issues around authentication/authorisation if you want to connect directly from your app; how do plan to do that? (I’ve only used DynamoDB from AWS Lambda functions that the app invokes.)

For those users who have opted-in to “share analytics with app developers”, you will get anonymised aggregated crash reports that appear magically in XCode’s “organizer” window. Regarding the privacy declaration, IMO all apps should disclose “diagnostics - not linked to you” because of this feature. But others seem to have different ideas.

No.

No, you don’t need them.

There isn't enough input data. It's waiting for more input.

You have the financial reports, which you can download manually from App Store Connect; you can also download them automatically using the Reporter java utility.

Do you get warnings when compiling?

Are you sure you want to support 10.10? It would be much easier to support only macOS 11 and newer. Exporting the SF Symbols images and including those in your bundle is technically possible, but legally dubious.

You aren’t the first to post here about this API being over-complicated and poorly documented - though most have been asking about IAP pricing, rather than apps. (See the “App Store Connect API” forum tag for more posts.) Personally, I’m hoping that there will be an easy-to-use utility on Github before I need to deal with this myself!

The SF Symbols app says it is available (in monochrome) since SF Symbols version 1.0, which means macOS 11.0. Do you have the SF Symbols app?

Generally those identifiers are not available to apps. There may be exceptions for e.g. cellular networks' own apps.

It sounds like you understand the issues involved with using the accelerometer. In some cases, "sensor fusion" can be used to combine inputs from multiple sensors to get useful results; search for "Kalman Filter". I think this was first used for the Apollo navigation computer. It might be possible to combine barometric pressure data with accelerometer data to measure things in the way you want. Have you looked at the barometric pressure data? Does Core Motion already do any of this for you?