◇ アプリ開発/2026-06-16中級

Rork Max で WeatherKit を使う天気アプリ — 認証とアトリビューションの落とし穴

Rork Max が生成したネイティブ Swift アプリに WeatherKit を組み込む際、最初に詰まるのは認証とアトリビューションでした。トークンの扱い、レート上限、必須の出典表示まで、実装で確認した手順を整理します。

Rork Max¹⁶⁶ WeatherKit Swift²⁵ iOS⁸⁰ 天気アプリ

✦ プレミアム記事

天気アプリは「動くだけ」では公開できません

小さな天気ウィジェットを作ろうとして、Rork Max にネイティブ Swift で生成させたところまでは順調でした。問題は、その後でした。WeatherKit から予報を取得して表示するコードは数十行で書けるのに、App Store の審査で二度はねられたのです。

理由は、コードのバグではありませんでした。Apple が WeatherKit に課している「データの出典表示」と「Apple Weather へのリンク」という規約を満たしていなかったためです。機能としては完成していても、規約を満たさなければ公開できません。個人開発でアプリを出していると、この種の「動くのに公開できない」壁に時々ぶつかります。ここでつまずく方は少なくないと思いますので、認証とアトリビューションを中心に、実装で確認した手順を残しておきます。

Swift API と REST API、どちらを選ぶか

WeatherKit には二つの入口があります。一つはアプリ内から直接呼ぶ Swift の WeatherKit フレームワーク、もう一つはサーバーから叩く REST API です。Rork Max が生成するのはネイティブ Swift アプリですから、基本は前者を使います。

私の判断基準はこうです。予報をその場で表示するだけなら Swift API、複数アプリやバックエンドで天気データを共有・キャッシュするなら REST API、という分け方です。両者は同じ月間クォータ(無料枠は Apple Developer Program の範囲で月50万回)を共有するため、サーバー側で一度取得して配るほうが、呼び出し回数を抑えられる場面があります。私自身は、まず Swift API で素早く出し、共有が必要になった段階で REST へ移すことを推奨します。最初から作り込みすぎないほうが、結果的に手戻りが少ないと感じています。

今回は単一アプリなので Swift API を選びました。最小の取得コードはこうなります。

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)")
        }
    }
}

including: に欲しい要素だけを渡すのが要点です。.current、.hourly、.daily を全部まとめて取ると一回の呼び出しで済みますが、現在の気温しか表示しない画面で日次予報まで取るのは無駄になります。画面ごとに必要な要素だけを指定する習慣をつけると、クォータの消費が目に見えて減ります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦WeatherKit の Swift API とサーバー REST API の使い分け、そして月50万回の無料枠を超えない設計判断を理解できる

✦Apple が必須としているアトリビューション（出典）表示を、SwiftUI で正しく実装するコードを習得できる

✦位置情報の取得から予報の差分更新まで、無駄な API 呼び出しを減らすキャッシュ構成を再現できる

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

認証は「設定し忘れ」が一番多い

WeatherKit の Swift API は、API キーを直接コードに書きません。代わりに、Apple Developer のアカウントで WeatherKit を有効化し、アプリの Capability に追加することで認証が通ります。Rork Max が生成したプロジェクトをそのまま使う場合、ここが抜けやすい箇所です。実機で空データが返るというトラブルの多くは、コードではなくこの設定漏れが原因でした。

確認すべきは次の三点です。

Apple Developer の Identifiers で、アプリの App ID に WeatherKit が有効化されていること
プロジェクトの Signing & Capabilities に WeatherKit が追加されていること（Rork Max のクラウドビルドでも内部的に同じ設定が必要です）
Info.plist に位置情報の利用目的（NSLocationWhenInUseUsageDescription）が記載されていること

このうち一つでも欠けると、実機では WeatherDaemon 由来のエラーが返り、シミュレータでは動くのに実機で空のデータになる、という分かりにくい症状になります。私は最初、これをコードのバグだと思い込んで半日溶かしました。原因の切り分けに時間がかかったぶん、教訓として深く残っています。本番の実機で空データが返るときは、まず Capability を疑って一つずつ潰すのが、結局いちばん早い解決でした。

審査で必須のアトリビューション

ここが本題です。WeatherKit のデータを使うアプリは、Apple の規約により「データ出典の明記」と「法的リンクへの導線」を画面に表示する義務があります。これを満たさないと、機能が完璧でも審査でリジェクトされます。回避策はなく、正面から実装するしかありません。

具体的には、取得した Weather オブジェクトから attribution を読み出し、ロゴ画像と Apple が指定する法的ページへのリンクを表示します。

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(" 天気データについて", destination: attribution.legalPageURL)
                .font(.caption2)
                .foregroundStyle(.secondary)
        }
    }
}

combinedMarkLightURL と combinedMarkDarkURL はライト/ダークで出し分けます。legalPageURL は Apple が用意する出典一覧ページで、自前のページに差し替えてはいけません。私が最初にリジェクトされたのは、ロゴは出していたのに legalPageURL へのリンクを省いていたためでした。「Apple Weather」の文字とリンクの両方が必要だと考えてください。

アトリビューションの取得自体は予報取得と同時に行えます。

let attribution = try await WeatherService.shared.attribution

無駄な呼び出しを減らすキャッシュ

天気は分単位で変わるものではありません。にもかかわらず、画面を開くたびに取得していると、クォータをあっという間に使い切ります。私は「同じ位置・同じ時間帯なら再取得しない」という単純な規則でキャッシュを入れました。

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)
    // 15分以上経過、または2km以上移動したら再取得
    return age > 900 || moved > 2000
}

この「15分・2km」という閾値は、天気アプリの体感としてちょうど良い値でした。秒単位で更新しても表示はほとんど変わらないのに、呼び出し回数だけが増えます。実測では、この規則を入れる前後で一日あたりの WeatherKit 呼び出しがおおよそ50%ほど減りました。個人開発で複数のアプリを運用していると、こうした「呼ばない設計」の差が月間クォータに効いてきます。私はこの手の地味な節約を、機能追加と同じくらい大切にしています。

まず確かめてほしいこと

WeatherKit を組み込んだら、公開前に実機で一度だけ確認してください。アトリビューションのロゴとリンクが、ライト・ダーク両方できちんと表示されているか。この一点を満たすだけで、私が二度繰り返したリジェクトは避けられます。機能の実装よりも、規約の一行のほうが公開を左右することがある——天気アプリは、それを静かに教えてくれる題材だと感じています。