Do I need an app store release to change content?

No, for content and forms that the app already fetches. Edit in Development, merge a Release, and the next request returns Production. New screens or layout still need a code release.

Is this a React Native CMS or Flutter headless CMS?

It works with both — and with Swift and Kotlin — because the contract is HTTP. There is no special React Native or Flutter package today; you call the same endpoints as a website.

Can I use it with Expo or FlutterFlow?

Yes, if the tool can make authenticated HTTP requests. Point it at your Content Delivery and Form API endpoints with a website key. There is no first-party FlutterFlow plugin.

Is mywebcms a mobile backend or Firebase alternative?

No. It does not do app user accounts, push notifications, offline sync, in-app purchases or product analytics. Use it for content and form leads only.

Are API keys safe inside the app?

Treat them as public, like a key in a web bundle — they can be extracted. Website keys only read released content and submit forms, and are rate limited. Never embed management secrets. Rotate if a key leaks.

Do domain allowlists apply to mobile apps?

No. Apps typically send no Origin, so CORS doesn't gate them. The API key identifies the website and environment; rate limits still apply.

Can the same content power the website and the app?

Yes. One website's pages and forms can serve both clients over the same API, or you can keep a separate website for the app — your choice.

A headless CMS for mobile apps.

Change onboarding, banners, catalogues and in-app forms without an app store release. Your iOS, Android, React Native or Flutter app reads plain HTTP and JSON — no mobile SDK, and not a backend for users or push.

Get started See the Content API

Store. The build in TestFlight or Play Console already shipped. It reads Production over HTTP — no hardcoded banner.

Without a content API

Every copy change waits for the store.

Hardcoded strings, a home-grown admin, or bending Firebase into an editor all slow the same loop: marketing wants a new banner, and engineering opens a release. mywebcms is the content and forms side so you never build that panel again.

Words baked into the binary
Onboarding lines, FAQ answers and empty states live in code. Non-developers can't ship a tweak.String.localized…
Store review for a headline
Even a one-line change sits behind TestFlight, Play review and phased rollout — days for minutes of work.BuildReviewWait
A second backend to maintain
Rolling your own content API means auth for editors, validation, staging and an admin UI — before the app features.Homegrown CMS
Lists without a schema
Catalogues, menus and help articles need filters, detail screens and forms. A page with many items already has that API.GET …?sort=-price

What the app reads

Screens, lists and detail pages — as JSON.

Model onboarding, help, a catalogue or a menu the same way a website would: pages, sections and items. The app fetches at runtime; how long it caches is your call.See pages and content models

Single screens
App home, paywall copy, settings blurbs — a page with sections, each field keyed for your clients.GET /v1/pages/app-home
Lists with detail screens
A page with many items gives you the list API (filters, sorts, pages) and one item with every field — catalogue, courses, FAQs.listitem
Release, don't resubmit
Edit in Development, merge a Release, Production updates. Store builds keep the same binary.See staging and Releases
Same content as the website
One website can feed the marketing site and the app. Same keys, same pages — or separate websites if you prefer.One API · two clients

In-app forms

Feedback and support land as leads.

POST to the Form API from the app. Fields are validated against the form definition; every acceptance becomes a lead your team works in admin — no inbox to invent.See how forms and leads work

LeadsFrom the app

Sam T.FeedbackiOSNew
Riley M.SupportAndroidContacted
Casey L.BookingReact NativeNew

Any in-app form
Feedback, support, contact or booking — define fields once; the app posts JSON by key.POST /v1/forms/…/submit
Leads in admin
Statuses, owners and follow-ups for the content or support team. Editors never need API keys.NewContacted
Validated and rate limited
Required fields, honeypot and rate limits apply the same as web. Invalid posts get structured 422 errors.422 · errors
Export when you need it
CSV of the filter or selection. WhatsApp and CRM delivery aren't built — the leads are yours to take..csv

Keys for test and store builds

Development for previews. Production for the store.

Point debug and TestFlight builds at a Development key; ship store builds with Production. Apps send no browser Origin, so the domain allowlist doesn’t apply — the key and rate limits do. Treat a key in the binary like one in a web page: it can be extracted.

Development key
Test builds read Development content — the staging overlay — so demos never touch live copy.mwc_dev_…
Production key
Store builds only see released Production content. New words appear after a Release merges.mwc_live_…
Read content, send forms
Public website keys are not god-mode: they fetch published JSON and submit forms. They can't edit admin or list other websites.GET pagesPOST forms
Assume the key is public
Anyone who unpacks the app can see it — same as a browser bundle. Never put management secrets in the client; rotate if it leaks.Rate limited

Any mobile stack

Swift, Kotlin, React Native, Flutter — same JSON.

There is no mywebcms mobile SDK. If the runtime can call HTTP with a Bearer header, it can use the Content and Form APIs. Expo and FlutterFlow work the same way: point them at the endpoints.See every stack on Developers

ContentAPI.swift

var request = URLRequest(
  url: URL(string: "\(api)/pages/app-home")!
)
request.setValue(
  "Bearer \(key)",
  forHTTPHeaderField: "Authorization"
)
let (data, _) = try await URLSession.shared.data(for: request)
let json = try JSONDecoder().decode(Page.self, from: data)

Shape follows admin’s API tab: Bearer key, { data } on success.

What this is not

Content and forms — not a mobile backend.

mywebcms is a headless CMS for the words, images and enquiries your app shows. It is not Firebase, Supabase or a BaaS. Keep product auth, user data and push in the stack you already trust.

No app user accounts
Sign-in, profiles and per-user data stay in your auth provider. mywebcms never stores your end users.Not auth
No push notifications
Campaign pushes, device tokens and APNs/FCM are out of scope. Content updates are pull via the API.Pull, not push
No offline sync SDK
Cache JSON how your app already does. There is no mywebcms sync engine or conflict resolver.Your cache
No mobile SDKs (yet)
Call HTTP yourself in Swift, Kotlin, Dart or JS. Optional SDKs are future work — the API is the product today.Plain HTTP

FAQ

Questions mobile teams ask.

Store releases, React Native and Flutter, keys, and what isn’t a BaaS.

Get started See Developers

A content API your app calls at runtime for text, images, lists and forms — so marketing can change screens without shipping a new binary. mywebcms serves that over HTTP and JSON for iOS, Android, React Native and Flutter.

Get started

Build your next client site on mywebcms.

Start from a screenshot, give your client one simple place to run it, and ship it on any stack you like.

Get started

Log in

Two steps to your first website:
1Create your workspace
2Add a client website

Everything that comes with mywebcms

Tap any feature to learn more.

A headless CMS for mobile apps.

Every copy change waits for the store.

Words baked into the binary

Store review for a headline

A second backend to maintain

Lists without a schema

Screens, lists and detail pages — as JSON.

Single screens

Lists with detail screens

Release, don't resubmit

Same content as the website

Feedback and support land as leads.

Any in-app form

Leads in admin

Validated and rate limited

Export when you need it

Development for previews. Production for the store.

Development key

Production key

Read content, send forms

Assume the key is public

Swift, Kotlin, React Native, Flutter — same JSON.

Content and forms — not a mobile backend.

No app user accounts

No push notifications

No offline sync SDK

No mobile SDKs (yet)

Questions mobile teams ask.

What is a headless CMS for mobile apps?

Do I need an app store release to change content?

Is this a React Native CMS or Flutter headless CMS?

Can I use it with Expo or FlutterFlow?

Is mywebcms a mobile backend or Firebase alternative?

Are API keys safe inside the app?

Do domain allowlists apply to mobile apps?

Can the same content power the website and the app?

Build your next client site on mywebcms.

A headless CMS for mobile apps.

Every copy change waits for the store.

Words baked into the binary

Store review for a headline

A second backend to maintain

Lists without a schema

Screens, lists and detail pages — as JSON.

Single screens

Lists with detail screens

Release, don't resubmit

Same content as the website

Feedback and support land as leads.

Any in-app form

Leads in admin

Validated and rate limited

Export when you need it

Development for previews. Production for the store.

Development key

Production key

Read content, send forms

Assume the key is public

Swift, Kotlin, React Native, Flutter — same JSON.

Content and forms — not a mobile backend.

No app user accounts

No push notifications

No offline sync SDK

No mobile SDKs (yet)

Questions mobile teams ask.

What is a headless CMS for mobile apps?

Do I need an app store release to change content?

Is this a React Native CMS or Flutter headless CMS?

Can I use it with Expo or FlutterFlow?

Is mywebcms a mobile backend or Firebase alternative?

Are API keys safe inside the app?

Do domain allowlists apply to mobile apps?

Can the same content power the website and the app?

Build your next client site on mywebcms.