-Werror=return-type might turn that into an error, if you're lucky.

Very interesting. I watched the video but haven't looked at the code yet. My initial reaction was that their approach to memory management seemed to be adding the worst of objC to C++, when they could have adopted "modern C++" memory management (i.e. unique_ptr, shared_ptr) for these classes.

built in app You could use Core Location to get the user's (approximate) location, but that requires that the user acks a permission dialog, which may not be ideal. The user's locale (i.e. their preferred language) could also be used. Do consider what you want to happen when e.g. and American is travelling in Europe etc. etc. Simply asking the user to choose their location when the app starts for the first time is a serious option to consider.

Mac or iOS? Where are you observing the MIME type?

I've reported essentially the same issue, IIUC, with NSFileVersion.persistentIdentifier. FB10666727

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.

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.

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.

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.

Apps cannot use "classic bluetooth" on iOS.

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!

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

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.

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?

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.