BbitbbitBook Dev Log #5 — Use Without Login: Local Mode and Authentication Design

Apple Sign-In Is Not Optional

Adding Google Sign-In meant Apple Sign-In had to come along.

App Store policy requires that any app offering third-party login (Google, Facebook, etc.) must also offer Sign in with Apple. Missing it means review rejection.

The implementation wasn't difficult. Firebase Authentication handles the flow; Swift's AuthenticationServices framework manages the Apple credential. The pattern is similar to Google Sign-In.

Users Should Be Able to Skip Login

While building the authentication flow, a concern arose.

"Some people won't use the app just because they don't want to create an account."

An app that opens to a login screen gets closed by a certain percentage of users who would have become regulars if they could have just started using it. Especially for a new, unknown app — forcing account creation before the user has seen anything of value is a conversion killer.

"I need to try it to decide if I want it, but it requires login before I can try anything."

I added a "Continue Without Login" button. All features available immediately; data stored on-device using Realm Swift.

Local Mode: Realm Swift

Logged-in users have their data in Firebase Firestore. Local users need on-device storage.

Realm Swift was the choice — familiar from other projects, well-suited to iOS local persistence.

The challenge: Firestore and Realm have different data models.

Firestore is a NoSQL document database; Realm is an object-based local database. The same "book record" concept has different storage structures in each. The app abstracts over both, routing reads and writes to the appropriate backend depending on login state.

The Unsolved Problem: Local-to-Cloud Migration

What happens when a local user decides to create an account?

Ideally, their local Realm data migrates to Firestore. The reading records they've built up shouldn't disappear.

I attempted this migration. It turned out to be more complex than anticipated.

The structural differences between Realm and Firestore models require transformation, not just copying. A failed migration could silently lose data, so the logic needed to be robust. Getting it right without introducing data loss risk in edge cases proved difficult.

I shipped without a complete solution. This remains an open problem today. When a local user logs in, their existing records are not migrated — they start fresh in the cloud. Their accumulated data stays in local storage but doesn't transfer.

This is a meaningful UX gap. It's on the list to fix. Not yet fixed.

The Strategy Works Despite the Gap

Allowing login-free use has proven worthwhile.

The natural flow: use the app without an account, decide you want cross-device sync or data backup, then create an account. The value proposition is clear by the time someone reaches the login decision.

The migration failure needs to be communicated clearly in the UX — users should know their local data won't transfer before they log in. Handling that gracefully is ongoing work.