If these are the 'best worst examples' you can come up with after ~3 years of iOS work, they are not really convincing. I just scanned the CoreLocation docs, and while it is true they do not explicitly state what sources are used for getting a certain accuracy, the documentation makes it very clear and unambiguous what you should use. You use kCLLocationAccuracyBest if you need to be absolutely sure you have the highest accuracy, otherwise you use one of the distance-based accuracy settings. How these get the location should be irrelevant to any application that doesn't need to force 'best available', and it's pretty clear from how the API is structured that iOS will combine whatever data is available to give you the accuracy you asked for (ie: if there is no cell tower or WIFI geolocation available, it will fall back to GPS even for the lower-accuracy setting). It took me only 5 minutes of reading the documentation to figure this out, I would say its an example of good documentation, not bad documentation.
As for 'how large is the maximum iPhone process address space', I don't really know how bad it is that you cannot easily find this documented. It doesn't really seem like something many apps need to know about, and highly specific to the iOS version and maybe even hardware it is running on. Not saying your app or whatever you are making doesn't need it, but I estimate this kind of information is irrelevant for close to 99% of apps. I don't think the iOS programming model is such that you can derive any kind of guarantees how much you can allocate from that number. What do you want to use it for?
Your assertion in the first paragraph is not actually true. Go to Central Park or somewhere else with no nearby WiFi beacons and try it out. Your test app will not fall back to GPS accuracy. I have done this. So actually the documentation you’re quoting is wrong.
As for what you might want to know the maximum address space size for: evaluating whether unattributable production crashes might be due to running out of address space.
>> Your assertion in the first paragraph is not actually true. Go to Central Park or somewhere else with no nearby WiFi beacons and try it out. Your test app will not fall back to GPS accuracy. I have done this
That's not what I said, nor what the documentation said. From the documentation:
The system always tries to give you the best location data that is available, but these properties give the system the flexibility to turn off hardware elements when they are not needed. For example, if you set the desired accuracy to kCLLocationAccuracyKilometer, the system might disable GPS and use only the Wi-Fi hardware, which would save power and still give you a greater accuracy than you requested.
In other words: the system will not promote the returned accuracy if the data it has is already within the accuracy you asked for, but it will still fall back to whatever source of location data available, possibly higher accuracy, if no lower-accuracy source is available.
This makes a lot of sense, because it is much more common to only have a GPS signal, and no cell tower or WiFi geolocation (e.g. when doing outdoor activities) than the other way around. In that case your '1 km accuracy' app might in fact get you GPS accuracy. But if you are in Central Park, you will most definitely get location data from cell towers, so in that case your app will not promote the accuracy since you didn't ask for it. Ergo, if you need the highest accuracy, you have to ask for it. The documentation makes it very clear the accuracy parameter is not a tool to force a specific accuracy, but to allow the system to relax accuracy in favor of lower power consumption, if your app doesn't need it.
Not trying to be snarky here, but in this particular case it seems the problem is not in the documentation, but in your reading comprehension of it. Unless of course there is a bug in CoreLocation, or you got so unlucky when you tested in Central Park, that there was somehow not even a GPS signal available.
As for 'how large is the maximum iPhone process address space', I don't really know how bad it is that you cannot easily find this documented. It doesn't really seem like something many apps need to know about, and highly specific to the iOS version and maybe even hardware it is running on. Not saying your app or whatever you are making doesn't need it, but I estimate this kind of information is irrelevant for close to 99% of apps. I don't think the iOS programming model is such that you can derive any kind of guarantees how much you can allocate from that number. What do you want to use it for?