オフラインでも — 決まった時間にアプリを制限したい時にも
アプリはブロックされたまま

はい。セットアップ済みのiPhoneなら、Fellaの中核であるアプリブロックはオフラインで動作します。 Wi-Fiやモバイルデータをオフにしても、実行中のブロック（シールド）は解除されません。登録済みのスケジュールはAppleのDeviceActivityが実行します。手動セッションや緊急ロック解除も、端末が有料プランを認識していればローカルのスクリーンタイムAPIと端末内データだけで動きます。

ただし、Fellaのすべてがオフラインで完結するわけではありません。 サブスクリプションの購入や復元、キャッシュがない状態でのアカウント・購入情報の更新、アプリのダウンロードやアップデート、解析データの送信にはネット接続が必要です。オフラインで保証されるのは「ブロックの強制力」であり、課金やアカウント周りすべてではありません。

端末の再起動は、保証されるオフライン動作として記載していません。 再起動時にFellaは共有されたローカルデータからシールドとセッション状態を再構築し、登録済みのDeviceActivityスケジュールはシステムが管理します。ただし、機内モードのまま再起動する実機テストができていないため、この特定の手順を保証するものではありません。

1. ブロックの実行はiPhone本体で行われます。 FellaはAppleのFamilyControlsに権限をリクエストし、選んだアプリやカテゴリに対応するプライバシー保護されたトークンを受け取り、Managed Settingsに渡します。Managed Settingsがシステムのシールドを適用します。

2. セッションとスケジュールの状態は端末内に保存されます。 手動セッションの開始・終了時刻、有効なブロック源、ルーティン、登録されたアクティビティ名、緊急ロック解除のタイミングは、アプリの共有App Groupに保存されます。メインアプリと拡張機能がFellaのサーバーに問い合わせずに現在のルールを共有できるのはこのためです。

3. サブスクリプションやアカウント、解析はネットを使います。 RevenueCatが商品・購入・復元・購入情報の更新を担当します。アカウントを使う場合はFellaのアカウントサービスで認証します。PostHogが利用解析、Sentryが不具合解析を担います。これらのサービスは、すでに有効なアプリシールドを画面に表示し続ける仕組みではありません。

ブロックは維持されます。 Wi-Fiをオフにしても、モバイルデータを無効にしても、機内モードをオンにしても、Managed Settingsのシールドは解除されません。アプリが開けるかどうかを、常にリモートサーバーに問い合わせて決めているわけではないからです。

セッションには端末内の終了時刻があります。 Fellaは手動セッションの期間を保存し、バックアップとしてDeviceActivityのコールバックを登録しています。接続が切れても、この状態が書き換わったりブロック源が無効になったりすることはありません。

機内モードは抜け道になりません。 現在の設計では、シールド、スケジュール監視、緊急時の再ロックのいずれの処理にもネット依存がありません。これはコードと自動テストで確認された事実であり、現時点の実機で機内モードを再現したテストによるものではない点は明記します。

はい。セットアップと有料認証が済んでいれば可能です。 手動セッションの開始は、開始・終了をAppleのDeviceActivityに登録し、期間を共有ローカルストレージに書き込み、手動のブロック源を有効化し、選択したアプリにシールドを適用します。これらの処理はFellaのバックエンドを呼び出しません。

境界線はサブスクリプションの確認です。 Fellaは開始前に有料アクセスを確認します。RevenueCatは顧客情報を端末にキャッシュし、更新に失敗してもFellaは最後に確認できた有効状態を保持します。初回購入前などで利用可能なキャッシュがない場合は、オフラインで有料アクセスを確立できません。

アプリ選択とスクリーンタイムの権限が事前に必要です。 システムの選択画面と権限付与はiOSの機能です。初回セットアップや購入、アカウント復旧がネットなしで完了するとは保証しません。

FellaはルーティンのスケジュールをDeviceActivityに登録します。 登録された時間帯が始まると、iOSがFellaの監視拡張（monitor extension）を起動します。拡張は対応するブロック源を有効化し、共有ローカルデータからシールドを適用。時間帯が終わればそのブロック源を解除し、重なるブロックがあれば整合性を取ります。

メインアプリを開いておく必要はありません。 DeviceActivityの監視拡張を使う目的はそこにあります。開始・終了のコールバックにはRevenueCatやPostHog、Supabase、URLSessionなどのネットワーク処理は一切含まれません。

オフライン＝あらゆるシステム変更に強い、ではありません。 スクリーンタイムの権限を取り消したり、端末設定を変更したり、必要な認証を外したりするのは、ネット切断とは別の問題です。詳しくはFellaのセッションとルーティンの仕組みをご覧ください。

ロック解除自体にサーバー応答は不要です。 条件を満たせば、Fellaは5分間の開始・終了時刻を端末内に保存し、一時的にシールドを外し、終了時刻にDeviceActivityのコールバックを予約します。メインアプリが起動していなくても、監視拡張が現在のブロックルールを再適用します。

端末が有料アクセスを認識していることは依然必要です。 アプリは緊急ロック解除の前にサブスクリプション状態を確認します。キャッシュされた購入情報があれば更新失敗時も維持されますが、キャッシュがない初回状態ではオフラインで作成できません。

再ロックには2つのローカル経路があります。 システム拡張がバックグラウンドでの経路です。コールバックが遅延したり予約に失敗したりした場合、次回アプリ起動時に端末内に保存された終了時刻を照合して再調整します。緊急ロック解除の挙動で詳しく解説しています。

FellaはVPNやプロキシ経由で通信を流しません。 Fellaの役割は、Appleのスクリーンタイムフレームワークを通じて選択したiPhoneアプリへのアクセスを制限することです。だからこそ、アプリシールドはデータ通信や外部のフィルタリングサーバーが有効であることに依存しません。

ネットワークフィルタは別の課題を解きます。 VPNやDNSベースのツールは、ウェブサイトやネットワークリクエストのフィルタリングを目的に設計されることが多く、中にはオフラインでも有用な動作を保つものもあります。Fellaは「すべてのVPN型ブロッカーがネットなしでは無効になる」と主張しているわけではなく、Fella自身のアプリブロック経路がVPNを使わないことを説明しています。

オフラインのアプリブロックは、オフラインのウェブフィルタリングではありません。 Fellaがブロックするのは選択したアプリです。オフラインの間にすべてのウェブサイトや通信、コンテンツをブロックすると主張するものではありません。方式の比較は、専用ページが公開される際にそちらで詳述します。

ブロック対象のアプリ選択はAppleの不透明なスクリーンタイムトークンで表現されます。 Fellaはそのトークンを、アプリ本体とブロック用拡張機能が共有するローカルApp Groupに保存します。Appleの選択画面由来のトークンは解析データとして送信されません。

Fellaは完全なオフラインアプリではありません。 製品版アプリは、サブスクリプションにRevenueCat、認証や対応する同期に任意のアカウントサービス、利用解析にPostHog、診断にSentryを使用しています。これらのサービスは接続可能なときにそれぞれのデータを送信します。

判断前に全体像を確認してください。 プライバシーポリシーでデータの全体像を、Fellaの仕組みで端末内ブロックの考え方をわかりやすく説明しています。

ブロックが有効かどうかをネット接続が決めるべきではありません。 Fellaの中核ルールはiPhone上のiOSによって適用されるため、トンネルや電波の届かない場所、データプランの無効化、意図的な機内モードへの切り替えでも、すでに有効なアプリシールドが外れることはありません。

Fellaはアプリへのアクセスが課題のときに適しています。 VPNでも、ウェブサイトフィルタでも、リモート監視サービスでもありません。iPhoneアプリブロッカーとして、端末内での選択アプリ制限、手動セッション、スケジュールされたルーティン、そして制御された緊急アクセスを中心に設計されています。