Scroll Brake: Wie ich einen 4-MB-iOS-Blocker gegen Doomscrolling gebaut habe

Wie der Kampf gegen Dopamin-Schleifen zu Scroll Brake führte, warum bekannte Konkurrenten fragwürdige Berechtigungen fordern und wie man die Tücken von Apples Screen Time API meistert.

Die 45-Minuten-Falle

Ich lege extrem viel Wert auf persönliche Produktivität. Über die Jahre habe ich ein eigenes System für Zeit- und Energiemanagement aufgebaut, das meinen Arbeitstag strukturiert und dafür sorgt, dass anspruchsvolle Softwareprojekte zuverlässig fertiggestellt werden.

Trotzdem gibt es diese Momente: Man greift völlig automatisch zum Smartphone und verfällt ins Doomscrolling auf Instagram Reels. Ein kurzes Video, ein zweites, ein drittes — der Algorithmus liefert pausenlos neue Reize. Eigentlich wollte man nur zwei Minuten durchatmen, und plötzlich sind 40 Minuten oder eine ganze Stunde spurlos verflogen. Empfehlungs-Algorithmen sozialer Netzwerke wurden von Top-Ingenieuren genau dafür optimiert: menschliche Aufmerksamkeit um jeden Preis zu binden. Jeder Swipe fühlt sich noch ein bisschen lohnender an als der vorherige und hält das Gehirn in einer endlosen Dopaminschleife fest.

Ich hatte ursprünglich überhaupt nicht vor, eine eigene App zu schreiben. Als Softwareentwickler und Gründer ist meine Zeit knapp, und ich greife am liebsten zu bewährten Werkzeugen. Also suchte ich direkt im App Store.

Was bei modernen App-Blockern schiefläuft

Ich habe die bekanntesten Apps der Kategorie getestet — Opal, OneSec, ScreenZen, Refocus sowie Apples integrierte Bildschirmzeit. Schnell stieß ich dabei auf architektonische und UX-Entscheidungen, die mich stutzig machten:

Das Paradox der Push-Benachrichtigungen

Nahezu jede dieser Apps verlangt als Allererstes die Berechtigung für Push-Benachrichtigungen und Tracking. Warum sollte ein Werkzeug, das mich vom Smartphone wegholen soll, mein Display ständig mit Bannern aufwecken? Wie sich später bei der Entwicklung herausstellte, lag das nicht an böser Absicht der Entwickler, sondern an einer historischen Systembeschränkung von iOS, auf die ich weiter unten im technischen Teil detailliert eingehe.

Aggressive Paywalls und Abo-Müdigkeit

Noch bevor man die Benutzeroberfläche sieht oder prüfen kann, ob die App das Problem überhaupt löst, landet man auf einer aufdringlichen Bezahlseite. Verpackt in ein „kostenloses Probeabo“, das vor allem darauf spekuliert, dass der Nutzer die Kündigung vergisst. Als Unternehmer kenne ich die Conversion-Mechanismen; als Nutzer empfinde ich solche Dark Patterns als störend.

Die Wirkungslosigkeit von Apples Standard-Bildschirmzeit

Apples native Bildschirmzeit scheitert an der menschlichen Psychologie. Wenn das Sperr-Overlay erscheint, tippt der Daumen rein reflexartig auf „Limit für 15 Minuten ignorieren“. Es gibt keinerlei kognitive Hürde — die Handlung läuft komplett über das Muskelgedächtnis.

Ich hatte keine Lust, Dutzende ähnlicher Apps mit identischen Abo-Preisen zu vergleichen. Mir wurde klar: Eine schlanke, native Lösung selbst zu bauen, ging schneller und war schlicht ehrlicher.

Die Prinzipien von Scroll Brake: 4 MB, keine Tracker, kein Abo

Bei NovaSynapse gilt für uns der Grundsatz: „Alles, was du brauchst. Nichts, was du nicht brauchst.“ Gute Software löst eine konkrete Aufgabe, schont den Akku und respektiert die Grenzen des Nutzers.

Aus diesem Ansatz heraus entstand Scroll Brake:

• Rund 4 MB Installationsgröße: Keine aufgeblähten Cross-Platform-Frameworks, keine WebViews, null externe Tracking-SDKs.
• 100 % Privacy-First: Keine Konten, keine Datenbank, keine Server im Hintergrund. Alles läuft vollständig lokal auf dem Gerät über die nativen iOS-APIs.
• Kognitive Barriere statt sturer Verbote: Um die Nutzungszeit in einer gesperrten App zu verlängern, muss der präfrontale Kortex aktiviert werden — durch das Lösen einer kurzen Matheaufgabe. Diese eine Sekunde bewusster Anstrengung durchbricht den Autopiloten zuverlässig.
• Anti-Dopamin-Design statt Gamification: Nach dem Lösen der Aufgabe gibt es bewusst kein Konfetti, kein Feuerwerk und keine motivierenden Glückwünsche. Das Gehirn mit billigem Dopamin dafür zu belohnen, dass man Social Media öffnet, wäre absurd. Der Bildschirm bleibt bewusst nüchtern und ruhig. Die Zeit wird freigeschaltet, und der Rückweg erfolgt über den Standard-Back-Button von iOS oben links (aus Datenschutzgründen verbietet Apple der Host-App zu wissen, welche Ziel-App gesperrt wurde, weshalb eine automatische Rückleitung unmöglich ist).
• Faire Monetarisierung: Bis zu 3 Regeln sind dauerhaft kostenlos (ich selbst nutze im Alltag nur eine einzige: Kategorie „Soziale Netze“ auf 5 Minuten pro Tag begrenzt). Wer mehr Regeln braucht, zahlt einmalig für eine Lifetime-Lizenz statt in ein Dauer-Abo gedrängt zu werden.

In 4 Tagen gebaut: KI und Xcode-Tools

Ich habe die App mithilfe von KI-Assistenten entwickelt — konkret mit Antigravity und den Modellen Gemini 3.1 Pro und Flash.

Ich hatte bereits Erfahrung in der mobilen Entwicklung mit Flutter und nativem iOS, allerdings noch aus der Zeit vor modernen KI-Coding-Assistenten. Mit KI ließ sich ein so fokussiertes, kompaktes Projekt bemerkenswert zügig umsetzen. Natürlich kann man generierten Code nicht blind übernehmen: Apples System-Erweiterungen reagieren extrem empfindlich auf kleinste Fehler, weshalb ich jede Zeile selbst geprüft habe, um Abstürze und Speicherlecks auszuschließen. Insgesamt dauerte die Entwicklung inklusive manueller Tests auf echten Geräten und älteren iOS-Versionen gerade einmal 3 bis 4 Arbeitstage:

• Icon in 15 Minuten: Statt dutzende PNG-Ebenen manuell zu exportieren, nutzte ich das Xcode-Entwicklertool Icon Composer. Die Vektorebenen passen sich automatisch an helle, dunkle und getönte iOS-Designs an.
• App Store Review in unter 24 Stunden: Da die App keinerlei Tracking-SDKs enthält und keine privaten Nutzerdaten abfragt, wurde sie von Apple direkt am nächsten Tag freigegeben.

Technischer Deep-Dive: Die Tücken der Screen Time API

Kommen wir zum spannendsten Teil: der Architektur rund um das Trio aus ManagedSettings, DeviceActivity und FamilyControls. Wer mit Apples Screen Time API arbeitet, stößt früher oder später auf drei handfeste systemische Hürden. So habe ich sie gelöst:

Warum Mitbewerber Push-Benachrichtigungen erzwingen (iOS < 26.5 vs. iOS 26.5+)

Nutzer beschweren sich regelmäßig über Benachrichtigungs-Spam bei App-Blockern. Doch Entwickler steckten lange Zeit in einer Sandbox-Falle von Apple.

• Die frühere Systembeschränkung:

Wird eine App gesperrt, blendet das System das Overlay der ShieldActionExtension ein. Tippt der Nutzer auf eine Aktion wie „Verlängern“, läuft diese Extension in einer isolierten Sandbox, in der der Aufruf von UIApplication.shared.open vom Compiler und vom System strikt untersagt ist. Das ShieldActionResponse-Enum unterstützte historisch lediglich .close, .defer und .none. Es gab schlicht keinen legalen Weg, die Haupt-App direkt zu öffnen, um dem Nutzer ein Rätsel oder eine Aufgabe zu präsentieren!

• Der Workaround der Branche:

Der einzige Ausweg bestand darin, eine lokale Push-Benachrichtigung über UNUserNotificationCenter abzufeuern. Der Nutzer musste auf das Banner tippen, um die App zu öffnen. Genau aus diesem Grund verlangt fast jeder Blocker im App Store Benachrichtigungsrechte.

• Die native Lösung ab iOS 26.5+:

Apple hat endlich den Fall ShieldActionResponse.openParentalControlsApp nachgereicht. Sobald dieser zurückgegeben wird, öffnet das System sofort die Host-App und zeigt direkt die Mathe-Aufgabe (MathPuzzleView):

  // ShieldActionExtension.swift
  defaults?.set(true, forKey: "launchedFromShieldAction")
  completionHandler(.openParentalControlsApp)

Indem ich iOS 26.5+ als Mindestanforderung definiert habe (IPHONEOSDEPLOYMENTTARGET = 26.5), konnte ich auf Push-Tricks komplett verzichten.

Die strikte Sandbox für Nutzungsanalysen

Ich werde oft gefragt: „Warum zeigt die App keine sekundengenaue Nutzungsstatistik in eigenen Diagrammen an?“

Die Antwort: Apple isoliert Screen-Time-Daten architektonisch vollständig von der Host-App.

• Der Zugriff auf das DeviceActivityResults-Array ist ausschließlich der DeviceActivityReportExtension gestattet, die in einem separaten Systemprozess ausgeführt wird.
• Die Host-App bindet lediglich einen visuellen Container ein: DeviceActivityReport. Dieser wird out-of-process gerendert und als fertiges Bild in das UI der App projiziert.
• Die Rohdaten verlassen die Sandbox der Extension nie — die Host-App kann diese Daten weder in SQLite speichern, noch serialisieren oder über das Netzwerk versenden.

In der Apple-Dokumentation heißt es dazu unmissverständlich:

„Zum Schutz der Privatsphäre der Nutzer wird die DeviceActivityReport-Erweiterung in einer Sandbox ausgeführt, und ihre Daten verlassen die Erweiterung nicht. Stattdessen erstellt und liefert die Erweiterung Ansichten, die Ihre App anzeigt.“

• Auswirkungen auf das Monitoring:

Die Überwachung von Limits über das DeviceActivityCenter basiert ausschließlich auf einem Schwellenwert-Abonnement (DeviceActivityEvent.threshold). Das System informiert die DeviceActivityMonitorExtension erst dann, wenn der Schwellenwert erreicht wurde (eventDidReachThreshold), ohne fortlaufende Telemetriedaten bereitzustellen.

• Warum die Rückkehr über die Statusleiste erfolgt:

Unter iOS hat die Host-App keinerlei Zugriff auf die bundleIdentifier der App, die den Schutzschirm ausgelöst hat. Eine App kann den Nutzer daher nicht programmatisch zurück zu Instagram oder TikTok leiten. Man tippt einfach auf den Zurück-Pfeil des Systems oben links in der Statusleiste.

Versteckte Tücken der Screen Time API überwunden

Während ausgiebiger Tests stieß ich auf subtile Plattform-Bugs in iOS, die jeden Blocker unbrauchbar machen können:

Event-Caching-Bug in DeviceActivityCenter

• Das Problem: Wurde der Schwellenwert für einen bestehenden DeviceActivityName bei einer Verlängerung aktualisiert, reagierte iOS oft nicht auf das neue Limit.
• Die Lösung: Erzeugung eines eindeutigen Aktivitätsnamens mit Session-Token DeviceActivityName("limit"), kombiniert mit einem vorherigen expliziten Aufruf von stopMonitoring().
• Apple-Dokumentation: DeviceActivityCenter.startMonitoring.

deviceActivityCenter.stopMonitoring([previousActivityName])
let newActivity = DeviceActivityName("limit_\(UUID().uuidString)_\(sessionToken)")
try deviceActivityCenter.startMonitoring(newActivity, during: schedule, events: events)

Der Reset-Fehler am Folgetag (Dual-Event-Muster)

• Das Problem: War ein DeviceActivitySchedule mit repeats: true konfiguriert und der Nutzer verlängerte seine Zeit um 1 Minute, wandte das System am nächsten Morgen fälschlicherweise denselben 1-Minuten-Schwellenwert an, statt auf das volle Tageslimit zurückzusetzen.
• Die Lösung: Registrierung zweier separater Events innerhalb eines Zeitplans:

1. mainEvent: das reguläre volle Tageslimit für den Folgetag.
2. extEvent: ein temporäres Event mit integriertem Tagesdatum im Identifier, das um 23:59 Uhr desselben Tages verfällt.

OOM-Abstürze (Code 11) in DeviceActivityReport

• Das Problem: Reaktive Timer (wie sekundengenaue SwiftUI-Zähler) innerhalb der View-Hierarchie von DeviceActivityReport führten zu pausenlosen XPC-Neuberechnungen der 7-Tage-Historie. Dies verursachte rasante Speicherlecks, woraufhin iOS den Prozess mit einem Out-Of-Memory-Fehler (Code 11) beendete.
• Die Lösung: Vollständiger Verzicht auf reaktive Timer in Ansichten mit Reports, unveränderliche Filterparameter ohne ständige Mutationen und Datenaktualisierung ausschließlich über Lebenszyklus-Events (onAppear, willEnterForeground).

Mein persönliches Setup

Seit dem Release ist Scroll Brake meine wichtigste Verteidigung gegen Ablenkung geworden.

So habe ich die App für mich eingerichtet:

• 1 Regel: Kategorie „Soziale Netze“ blockiert.
• Basis-Limit: 5 Minuten pro Tag.
• Verlängerung: 5 Minuten pro gelöster Matheaufgabe.
• Maximale Verlängerungen: Höchstens 5 Mal am Tag.

Ich kann rein rechnerisch maximal 25 Minuten pro Tag in sozialen Netzwerken verbringen. Noch wichtiger ist aber der psychologische Lerneffekt: Mein Gehirn weiß, dass jedes Anschauen eines geteilten Videos kognitive Reibung erfordert. Diese kleine Barriere reicht in 8 von 10 Fällen völlig aus, um das Smartphone wieder wegzulegen und sich auf die eigentliche Arbeit zu konzentrieren.