when I look inside UITableView class scope by using "Jump to Definition" As a general rule, learning a language by reading the source of its standard library is a bad idea. For various reasons, system libraries in most languages often contain unusual constructs that should never appear in "normal" code. Swift is not the worst in this respect, but I would still advise using "Jump to definition" etc. only for navigating within your own code.

My guess is that Firebase is using HTTPS, is that right? Are you using a Firebase client library? Does it embed its own encryption, or is it using the iOS services? "Sign in with Apple" apparently uses OAUTH, which uses standard protocols and is built in to iOS. do I need to answer Yes to all the questions? No, I don't think so.

Can we use the existing infrastructure to send those (TCP and UDP) IP packets ? Yes.

My app is an audiobook version of a book written by myself, I have only released it for about a month, currently only have 1 rating and no reviews, nor have I run any marketing campaigns. And it's a paid app? Well, it's possible that all those people buy it, start listening, and think "this is *****" and get a refund. BUT more likely at least some of them would also leave a bad review, and at least some of them would think "this is *****" but NOT get a refund - your graphs are almost perfectly symetrical, as if literally everyone is refunding it. I don't know how to explain that. In App Store Connect, it is possible to explicitly show refunds: App Store Connect -> Sales and Trends -> Select the app -> Click on "Transaction Type". This will separate out sales and refunds. Does that agree with the graph you've posted?

Is that local receipt validation, or server receipt validation? I think it's likely that server receipt validation will indicate a refunded purchase, though I don't know for sure. Local receipt validation, I'm pretty sure will still report a valid receipt after a refund; the user will continue to be able to use the app until they try to re-install it for some reason.

You have all the normal POSIX APIs for TCP and UDP. "Similar to TCP or UDP" is a bit vague, what are you trying to do? There are also some higher-level but less portable APIs for TCP including NSStream and NSNetService.

When the app is opened, I will get the AppStoreReceiptUrl. If AppStoreReceiptUrl is null or empty, I will force close the app, otherwise the user will be able to access the app. No, I don't think that will work. I think the valid receipt will remain in place indefinitely. Your graphs do look suspicious, to say the least. How are your reviews and ratings? What sort of app is it?

There may be issues with networking. The vmnet framework ( https://developer.apple.com/documentation/vmnet ) needs either a special entitlement or to be a privileged process. If you install an app from the App Store it may have the special entitlement. There are alternatives to vmnet for networking. Personally I used qemu 7.0 via Homebrew to run a Debian VM. vmnet support is added in qemu 7.1, so for now I’m using their “user mode networking”. This means the VM doesn’t get its own IP address. I don’t think this requires any special privileges but I could be wrong.

Yes, it is possible (I did it a few years ago). You need to contact a Developer Program Support human.

I don't think you'll find good documentation. I do recall some previous discussions about this. Note that while GPS locations could in principle have accurate timestamps from the GPS receiver, in practice Core Location also includes locations from other sources and for those iOS probably has to use its own internal clock. So maybe all locations get timestamps from the internal clock. And where does the iOS clock get its reference time from? None of this is documented. I suggest trying to avoid writing any code that relies on these timestamps.  time from Core Location is progressing at a different rate than the UTC time as reported by the GPS receiver. A fixed offset would be easier to understand than "progressing at a different rate"! Over how long are you measuring this? The "different flavours of UTC" that you refer to can't possibly progress at 0.6% different rates!

Apps cannot use "classic bluetooth" on iOS.

would rather try another submission and hope for a different reviewer. We don't know how App Review works. I don't think there is any evidence that a new submission goes to a different human while a re-review of the same submission goes to the same human. I am supporting an API that was added in macOS 12. Removing it just because a reviewer claims it's "pre-release" (while the Apple website states it is not) I would have thought that that analysis was automatic. I would guess that either (a) there is a bug in their tool, in which case App Review won't be able to fix it; a DTS incident might be a better approach, or (b) you really are using something "beta", maybe not exactly the thing they mention in the rejection.

The file command inspects the content of the file to determine the type. I don't know exactly what it looks for to identify a CSV file, but could it be that something like line-break characters are causing the difference? CSV (as defined by RFC4180) is supposed to use CRLF line breaks. I could imagine that whatever you have used to modify it has leniently accepted e.g. LF line breaks and saved it with the required CRLF. (Less likely with a "text editor" (be specific!!) and more likely with a spreadsheet.) If you post the output of e.g. od -a | head for both files, maybe someone will spot the important difference. Be aware that what the file command things may not be very important in general on MacOS; what Splotlight thinks makes more difference to e.g. Finder. P.S. I suggest not posting comments on this forum - post replies. Comments don't seem to trigger emails to people who are watching the thread.

If the content is "delivered in the app", it must use IAP. It sounds to me like what you want to do does require IAP.

After only a week, I'd say "be patient, just wait". More generally, my policy has always been to just comply immediately with their requests, however ridiculous; if they don't like a new feature, just remove it from the app. It's pointless trying to interact with them in any way. I would also say: After pointing out the wrongly tested feature (left me speechless)  Some real users will be even more clueless. What's worse, a clueless Apple reviewer or a clueless end user who can write an app store review? Answer: the end user. App Review can only delay your update or make you remove features they don't like; an end user who writes a bad review in the App Store can destroy your sales overnight. So: if App Review found it hard to use a feature, take that feedback seriously and consider how you can make that easier to use.