ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English

AI画像生成でiOSアプリアイコンを作るためのプロンプトテンプレート

はじめに iOSアプリのアイコンをAI画像生成ツール(Gemini、ChatGPT/DALL-E、Midjourney等)で作る際、Apple Human Interface Guidelines(HIG)に準拠した画像を一発で生成するのは意外と難しいです。 よくある失敗: 角丸が事前に適用されている(iOSが自動で角丸マスクをかけるので不要) 四隅に白い隙間がある テキストが入っている 細かすぎて小サイズで潰れる 本記事では、これらの問題を回避するプロンプトテンプレートを紹介します。 テンプレート A flat, square 1024x1024 app icon for an iOS app called "{{APP_NAME}}" that {{APP_DESCRIPTION}}. Design requirements: - Fill the entire canvas edge-to-edge with a uniform {{BACKGROUND_COLOR}} background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: {{ILLUSTRATION_DESCRIPTION}}, rendered in {{INK_COLOR}} line art style. - Include one {{ACCENT_COLOR}} {{ACCENT_ELEMENT}} placed on the illustration to {{ACCENT_PURPOSE}}. - {{OPTIONAL_ELEMENT}} - Style: elegant, minimal color palette ({{COLOR_PALETTE}}), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ## 変数一覧 | 変数 | 説明 | 例 | |------|------|-----| | `APP_NAME` | アプリ名 | IIIF AR | | `APP_DESCRIPTION` | 機能を1文で | places historical maps in AR | | `BACKGROUND_COLOR` | 背景色 | warm cream (#F0E4CC) | | `ILLUSTRATION_DESCRIPTION` | 中央イラストの内容 | a Japanese landscape with mountains | | `INK_COLOR` | イラストの線画色 | dark navy (#1A237E) | | `ACCENT_COLOR` | アクセント色 | blue (#1565C0) | | `ACCENT_ELEMENT` | アクセント要素 | AR pin marker | | `ACCENT_PURPOSE` | アクセントの意図 | suggest spatial placement | | `OPTIONAL_ELEMENT` | 追加要素(不要なら行ごと削除) | a subtle perspective grid | | `COLOR_PALETTE` | 色パレットの説明 | cream + navy + blue accent | ## 使用例 ### 歴史的絵図ARアプリ ```text A flat, square 1024x1024 app icon for an iOS app called "IIIF AR" that places high-resolution cultural heritage images in augmented reality at real-world scale. Design requirements: - Fill the entire canvas edge-to-edge with a uniform warm cream/parchment (#F0E4CC) background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: a stylized composition showing overlapping cultural heritage imagery — such as a fragment of a traditional Japanese landscape painting with mountains, water, and architecture — rendered in dark navy (#1A237E) line art style. - Include one blue (#1565C0) location/AR pin marker placed on the illustration to suggest spatial placement. - Optionally include a subtle perspective grid (2-3 thin lines) at the bottom to hint at AR floor placement. - Style: elegant, minimal color palette (cream + navy ink + one blue accent), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ### くずし字OCRアプリ ```text A flat, square 1024x1024 app icon for an iOS app called "KotenOCR" that recognizes classical Japanese cursive script (kuzushiji) using on-device AI. Design requirements: - Fill the entire canvas edge-to-edge with a uniform warm ivory (#FAF3E8) background. No white areas, no transparency, no empty corners. - Do NOT include frames, borders, or decorative edges of any kind. - Center illustration: a stylized fragment of a classical Japanese manuscript page with elegant brushstroke characters, rendered in dark sumi ink (#2C1810) line art style. - Include one teal (#00897B) scanning/recognition indicator (such as a viewfinder bracket or highlight box) placed over one character to suggest OCR recognition. - Style: elegant, minimal color palette (ivory + sumi ink + one teal accent), flat design, no gradients on illustration, no shadows, no 3D effects. - Detailed enough to be interesting but clear at small sizes (29px). Medium-weight lines. - Do NOT add any text, letters, or characters. - Do NOT pre-round corners — perfectly square image. iOS applies rounded corners automatically. - Output: square PNG, 1024x1024 pixels. ```text ## Apple HIG準拠チェックリスト 生成後に以下を確認してください。 - [ ] 正方形(1024×1024px)で、角丸なし - [ ] 四隅まで背景色で塗りつぶされている(透明や白の隙間なし) - [ ] テキストが含まれていない - [ ] 写真ではなくイラスト/グラフィック - [ ] 29pxに縮小しても何のアプリかわかる - [ ] Apple製品のレプリカが含まれていない - [ ] カスタムのハイライトやドロップシャドウがない ## 適用方法 ```bash # 生成した画像を配置 cp ~/Downloads/generated_icon.png \ {PROJECT}/Assets.xcassets/AppIcon.appiconset/AppIcon.png # ビルドして確認 xcodegen generate xcodebuild build -project {PROJECT}.xcodeproj -scheme {SCHEME} ... ```text ## 参考 - [Apple Human Interface Guidelines - App Icons](https://developer.apple.com/design/human-interface-guidelines/app-icons)

Firebase不要:Apple標準ツールだけでiOSアプリを運用する

はじめに iOSアプリの運用を始めると、すぐに以下のような課題に直面します。 クラッシュしているのか、どこで落ちているのか知りたい ダウンロード数やセッション数を把握したい 古いバージョンのユーザーにアップデートを促したい レビューを書いてもらいたい 多くの記事が Firebase Crashlytics + Firebase Analytics の導入を勧めますが、これはGoogleのサーバーにユーザーのデバイス情報・使用状況・クラッシュログなどを送信することを意味します。App Storeへの提出時にも「データ収集・追跡」の申告が必要になります。 個人開発や学術目的のアプリでは、そこまでのデータ収集が本当に必要でしょうか? 本記事では、ユーザーデータを外部に送信せず、Apple標準ツールとOSSだけで運用する構成を、実際のApp Store公開アプリ KotenOCR での経験をもとに紹介します。 構成の全体像 目的 Firebase構成 本記事の構成 外部送信 クラッシュ計測 Crashlytics MetricKit なし アナリティクス Firebase Analytics App Store Connect Analytics API なし アップデート促進 Remote Config Siren(iTunes Lookup API) なし※ レビュー促進 In-App Messaging SKStoreReviewRequest なし クラッシュログ閲覧 Crashlytics Console Xcode Organizer なし ※ Sirenは iTunes Lookup API(Apple公式)にバージョン確認のリクエストを送りますが、ユーザーの個人情報は含まれません。 1. MetricKit — クラッシュ計測 MetricKit はiOS 13+で利用可能なApple標準フレームワークです。クラッシュレポート、ハング(応答なし)、起動時間などのパフォーマンスデータをアプリ内で受け取れます。 実装 import MetricKit class MetricKitManager: NSObject, MXMetricManagerSubscriber { static let shared = MetricKitManager() func start() { MXMetricManager.shared.add(self) } // iOS 15+: クラッシュ・ハングの即時通知 func didReceive(_ payloads: [MXDiagnosticPayload]) { for payload in payloads { if let crashDiagnostics = payload.crashDiagnostics { for crash in crashDiagnostics { // クラッシュのスタックトレースを処理 let description = crash.callStackTree.jsonRepresentation() // ログに記録、またはローカルに保存 } } } } // iOS 14+: 24時間ごとのパフォーマンスメトリクス func didReceive(_ payloads: [MXMetricPayload]) { for payload in payloads { // 起動時間、メモリ使用量、ディスクI/Oなど } } } ```text アプリの起動時に `MetricKitManager.shared.start()` を呼ぶだけです。 ### MetricKitの特徴 - **外部送信なし** — データはアプリ内で完結。Appleのサーバーにも送らない - **即時通知** — iOS 15以降、クラッシュ直後に `didReceive(_: [MXDiagnosticPayload])` が呼ばれる - **バッテリー・パフォーマンス** — クラッシュだけでなく、起動時間やメモリ使用量も計測できる ### Xcode Organizer との違い Xcode Organizer(Xcode → Window → Organizer → Crashes)も追加実装なしでクラッシュログを表示しますが、以下の制限があります。 - ユーザーが「診断データ共有」をオンにしている必要がある(オプトイン) - ある程度のユーザー数がないとデータが集まらない - 蓄積に数日〜数週間かかる ユーザー数が少ない段階では MetricKit の方が実用的です。 ## 2. App Store Connect Analytics API — アナリティクス App Store Connect のWebコンソールでもアナリティクスは見られますが、APIで取得すると自動化や詳細な分析が可能になります。 ### 準備:JWT認証 App Store Connect APIは JWT(JSON Web Token)で認証します。 ```python import jwt import time import requests KEY_ID = "YOUR_KEY_ID" ISSUER_ID = "YOUR_ISSUER_ID" with open("AuthKey.p8", "r") as f: private_key = f.read() payload = { "iss": ISSUER_ID, "iat": int(time.time()), "exp": int(time.time()) + 1200, "aud": "appstoreconnect-v1" } token = jwt.encode(payload, private_key, algorithm="ES256", headers={"kid": KEY_ID}) headers = {"Authorization": f"Bearer {token}"} ```text ### レポートリクエストの作成 Analytics APIを使うには、まずレポートリクエストを作成(または既存のものを取得)します。 ```python APP_ID = "YOUR_APP_ID" # レポートリクエストの確認 r = requests.get( f"https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/analyticsReportRequests", headers=headers ) report_requests = r.json()["data"] # なければ作成(ONGOINGで継続的にレポート生成) if not report_requests: r = requests.post( f"https://api.appstoreconnect.apple.com/v1/apps/{APP_ID}/analyticsReportRequests", headers=headers, json={ "data": { "type": "analyticsReportRequests", "attributes": {"accessType": "ONGOING"}, "relationships": { "app": {"data": {"type": "apps", "id": APP_ID}} } } } ) ```text ### レポートの取得 ```python import gzip import csv import io from collections import defaultdict REPORT_REQUEST_ID = report_requests[0]["id"] def fetch_report(report_name): """指定したレポートの全インスタンスを取得して結合""" # レポート一覧を取得 r = requests.get( f"https://api.appstoreconnect.apple.com/v1/analyticsReportRequests/" f"{REPORT_REQUEST_ID}/reports", headers=headers, params={"limit": 200} ) for report in r.json()["data"]: if report["attributes"]["name"] == report_name: # インスタンス(日付ごとのデータ)を取得 r2 = requests.get( f"https://api.appstoreconnect.apple.com/v1/analyticsReports/" f"{report['id']}/instances", headers=headers, params={"limit": 10} ) all_data = "" for inst in r2.json().get("data", []): # セグメント(実際のデータファイル)を取得 r3 = requests.get( f"https://api.appstoreconnect.apple.com/v1/" f"analyticsReportInstances/{inst['id']}/segments", headers=headers ) for seg in r3.json().get("data", []): url = seg["attributes"].get("url") if url: r4 = requests.get(url) text = gzip.decompress(r4.content).decode("utf-8") lines = text.strip().split("\n") if not all_data: all_data = text.strip() else: all_data += "\n" + "\n".join(lines[1:]) return all_data return None ```text ### 利用可能なレポートの例 | レポート名 | カテゴリ | 内容 | |-----------|---------|------| | App Downloads Standard | COMMERCE | ダウンロード数(新規/再DL、デバイス、地域別) | | App Sessions Standard | APP_USAGE | セッション数、平均時間 | | App Store Discovery and Engagement Standard | APP_STORE_ENGAGEMENT | インプレッション、ページ閲覧、タップ | | App Store Installation and Deletion Standard | APP_USAGE | インストール・削除数 | | App Crashes | APP_USAGE | クラッシュ数 | ### 実際の出力例 KotenOCRの公開直後のデータです。 ```text === ダウンロード数 === 2026-03-20: 新規 95 / 再DL 2 / 計 97 2026-03-21: 新規 348 / 再DL 14 / 計 362 2026-03-22: 新規 104 / 再DL 188 / 計 292 2026-03-23: 新規 23 / 再DL 231 / 計 254 合計: 新規 570 / 再DL 435 / 計 1,005 === セッション数 === 2026-03-20: 159 セッション / 平均 81秒 2026-03-21: 345 セッション / 平均 85秒 2026-03-22: 126 セッション / 平均 84秒 2026-03-23: 50 セッション / 平均 115秒 === App Store エンゲージメント === 2026-03-19: Impression: 79 / Page view: 14 / Tap: 19 2026-03-20: Impression: 172 / Page view: 315 / Tap: 336 2026-03-21: Impression: 596 / Page view: 576 / Tap: 600 2026-03-22: Impression: 193 / Page view: 106 / Tap: 101 === インストール / 削除 === 2026-03-20: インストール 63 / 削除 0 2026-03-21: インストール 249 / 削除 0 2026-03-22: インストール 66 / 削除 0 2026-03-23: インストール 56 / 削除 0 ```text データの遅延は約1〜2日です。Web UIではほぼ前日分まで閲覧できます。 ## 3. Siren — アップデート促進 [Siren](https://github.com/ArtSabintsev/Siren) は、App Storeの最新バージョンとアプリのバージョンを比較し、更新を促すダイアログを表示するOSSライブラリです。 ### 導入 Swift Package Manager で追加します。 ```text https://github.com/ArtSabintsev/Siren (6.1.0+) ```text ### 実装 ```swift import Siren // SwiftUIの場合、onAppear内で呼ぶこと(init()では動かない) private func configureSiren() { let siren = Siren.shared siren.rulesManager = RulesManager( majorUpdateRules: .critical, // メジャー: スキップ不可 minorUpdateRules: .annoying, // マイナー: スキップ不可(後で通知) patchUpdateRules: .default // パッチ: スキップ可能 ) siren.wail() } ```text ### 注意点 - **SwiftUIでは `onAppear` で呼ぶ** — `App.init()` の段階ではUIWindowが存在しないため、Sirenが正しく動作しません - **テスト方法** — Sirenは iTunes Lookup API で App Store上のバージョンと比較するため、テスト時は Info.plist の `CFBundleShortVersionString` を意図的に古いバージョンに設定する必要があります - **リリース直後の遅延** — デフォルトでリリースから1日経過しないとダイアログが表示されません(`showAlertAfterCurrentVersionHasBeenReleasedForDays` で変更可能) ### ダイアログの種類 | ルール | 動作 | |--------|------| | `.critical` | 「Update」ボタンのみ。スキップ不可 | | `.annoying` | 「Update」「Next time」の2ボタン。スキップ不可だが後回し可 | | `.default` | 「Update」「Next time」「Skip」の3ボタン | | `.relaxed` | `.default` と同じだが、表示頻度が低い | ## 4. SKStoreReviewRequest — レビュー促進 Apple標準のレビュー促進APIです。追加のフレームワークは不要です。 ```swift import StoreKit // OCR成功後など、ユーザーが価値を感じたタイミングで呼ぶ func requestReviewIfAppropriate() { let count = UserDefaults.standard.integer(forKey: "ocrSuccessCount") // 3回目のOCR成功後にレビューを依頼 if count == 3 { if let scene = UIApplication.shared.connectedScenes .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene { SKStoreReviewController.requestReview(in: scene) } } } ```text ### ポイント - Appleがダイアログの表示を制御するため、呼び出しても必ず表示されるとは限らない - **年3回まで**の制限がある - ユーザーが「成功体験」を感じた直後に呼ぶのが効果的 ## 5. 所感と限界 ### この構成でカバーできること - 基本的なダウンロード数・セッション数の把握 - クラッシュの検知と原因調査 - ユーザーへのアップデート促進 - レビュー促進 実際に KotenOCR をこの構成で運用していますが、個人開発アプリとしては十分な情報が得られています。 ### この構成の限界 - **画面単位・機能単位の詳細な計測ができない** — 「どの画面が最も使われているか」「翻訳機能の利用率は?」といった分析にはアプリ内のイベント計測が必要 - **リアルタイム性がない** — Analytics APIのデータには1〜2日の遅延がある - **MetricKitのクラッシュ情報は構造化されていない** — スタックトレースのJSON解析は自前で実装する必要がある - **A/Bテストや段階的ロールアウトは不可能** — これらが必要な場合はFirebase Remote Configなどが必要 ### Firebaseが必要になるケース - ユーザー行動の詳細な分析が必要な場合 - リアルタイムのクラッシュ通知が必要な場合 - Feature Flagsやリモート設定が必要な場合 - プッシュ通知を実装する場合 ## まとめ | ツール | 用途 | 実装コスト | |--------|------|-----------| | MetricKit | クラッシュ・パフォーマンス計測 | 小 | | App Store Connect Analytics API | DL数・セッション・エンゲージメント | 中(Python) | | Siren | アップデート促進ダイアログ | 小 | | SKStoreReviewRequest | レビュー促進 | 最小 | | Xcode Organizer | クラッシュログ閲覧 | なし | Firebase不要でも、個人開発アプリの運用に必要な情報はほぼ揃います。プライバシーポリシーの記載義務も最小限で済み、ユーザーに対して「データを収集していません」と言い切れるのは大きなメリットです。 まずはこの構成で始めて、必要に応じてFirebaseを追加する、という段階的なアプローチがおすすめです。 ## 関連記事 - [KotenOCR:くずし字をオフラインで認識するiOSアプリの開発と公開](/posts/kotenocr-ios-app/) - [App Store Connect APIだけでiOSアプリを審査提出する手順](/posts/appstore-connect-api-guide/) - [iOSアプリのメモリ最適化とクラッシュ修正の実践記録](/posts/ios-memory-crash-fixes/)

App Store Connect APIでiOSアプリのアップデートを審査提出する方法

App Store Connect APIでiOSアプリのアップデートを審査提出する方法

TL;DR iOSアプリのアップデート版を ビルド → アップロード → ビルド紐付け → whatsNew設定 → 審査提出 まで、すべてコマンドラインとApp Store Connect REST APIで完結させた。初回リリース時と異なり、メタデータやスクリーンショットは既存のものが引き継がれるため、更新時に必要な操作は少ない。 前提: App Store Connect APIだけでiOSアプリを審査提出する完全ガイドのセットアップ(APIキー取得・JWT生成・ヘルパー関数)が完了しているものとする。 全体の流れ ビルド番号のインクリメント アーカイブ・IPA書き出し・アップロード(xcodebuild + xcrun altool) ビルドの処理完了を確認(API) ビルドをバージョンに紐付け(API) 暗号化コンプライアンスの設定(API) whatsNew(新機能)の設定(API) 審査提出(API) 1. ビルド番号のインクリメント App Store Connectは同じビルド番号のアップロードを拒否する。CURRENT_PROJECT_VERSION を上げる必要がある。 XcodeGenを使っている場合は project.yml を編集する: # project.yml settings: base: MARKETING_VERSION: "1.1.0" CURRENT_PROJECT_VERSION: "4" # 3 → 4 に変更 ポイント: マーケティングバージョン(1.1.0)はユーザーに見えるバージョン番号、ビルド番号(4)は同一バージョン内の連番。不具合修正の再提出など、ユーザーから見た変更がない場合はビルド番号だけ上げればよい。 2. アーカイブ・アップロード # 環境変数を設定 export APP_STORE_API_KEY="YOUR_KEY_ID" export APP_STORE_API_ISSUER="YOUR_ISSUER_ID" # XcodeGenでプロジェクト再生成 xcodegen generate # アーカイブ xcodebuild archive \ -project KotenOCR.xcodeproj \ -scheme KotenOCR \ -archivePath build/KotenOCR.xcarchive \ -destination "generic/platform=iOS" \ -quiet # IPA書き出し xcodebuild -exportArchive \ -archivePath build/KotenOCR.xcarchive \ -exportPath build/export \ -exportOptionsPlist scripts/ExportOptions.plist \ -quiet # App Store Connectへアップロード xcrun altool --upload-app \ --type ios \ --file build/export/KotenOCR.ipa \ --apiKey "$APP_STORE_API_KEY" \ --apiIssuer "$APP_STORE_API_ISSUER" 注意: xcrun altool に渡す環境変数は export しておく必要がある。source .env だけではサブプロセスに渡らない。 ...

App Store Connect APIでiOSアプリにチップ(Tip Jar)機能を追加する完全ガイド

App Store Connect APIでiOSアプリにチップ(Tip Jar)機能を追加する完全ガイド

TL;DR iOSアプリにチップ(Tip Jar)機能を追加した。SwiftUI + StoreKit 2 でアプリ側を実装し、App Store Connect REST API を使って商品登録・ローカライズ・価格設定・審査用スクリーンショット・配信地域設定・TestFlight配信までをコマンドラインから完了させた。本記事ではその全手順を再現可能な形で記載する。 前提: App Store Connect APIだけでiOSアプリを審査提出する完全ガイドの続編として、APIキーの取得・JWT生成は既にセットアップ済みとする。 全体の流れ アプリ側の実装(StoreKit 2 + SwiftUI) App Store Connect APIで商品登録(3つの消費型アイテム) ローカライズ設定(日本語・英語) 価格設定($0.99 / $2.99 / $6.99) 審査用スクリーンショットのアップロード 配信地域の設定 有料アプリ契約の締結 TestFlightでの動作確認 1. アプリ側の実装 1.1 StoreKit設定ファイル Xcodeのテスト環境用に TipJar.storekit を作成する。これによりシミュレータでStoreKitのテストが可能になる。 { "products" : [ { "displayPrice" : "0.99", "familyShareable" : false, "internalID" : "tip_small_001", "localizations" : [ { "description" : "開発を応援する小さなチップ", "displayName" : "小さな応援", "locale" : "ja" }, { "description" : "A small tip to support development", "displayName" : "Small Tip", "locale" : "en_US" } ], "productID" : "com.example.app.tip.small", "referenceName" : "Small Tip", "type" : "Consumable" } ] } XcodeGen を使っている場合は project.yml の scheme に StoreKit 設定を追加する: ...

App Store Connect APIだけでiOSアプリを審査提出する手順

App Store Connect APIだけでiOSアプリを審査提出する手順

TL;DR App Store Connect の REST API を使い、コマンドラインからiOSアプリの審査提出に必要なほぼ全作業(メタデータ・スクリーンショット・年齢レーティング・ビルド紐付け・URL設定・暗号化コンプライアンス・価格設定)を完了させた。本記事ではその手順を再現可能な形で記載する。 注意: 「App Privacy(アプリのプライバシー)」のデータ使用状況の宣言だけは、2026年3月時点でAPIが提供されておらず、App Store Connectのブラウザから設定する必要がある。 前提条件 Apple Developer Program に登録済み App Store Connect で API キーを発行済み アプリの Bundle ID が登録済み Xcode でアーカイブ・アップロード済みのビルドが存在する(xcodebuild -exportArchive でアップロード可能) Python 3 + PyJWT + cryptography がインストール済み pip install PyJWT cryptography 1. API キーの準備 1.1 API キーの発行 App Store Connect → ユーザーとアクセス → 統合 → App Store Connect API から新しいキーを発行する。 名前: 任意(例: deploy-key) アクセス: Admin(メタデータ更新・提出に必要) 発行後、以下の情報をメモする: 項目 説明 Key ID APIキーの識別子(10文字程度の英数字) Issuer ID 組織の識別子(UUID形式) ダウンロードした .p8 ファイルは安全な場所に保存する(一度しかダウンロードできない): ...