Block apps even with
no signal
Fella uses Apple’s native Screen Time controls. An active block doesn’t rely on Wi-Fi, mobile data, a VPN or a server staying reachable — handy on the Tube or in a not-spot.
Block apps even with
Does Fella work offline?
Yes — core blocking works offline once set up on your iPhone. Switching off Wi-Fi or mobile data doesn’t remove an active shield. Previously registered schedules still fire via DeviceActivity. Manual sessions and Emergency Unlock use local Screen Time APIs when the handset already recognises your entitlement.
That doesn’t mean every part of Fella is fully offline. Buying or restoring a subscription, refreshing account/entitlement without a usable cache, downloading updates and sending analytics all need a network. Offline refers to enforcement — not billing or account services.
| Feature | Works offline? | What the current build does |
|---|---|---|
| Existing active block | Yes | Managed Settings keeps chosen apps shielded on device |
| Wi-Fi/mobile off mid-session | Yes | Active source, dates, selection tokens and shield state are local |
| New manual session | Yes, when set up and entitled | Registers a local DeviceActivity timer and shield; entitlement must be cached |
| Previously configured schedule | Yes | DeviceActivity extension starts/ends windows without calling Fella servers |
| Create/change a schedule | Yes, when set up | Schedule and selection stored locally and registered with DeviceActivity |
| Emergency Unlock | Yes, when eligible | Local state lifts shield for 5 minutes; on-device callback reapplies |
| App relaunch | Core block: yes | Rebuilds truth from local App Group and reapplies shield; entitlement must be cached |
| Subscription purchase | No | Apple and RevenueCat must complete the transaction |
| Restore Purchases | No | RevenueCat and App Store receipt services involved |
| Fresh entitlement/account sync | No | Remote state needs connection when not cached |
| Analytics upload | No | Events reach PostHog when back online; extension counters stored locally first |
| App Store download/update | No | App Store needs a network |
What works without internet
Device restart isn’t listed as guaranteed offline. The build rebuilds shields from shared local state at launch, and DeviceActivity schedules are system-managed. But no handset was available for a restart-in-Aeroplane-Mode test, so that sequence isn’t promised.
Blocking, local state and online services are separate layers
1. Enforcement happens on iPhone. Fella asks FamilyControls for permission, receives privacy-preserving tokens for chosen apps/categories and hands them to Managed Settings, which applies the system shield.
2. Session and schedule state is stored locally. Manual start/end times, active sources, routines, activity names and Emergency Unlock timing live in the shared App Group. App and extensions agree without checking a Fella server.
3. Subscription, account and analytics use the network. RevenueCat handles products, purchases, restores and entitlement refreshes. Authentication uses Fella’s account service when used. PostHog receives analytics. None keep an already-active shield on screen.
What happens when signal drops mid-block
The block stays active. Switching off Wi-Fi, disabling mobile data or switching on Aeroplane Mode doesn’t remove the Managed Settings shield. It isn’t enforced by repeatedly asking a remote server.
The session still has a local end time. Fella persists manual dates and registers DeviceActivity callbacks as a backstop. Loss of signal doesn’t rewrite state or deactivate the source.
Aeroplane Mode isn’t an offline bypass. Current architecture has no network dependency in shield, schedule-monitor or emergency-relock paths. Code-level and automated-test evidence, not a live handset Aeroplane Mode test.
Can you start a new block whilst offline?
Yes, with an already-configured and entitled install. Starting a manual session registers start/end with DeviceActivity, writes dates to shared local storage, marks the manual source active and applies the shield. No Fella backend call.
The subscription check is the boundary. Fella checks the paid entitlement before starting. RevenueCat caches customer info on device and Fella keeps last known active state if refresh fails. Without a usable cache — before a first purchase — it can’t establish entitlement offline.
App selection and Screen Time permission must already exist. The system picker and authorisation belong to iOS. This page doesn’t promise that first-time setup, purchase or account recovery work without a connection.
Scheduled blocks run on device
Fella registers routine schedules with DeviceActivity. When a registered interval begins, iOS runs Fella’s monitor extension. It activates the matching source and applies the shield from shared local state. When it ends, it removes the source and reconciles any overlap.
The main app doesn’t need to be open. That’s the point of a DeviceActivity monitor extension. Its start/end callbacks contain no RevenueCat, PostHog, Supabase, URLSession or other network client.
Offline doesn’t mean immune to every system change. Revoking Screen Time permission, changing device settings or removing authorisation is distinct from losing the internet. See how Fella sessions and routines work.
Emergency Unlock also uses local state
The unlock itself doesn’t need a server response. When eligible, Fella stores the 5-minute start/end locally, lifts the shield and schedules a DeviceActivity callback for the window end. The monitor reapplies the current rule even if the main app isn’t running.
Paid entitlement still must be recognised on device. The app checks subscription state before granting Emergency Unlock. An existing cached entitlement can survive a failed refresh; a missing or first-time entitlement cannot be created offline.
The relock has two local paths. The system extension is the background path. If that callback is delayed, Fella also reconciles the locally stored end time next time the app runs. Learn more about Emergency Unlock.
Native shielding is different from network filtering
Fella doesn’t route app traffic through a VPN or proxy. Its job is to restrict access to chosen iPhone apps through Apple’s Screen Time frameworks. That’s why the shield doesn’t need an active data connection or remote filtering server.
Network filters solve a different problem. VPN or DNS tools are often built to filter websites and requests. Some can retain useful offline behaviour too. Fella isn’t claiming every VPN blocker fails without internet; it’s explaining its own app-blocking path doesn’t use one.
Offline app blocking isn’t offline web filtering. Fella blocks chosen apps. It doesn’t claim to block every website or piece of internet content whilst offline.
What stays local — and what doesn’t
Your blocked-app selection is represented by Apple’s opaque Screen Time tokens. Fella stores those tokens in the local App Group used by the app and its extensions. The tokens from Apple’s picker are not sent as analytics properties.
Fella isn’t an entirely offline app. The production app uses RevenueCat for subscriptions, optional account services, PostHog for analytics and Sentry for diagnostics. Those services may send their documented data when a connection is available.
Read the complete boundaries before deciding. See the Privacy Policy and Fella’s privacy philosophy for the full inventory and plain-English explanation of on-device blocking.
A blocker shouldn’t disappear with your Wi-Fi
Your internet connection shouldn’t be what keeps the block alive. Fella’s core rule is applied by iOS on the handset, so a Tube tunnel, not-spot, disabled data plan or deliberate switch to Aeroplane Mode doesn’t remove an already-active shield.
Fella fits when app access is the problem. It isn’t a VPN, website filter or remote monitoring service. It’s an iPhone app blocker built around local app restrictions, manual sessions, scheduled routines and controlled emergency access.
7-day free trial
Fella, up close.
- Built with Apple’s Screen Time controls.
- One 5-minute emergency unlock per session.
- Apps stay blocked by default.
Offline app blocking FAQ
Yes. Once set up and with a cached entitlement, core blocking does not need Wi-Fi. Active shields, registered schedules, timing and Emergency Unlock are handled through Screen Time and local storage.
Yes. Switching off mobile data does not remove an active shield or stop a registered schedule. Purchases, restores, account sync and analytics still need a connection.
Aeroplane Mode does not remove locally-applied Screen Time restrictions. Based on on-device architecture and automated tests, not a live handset test.
Core blocking does not. Managed Settings applies the shield on device, DeviceActivity runs callbacks. Billing, account sync and analytics remain network services.
No. Fella uses FamilyControls, ManagedSettings and DeviceActivity rather than routing traffic through a Fella VPN.
Previously registered schedules are started and ended by the DeviceActivity system extension. It reads locally persisted state and has no network client.
Yes, for an active local session when the device already recognises a valid entitlement. Fella stores the 5-minute window locally and registers an on-device callback to reapply.
Yes on an already set-up handset when Screen Time permission, app selection and entitlement are available locally. A first purchase or uncached check still needs internet.
RevenueCat handles products, purchases, restores and entitlement refreshes. Those can need internet. Fella keeps the last known state if refresh fails, but a first purchase without a cache cannot complete offline.
The native Screen Time picker returns privacy-preserving tokens. Fella stores them in its local App Group for the app and extensions. They are not sent as analytics.
