Reverse geocoding rate limit of MKReverseGeocodingRequest compared to CLGeocoder

The documentation for CLGeocoder states

Geocoding requests are rate-limited for each app, so making too many requests in a short period of time may cause some of the requests to fail. (When the maximum rate is exceeded, the geocoder returns an error object with the CLError.Code.network error to the associated completion handler.)

And it provides helpful guidance on how and when to submit geocoding requests.

The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited? If it is rate-limited, is it similar to CLGeocoder, what is its behavior?

It is important to understand behavior of the API in order to understand impact on my app’s use case and how users will be affected should I change the implementation. Thanks!

Answered by DTS Engineer in 870303022

The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited?

No. Both APIs are built on the same underlying SPI and I believer their limits are broadly similar.

If it is rate-limited, is it similar to CLGeocoder, what is its behavior?

I believe it will return MKError.Code.loadingThrottled if you hit the limit.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

This might not be the sort of "official" response you're hoping for, but for what it's worth, I just got a rate limit error from MKReverseGeocodingRequest.

Just to make sure I didn't miss anything, I just checked every sub page of the docs for that class, I didn't find anything talking about a rate limit.

It seems like the error got thrown when I tried to access the mapItems property

Here's the error I received:

Throttled "PlaceRequest.REQUEST_TYPE_REVERSE_GEOCODING" request: Tried to make more than 50 requests in 60 seconds, will reset in 43 seconds - Error Domain=GEOErrorDomain Code=-3 "(null)" UserInfo={details=(
        {
        intervalType = short;
        maxRequests = 50;
        "throttler.keyPath" = "REDACTED)";
        timeUntilReset = 43;
        windowSize = 60;
    }
), requestKindString=PlaceRequest.REQUEST_TYPE_REVERSE_GEOCODING, timeUntilReset=43, requestKind=772}

It is true that the mapItems property is labeled as something that throws but I would have expected that to happen if it couldn't find something for that coordinate. I was surprised to see that happen for a coordinate I knew was valid. It would be nice if the docs explained what errors it could throw, and under what conditions.

In my opinion, Apple's own example doesn't really set developers up for success either.

They use try? await in a task in the view, but if you follow that example, and your list of coordinates got too large, your UI would show un-geocoded entries and there'd be no obvious way to "retry it", which isn't great!

I think there's really room for improvement on the docs here.

Accepted Answer

The documentation for MKReverseGeocodingRequest does not mention requests are rate-limited. Does this mean it is not rate-limited?

No. Both APIs are built on the same underlying SPI and I believer their limits are broadly similar.

If it is rate-limited, is it similar to CLGeocoder, what is its behavior?

I believe it will return MKError.Code.loadingThrottled if you hit the limit.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Reverse geocoding rate limit of MKReverseGeocodingRequest compared to CLGeocoder
 
 
Q