WeatherKit

The Dark Sky API is dead. Long live the Dark Sky API.

On March 31, 2020, everyone’s favorite iPhone weather app announced that they had joined Apple. Soon after, their excellent API no longer accepted new signups and was set to shut down completely three years later on March 31st, 2023. Well, time sure flies, and we are now less than one year away from that date. I can’t help but reminisce about my two favorite Dark Sky powered projects: Purple Rain Report and Tycho’s Forecast playlist generator. Their simple but powerful API was always so inspiring and I love weather personally. So, what do we do now? Well, it looks like the Dark Sky team has been hard at work at their new home at Apple to bring us WeatherKit, an all-new Apple Weather service which provides the same sort of data we came to rely on: hyperlocal weather info, 10-day hourly forecasts, minute-by-minute precipitation, and more. The most surprising thing? In addition to their typical platform-specific API, it comes with a REST API. The least surprising thing? It is complicated to generate a web token to make calls.

Yes. I’m having flashbacks to the launch of Apple MusicKit JS, in which they launched an exciting new service but did not provide documentation on properly generating the token required to call it, leaving lots of excited developers confused and frustrated. As it turns out, one of my most read blogs here is simplified instructions on creating an Apple Music API token. 😅 In WeatherKit’s defense, they did end up publishing some authentication instructions a week after launch. So, if you follow those instructions you should be able to get the Apple WeatherKit REST API up and running.

Unlike the Apple Music API token, it does not look like a long-lived token will suffice here and you’ll instead want to keep that token fresh between calls. That means you’re going to want to generate the token each time a user makes a weather request. I was actually in the middle of building a Dark Sky API powered client project on

when the WeatherKit REST API dropped and made the questionable decision to try and integrate the beta API. Risky, I know. So, I knew how to use the JSON web token package to generate a working web token by following Apple’s instructions but in order to distribute this solution via a Netlify Function I needed to figure out what to do with my private key. A new token must be signed by a private key (provided by Apple as a .p8 file) but private keys should not be distributed so I didn’t want to put it in my Github repository. How the hell was I going to handle this?

Environment variables?

Well, that’s what I did. In fact, I ended up encoding my private key as a Base64 string so I could store it right in the Netlify admin as an environment variable. I then decoded it on my Netlify function and used it to sign my JWT token. In the end, it looks a lot like my Apple Music API token generation logic albeit with the recommended headers and payload. So, first, here’s how the private key was encoded locally.

This encoded key was stored as an environment variable alongside the team, key, and app id associated with this Apple WeatherKit project.

And here’s a look at the Netlify function I’m using to generate a fresh token and finally call the WeatherKit REST API with axios. First, I decode the Base64 private key back into its original format. Then, I grab my team, key, and app id from environment variables. All of these elements are used to generate a JWT token which expires in 1 hour. The Netlify function itself has query parameters for latitude and longitude which are passed to the axios API call, along with the JWT token in the header. If all goes well, the weather data is returned by the Netlify function endpoint.

Is this better than the Dark Sky API? I’m not sure yet. However, I am sure that it is way more confusing to access than receiving a non-expiring API token in one-click. (The old Dark Sky API flow.) I hope documentation like this alleviates some of the confusion around this new API so we can figure out if this is a viable solution for our web apps or if we should continue to look towards other solutions like Open Weather. Let me know if you think what I did here was smart or dumb. I appreciate any tips on securely integrating this API into future projects.