There are all kinds of potential performance benefits to a native SDK. Cross app caching for such common data could be a huge boon for watchOS complications & Home/Lock Screen widgets, for instance.

No idea if they are implementing those kinds of enhancements but it’s no surprise that a native SDK would be provided.

Also, how would they implement the privacy preserving black box location implementation with a REST API? There is no need for the app to ask for or receive specific location details by using this SDK.

> Cross app caching for such common data could be a huge boon for watchOS complications..

What is your differentiation criteria between anticipating a "huge" boon versus a "regular" or "modest" boon"?

What's your differentiation criteria for whether a comment is worth posting or not?

Whenever there's a bj in the username, I definitely go for it!

Would you like to know more? If so just shoot me an email.

The Swift API is ergonomic and strongly-typed.

My hunch, but I'm not sure about this, is that there might be some centralized caching going on on with the native SDK, so that if multiple apps use the WeatherKit API, they can share the cache.

No idea if there's caching across apps, but similar requests from the same app does hit a cache.

I imagine WeatherKit can then have leverage to do system-level caching of same data being requested by multiple apps?

Also not having to deal with web requests (client, retry logic, polling, etc)

> I was questioning why WeatherKit needs a "platform-specific Swift API" at all

So you can use it without having to deal with the low level detail of HTTP connections.

Low level detail of HTTP connections is already abstracted away in any general REST API.

Yes but many developers end up writing objects to hold the REST API data and methods to operate on it. And as the API changes you then to have a whole bunch of code you need to maintain and keep up to date.

Client library frees you from that.

Types is at least one thing that immediately comes to mind