Devlog #2: The OAuth Challenges, Supabase over Appwrite

Devlog #2: The OAuth Challenges and Why I Might Move from Appwrite to Supabase

A deep dive into mobile OAuth frustrations and lessons learned while building TaskTracker


The Setup

After wrapping up the initial design work for TaskTracker, my productivity and time tracking app, I moved on to authentication. Since this app is meant to be cross-platform and cloud-backed, I needed a reliable backend that could handle both user auth and data sync efficiently.

Appwrite looked like the perfect fit. Clean API, open source, and a modern developer experience. It was also easy to self host and I had already implemented email and password login successfully, so the next step was Google OAuth.

That was the beginning of what I now call the OAuth nightmare.

The Unexpected Problem

Everything looked fine on paper. Appwrite’s documentation mentioned that setting up OAuth for Google was as simple as calling:

account.createOAuth2Session(provider: 'google');

But in practice, nothing worked as expected. On Android, instead of showing the native Google Sign-In UI, Appwrite opened a Chrome Custom Tab. After signing in, it closed automatically and returned… nothing.

The app never received the callback, leaving users stuck and authentication incomplete.

At first, I assumed this was a configuration issue. It wasn’t.

Debugging the Mystery

The logs revealed a strange message that had nothing to do with authentication itself:

I/ImeTracker: onCancelled at PHASE_CLIENT_ALREADY_HIDDEN

That message appears when the input method (keyboard) state changes, but it was triggered every single time OAuth failed. Clearly, Appwrite’s mobile OAuth flow was not completing properly.

I spent hours experimenting with callback URLs, manifest configurations, and Appwrite console settings. I even tried community workarounds from GitHub that involved manually triggering the OAuth flow with the flutter_web_auth_2 package and then creating a session afterward.

None of it worked reliably.

Core Problems I Discovered

After countless attempts, I realized the issue was not just in my setup. It was deeper than that.

1. Mobile-first design is lacking

Appwrite’s OAuth seems to be built with web apps in mind. It restricts callback URLs to known domains, which makes sense on web but not for mobile apps that use custom URL schemes like myapp://callback.

2. Chrome Custom Tabs instead of native sign-in

On Android, OAuth opens a browser rather than using the native Google Sign-In API. This causes inconsistent session handling and disrupts the user flow.

3. Silent failures with no helpful errors

The flow fails quietly. There are no error messages or codes that point to what went wrong.

4. Documentation gaps

The documentation doesn’t cover mobile-specific edge cases or known issues. Most of what I learned came from trial, error, and GitHub discussions.

5. Reliance on workarounds

When the community has to invent multi-step hacks just to make OAuth work, it is a clear sign that the system isn’t mobile-ready yet.

Why I Started Looking at Supabase

After spending days debugging something that should have taken an hour, I started looking into alternatives. Supabase quickly stood out as a strong option.

Here’s why it caught my attention:

  • It’s built on PostgreSQL, which means reliable data integrity and advanced query capabilities.

  • It has great documentation for mobile and Flutter OAuth, including deep linking setup examples.

  • It has native OAuth support using google_sign_in package for Flutter.  

  • The community support is active and responsive.

  • Row Level Security (RLS) offers flexible and powerful permission management.

  • Edge Functions are modern, TypeScript-friendly, and easy to deploy.

  • The pricing is simple and transparent.

  • I can Self-Host and Migrate to self-hosted easily after building on their clouds.

In short, Supabase kind of solved my wanting to have native OAuth support, and it seems to have greater support for mobile.

What I Learned

This experience taught me a few important lessons:

  1. Always test your critical features early. OAuth and authentication are not optional features, they are the foundation of the app.

  2. Don’t rely solely on documentation. Test on real devices, not just simulators.

  3. If something feels too complicated, it might actually be a limitation of the tool, not your code.

My Next Step

I plan to create a proof-of-concept Supabase integration for TaskTracker. The goal is to replicate the same authentication flow and see if it works seamlessly across Android and iOS.

If Supabase delivers a smoother experience, I’ll start migrating the project entirely. That includes:

  • Exporting and migrating Appwrite data to PostgreSQL

  • Switching to Supabase Auth

  • Rebuilding real-time sync features

  • Moving file storage and server functions to Supabase services

It’s not a small effort, but at this point, reliability matters more than convenience.

Conclusion

Appwrite is promising, but it’s not ready for production-level mobile apps that depend on OAuth. The lack of native support and limited error handling make it difficult to build a stable user experience.

Supabase feels more mature, mobile-friendly, and transparent. If my next experiment works as expected, TaskTracker will be powered by Supabase moving forward.

Comments

Post a Comment

Popular Posts