The Case for a Shared Web + Mobile Architecture
Many startups build their marketing site in Webflow and their mobile app in React Native. The two projects often diverge quickly — different design systems, separate auth flows, duplicate content management. A shared architecture solves this by treating Webflow as the CMS and marketing front, React Native as the native experience, and a common backend (Supabase, Firebase, or a custom API) as the single source of truth. The result is faster iteration, consistent branding, and a smaller team footprint.
Architecture Diagram
The architecture has four layers. At the top sits the Webflow marketing site and the React Native app — both are consumer-facing. Below them is a shared API layer: Supabase (Postgres + Auth + Storage + Edge Functions) serves both clients. The Webflow site calls Supabase from embedded JavaScript; the React Native app calls the same Supabase project through the official React Native SDK. Underneath Supabase is the data layer: Postgres tables with RLS policies, a storage bucket for uploads, and Edge Functions for server-side logic. At the bottom is a CI/CD layer: GitHub Actions deploys Edge Functions and runs database migrations, while Webflow publishes the site independently.
// Shared Supabase client config — used in both platforms
// web: loaded via ESM in Webflow custom code
// mobile: imported in React Native from a shared config file
export const supabaseConfig = {
url: "https://your-project.supabase.co",
anonKey: "your-anon-key",
};
// React Native initialization
import { createClient } from "@supabase/supabase-js";
import AsyncStorage from "@react-native-async-storage/async-storage";
export const supabase = createClient(
supabaseConfig.url,
supabaseConfig.anonKey,
{
auth: {
storage: AsyncStorage, // persist session on device
autoRefreshToken: true,
persistSession: true,
detectSessionInUrl: false, // no URL-based auth in RN
},
}
);Sharing Authentication Across Platforms
Supabase Auth works on both web and React Native. On the Webflow side, use magic links or OAuth redirects. In the React Native app, use the same Supabase project with email/password, Apple Sign-In, or Google Sign-In via the native auth providers. Because both platforms share the same Supabase project, a user who signs up on the website has the same user ID and profile in the mobile app. You do not need a separate user table or sync mechanism.
Using Webflow CMS as a Headless Content Source
The Webflow Data API lets your React Native app fetch CMS content — blog posts, help articles, changelog entries — and render them natively. This means your marketing team writes content in Webflow's visual editor, publishes it, and the mobile app picks it up automatically. Fetch CMS items from the API, cache them locally with React Query or AsyncStorage, and render the rich text using a lightweight Markdown or HTML renderer. This eliminates the need for a separate CMS for the mobile app.
// Fetch Webflow CMS items in React Native
const WEBFLOW_API = "https://api.webflow.com/v2";
const BLOG_COLLECTION_ID = "your-blog-collection-id";
export async function fetchBlogPosts() {
const res = await fetch(
`${WEBFLOW_API}/collections/${BLOG_COLLECTION_ID}/items?limit=20`,
{
headers: {
Authorization: `Bearer ${process.env.WEBFLOW_API_TOKEN}`,
"Content-Type": "application/json",
},
}
);
const { items } = await res.json();
return items.map((item) => ({
id: item.id,
title: item.fieldData.name,
slug: item.fieldData.slug,
excerpt: item.fieldData["post-summary"],
body: item.fieldData["post-body"], // rich text HTML
coverImage: item.fieldData["main-image"]?.url,
publishedAt: item.fieldData["published-date"],
}));
}Shared Design Tokens
Visual consistency between Webflow and React Native requires shared design tokens — colors, typography scales, spacing units, and border radii. Export your Webflow variables (or define them in a JSON token file) and consume them in both environments. In Webflow, map tokens to CSS custom properties. In React Native, import the same JSON and reference the values in your StyleSheet. Tools like Style Dictionary can automate the transformation from a single source-of-truth token file into platform-specific formats.
// design-tokens.json — single source of truth
{
"color": {
"primary": { "value": "#6C3CE1" },
"secondary": { "value": "#1A1A2E" },
"surface": { "value": "#FFFFFF" },
"text": { "value": "#111111" },
"muted": { "value": "#6B7280" }
},
"spacing": {
"xs": { "value": 4 },
"sm": { "value": 8 },
"md": { "value": 16 },
"lg": { "value": 24 },
"xl": { "value": 32 }
},
"radius": {
"sm": { "value": 4 },
"md": { "value": 8 },
"lg": { "value": 16 },
"full": { "value": 9999 }
}
}Deep Linking Between Web and App
When a user clicks a link on your Webflow site, you may want to open the corresponding screen in the React Native app if it is installed, or fall back to the web page if not. This is accomplished with universal links (iOS) and app links (Android). Configure your Webflow hosting domain's .well-known/assetlinks.json (Android) and apple-app-site-association (iOS) files to declare the association. In React Native, use expo-linking or React Navigation's deep link configuration to map URL paths to screens.
Host the .well-known association files on your Webflow domain using custom code in the page head, or use a Cloudflare Worker in front of your Webflow site to serve them. Webflow does not natively support .well-known paths, so you need a workaround.
- Define URL-to-screen mappings in React Navigation's linking config
- Use expo-linking for Expo-managed projects or react-native-app-link for bare RN
- Test on both iOS and Android simulators with adb and xcrun
- Implement a fallback: if the app is not installed, the Webflow page loads normally
- Track deep link opens in your analytics to measure cross-platform engagement
Building a web + mobile product? Let us architect it.
Get architecture consulting→
