Fella usa os controles nativos de Tempo de Uso da Apple — como no dia a dia com WhatsApp, Instagram e Kwai de Tempo de Uso da Apple. Um bloqueio ativo não depende de Wi-Fi, dados móveis, VPN ou servidor remoto.
Yes—Fella's core blocking works offline once the app is set up on the iPhone. Turning off Wi-Fi or cellular data does not remove an active shield. Previously registered schedules still run through Apple's Device Activity system. Manual sessions and Desbloqueio de emergência use local Tempo de Uso APIs and local state when the device already recognizes your paid access.
That does not mean every part of Fella is fully offline. Buying or restoring a subscription, refreshing account or entitlement information when no usable cache exists, downloading updates, and delivering analytics all require a network. Offline blocking is a claim about enforcement—not billing, accounts, or every surrounding service.
| Feature | Works offline? | What the current implementation does |
|---|---|---|
| Existing active app block | Yes | Managed Settings keeps the selected apps shielded on the device |
| Wi-Fi or cellular switched off mid-session | Yes | The active source, session dates, selection tokens, and shield state are local |
| New manual session | Yes, when already set up and entitled | Fella registers a local Device Activity timer and applies the shield; the entitlement must be available from device cache |
| Previously configured schedule | Yes | The Device Activity extension starts and ends registered schedule windows without calling Fella's servers |
| Create or change a schedule | Yes, when already set up and entitled | The schedule and selection are stored locally and registered with Device Activity |
| Desbloqueio de emergência | Yes, when eligible | Local state lifts the shield for five minutes; an on-device callback reapplies it |
| App relaunch | Core block state: yes | Fella rebuilds its blocking truth from local App Group data and reapplies the desired shield; paid access must remain available from cache |
| Subscription purchase | No | Apple and RevenueCat must complete the transaction |
| Restore Purchases | No | RevenueCat and App Store receipt services are involved |
| Fresh entitlement or account sync | No | Remote subscription or authentication state needs a connection when it is not already cached |
| Analytics upload | No | Events can only reach PostHog when connectivity returns; extension-side counters are stored locally first |
| App Store download or update | No | The App Store requires a network connection |
Device restart is not listed as a guaranteed offline scenario. The source rebuilds shields and session truth from shared local state when Fella launches, and registered Device Activity schedules are system-managed. But no connected iPhone was available for a restart-in-Airplane-Mode test, so this page does not promise that specific sequence.
1. Blocking enforcement happens on the iPhone. Fella asks Apple's Family Controls system for permission, receives privacy-preserving tokens for the apps or categories you select, and gives those tokens to Managed Settings. Managed Settings applies the system shield.
2. Session and schedule state is stored locally. Manual start and end times, active blocking sources, routines, registered activity names, and Desbloqueio de emergência timing live in the app's shared App Group. That lets the main app and its extensions agree on the current rule without checking a Fella server.
3. Subscription, account, and analytics services use the network. RevenueCat handles products, purchases, restores, and entitlement refreshes. Authentication uses Fella's account service when an account is used. PostHog receives product analytics. None of those services is the mechanism that keeps an already active app shield on screen.
The block stays active. Switching off Wi-Fi, disabling cellular data, or enabling Airplane Mode does not remove the Managed Settings shield. The restriction is not enforced by continuously asking a remote server whether an app may open.
The session still has a local end time. Fella persists the manual session dates and registers Device Activity callbacks as a system backstop. A connection loss does not rewrite that state or deactivate the blocking source.
Airplane Mode is not an internet-off bypass. The current architecture contains no network dependency in the shield, schedule-monitor, or emergency-relock paths. This is code-level and automated-test evidence; it has not been repeated on a currently connected physical iPhone for this page.
Yes, with an already configured and entitled installation. Starting a manual session registers its start and end with Apple's Device Activity system, writes the dates into shared local storage, marks the manual blocking source active, and applies the selected-app shield. None of those actions calls a Fella backend.
The subscription check is the boundary. Fella checks paid access before starting. RevenueCat caches customer information on the device, and Fella keeps its last known active status if a refresh fails. If the app has no usable entitlement cache—such as before a first purchase—it cannot establish paid access offline.
App selection and Tempo de Uso permission must already be available. The system picker and authorization belong to iOS. This page does not promise that first-time setup, purchase, or account recovery can be completed without a connection.
Fella registers routine schedules with Device Activity. When a registered interval begins, iOS runs Fella's monitor extension. The extension activates the matching blocking source and applies the shield from shared local state. When the interval ends, it removes that source and reconciles any overlapping block.
The main app does not have to be open. That is the point of using a Device Activity monitor extension. Its start and end callbacks contain no RevenueCat, PostHog, Supabase, URLSession, or other network client.
Offline does not mean immune to every system change. Revoking Tempo de Uso permission, changing device settings, or removing required authorization is a different issue from losing internet connectivity. See how Fella's sessions and routines work.
The unlock itself does not need a server response. When eligible, Fella stores the five-minute start and end locally, temporarily removes the shield, and schedules a Device Activity callback for the end of the window. The monitor extension then reapplies the current blocking rule even if the main app is not running.
Paid access still has to be recognized on the device. The app checks subscription state before granting Desbloqueio de emergência. 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 or scheduling fails, Fella also reconciles the locally stored end time the next time the app runs. Learn more about Desbloqueio de emergência behavior.
Fella does not route app traffic through a VPN or proxy. Its job is to restrict access to selected iPhone apps through Apple's Tempo de Uso frameworks. That is why the app shield does not depend on an active data connection or a remote filtering server.
Network filters solve a different problem. VPN- or DNS-based tools are often designed to filter websites and network requests. Some can retain useful offline behavior too. Fella is not claiming that every VPN blocker fails without internet; it is explaining that Fella's own app-blocking path does not use one.
Offline app blocking is not offline web filtering. Fella blocks selected apps. It does not claim to block every website, connection, or piece of internet content while offline. The dedicated no-VPN page will own the broader enforcement-method comparison when that page is published.
Your native blocked-app selection is represented by Apple's opaque Tempo de Uso tokens. Fella stores those tokens in the local App Group used by the app and its blocking extensions. The tokens from Apple's picker are not sent as analytics properties.
Fella is not an entirely offline application. The production app uses RevenueCat for subscriptions, optional account services for authentication and supported synchronization, PostHog for product analytics, and Sentry for diagnostics. Those services can send their documented data when a connection is available.
Read the complete boundaries before deciding. See the Privacy Policy for the full data inventory and Fella's privacy philosophy for a plain-language explanation of on-device blocking.
Your internet connection should not be what keeps the block alive. Fella's core rule is applied by iOS on the phone, so a train tunnel, dead zone, disabled data plan, or deliberate switch to Airplane Mode does not remove an already active app shield.
Fella is a fit when app access is the problem. It is not a VPN, website filter, or remote monitoring service. It is an iPhone app blocker built around local selected-app restrictions, manual sessions, scheduled routines, and controlled emergency access.
Yes. After Fella is set up and paid access is available on the device, core app-blocking rules do not need Wi-Fi. Active shields, registered schedules, session timing, and Desbloqueio de emergência state are handled through Apple's Tempo de Uso frameworks and local storage.
Yes. Turning off cellular data does not remove an active Fella app shield or stop a previously registered schedule. Purchases, restores, account synchronization, and analytics delivery still need a connection.
Airplane Mode does not remove Fella's locally applied Tempo de Uso restrictions. This is verified from Fella's on-device architecture and automated tests, not from a current real-device Airplane Mode test.
Fella's core blocking does not. Managed Settings applies the app shield on the device, while Device Activity runs registered session and schedule callbacks. Billing, account synchronization, and analytics remain network services.
No. Fella applies app restrictions through Apple's Family Controls, Managed Settings, and Device Activity frameworks rather than routing traffic through a Fella VPN.
Previously registered schedules are started and ended by Apple's Device Activity system extension. The extension reads locally persisted state and contains no network client.
Yes, for an active local session when the device already recognizes paid access. Fella stores the five-minute window locally and registers an on-device callback to reapply the block.
Yes on an already set-up installation when Tempo de Uso permission, app selection, and paid entitlement are available locally. A first purchase or missing entitlement cache still requires internet.
RevenueCat handles subscription products, purchases, restores, and entitlement refreshes. Those operations can require internet. Fella preserves the last known subscription state when a refresh fails, but a first purchase or missing cache cannot be completed offline.
The native Tempo de Uso picker returns privacy-preserving tokens. Fella stores them in its local App Group for the app and blocking extensions, and does not send those tokens as analytics properties.
