5 ms·

There is a rest api. > 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

There is a rest api. > 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]

cube00 4y ago
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.
- bjtitus 4y ago
  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.
  - metadat 4y ago
    > 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"?
    - deleted 4y ago
      [deleted]
    - bjtitus 4y ago
      What's your differentiation criteria for whether a comment is worth posting or not?
      - metadat 4y ago
        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.
        deleted 4y ago
        [deleted]
        deleted 4y ago
        [deleted]
- asadlionpk 4y ago
  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)
- mcphage 4y ago
  > 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.
  - cube00 4y ago
    Low level detail of HTTP connections is already abstracted away in any general REST API.
    - threeseed 4y ago
      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.
- bigblind 4y ago
  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.
  - saagarjha 4y ago
    No idea if there's caching across apps, but similar requests from the same app does hit a cache.
- saagarjha 4y ago
  The Swift API is ergonomic and strongly-typed.
- dbbk 4y ago
  Types is at least one thing that immediately comes to mind

cube00 4y ago

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.

bjtitus 4y ago
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.
- metadat 4y ago
  > 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"?
  - deleted 4y ago
    [deleted]
  - bjtitus 4y ago
    What's your differentiation criteria for whether a comment is worth posting or not?
    - metadat 4y ago
      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.
      - deleted 4y ago
        [deleted]
      - deleted 4y ago
        [deleted]
asadlionpk 4y ago
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)
mcphage 4y ago
> 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.
- cube00 4y ago
  Low level detail of HTTP connections is already abstracted away in any general REST API.
  - threeseed 4y ago
    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.
bigblind 4y ago
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.
- saagarjha 4y ago
  No idea if there's caching across apps, but similar requests from the same app does hit a cache.
saagarjha 4y ago
The Swift API is ergonomic and strongly-typed.
dbbk 4y ago
Types is at least one thing that immediately comes to mind