【開発日誌 Day1】Captioが好きすぎて、もう一度"あの体験"を作りたくなった

2026年のiOS開発で、SwiftUIではなくUIKitを選ぶのは異端に見えるかもしれない。しかし、私たちの最優先目標は明確だった——Time-to-Text 500ms以下。

SwiftUIの`body`再評価、`StateObject`の初期化、`@Environment`の解決——これらのオーバーヘッドは通常のアプリ開発では無視できる範囲だが、「起動即入力」を実現するには無視できない。1msでも速く、テキストフィールドにフォーカスを当てたい。

そこで採用したのが、Storyboardを使わないUIKit直接構築だ。

SceneDelegateでwindowを生成し、rootViewControllerに直接ComposeViewControllerを設定する。Storyboardのパース処理すらスキップする。

// SceneDelegate.swift
func scene(_ scene: UIScene,
           willConnectTo session: UISceneSession,
           options connectionOptions: UIScene.ConnectionOptions) {
    guard let windowScene = (scene as? UIWindowScene) else { return }
    let window = UIWindow(windowScene: windowScene)
    window.rootViewController = ComposeViewController()
    window.makeKeyAndVisible()
    self.window = window
}

そしてComposeViewControllerの`viewDidAppear`で、即座にテキストビューにフォーカスを当てる。

// ComposeViewController.swift
override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    textView.becomeFirstResponder()
}

この2つのコードだけで、起動からキーボード表示までのパスが最短になる。

目標は500ms以下。のちに画面録画で測った記録（2026年8月11日、iPhone 16e・ウォーム起動）では、アイコンのタップからキーボードの表示完了まで0.4秒だった。SwiftUIでは`@FocusState`やbodyの再評価のタイミングを細かく制御しにくく、この経路を詰めるのは難しいと判断した（両者を同じ条件で計測して比べたわけではない）。

UIKitは「古い」かもしれない。しかし「速い」。この1点において、UIKitは今でも最良の選択肢だ。

Captioの「送ったら消える」体験を再現するために、最も重要な設計判断がある。それは、送信アニメーションとUIクリアを、ネットワークレスポンスから完全に分離することだ。

一般的なアプリの送信フローはこうだ：

1. 送信ボタンを押す
2. ローディングインジケーターを表示
3. サーバーからのレスポンスを待つ
4. 成功ならUIをクリア、失敗ならエラーを表示

このフローでは、ネットワークの遅延がそのままUIの遅延になる。私たちのフローはこうだ：

1. 送信ボタンを押す
2. 即座にUIをクリア（アニメーション: 0.25秒）
3. バックグラウンドでネットワーク送信
4. 成功→静かにOutboxから削除 / 失敗→バックグラウンドでリトライ

// ComposeViewController.swift
private func performSendAnimation() {
    UIView.animate(withDuration: 0.25,
                   delay: 0,
                   options: .curveEaseOut) {
        self.textView.alpha = 0
        self.subjectField.alpha = 0
    } completion: { _ in
        self.textView.text = ""
        self.subjectField.text = ""
        self.textView.alpha = 1
        self.subjectField.alpha = 1
        self.textView.becomeFirstResponder()
    }
}

ユーザーにとっては、送信ボタンを押した瞬間にメモが「消えて」、次のメモを書ける状態になる。ネットワークの成功・失敗は、ユーザーの目に見えないところで処理される。

「でも、送信に失敗したらどうするの？」——その疑問に答えるのが、次のセクションのOutboxアーキテクチャだ。

送信UIをネットワークレスポンスから分離するということは、「UIはクリアされたけど、実はメール送信に失敗していた」という状況が起こり得るということだ。これは絶対に許容できない。ユーザーが「送った」と思ったメモが、実は送られていなかった——これはメモアプリにとって致命的な信頼の喪失だ。

そこで採用したのがOutboxパターンだ。

メッセージの送信フローは以下の通り：

1. 送信ボタンタップ：メッセージをAES-GCM暗号化してOutbox（ローカルストレージ）に保存
2. UIクリア：performSendAnimationで即座に画面をクリア
3. バックグラウンド送信：Outboxからメッセージを取り出してRelay APIに送信
4. 成功：Outboxからメッセージを削除
5. 失敗：送信待ちに残して、あとで送り直す
6. オフライン：NWPathMonitorで接続を監視し、復帰時に自動再送

重要なのは、ネットワーク送信の前にOutboxに保存するという順序だ。これにより、アプリが突然クラッシュしても、端末の電源が落ちても、Outboxに書き込んだメッセージは残る。

Outboxに保存されるメッセージは、CryptoKitを使ったAES-GCM暗号化で保護される。暗号化キーはKeychainに保存され、アプリのサンドボックス外からはアクセスできない。

// OutboxManager.swift
func enqueue(message: OutboxMessage) throws {
    let key = try KeychainHelper.getOrCreateSymmetricKey()
    let sealedBox = try AES.GCM.seal(
        message.plainData,
        using: key
    )
    let encrypted = EncryptedOutboxEntry(
        id: message.id,
        sealedData: sealedBox.combined!,
        createdAt: Date(),
        retryCount: 0
    )
    try persistenceStore.save(encrypted)
}

また、すべてを自前で実装しているため、外部ライブラリへの依存はゼロだ。CryptoKit、NWPathMonitor、URLSession——すべてApple純正のフレームワークで完結する。サードパーティライブラリのバージョン管理やセキュリティ監査から解放されるのは、小規模チームにとって大きなメリットだ。

Captioの送信の仕組みは公式には公開されていない。開発元の終了告知が挙げた理由は、アプリの安定性と安全性を保つための手間をかけ続けられなくなったことで、送信の方式は理由に挙げられていない。ただ一般論として、外部のメールAPIに頼る送信は、提供元の要件の変更やアクセス制限の影響を受けやすい。

私たちはCloudflare Workers + Resend APIという構成を選んだ。

Cloudflare Workersはエッジコンピューティング基盤で、世界中のユーザーに最も近いデータセンターでコードが実行される。日本からのリクエストは日本のエッジで処理され、アメリカからのリクエストはアメリカのエッジで処理される。これにより、従来のサーバーレス（AWS Lambda等）と比べて、コールドスタートの問題がほぼ解消される。

メール送信にはResend APIを使用する。Resendは開発者向けのメール送信APIだ。

メール認証フロー

ユーザーが宛先メールアドレスを設定する際、6桁の認証コードによるメール認証を行う。これにより、第三者のメールアドレスへの不正送信を防ぐ。

多層レート制限

不正利用を防ぐために、多層のレート制限を実装している。

// Cloudflare Worker - Rate Limit Configuration
const RATE_LIMITS = {
  devicePerMinute: 30,    // 1デバイスあたり1分30回
  devicePerDay: 200,      // 1デバイスあたり1日200回
  ipPerHour: 120,         // 1IPあたり1時間120回
  globalPerDay: 300       // サービス全体で1日300回（調整可能）
};

デバイス単位、IP単位、グローバル単位の3層でレート制限をかけることで、単一デバイスの暴走もボットネット攻撃もブロックできる。

2026-09 追記：端末ごとの上限と全体の1日の上限は、2026年6月に撤去しました。いまの送信の上限は、IPアドレスごとの1時間あたりの上限です。

冪等性の保証

ネットワークの不安定さによる重複送信を防ぐため、各メッセージにUUIDを割り当て、Relay API側で重複チェックを行う。同じUUIDのメッセージが再送された場合、2回目以降はメール送信を行わずに成功レスポンスを返す。これにより、Outboxパターンのリトライ機構と組み合わせても、ユーザーが同じメモを二重に受信することはない。

2026-10 追記：いまの送信用サーバーは、重複の確認を自分では行っていません。メッセージIDを Resend への要求の冪等キー（Idempotency-Key）として渡し、Resend が同じキーを24時間覚えていて、同じ内容の要求には前と同じ応答を返します。そのため、24時間のうちは同じメモが重ねて送られません（詳しくはRelay APIの設計）。

Day1の実装作業の多くは、星評価ダイアログの見直しに費やした。App Storeの評価はアプリの生命線だが、ユーザー体験を損なう形で評価を求めてはいけない。

表示条件の再設計

星評価ダイアログの表示条件を以下のように設定した：

• 100通ごとに表示：十分にアプリを使い込んだユーザーにのみ表示
• 最低14日間の間隔：前回表示してから14日以上経過していること
• 閉じた後は30日間表示しない：ユーザーが閉じた場合、30日間は再表示しない

星アイコンのタップ領域修正

Apple Human Interface Guidelinesでは、タッチターゲットのサイズは最低44x44ptが推奨されている。星アイコンのタップ領域がこの基準を満たしていなかったため修正した。

// StarRatingView.swift
private func createStarButton() -> UIButton {
    let button = UIButton(type: .custom)
    button.translatesAutoresizingMaskIntoConstraints = false
    NSLayoutConstraint.activate([
        button.widthAnchor.constraint(greaterThanOrEqualToConstant: 44),
        button.heightAnchor.constraint(greaterThanOrEqualToConstant: 44)
    ])
    return button
}

星アイコンの歪み修正

UIStackViewの`.fillEqually` distributionが原因で星アイコンが歪んでいた問題を修正。`contentMode`を`.scaleAspectFit`に設定し、StackViewのdistributionを`.equalSpacing`に変更した。

評価後のフロー

• 5つ星：App Storeのレビュー画面に遷移（`SKStoreReviewController`）
• 4つ星以下：「ありがとうございます」のトーストを静かに表示して終了。ネガティブなレビューをApp Storeに誘導しない。

送信履歴画面（History）で、あるバグに気づいた。送信が完了しているにも関わらず、ステータスが「送信中」のまま変わらないメッセージがあった。

原因を調査した結果、ステータス更新のロジックに問題があることが判明した。従来の実装では、メッセージのテキスト内容をキーにしてステータスを更新していた。しかし、同じ内容のメモを複数回送信した場合、テキストベースの検索では正しいメッセージを特定できない。

修正は単純明快だった。テキストベースの検索をIDベースのステータス更新に変更した。各メッセージにはOutbox保存時にUUIDが割り当てられているため、このIDを使ってHistoryのステータスを更新する。

// HistoryManager.swift
// Before: テキストベースの検索（バグの原因）
// func updateStatus(forText text: String, status: SendStatus)

// After: IDベースのステータス更新
func updateStatus(forMessageId id: UUID, status: SendStatus) {
    guard let index = entries.firstIndex(where: { $0.messageId == id }) else {
        return
    }
    entries[index].status = status
    persistEntries()
}

この修正により、同じ内容のメモを何度送っても、それぞれのステータスが正しく表示されるようになった。

メモアプリにはプライベートな情報が書き込まれる。パスワード、個人的な悩み、ビジネスアイデア——ユーザーが何を書くかは予測できない。だからこそ、プライバシー保護は「十分」ではなく「過剰」なくらいがちょうどいい。

アプリスイッチャーでのプライバシーオーバーレイ

iOSのアプリスイッチャーでは、アプリの画面がサムネイルとして表示される。アプリスイッチャーの画面からメモの内容が見えないように、アプリがバックグラウンドに移行する際にプライバシーオーバーレイを表示する。

2026-09 追記：いまのアプリでは、この保護は有効になっていません（表示用の処理はソースに残っていますが、呼び出されていません）。表示中のメモがアプリスイッチャーの画像に残ることがあります。詳しくは「プライバシー設計」の記事をご覧ください。

Ephemeral URLSession

通常のURLSessionは、キャッシュ、クッキー、認証情報をディスクに保存する。私たちは`URLSessionConfiguration.ephemeral`を使用することで、これらの情報がディスクに一切残らないようにしている。通信のキャッシュとしてメモの内容がストレージに残らないようにするためだ。

ログの無害化

開発中のデバッグログには注意が必要だ。「送信したメモの内容をログに出力する」という一見無害な処理が、セキュリティホールになり得る。私たちのポリシーは明確だ：

• メモの内容は、DEBUGビルドであっても一切ログに記録しない
• エラーログでは`localizedDescription`を使わず、`type(of: error)`のみを記録
• 理由：`localizedDescription`にはユーザー入力が含まれる可能性があるため

// NetworkManager.swift
// BAD: エラーの詳細をログに出力
// Logger.error("Send failed: \(error.localizedDescription)")

// GOOD: エラーの型のみをログに出力
Logger.error("Send failed: \(type(of: error))")

偏執的に見えるかもしれない。しかし、メモアプリを信頼して使ってもらうためには、この程度の偏執さが必要だと考えている。

Captioは英語圏を中心に世界中にユーザーがいた。その元ユーザーたちに「Obsidian連携シンプルメモ」を届けるために、初回リリースから10言語に対応した。

対応言語：日本語、英語、スペイン語、フランス語、ドイツ語、イタリア語、ポルトガル語、韓国語、中国語（簡体字）、アラビア語。

2026-09 追記：いまの App Store の表記では、対応言語は日本語、英語、スペイン語、フランス語、ドイツ語、ポルトガル語、ロシア語、中国語（簡体字）、中国語（繁体字）、アラビア語の10言語です。上の一覧のイタリア語と韓国語は、いまの表記には含まれていません。

特にアラビア語のRTL（Right-to-Left）対応は技術的な挑戦だった。テキストの方向だけでなく、UIレイアウト全体をミラーリングする必要がある。Auto Layoutの`leading`/`trailing`制約を一貫して使うことで、RTL環境でも自然なレイアウトを実現している。

アプリ内言語切り替え

iOS 16以降のアプリ内言語切り替えに加え、独自の言語切り替えメカニズムも実装している。言語が切り替わった際は、ViewControllerを`cross-dissolve`トランジションで差し替えることで、スムーズな切り替え体験を提供する。

// LanguageManager.swift
func applyLanguageChange() {
    guard let window = UIApplication.shared.connectedScenes
        .compactMap({ $0 as? UIWindowScene })
        .first?.windows.first else { return }

    let newVC = ComposeViewController()
    newVC.view.frame = window.bounds
    UIView.transition(with: window,
                      duration: 0.3,
                      options: .transitionCrossDissolve,
                      animations: {
        window.rootViewController = newVC
    })
}