Wie funktionieren App-Blocker?

Ein App-Blocker funktioniert, indem er sich zwischen dich und die App stellt, die du zu öffnen versuchst, und dabei nutzt, welchen Zugriff das Betriebssystem ihm gewährt, um den Start dieser App entweder zu verhindern oder ihn etwas kosten zu lassen, bevor sie startet. Auf iOS läuft dieser Zugriff fast ausschließlich über Apples eigenes Screen-Time-Framework — Drittanbieter-Apps dürfen keine anderen Prozesse still beenden, also ist alles, was sich auf einem iPhone „Blocker“ nennt, im Grunde nur eine Oberfläche für dieselben App-Limits und Kommunikationslimits, die Apple bereits mitliefert. Auf Android ist das Betriebssystem großzügiger: Eine App kann Bedienungshilfen- oder Nutzungszugriff-Berechtigungen anfordern und damit erkennen, wenn eine blockierte App in den Vordergrund kommt, um sie sofort mit einem eigenen Bildschirm zu überdecken. Der Mechanismus unterscheidet sich je nach Plattform, aber das Ziel ist identisch — den Öffnungsversuch abfangen und entscheiden, was als Nächstes passiert.

Die beiden Mechanismen — und warum sie sich unterschiedlich verhalten

Auf iOS beantragt ein Drittanbieter-Blocker in der Regel eine Family-Controls-/Screen-Time-Autorisierung, mit der er über Apples ManagedSettings-Framework eine Liste von Apps als „eingeschränkt“ registrieren kann. Wenn du auf eine eingeschränkte App tippst, fängt iOS selbst — nicht die Drittanbieter-App — den Start ab und zeigt einen Screen-Time-Sperrbildschirm, denn der Drittanbieter-Entwickler hat nie tatsächlich Zugriff auf die Daten oder Prozesse deiner anderen Apps; er kann das Betriebssystem nur bitten, sie zu markieren. Das erklärt auch, warum sich iOS-Blocker in ihrem Verhalten relativ ähnlich sind: Sie sind alle nur Hüllen um dasselbe zugrunde liegende System. Auf Android nutzt ein Blocker in der Regel die Bedienungshilfen-API (eigentlich für Screenreader gedacht) oder die Nutzungsstatistik-API, um zu beobachten, welche App gerade im Vordergrund ist, und wenn er einen blockierten Paketnamen erkennt, legt er ein Overlay darüber, bevor du mit der App darunter interagieren kannst. Das verschafft Android-Blockern mehr Flexibilität — reichhaltigere Overlays, individuelle Entsperr-Abläufe wie ein Quiz —, aber auch mehr Zerbrechlichkeit, denn Bedienungshilfen-Berechtigungen lassen sich in den Einstellungen genau von der Person widerrufen, die der Blocker eigentlich aufhalten soll. Diese Aufteilung erklärt auch eine verbreitete Beschwerde speziell über iOS-Blocker — dass viele von ihnen sich trotz unterschiedlicher Hersteller ziemlich ähnlich anfühlen —, denn sie sind alle durch dieselbe begrenzte Auswahl an Anknüpfungspunkten eingeschränkt, die Apple bereitstellt, statt jeweils einen wirklich eigenständigen Blockiermechanismus von Grund auf zu bauen.

Was tatsächlich entscheidet, ob eine Sperre hält

Die Stärke eines jeden App-Blockers hängt letztlich von einer Frage ab: Wer kontrolliert den Ausschalter? Ein Blocker, der komplett innerhalb desselben Kontos wie die Person läuft, die er blockiert — kein separater Code, kein zweites Gerät, keine andere Person, die den Schlüssel hält —, ist mechanisch gesehen immer von genau dieser Person rückgängig zu machen, denn das Betriebssystem muss zulassen, dass die eigenen Einstellungen einer App von der Person geändert werden können, die das Handy gerade benutzt. Apples Screen Time zeigt das am deutlichsten: Ohne separaten Screen-Time-Code lassen sich App-Limits in den Einstellungen in unter dreißig Sekunden von genau der Person ausschalten, die sie eigentlich einschränken sollen. Kommt ein Code hinzu, den eine andere Person hält — das Eltern-Kind-Family-Sharing-Setup, um das Screen Time herum gebaut ist —, ändert sich an der Mechanik nichts, aber es ändert sich, wer die Sperre aufheben kann, und genau das ist der gesamte Unterschied zwischen einer Einschränkung und einer bloßen Empfehlung. Das ist auch der Grund, warum „Wie stark ist dieser Blocker“ eine leicht irreführende Frage ist; das Framework unter den meisten Blockern einer bestimmten Plattform ist weitgehend dasselbe. Was variiert, ist, was zwischen der Sperre und dem Tap steht, der sie aufheben würde — nichts, ein Countdown, ein eingetippter Code oder etwas, das echten Aufwand erfordert. Es lohnt sich, klarzustellen, dass das kein Fehler einer bestimmten App ist; es ist eine strukturelle Eigenschaft jedes Werkzeugs, das auf einem Gerät läuft, das dieselbe Person sowohl besitzt als auch einzuschränken versucht — das gilt im Grunde für jeden Verbraucher-App-Blocker auf dem Markt, nicht nur für die schwächeren.

Wo Reibung in den Mechanismus passt

Weil der zugrunde liegende Sperren-oder-nicht-Mechanismus weitgehend vom Betriebssystem vorgegeben ist, liegt die eigentlich bedeutsame Design-Entscheidung der meisten Blocker darin, was im Moment des Entsperrens passiert. Eine timerbasierte Entsperrung (fünf Minuten warten) fügt Verzögerung, aber keinen Aufwand hinzu. Eine Code-Entsperrung (einen Code von einem anderen Gerät holen) fügt eine kleine logistische Hürde hinzu. Eine Entsperrung mit kognitivem Aufwand — eine echte Frage beantworten, eine Reihe Liegestütze machen, verifiziert vom Bewegungssensor des Handys — kommt eher dem Unbehagen der Aufgabe nahe, die man eigentlich vermeiden wollte, was eine spürbar andere Art von Reibung ist als bloßes Warten. Nichts davon ändert, ob sich die zugrunde liegende Betriebssystem-Berechtigung technisch widerrufen lässt; es ändert, wie sehr die widerrufende Person es in genau diesem Moment wirklich wollen muss — und das behandeln Verhaltensforscher, die zwanghafte Handynutzung untersuchen (in der Fachliteratur manchmal „problematische Smartphone-Nutzung“ genannt, da es keine formale DSM-5-Diagnose für Handysucht gibt), generell als den relevanteren Hebel gegenüber der reinen Sperrstärke, denn Willenskraft schwankt, ein gleichbleibender Preis dagegen nicht. Es lohnt sich auch festzuhalten, dass Reibung und harte technische Einschränkung keine konkurrierenden Ansätze sind, sondern eher auf einem Spektrum liegen — eine geplante Auszeit ohne Code ist auf beiden Achsen schwach, ein codegeschütztes Limit ist auf der technischen Achse stark, bietet aber keine Reibung, wenn der Code bekannt ist, und eine quizbasierte Entsperrung ist auf der technischen Achse vergleichsweise schwach (nichts hindert dich daran, die App komplett zu deinstallieren), aber stark darin, aktives, aufwändiges Engagement genau in dem Moment zu verlangen, in dem es zählt.

Wo Mr. Grummel ins Bild passt

Mr. Grummel nutzt die aufwandsbasierte Version dieses Mechanismus: Statt eines Timers oder eines eingetippten Codes bedeutet das Vorbeikommen an einer Sperre, eine echte Quizfrage richtig zu beantworten. Er versucht nicht, eine technisch härtere Sperre zu sein, als das Betriebssystem erlaubt — das ist ohne eine zweite Person, die einen Code hält, keine App vollständig —, sondern ist darauf ausgelegt, die kognitiven Kosten genau in dem Moment zu erhöhen, in dem man sonst einfach durchtippen würde. Diese Design-Entscheidung spiegelt eine bestimmte Wette wider: dass das Problem für die meisten Menschen, die meiste Zeit, nicht eine technisch unknackbare Sperre ist, die gebraucht wird, sondern ein kostenloser Ausweg, der zu leicht zu greifen ist.