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

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.