Install Fella, grant Apple's Screen Time permission, choose the apps that distract you, and start blocking. No Fella username, password, or mandatory login stands between you and the block.
No. A Fella account is not required for the core app-blocking flow. You can complete onboarding, choose the apps you want to restrict, purchase Fella+, and start a session without creating a Fella profile or signing in.
There is no required Fella email or password field. You also do not need to use Sign in with Apple or Google login. Optional account features may still be offered, but they are separate from setting up the blocker itself.
Your Apple Account is different. Apple still uses the Apple Account signed in to the App Store to process a subscription and help determine whether a purchase is eligible to be restored. That is not a Fella account.
| Step | What you do |
|---|---|
| 1 | Download and open Fella |
| 2 | Complete the short product introduction |
| 3 | Grant Apple's Screen Time authorization |
| 4 | Choose the apps or categories you want to block |
| 5 | Select a Fella+ plan through the App Store |
| 6 | Start a session or create a scheduled routine |
The job is app blocking, not profile building. Fella does not need a social identity, cloud dashboard, or another set of credentials before it can tell iOS which selected apps to restrict. See the full Fella blocking flow, including sessions, routines, and Emergency Unlock.
| Identity or data | Required for core blocking? | What it is used for |
|---|---|---|
| Fella username or profile | No | Optional connected account features, if you choose to use them |
| Fella password | No | Not required for onboarding, purchase, or blocking |
| Apple Account | For App Store purchases | Apple processes the subscription and provides receipt information |
| RevenueCat app-user identifier | For subscription management | Connects purchase and entitlement records without acting as a Fella login |
| Analytics and diagnostics identifiers | Used by the app | Help measure product use and diagnose reliability; they are not a Fella profile |
| Support email | No | Provided only if you contact support or choose an account flow |
| Selected-app tokens | For blocking selected apps | Stored in Fella's local shared app container for the app and its extensions |
These are different kinds of identity. A subscription system needs a technical way to recognize paid access. Analytics and diagnostics also use technical identifiers. Neither requires you to invent a Fella username, remember a password, or maintain a public profile.
No-account is not the same as no data collection. Fella uses RevenueCat for subscriptions, PostHog for product analytics, and Sentry for diagnostics. Read the full Privacy Policy and the plain-language privacy philosophy for the broader data picture.
Fella uses Apple's native Screen Time picker. When you choose apps or categories, iOS represents them with system tokens rather than handing Fella a simple behavioral profile. Fella stores those tokens in its local App Group so the main app and blocking extensions can apply the same restriction.
The tokens are part of the blocking rule, not an analytics payload. Fella does not send the selected-app tokens as PostHog analytics properties. The system can apply a shield to the selected apps without Fella building an email-linked list of everything you chose.
Screen Time permission is still required. Accountless does not mean permissionless. You must approve Apple's Screen Time authorization before Fella can restrict apps on your iPhone.
Apple handles payment; RevenueCat handles entitlement status. Fella does not receive your full card number or Apple Account password. Apple completes the App Store transaction, while RevenueCat provides the app with the information needed to decide whether Fella+ is active.
The purchase still has an app-user identifier. That identifier lets subscription infrastructure associate a transaction with app access. It is a technical record, not a Fella email-and-password account.
Restore Purchases is built in. Fella can ask Apple and RevenueCat to recover an eligible entitlement. Restoration depends on the relevant Apple Account, App Store receipt eligibility, connectivity, and third-party service availability; it is not a password-reset flow.
Restoring Fella+ does not automatically promise to restore every local choice. Your subscription entitlement, selected apps, routines, settings, and progress are different data. Restore Purchases is designed to recover eligible paid access; it should not be read as a guarantee that every local configuration will return after deleting the app or moving to a new iPhone.
Plan to recreate local setup when necessary. Without relying on an account-based cloud profile, a reinstall or new device may require you to grant Screen Time permission again, reselect apps, and rebuild routines. That is the practical tradeoff behind a lighter account footprint.
| Decision | No-account approach | Account-based approach |
|---|---|---|
| Onboarding | No profile or login before the core task | Usually includes registration or sign-in |
| Credentials | No extra username or password to maintain | Can support password or SSO recovery |
| Cloud recovery | Local setup may need to be recreated | Can restore configuration when the service supports it |
| Cross-device features | Fewer identity-linked features by default | Can make sync, dashboards, and shared management easier |
| Purchase restoration | Can use App Store purchase restoration | May combine App Store restoration with an app account |
Accounts are not automatically bad for privacy. They can provide useful backup, cross-device sync, family management, web dashboards, and support recovery. The right choice depends on whether you value those services more than skipping registration.
Fella fits the simpler job. It is for self-managed iPhone blocking: choose distracting apps, start a session yourself or use a scheduled routine, and get one five-minute Emergency Unlock per active session before Fella blocks them again.
Choose Fella if you want to start quickly and do not need another profile. It suits people who want fewer credentials, no mandatory registration, self-managed iPhone blocking, and a focused product instead of a cloud dashboard.
Choose something else if account features are the point. A service built around cross-platform sync, family or organization management, a web dashboard, or guaranteed account-based configuration recovery may be a better fit. Fella's iPhone app blocker is deliberately narrower.
No. You can complete the current onboarding, purchase a subscription, choose apps, and start blocking without creating or signing in to a Fella account.
No email address or Fella password is required for the core app-blocking flow. You may provide an email if you contact support or choose an optional account feature.
No. Neither sign-in method is required to complete the core onboarding and purchase flow.
You need an Apple Account for App Store purchase and restoration services. That Apple Account is managed by Apple and is not a Fella account.
Apple handles the transaction, and RevenueCat manages the Fella+ entitlement using an app-user identifier. This is a technical purchase identity, not a Fella username or password.
Fella includes Restore Purchases, which asks Apple and RevenueCat to recover an eligible entitlement. Restoration depends on the relevant Apple Account, receipt eligibility, connectivity, and service availability.
You can request restoration of an eligible Fella+ purchase. Local setup is separate: you may need to authorize Screen Time again, reselect apps, and recreate routines or preferences.
Fella stores Apple's privacy-preserving selection tokens in its local shared app container so its blocking extensions can apply the rule. Those tokens are not sent as analytics properties.
Yes. Fella uses product analytics and diagnostics services. No-account means no mandatory Fella login; it does not mean no technical identifiers or no data processing.
No. Apple, RevenueCat, analytics, and diagnostics can still use technical identifiers for purchases, product operation, measurement, and reliability.
