Apps sperren –
auch ohne Internet

Ja – Fellas Kern der App-Sperre funktioniert offline, sobald die App auf dem iPhone eingerichtet ist. WLAN oder mobile Daten auszuschalten entfernt keine aktive Sperre. Bereits registrierte Zeitpläne laufen weiter über Apples DeviceActivity-System. Manuelle Sitzungen und die Notfall-Freischaltung nutzen lokale Bildschirmzeit-APIs und lokalen Status, wenn das Gerät deinen bezahlten Zugang bereits erkennt.

Das heißt nicht, dass jeder Teil von Fella komplett offline ist. Kauf oder Wiederherstellung eines Abos, das Aktualisieren von Account- oder Berechtigungs-Infos ohne nutzbaren Cache, das Laden von Updates und das Senden von Analysen brauchen ein Netz. Offline-Sperren ist eine Aussage über die Durchsetzung – nicht über Abrechnung, Accounts oder alle umliegenden Dienste.

Geräteneustart ist nicht als garantiertes Offline-Szenario gelistet. Die Quelle baut Sperren und Sitzungs-Wahrheit aus geteiltem lokalen Status neu auf, wenn Fella startet, und registrierte DeviceActivity-Zeitpläne werden vom System verwaltet. Aber es stand kein verbundenes iPhone für einen Neustart-im-Flugmodus-Test zur Verfügung, daher verspricht diese Seite diese spezifische Abfolge nicht.

1. Die Durchsetzung der Sperre passiert auf dem iPhone. Fella bittet Apples FamilyControls-System um Erlaubnis, erhält datenschutzfreundliche Tokens für die von dir ausgewählten Apps oder Kategorien und gibt diese Tokens an Managed Settings weiter. Managed Settings setzt die System-Sperre um.

2. Sitzungs- und Zeitplan-Status wird lokal gespeichert. Manuelle Start- und Endzeiten, aktive Sperr-Quellen, Routinen, registrierte Activity-Namen und das Timing der Notfall-Freischaltung leben in der geteilten App Group der App. So können sich Haupt-App und Erweiterungen auf die aktuelle Regel einigen, ohne einen Fella-Server zu prüfen.

3. Abo-, Account- und Analyse-Dienste nutzen das Netz. RevenueCat kümmert sich um Produkte, Käufe, Wiederherstellungen und Berechtigungs-Aktualisierungen. Authentifizierung nutzt Fellas Account-Dienst, wenn ein Account verwendet wird. PostHog erhält Produkt-Analysen. Keiner dieser Dienste ist der Mechanismus, der eine bereits aktive App-Sperre auf dem Bildschirm hält.

Die Sperre bleibt aktiv. WLAN auszuschalten, mobile Daten zu deaktivieren oder den Flugmodus zu aktivieren entfernt die Managed-Settings-Sperre nicht. Die Einschränkung wird nicht dadurch durchgesetzt, dass ständig ein Remote-Server gefragt wird, ob eine App geöffnet werden darf.

Die Sitzung hat weiterhin ein lokales Enddatum. Fella speichert die Daten der manuellen Sitzung und registriert DeviceActivity-Callbacks als System-Absicherung. Ein Verbindungsverlust schreibt diesen Status nicht um und deaktiviert nicht die Sperr-Quelle.

Flugmodus ist kein Internet-aus-Trick. Die aktuelle Architektur enthält keine Netzwerk-Abhängigkeit in den Pfaden für Sperre, Zeitplan-Monitor oder Notfall-Wiedersperrung. Das ist Evidenz auf Code-Ebene und aus automatisierten Tests; es wurde für diese Seite nicht erneut auf einem aktuell verbundenen echten iPhone wiederholt.

Ja, mit einer bereits konfigurierten und berechtigten Installation. Eine manuelle Sitzung zu starten registriert Start und Ende bei Apples DeviceActivity-System, schreibt die Daten in den geteilten lokalen Speicher, markiert die manuelle Sperr-Quelle als aktiv und setzt die Sperre für die ausgewählten Apps. Keine dieser Aktionen ruft ein Fella-Backend auf.

Die Abo-Prüfung ist die Grenze. Fella prüft den bezahlten Zugang vor dem Start. RevenueCat cached Kundeninformationen auf dem Gerät, und Fella behält den letzten bekannten aktiven Status, wenn eine Aktualisierung fehlschlägt. Wenn die App keinen nutzbaren Berechtigungs-Cache hat – etwa vor einem ersten Kauf – kann sie offline keinen bezahlten Zugang herstellen.

App-Auswahl und Bildschirmzeit-Berechtigung müssen bereits vorhanden sein. Der System-Picker und die Autorisierung gehören zu iOS. Diese Seite verspricht nicht, dass Ersteinrichtung, Kauf oder Account-Wiederherstellung ohne Verbindung abgeschlossen werden können.

Fella registriert Routine-Zeitpläne bei DeviceActivity. Wenn ein registriertes Intervall beginnt, führt iOS Fellas Monitor-Erweiterung aus. Die Erweiterung aktiviert die passende Sperr-Quelle und setzt die Sperre aus geteiltem lokalem Status. Wenn das Intervall endet, entfernt sie diese Quelle und gleicht überlappende Sperren ab.

Die Haupt-App muss nicht geöffnet sein. Genau dafür gibt es die DeviceActivity-Monitor-Erweiterung. Ihre Start- und End-Callbacks enthalten keinen RevenueCat-, PostHog-, Supabase-, URLSession- oder anderen Netzwerk-Client.

Offline heißt nicht immun gegen jede Systemänderung. Bildschirmzeit-Berechtigung zu entziehen, Geräteeinstellungen zu ändern oder nötige Autorisierungen zu entfernen ist ein anderes Thema als die Internetverbindung zu verlieren. Sieh unter wie Fellas Sitzungen und Routinen funktionieren.

Die Freischaltung selbst braucht keine Server-Antwort. Wenn du berechtigt bist, speichert Fella Start und Ende der fünf Minuten lokal, hebt die Sperre temporär auf und plant einen DeviceActivity-Callback für das Ende des Fensters. Die Monitor-Erweiterung wendet dann die aktuelle Sperr-Regel wieder an, selbst wenn die Haupt-App nicht läuft.

Bezahlter Zugang muss trotzdem auf dem Gerät erkannt sein. Die App prüft den Abo-Status vor der Notfall-Freischaltung. Eine bestehende gecachte Berechtigung kann eine fehlgeschlagene Aktualisierung überstehen; eine fehlende oder erstmalige Berechtigung kann offline nicht erstellt werden.

Die Wiedersperrung hat zwei lokale Wege. Die System-Erweiterung ist der Hintergrund-Weg. Wenn dieser Callback verzögert ist oder das Planen fehlschlägt, gleicht Fella auch das lokal gespeicherte Enddatum beim nächsten App-Start ab. Mehr unter Verhalten der Notfall-Freischaltung.

Fella leitet App-Traffic nicht über ein VPN oder einen Proxy. Seine Aufgabe ist es, den Zugriff auf ausgewählte iPhone-Apps über Apples Bildschirmzeit-Frameworks einzuschränken. Deshalb hängt die App-Sperre nicht von einer aktiven Datenverbindung oder einem Remote-Filter-Server ab.

Netzwerk-Filter lösen ein anderes Problem. VPN- oder DNS-basierte Tools sind oft darauf ausgelegt, Websites und Netzwerkanfragen zu filtern. Manche können auch nützliches Offline-Verhalten behalten. Fella behauptet nicht, dass jeder VPN-Blocker ohne Internet versagt; es erklärt, dass Fellas eigener App-Blockier-Pfad kein VPN nutzt.

Offline-App-Sperre ist nicht Offline-Web-Filterung. Fella sperrt ausgewählte Apps. Es behauptet nicht, jede Website, Verbindung oder jedes Internet-Element offline zu blockieren. Die dedizierte No-VPN-Seite wird den breiteren Vergleich der Durchsetzungsmethoden übernehmen, wenn diese Seite erscheint.

Deine native Auswahl blockierter Apps wird durch Apples opake Bildschirmzeit-Tokens abgebildet. Fella speichert diese Tokens in der lokalen App Group, die von App und Sperr-Erweiterungen genutzt wird. Die Tokens aus Apples Picker werden nicht als Analyse-Eigenschaften gesendet.

Fella ist keine komplett offline App. Die Produktions-App nutzt RevenueCat für Abos, optionale Account-Dienste für Authentifizierung und unterstützte Synchronisierung, PostHog für Produkt-Analysen und Sentry für Diagnosen. Diese Dienste können ihre dokumentierten Daten senden, wenn eine Verbindung verfügbar ist.

Lies die kompletten Grenzen, bevor du dich entscheidest. Sieh die Datenschutzerklärung für das vollständige Datenverzeichnis und wie Fella funktioniert für eine verständliche Erklärung der On-Device-Sperre.

Deine Internetverbindung sollte nicht das sein, was die Sperre am Leben hält. Fellas Kern-Regel wird von iOS auf dem Telefon angewendet, daher entfernt ein Bahntunnel, ein Funkloch, ein deaktivierter Datentarif oder ein bewusster Wechsel in den Flugmodus keine bereits aktive App-Sperre.

Fella passt, wenn App-Zugriff das Problem ist. Es ist kein VPN, kein Website-Filter und kein Remote-Monitoring-Dienst. Es ist ein iPhone App-Blocker für mehr Fokus: lokale Sperren ausgewählter Apps, manuelle Sitzungen, geplante Routinen und kontrollierter Notfall-Zugriff.