# The OAuth Authentication Nightmare: Why I'm Considering Moving from Appwrite to Supabase

*A developer's journey through mobile OAuth hell and the quest for better solutions*

---

## The Problem That Started It All

I was building TaskTracker, a Flutter mobile application, and decided to use Appwrite as my Backend-as-a-Service (BaaS). Everything seemed promising - great documentation, modern API, and OAuth support out of the box. What could go wrong?

**Everything.**

After successfully implementing email/password authentication, I moved on to Google OAuth for a better user experience. The implementation seemed straightforward - just call `createOAuth2Session()` and you're done, right?

Wrong.

## The Mysterious ImeTracker Error

After clicking the Google OAuth button, Chrome Custom Tabs would open (not the native Android Google Sign-In UI, which was my first red flag). I'd select my Google account, authenticate successfully, and then... nothing. The browser would close, and I'd see this cryptic error in the logs:

```
I/ImeTracker( 5434): com.Xperience.TaskTracker.tasktracker:efd1ad6a: 
onCancelled at PHASE_CLIENT_ALREADY_HIDDEN
```

The error message suggested I had cancelled the authentication, but I hadn't touched anything. The OAuth flow was completing on Google's end, but my app wasn't receiving the callback properly.

## The Troubleshooting Marathon

### Attempt #1: Explicit Callback URLs

My first thought was that the callback URLs needed to be explicitly defined. I tried specifying success and failure URLs:

```dart
await widget.account.createOAuth2Session(
  provider: provider,
  success: 'appwrite-callback-tasktracker://success',
  failure: 'appwrite-callback-tasktracker://failure',
  scopes: ['email', 'profile'],
);
```

**Result:** Even worse. I got a new error:

```
Invalid success param, URL host must be one of localhost, supab.playpoolstudios.com
```

So Appwrite's server was rejecting my custom URL scheme entirely. This made no sense for a mobile application where custom URL schemes are the standard for OAuth callbacks.

### Attempt #2: Android Manifest Configuration

Maybe the issue was with my Android configuration? I updated the `AndroidManifest.xml` to be more explicit about handling OAuth callbacks:

```xml
<intent-filter android:label="flutter_web_auth_2" android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="appwrite-callback-tasktracker" android:host="success" />
    <data android:scheme="appwrite-callback-tasktracker" android:host="failure" />
</intent-filter>
```

**Result:** Still nothing. The callback wasn't being intercepted properly.

### Attempt #3: Appwrite Console Platform Configuration

Perhaps I needed to register my Android app as a platform in the Appwrite Console? I went through the process:
- Added Android platform
- Entered package name: `com.Xperience.TaskTracker.tasktracker`
- Configured OAuth provider settings

**Result:** No improvement. The OAuth flow still failed silently.

### Attempt #4: The GitHub Workaround

After hours of searching, I found a GitHub issue with a workaround suggesting a two-step OAuth process:

```dart
// Step 1: Manually trigger OAuth with flutter_web_auth_2
final result = await FlutterWebAuth2.authenticate(
  url: '$endpoint/account/sessions/oauth2/$provider?project=$projectId',
  callbackUrlScheme: 'appwrite-callback-$projectId',
);

// Step 2: Create Appwrite session
await widget.account.createOAuth2Session(provider: provider);
```

This workaround essentially bypasses Appwrite's OAuth handling by manually triggering the web authentication, then trying to create a session afterward.

**Result:** Still testing, but the fact that such a workaround exists is telling.

## The Fundamental Issues

After all this troubleshooting, I've identified several core problems with Appwrite's mobile OAuth implementation:

### 1. **Poor Mobile-First Design**
Appwrite's OAuth is clearly designed for web applications. The restriction that callback URLs must use the server's domain (`supab.playpoolstudios.com`) makes no sense for mobile apps that need custom URL schemes like `appwrite-callback-*://`.

### 2. **Chrome Custom Tabs Instead of Native UI**
On Android, the OAuth flow opens Chrome Custom Tabs instead of the native Google Sign-In UI. This creates a clunky user experience and introduces unnecessary complexity with session management between the browser and the app.

### 3. **Silent Failures**
The OAuth process fails silently with no meaningful error messages. The `ImeTracker` error is just a symptom - a side effect of the keyboard state when the browser closes - not the actual problem.

### 4. **Lack of Documentation**
The official Appwrite documentation doesn't cover mobile OAuth edge cases, troubleshooting steps, or known issues. I had to dig through GitHub issues to find any information.

### 5. **Workarounds Required**
The fact that a two-step workaround exists (and is recommended in GitHub issues) suggests this is a known problem that hasn't been properly fixed.

## Why I'm Looking at Supabase

After spending hours (days?) on this issue, I started researching alternatives. Supabase keeps coming up, and here's why it's appealing:

### 1. **PostgreSQL Foundation**
Supabase is built on PostgreSQL, a mature, battle-tested database. This means:
- Better query capabilities
- Mature ecosystem
- Reliable data integrity
- Easy migration path if needed

### 2. **Better OAuth Documentation**
Supabase has extensive documentation for mobile OAuth, including Flutter-specific guides and examples. They support:
- Deep linking configuration
- Platform-specific setup guides
- Native SDK implementations
- Working code examples

### 3. **Active Community Support**
The Supabase community is larger and more active. Issues get addressed faster, and there are more third-party tutorials and resources available.

### 4. **Row Level Security (RLS)**
Supabase's RLS is more powerful and flexible than Appwrite's permissions system, giving you fine-grained control over data access at the database level.

### 5. **Edge Functions with Deno**
Supabase Edge Functions run on Deno, which is modern, secure, and has better TypeScript support than Appwrite's functions.

### 6. **Transparent Pricing**
Supabase has clearer pricing and a more generous free tier for development and testing.

## The Verdict

I wanted to love Appwrite. The API is clean, the dashboard is beautiful, and the promise of an open-source Firebase alternative is compelling. But when basic functionality like mobile OAuth doesn't work reliably, it becomes a blocker for production applications.

**The problems I encountered are not edge cases** - mobile OAuth is a fundamental feature for modern apps. The fact that it requires workarounds and extensive troubleshooting suggests that Appwrite isn't ready for serious mobile development.

### What Appwrite Needs to Fix:

1. **Native mobile OAuth support** with proper deep linking
2. **Better error messages** that actually help developers diagnose issues
3. **Comprehensive mobile documentation** with troubleshooting guides
4. **Native SDK improvements** for mobile platforms
5. **Faster issue resolution** and community support

### The Supabase Migration Plan:

If I decide to switch (which I'm seriously considering), the migration would involve:

1. **Data Migration**: Export data from Appwrite, transform to PostgreSQL format
2. **Auth Migration**: Implement Supabase Auth with Flutter
3. **Real-time Features**: Switch to Supabase's real-time subscriptions
4. **File Storage**: Migrate to Supabase Storage
5. **Functions**: Rewrite cloud functions as Supabase Edge Functions

Is it worth the effort? Given the time I've already wasted on OAuth alone, probably yes.

## Conclusion

Appwrite has potential, but it's not production-ready for mobile applications that require OAuth authentication. The lack of proper mobile support, combined with silent failures and poor documentation, makes it a risky choice for serious projects.

**Supabase, while not perfect, offers a more mature and mobile-friendly solution** with better documentation, active community support, and proven reliability.

For fellow developers considering their BaaS options: **test your critical features early**. Don't commit to a platform until you've verified that core functionality like authentication actually works for your use case.

As for me, I'll probably start a Supabase proof-of-concept this weekend. If it goes well, TaskTracker will be migrating sooner rather than later.

---

## Update

If you're experiencing similar issues with Appwrite OAuth, here are some resources that might help:

- [Appwrite GitHub Issues](https://github.com/appwrite/appwrite/issues) - Search for mobile OAuth problems
- [Supabase Flutter Documentation](https://supabase.com/docs/guides/getting-started/tutorials/with-flutter)
- [Flutter Web Auth 2 Package](https://pub.dev/packages/flutter_web_auth_2) - The underlying package Appwrite uses

**Have you experienced similar issues?** Share your experience in the comments. Are you using Appwrite or Supabase? What has your experience been?

---

*Written by a frustrated developer who just wants OAuth to work*  
*Date: October 13, 2025*