Sätt upp din Supabase-backend
Skapa ett Supabase-projekt. För en uppgiftsapp skapar du tabellen:
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);
Row Level Security (RLS) är avgörande för GDPR-efterlevnad, med RLS kan varje användare bara se och redigera sina egna rader, direkt på databasnivå. Det är en av anledningarna till att vi alltid väljer Supabase framför Firebase för svenska kunder med GDPR-krav. Kopiera ditt Supabase-projekt-URL och anon-nyckel, du behöver dem i FlutterFlow.
Anslut FlutterFlow till Supabase
I FlutterFlow, gå till Settings → Supabase. Klistra in ditt Supabase-URL och anon-nyckel. FlutterFlow autentiserar och visar ditt databasschema.
Du ser din tasks-tabell listad med alla kolumner. FlutterFlow genererar automatiskt typade query-builders för varje tabell, ingen SQL behövs i frontend. Det här är en av de stora fördelarna med kombinationen: du designar gränssnittet visuellt i FlutterFlow medan Supabase hanterar all datalogik.
Ett tips: namnge ditt Supabase-projekt på ett sätt som speglar kundprojektet, exempelvis "company-app-prod". Det underlättar underhåll och gör det tydligare för alla i teamet.
Bygg autentisering
Använd FlutterFlows Supabase Auth-åtgärder för inloggning och registrering. Skapa: 1. En inloggningssida med e-post/lösenordsfält och en "Logga in"-knapp 2. En registreringssida med e-post, lösenord och bekräfta lösenord 3. Koppla knapp-OnTap-åtgärderna till "Log In with Email" och "Create Account with Email" (båda Supabase auth-åtgärder)
Sätt upp "Initial Page"-logiken: om användaren är autentiserad → Hemsida, annars → Inloggningssida.
För appar riktade mot svenska företagskunder kan du också lägga till BankID-autentisering via ett Xano-API-anrop som hanterar BankID-flödet, det ger omedelbar trovärdighet hos enterprise-kunder.
FlutterFlow-autentisering med Supabase: bortom e-post/lösenord
E-post- och lösenordsautentisering täcker de flesta användningsfall, men FlutterFlow stöder hela Supabases uppsättning av auth-leverantörer. Magic link-autentisering (lösenordsfri e-post) tar en stund att konfigurera och förbättrar mobilkonverteringen markant, användare behöver inte komma ihåg lösenord. OAuth-leverantörer (Google, Apple, GitHub) stöds genom Supabase och är avgörande för alla konsumentriktade mobilappar: Apple Sign-In krävs enligt App Store-riktlinjerna om du erbjuder något annat socialt inloggningsalternativ.
Telefon/OTP-autentisering via Supabase använder Twilio under huven. I FlutterFlow lägger du till åtgärden "Send OTP" på din telefoninmatningsskärm och "Verify OTP" på din kodinmatningsskärm. Supabase hanterar Twilio-uppgifterna i din dashboard, ingen kod krävs.
En kritisk detalj: för att Supabase-autentisering ska fungera korrekt i en publicerad FlutterFlow-app måste du vitlista din apps URL-schema i Supabase under Authentication → URL Configuration. För iOS-appar ser detta ut som com.yourcompany.yourapp://login-callback. Missar du detta steg gör att OAuth-omdirigeringar misslyckas tyst efter App Store-inlämning, vilket är en mycket vanlig fallgrop vid en första FlutterFlow + Supabase-driftsättning.
Bygg uppgiftslistan
Skapa en ListView-komponent. Sätt datakällan till din Supabase tasks-tabell. Lägg till ett filter: user_id = currentAuthUser.uid (FlutterFlow fyller i detta automatiskt).
För varje listobjekt: visa uppgiftstiteln, en kryssruta för completed-status och en raderingsknapp. Koppla kryssrutan till en Supabase UPDATE-åtgärd (uppdatera completed = true/false). Koppla raderingsknappen till en Supabase DELETE-åtgärd.
Ett designtips: lägg till ett tomt tillstånd (empty state) med en uppmanande text och knapp, exempelvis "Du har inga uppgifter ännu. Skapa din första!", istället för en tom lista. Det förbättrar aktiveringsgraden markant och ger ett professionellt intryck.
Lägg till realtidsprenumerationer
I FlutterFlows Supabase-inställningar, aktivera Realtime för tasks-tabellen. I din uppgiftslistekomponent, aktivera "Realtime" på datakällan.
När en uppgift nu läggs till, uppdateras eller raderas (från valfri enhet) uppdateras din lista automatiskt, ingen manuell polling behövs. Det här är en av Supabase starka sidor jämfört med traditionell REST: du får live-uppdateringar utan extra infrastruktur.
För team-appar och samarbetsfunktioner (till exempel att dela uppgifter med kollegor) kan du utöka detta med Supabase Presence för att visa vilka användare som är online i realtid.
Realtidsdata i FlutterFlow: arkitektur och begränsningar
FlutterFlows Supabase Realtime-integration använder PostgreSQLs logiska replikering. När du aktiverar Realtime på en tabell i Supabase sänds ändringar över en websocket till alla anslutna klienter. FlutterFlow hanterar prenumerationens livscykel automatiskt, prenumererar när widgeten monteras och avprenumererar vid dispose, vilket förhindrar de minnesläckor och dubbla prenumerationer som är vanliga i handskrivna Flutter-appar.
Den praktiska gränsen: Supabase Realtime på gratistjänsten tillåter 200 samtidiga anslutningar. Pro-planen höjer detta till 500. För en mobilapp med 1 000 aktiva användare men lågt samtidigt användande (typiskt för B2B-verktyg) räcker detta. För konsumentappar med hög samtidighet, planera för Supabase Pro och övervaka anslutningsmåttet i Supabase-dashboarden.
Realtime i FlutterFlow fungerar också för presence-funktioner, som visar vilka användare som är online just nu. Implementera detta via Supabases presence channel-API. Det här är något mer involverat än tabellprenumerationer och kräver för närvarande anpassad Action-kod i FlutterFlow, men det öppnar upp för samarbetsfunktioner som "Användare X visar den här posten" utan någon ytterligare backend-infrastruktur.
Konfigurera push-notiser
Push-notiser i FlutterFlow-appar kräver Firebase Cloud Messaging (FCM) för både iOS och Android, även för iOS, där Apple Push Notification Service (APNS) är den underliggande transporten, dirigerar FlutterFlow via FCM för konsekvens mellan plattformar.
Konfigurationssteg: skapa ett Firebase-projekt, ladda ner filerna google-services.json (Android) och GoogleService-Info.plist (iOS), och ladda upp båda i FlutterFlow under Settings → Firebase. Aktivera Cloud Messaging i Firebase Console. I din Supabase-databas lägger du till en device_tokens-tabell för att lagra FCM-tokens per användare, du skriver token till Supabase vid appstart med en anpassad FlutterFlow-åtgärd.
För att skicka en notis, anropa FCM HTTP v1-API från ett Make- eller n8n-arbetsflöde som triggas av en Supabase-webhook. Till exempel: ett nytt meddelande i en chattapp triggar en Supabase-webhook → Make-scenario → FCM-API-anrop → notis levererad till mottagarens enhet. Det här mönstret hanterar 95 % av notisbehoven utan någon serversidig kod. För höga volymer av notiser (10 000+ per dag), byt till en dedikerad tjänst som OneSignal, som har inbyggd Supabase-integration och en FlutterFlow-plugin.
Överväganden kring offline-läge
Fullt offline-läge i FlutterFlow (cacha data lokalt och synka när anslutningen återkommer) kräver anpassad kod och är inte tillgängligt direkt ur lådan. Det FlutterFlow stöder inbyggt är graciös degradering: att visa ett "ingen anslutning"-tillstånd via ConnectivityStatus-widgeten och förhindra åtgärder som kräver nätverksåtkomst. För de flesta B2B-mobilverktyg (fältserviceappar, inspektionschecklistor, leveransappar) räcker grundläggande offline-medvetenhet.
För verkligt offline-first-funktionalitet, där användare kan skapa och redigera poster utan anslutning och ändringar synkas automatiskt, behöver du integrera ett lokalt persistenslager. Den rekommenderade metoden: använd Supabases Edge Functions för att exponera en REST-endpoint som din app pollar vid återanslutning, kombinerat med FlutterFlows lokala state-hantering för att köa mutationer. Detta kräver anpassad Dart-kod (FlutterFlows funktion för anpassade widgets/actions) men är genomförbart utan en fullständig Flutter-utvecklare.
Ett enklare alternativ: avgränsa din apps offline-krav noggrant redan i designfasen. De flesta enterprise-mobilappar har en liten uppsättning verkligt kritiska offline-funktioner (visa mina tilldelade uppgifter, markera ett objekt som klart) som kan implementeras med FlutterFlows app state-variabler och ett synka-vid-öppning-mönster, utan att bygga en fullständig offline-motor.
Publicera till App Store och Google Play
I FlutterFlow, gå till Run → Build → iOS och Android.
För iOS: du behöver ett Apple Developer-konto (1 199 SEK/år). FlutterFlow genererar .ipa-filen. Skicka via Xcode eller Transporter. App Store-granskning tar 1-3 dagar för första inlämningen.
För Android: FlutterFlow genererar en signerad .aab-fil. Skicka via Google Play Console. Uppdateringar granskas vanligtvis inom 24 timmar.
Ett viktigt steg för svenska appar: se till att din App Store- och Google Play-beskrivning är på svenska om din primära målgrupp är svenska användare. Det förbättrar organisk synlighet i appbutikerna markant.
App Store-inlämning med FlutterFlow: vad du kan förvänta dig
FlutterFlows byggsystem genererar ett standardiserat Flutter-projekt och kompilerar det med deras molnbaserade byggarkitektur. Vid första App Store-inlämningen kontrollerar Apples granskningsteam att din app följer deras Human Interface Guidelines, dataskyddskrav och App Store Review Guidelines. Vanliga avslagsorsaker för FlutterFlow-byggda appar: saknad URL till integritetspolicy (krävs även för gratisappar), ofullständig appmetadata (skärmdumpar i fel dimensioner, Apple kräver specifika storlekar för olika enhetsklasser), och otillräcklig beskrivning av hur användardata hanteras i integritetsetiketten (privacy nutrition label).
För integritetsetiketten, var specifik om Supabases datainsamling. Om du samlar in e-postadresser och användningsdata, deklarera det i App Store Connects datasektion. Supabases auth-system samlar in enhetsmetadata som standard, redovisa detta. App Store-granskning tar vanligtvis 24-48 timmar för uppdateringar. Första inlämningen för en ny app tar 1-5 dagar och kan inkludera ett granskningssamtal för appar i reglerade kategorier (hälsa, finans, barn).
Google Play-granskning är generellt snabbare (4-24 timmar) och mindre strikt kring visuella designkrav, men tillämpar krav på dataskyddsdeklarationer lika strikt. Använd FlutterFlows TestFlight/interna testdistribution för att validera din app innan den publika inlämningen, det sparar cykler eftersom du kan fixa problem innan den formella granskningsklockan startar.