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.

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.

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

Ignore what other apps (Uber) do. Is there a legal requirement that means you cannot offer account deletion? If there is, the "additional information" they need would be, for example, a link to the law that you believe prevents you from offering account deletion, or a formal opinion from a lawyer, etc.

Is this content built in to the app, or does the app fetch it from a server? One option is to present a "Choose your location" dialog when the app starts.

we think that developers will see a huge benefit to adopting them Could you be specific about what that huge benefit is? As far as I can tell, it is providing the same functionality as the old XML API.

Yes, you can get location updates in the background, that's standard. I think they continue to come in at 1 per second but I'm not sure about that. In theory it may get terminated if some foreground app needs all the RAM and your app is using lots, but in practice I don't think that happens often; it may be more likely that your app crashes while it's in the background and the user doesn't notice. I don't know about sockets. That may be more difficult. You may need to use push notifications. But, reading you post something else occurred to me. Are you aware of the terms in the developer agreement regarding safety-critical apps? E.g. section 3.3.13 - "Applications that use Location APIs .... may not be designed or marketed for ... emergency or life-saving purposes" and section 12: "... APPLE SOFTWARE ... NOT SUITABLE FOR USE IN SITUATIONS ... WHERE ERRORS ... COULD LEAD TO DEATH". Is this something that you just ignore? I ask because I sometimes get questions from users who seem to be using my map apps in emergency-services type applications, and I wonder what I should tell them!

I don't believe that App Review have a limit, but I could be wrong. The question is, how long will your users be prepared to wait? I suggest that you check how quickly other comparable apps start up, and make yours no worse than average. The danger is a pile of 1-star reviews from impatient people. Is there some particular reason why yours is slow? Maybe someone can suggest how to improve it.

My big break thru was realizing the a file's URL (returned from the Swift code) needs to be modified (replace, for example "%20" with " ") before using them as a file name in the fopen() call. You should be using NSURL.getFileSystemRepresentation to do that. I need to figure out why these files are not visible in the Files app.   I don't yet see them being uploaded to my desktops Possibly because of the lack of a coordinated write.

How would I manually create the Documents/ directory? In C, mkdir(path, 0777). In C++, create_directory(path). In objC, [[NSFileManager defaultManager] createDirectoryAtURL: [NSURL urlWithFileSystemRepresentation: path] withIntermediateDirectories: false attributes: @[Some@[Extra]VerboSity]here] error: everyonejustpassesnil_becausewe'vegivenup_bythispoint_butReallyWeShouldDoSomethingToHandleErrors] In Swift, same as objC but with different punctuation. I'm not sure if this is necessary. What does seem to be the case is that if you haven't done anything then the empty directory is not visible in e.g. the Files app. I don't know if this is because the Documents directory doesn't exist, or because it is empty and empty directories are somehow hidden. Quite a few apps put a "readme" file in their iCloud Documents directory to make it appear. That is what I have done, using an NSFileManager method called something like copyFileFromHere: toThere: creatingIntermediateDirectoriesIfNecessary: true. So that would create Documents/ if necessary. I don't know what a coordinated write block is You need to look at the documentation for NSFilePresenter, NSFileCoordinator, and UIDocument. These are required for iCloud files, and also for local files if they are accessible from other apps, including the Files app. Basically if you're going to read from a file, you need to do a "coordinated read" so that e.g. an instance of your app on another device or the Files app on the same device are told to save the file first. Coordinated writes are the converse. UIDocument simplifies a lot of this. But one important feature of these coordinated things is that they give you a potentially different path to access, in place of the path that you think you want to use. The point is that if there are conflicts between different devices you can have multiple versions of each file. Having said all that - I don't think it would explain fopen(w) returning "no such file or directory". It there a particular naming convention for the container name? I would suggest reverse-dns i.e. com.your-business-name.your-app-name.this-container-name.

atomic_compare....() returns true if the location was 0 and has been updated to 1. Your atomic_store...() stores 0. Why do you have the ! in bool test = !atomic_compare...()? (A better name than "test" would help.) Maybe I'm missing something, but I think you want: expected = 0; // We hope it is unlocked bool succeeded_in_locking = atomic_compare_exchange....(flag, &expected, 1, ....); // Try to lock by storing a 1 in place of the 0. if (succeeded_in_locking) { // OK, we have the lock this is where we would do the work protected by it. // Now we want to unlock. // Just write 0: atomic_store...(flag, 0, ....); } else { // We didn't lock - presumably some other thread has it. // Try again. } Anyway... I'm not convinced that a memory_order_relaxed atomic can be used to implement a lock, as there are no constraints on the ordering of those atomic operations relative to the operations that you are trying to protect. But I know nothing about Metal.

I don't think you're supposed to be able to see iCloud Drive files in the CloudKit developer page. CloudKit != iCloud Drive. Have you enabled CloudKit instead of iCloud Drive somewhere? You may need to create the Documents/ directory initially. Are you using a coordinated write block?

Those will all be included in U.K. (Absolutely certainly, in the case of Northern Ireland; only 99% certain for IoM and the Channel Islands.)

No, you can't do that. IAP doesn't work for low-margin business models. It only really works when you have high enough margins that a difference of 20% or so doesn't matter - or, if you're only operating in one currency. Beware that exchange rate fluctuations, and Apple's changes to IAP price tiers, can also interfere.