You've got to wonder why the focus isn't on providing a seamless general Rest API experience for all services rather then having specific Swift extensions for each service.
> It’s easy to use WeatherKit in your apps for iOS 16, iPadOS 16, macOS 13, tvOS 16, and watchOS 9 with a platform-specific Swift API, and on any other platform with a REST API.
I was questioning why WeatherKit needs a "platform-specific Swift API" at all.
If the general REST API in Swift is good then WeatherKit can be integrated into Swift apps as easily as any other service. If it's not easy then improvements to the general REST API could be considered.
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.
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.
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.
Dark Sky had a big focus on "hyperlocal" weather prediction prior to the Apple acquisition.
If you're a weather app, being able to tell your users "it will start raining in 35 minutes but pass in 55 minutes" is a huge value add over "80% chance of rain in the next hour". I found it to be quite accurate down to the 5-10 minute increment when I used to live in an area with frequent summer thunderstorms.
