Does FlutterFlow export real code I can hand to a developer?

Yes. FlutterFlow exports standard Flutter/Dart code that any Flutter developer can read and extend. The quality of the generated code is decent for CRUD and UI patterns but may need refactoring for complex state management. This is one of FlutterFlow's key advantages over Adalo or Glide, you are never locked in.

Can I use Supabase Realtime in a FlutterFlow app without a paid Supabase plan?

Yes, Supabase Realtime is available on the free tier with a limit of 200 concurrent connections. For development and early-stage apps, the free tier is sufficient. Move to Supabase Pro ($25/month) when you approach 150+ simultaneous active users.

Do I need an Apple Developer account to test my FlutterFlow iOS app?

You can test in FlutterFlow's preview mode (browser-based) without an Apple Developer account. For device testing via TestFlight or App Store submission, you need an Apple Developer account at $99/year. There is no way around this Apple requirement.

How do I handle deep links in a FlutterFlow + Supabase app?

Deep links (e.g., opening a specific record from a notification) use FlutterFlow's deep link navigation settings combined with your app's URL scheme. Configure the URL scheme in FlutterFlow Settings → Deep Linking, and register the same scheme in Supabase's auth redirect URLs. Test deep links on a physical device, not the FlutterFlow preview.

What is the typical build time for a FlutterFlow app?

A typical B2B mobile app (5–10 screens, CRUD operations, authentication, push notifications) takes 3–6 weeks with an experienced FlutterFlow developer. Simple apps with 3–5 screens and basic Supabase queries can be done in 1–2 weeks. Complex apps with custom UI components, offline mode, and advanced Supabase integrations take 8–12 weeks.

FlutterFlow + Supabase

FlutterFlow and Supabase is the most powerful no-code mobile stack available today. You get native iOS and Android apps with real PostgreSQL data, built-in authentication, and real-time subscriptions, all without writing backend code. Here is the complete tutorial.

Set Up Your Supabase Backend

Create a Supabase project. For a task app:
CREATE TABLE tasks (
  id bigserial PRIMARY KEY,
  title text NOT NULL,
  completed boolean DEFAULT false,
  user_id uuid REFERENCES auth.users(id),
  created_at timestamptz DEFAULT now()
);

ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;
CREATE POLICY "user owns tasks" ON tasks
  FOR ALL USING (auth.uid() = user_id);

Copy your Supabase project URL and anon key, you'll need these in FlutterFlow.

Connect FlutterFlow to Supabase

In FlutterFlow, go to Settings → Supabase. Paste your Supabase URL and anon key. FlutterFlow will authenticate and display your database schema.

You'll see your tasks table listed with all columns. FlutterFlow auto-generates typed query builders for each table, no SQL needed in the frontend.

Build Authentication

Use FlutterFlow's Supabase Auth actions for login and signup. Create:
1. A login page with email/password fields and a "Sign In" button
2. A signup page with email, password, and confirm password
3. Connect the button OnTap actions to "Log In with Email" and "Create Account with Email" (both Supabase auth actions)

Set "Initial Page" logic: if user is authenticated → Home page, else → Login page.

FlutterFlow Auth with Supabase: Beyond Email/Password

Email and password authentication covers most use cases, but FlutterFlow supports the full Supabase auth provider set. Magic link authentication (passwordless email) is one tap to configure and significantly improves mobile conversion rates, users do not need to remember passwords. OAuth providers (Google, Apple, GitHub) are supported through Supabase and are essential for any consumer-facing mobile app: Apple Sign-In is required by App Store guidelines if you offer any other social auth option.

Phone/OTP authentication via Supabase uses Twilio under the hood. In FlutterFlow, add the "Send OTP" action to your phone input screen and "Verify OTP" to your code input screen. Supabase manages the Twilio credentials in your dashboard, no code required.

One critical detail: for Supabase auth to work correctly in a published FlutterFlow app, you must whitelist your app's URL scheme in Supabase under Authentication → URL Configuration. For iOS apps this looks like `com.yourcompany.yourapp://login-callback`. Missing this step causes OAuth redirects to fail silently after App Store submission, which is a very common gotcha in first-time FlutterFlow + Supabase deployments.

Build the Task List Screen

Create a ListView component. Set the data source to your Supabase tasks table. Add a filter: user_id = currentAuthUser.uid (FlutterFlow auto-populates this).

For each list item: display the task title, a checkbox for completed status, and a delete button. Wire the checkbox to a Supabase UPDATE action (update completed = true/false). Wire the delete button to a Supabase DELETE action.

Add Real-Time Subscriptions

In FlutterFlow's Supabase settings, enable Realtime for the tasks table. In your task list component, enable "Realtime" on the data source.

Now when any task is added, updated, or deleted (from any device), your list automatically refreshes, no manual polling needed.

Real-Time Data in FlutterFlow: Architecture and Limits

FlutterFlow's Supabase Realtime integration uses PostgreSQL's logical replication. When you enable Realtime on a table in Supabase, changes are broadcast over a websocket to all connected clients. FlutterFlow handles the subscription lifecycle automatically, subscribing on widget mount, unsubscribing on dispose, which prevents the memory leak and duplicate-subscription problems common in hand-written Flutter apps.

The practical limit: Supabase Realtime on the free tier allows 200 concurrent connections. The Pro plan increases this to 500. For a mobile app with 1,000 active users but low simultaneous usage (typical for B2B tools), this is sufficient. For consumer apps with high concurrency, plan for Supabase Pro and monitor the connections metric in the Supabase dashboard.

Realtime in FlutterFlow also works for presence features, showing which users are currently online. Implement this via Supabase's presence channel API. This is slightly more involved than table subscriptions and currently requires custom action code in FlutterFlow, but it opens up collaboration features like "User X is viewing this record" without any additional backend infrastructure.

Push Notifications Setup

Push notifications in FlutterFlow apps require Firebase Cloud Messaging (FCM) for both iOS and Android, even for iOS, where Apple Push Notification Service (APNS) is the underlying transport, FlutterFlow routes through FCM for cross-platform consistency.

Setup steps: create a Firebase project, download the google-services.json (Android) and GoogleService-Info.plist (iOS) files, and upload both in FlutterFlow under Settings → Firebase. Enable Cloud Messaging in Firebase Console. In your Supabase database, add a device_tokens table to store FCM tokens per user, you will write the token to Supabase on app launch using a FlutterFlow custom action.

To send a notification, call the FCM HTTP v1 API from a Make or n8n workflow triggered by a Supabase webhook. For example: a new message in a chat app triggers a Supabase webhook → Make scenario → FCM API call → notification delivered to recipient's device. This pattern handles 95% of notification requirements without any server-side code. For high-volume notifications (10,000+ per day), switch to a dedicated service like OneSignal, which has native Supabase integration and a FlutterFlow plugin.

Offline Mode Considerations

Full offline mode in FlutterFlow (caching data locally and syncing when connectivity returns) requires custom code and is not available out of the box. What FlutterFlow does support natively is graceful degradation: showing a "no connection" state via the ConnectivityStatus widget and preventing actions that require network access. For most B2B mobile tools (field service apps, inspection checklists, delivery apps), basic offline awareness is sufficient.

For true offline-first functionality, where users can create and edit records without connectivity and changes sync automatically, you need to integrate a local persistence layer. The recommended approach: use Supabase's Edge Functions to expose a REST endpoint that your app polls on reconnection, combined with FlutterFlow's local state management to queue mutations. This requires custom Dart code (FlutterFlow's custom widget/action feature) but is achievable without a full Flutter developer.

A simpler alternative: scope your app's offline requirements carefully at design time. Most enterprise mobile apps have a small set of truly critical offline features (view my assigned tasks, mark an item as complete) that can be implemented with FlutterFlow's app state variables and a sync-on-open pattern, without building a full offline engine.

Submit to App Store and Google Play

In FlutterFlow, go to Run → Build → iOS and Android.

For iOS: you need an Apple Developer account ($99/year). FlutterFlow generates the .ipa file. Submit via Xcode or Transporter.

For Android: FlutterFlow generates a signed .aab file. Submit via the Google Play Console.

First submission takes 1–3 days for review. Updates are usually reviewed in 24 hours.

App Store Submission with FlutterFlow: What to Expect

FlutterFlow's build system generates a standard Flutter project and compiles it using their cloud build infrastructure. For first-time App Store submissions, Apple's review team checks your app for compliance with their Human Interface Guidelines, data privacy requirements, and App Store Review Guidelines. Common rejection reasons for FlutterFlow-built apps: missing privacy policy URL (required even for free apps), incomplete app metadata (screenshots in wrong dimensions, Apple requires specific sizes for different device classes), and inadequate description of how user data is handled in the privacy nutrition label.

For the privacy nutrition label, be specific about Supabase data collection. If you collect email addresses and usage data, declare this in the App Store Connect data use section. Supabase's auth system collects device metadata by default, disclose this. App Store review typically takes 24–48 hours for updates. The first submission for a new app takes 1–5 days and may include a review call for apps in regulated categories (health, finance, children).

Google Play review is generally faster (4–24 hours) and less strict on visual design requirements, but enforces data safety declarations equally strictly. Use the FlutterFlow TestFlight/internal testing distribution to validate your app before public submission, it saves cycles since you can fix issues before the formal review clock starts.

FlutterFlow + Supabase: Building a Full-Stack Mobile App (Tutorial)