◇ App Dev/2026-06-16Intermediate

Building a WeatherKit App with Rork Max — The Auth and Attribution Pitfalls

When you add WeatherKit to a native Swift app generated by Rork Max, the first walls are authentication and attribution. Here is the workflow I confirmed: token handling, rate limits, and the mandatory data-source display.

Rork Max²³¹ WeatherKit Swift⁴⁸ iOS¹¹⁰ Weather App

✦ Premium Article

A Weather App That "Just Works" Still Won't Ship

Getting Rork Max to generate a small native Swift weather widget went smoothly. The trouble came afterward. The code to fetch and display a forecast from WeatherKit is only a few dozen lines, yet App Review rejected the app twice.

The reason was not a bug. It was that I had not met Apple's WeatherKit requirements for displaying the data source and linking to Apple Weather. A feature can be complete and still fail to ship if it breaks a policy. As an indie developer shipping apps solo, I run into this kind of "works but cannot ship" wall from time to time. Plenty of people stumble here, so let me leave behind the workflow I confirmed, focused on authentication and attribution.

Swift API or REST API?

WeatherKit has two entry points: the in-app WeatherKit Swift framework, and a REST API you call from a server. Since Rork Max produces a native Swift app, you generally use the former.

My rule of thumb: use the Swift API when you only need to show a forecast on screen, and the REST API when several apps or a backend need to share and cache the same weather data. Both share the same monthly quota (the free tier under the Apple Developer Program is 500,000 calls per month), so fetching once on a server and distributing the result can hold call counts down.

This was a single app, so I chose the Swift API. The minimal fetch looks like this:

import WeatherKit
import CoreLocation
 
@MainActor
final class ForecastStore: ObservableObject {
    @Published var current: CurrentWeather?
    @Published var hourly: [HourWeather] = []
 
    private let service = WeatherService.shared
 
    func load(for location: CLLocation) async {
        do {
            let weather = try await service.weather(
                for: location,
                including: .current, .hourly
            )
            self.current = weather.0
            self.hourly = Array(weather.1.forecast.prefix(24))
        } catch {
            print("WeatherKit error: \(error.localizedDescription)")
        }
    }
}

The key is passing only the elements you need to including:. Requesting .current, .hourly, and .daily together saves a round trip, but pulling daily forecasts on a screen that shows only the current temperature is waste. Build the habit of specifying just the elements each screen needs, and your quota consumption drops visibly.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦Understand when to use WeatherKit's Swift API versus the server REST API, and how to design around the 500K monthly free-tier calls

✦Learn the exact SwiftUI code to render the attribution and Apple Weather legal link that Apple requires

✦Reproduce a caching setup that cuts wasted API calls, from location capture to incremental forecast refresh

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Authentication Is Most Often Just "Forgotten"

The WeatherKit Swift API does not embed an API key in code. Instead, you enable WeatherKit for your account in Apple Developer and add it to the app's capabilities. When you use the project Rork Max generated as-is, this is the easiest piece to miss.

Three things to check. First, WeatherKit is enabled for your App ID under Identifiers in Apple Developer. Second, WeatherKit is added under Signing & Capabilities in the Xcode project (Rork Max's cloud build needs the same setting internally). Third, Info.plist declares a location-usage purpose string (NSLocationWhenInUseUsageDescription).

Miss any one of these and you get a confusing symptom: a WeatherDaemon error on device, or data that works in the simulator but comes back empty on a real device. I lost half a day convinced this was a code bug. When real-device data comes back empty, suspect the capability first.

The Attribution App Review Requires

Here is the heart of it. Apps that use WeatherKit data are required by Apple's terms to display the data source and a path to the legal page. Skip this and your app is rejected no matter how flawless the feature is.

Concretely, read attribution off the fetched Weather object and show the logo image plus a link to Apple's designated legal page.

import WeatherKit
import SwiftUI
 
struct AttributionView: View {
    let attribution: WeatherAttribution
 
    var body: some View {
        HStack(spacing: 6) {
            AsyncImage(url: attribution.combinedMarkLightURL) { image in
                image.resizable().scaledToFit()
            } placeholder: {
                Color.clear
            }
            .frame(height: 14)
 
            Link(" About this weather data", destination: attribution.legalPageURL)
                .font(.caption2)
                .foregroundStyle(.secondary)
        }
    }
}

Swap combinedMarkLightURL and combinedMarkDarkURL for light and dark. legalPageURL is Apple's hosted source list — do not replace it with your own page. My first rejection happened because I showed the logo but omitted the link to legalPageURL. Assume you need both the "Apple Weather" mark and the link.

Fetching the attribution itself happens alongside the forecast:

let attribution = try await WeatherService.shared.attribution

Caching to Cut Wasted Calls

Weather does not change by the minute, yet fetching every time a screen opens burns through your quota fast. I added a cache with one simple rule: do not refetch for the same location and time window.

struct CacheEntry {
    let location: CLLocation
    let fetchedAt: Date
    let current: CurrentWeather
}
 
func shouldRefetch(_ entry: CacheEntry?, for location: CLLocation) -> Bool {
    guard let entry else { return true }
    let age = Date().timeIntervalSince(entry.fetchedAt)
    let moved = entry.location.distance(from: location)
    // Refetch if more than 15 min old, or moved more than 2 km
    return age > 900 || moved > 2000
}

The "15 minutes, 2 km" threshold felt right for a weather app. Updating by the second barely changes the display while only inflating call counts. In practice, daily WeatherKit calls felt like they dropped by more than half once this rule was in place. As an indie developer running several apps, this kind of "don't call" design adds up against the monthly quota, and I value these quiet savings as much as new features.

The One Thing to Check First

Once WeatherKit is in, verify one thing on a real device before shipping: that the attribution logo and link both render correctly in light and dark mode. Meeting that single point would have spared me the two rejections I went through. Sometimes a single line of policy decides whether you ship more than the feature work does — a weather app quietly teaches you that.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.