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.
[edited for tone]
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.
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.
What is your differentiation criteria between anticipating a "huge" boon versus a "regular" or "modest" boon"?
Would you like to know more? If so just shoot me an email.
Also not having to deal with web requests (client, retry logic, polling, etc)
So you can use it without having to deal with the low level detail of HTTP connections.
Client library frees you from that.
b) OpenWeatherMap limits not just by total API calls but by API calls per second.
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.