The response is supposed to be an email, and no it is not shown on the web page.

They want a screenshot showing what the app looks like after purchasing the IAP. Presumably there will be some difference somewhere, even if it’s just a list with an additional item in it.

Screenshots should not be created on device but with simulator. You're lucky if you can use the simulator for everything. Haven't we had this discussion before? Yes: https://developer.apple.com/forums/thread/728194 could try to tweak it in Preview application (resize image). I would not admit to "faking" screenshots in a public forum! Interestingly, App Store Connect seems happy to accept preview videos of the "wrong" size (i.e. recorded on an iPhone XS, 6.5-inch) in this case, but not screenshots.

For the success of this project, it is essential to have precise information about the hardware components of specific iPhone models In that case your project is doomed. Give up and find a different project before it is too late. Your only hope is to measure these parameters yourself. Apple do not publish this sort of information.

I also find that the sandbox IAP server is very slow, but I've never had complaints from users so I presume that the production servers are much faster.

What country are you in? You don’t need to be VAT-registered if your turnover is below the registration threshold, but it can be beneficial to register voluntarily. Your receipts from Apple are an international business-to-business transaction, so are “reverse charged” i.e. in effect no VAT, but your expenses will likely be domestic (e.g. buying computers), so you reclaim VAT on them.

P.S. Have a look at the LLVM coding conventions, described here: https://llvm.org/docs/CodingStandards.html They say that they actually prefer using continue rather than extra indentation. This also reminds me that some people say that having multiple return statements in a function is bad.

The reason for disliking them is that they permit "less structured" control flow. GOTO permits totally-unstructured control flow. break and continue are like a restricted form of GOTO. Structured control flow is preferred because it is easier to correctly understand it when you read it. Remember, the next person who will read the code that you write will be a violent psychopath who knows where you live. Consider reading Djikstra's "GOTO considered harmful" paper. I don't know if you'll really understand it, but try. In my opinion, when you consider writing break or continue your should ask yourself "How could I write this otherwise, and would that be more or less clear?". If the alternative would be less clear (to the axe-wielding psychopath), then break and continue are fine.

NSFileCoordinator doesn't seem appropriate for SQLite at all. Use NSFileCoordinator when the file can't cope with simultaneous accesses. But SQLite can cope with simultaneous accessed. So no need for NSFileCoordinator.

I've no idea what Apple do. There are various corporate style guides that are available online, including Google's. The important thing is to understand why these things might be discouraged. If you're smart, you should imagine future-you writing a style guide for your subordinates, not blindly following one written by someone else. (If you're not smart, stop asking questions and just do what you're told!)

It requires SF Symbols 5, which is in iOS 17.

It doesn't matter, the results are better from a proper search engine.....

we observed disparities between the figures displayed in the dashboard and those obtained through the APIs. Which dashboard figures, and which API figures, precisely, are you comparing?

Apple would like you to buy search ads.

I guess you have set 32 bits per pixel, right? Does your data actually have 32 bits per pixel, or 24?