How to Turn a Softr App into a Mobile App (iOS & Android)

The short answer:Softr does not build native mobile apps. Its official mobile story is a Progressive Web App — users “install” your portal from the browser — and its own help docs confirm there is no App Store or Google Play publishing. To get your Softr app into the stores anyway, you wrap the published URL in a native shell: paste the URL into Code2Native, and in a few minutes you get a signed Android APK/AAB you can upload to Google Play under your own account. On iOS you get a Web Clip for instant home-screen installs, or — on the Pro plan and up — a cloud-built .ipa for the App Store route. The first Android build is free.

What Softr publishes — and the store gap

Softr's sweet spot is data-backed web apps you'd otherwise pay a developer for: client portals, member directories, internal tools, marketplaces — built on top of Airtable, Google Sheets, or another data source, with logins, gated pages, and per-user permissions handled for you. When you hit publish, the result is a website: it goes live at a Softr subdomain — or, on any paid plan (Basic and up), your own custom domain; the free plan stays on the Softr subdomain.

The mobile ceiling is equally clear. There is no “export to App Store” button, no APK or IPA download, no native build pipeline. Softr's answer for mobile is the PWA option — a floating install prompt that walks users through adding the portal to their home screen — and even that is gated to the Professional plan and above, which as of mid-2026 runs roughly $139+/month. So the situation many Softr builders land in: you're paying real money, your client asks “is it on the App Store?”, and the accurate answer from inside Softr is no — and never will be, because Google Play doesn't accept URLs. It accepts a signed Android App Bundle. Your Softr portal is a URL.

Closing that gap — URL in, signed binary out — is what a wrapping service does. We covered the general pattern in how to convert any website to an Android app; this post covers what's specific to Softr, which mostly comes down to one thing: logins.

How the wrap works, in three sentences

Your published Softr URL becomes the home screen of a real Android project — rendered in a full-screen WebView, compiled in the cloud, and signed with a release keystore that's reused on every rebuild so updates install cleanly on top of each other. Around that WebView goes what a browser tab can't give you: your icon and splash screen, push notifications via OneSignal, and native handling of the back button and external links. Your portal keeps running on Softr's servers — nothing is exported or converted — and the full pipeline details are in the docs.

One scope note before the steps: this flow is for hosted URLs. If what you have is a React Native, Ionic, or Expo source project rather than a published site, those source builds are currently on a waitlist — wrapping a live Softr URL is available today.

Softr URL to Google Play, step by step

1. Publish Softr on your custom domain. Every paid Softr plan (Basic and up) includes one, and you should wrap that domain rather than the Softr subdomain — it keeps branding consistent, and login cookies stay tied to a domain you control if you ever migrate.
2. Set the login method for mobile.In Softr's user settings, make sure email + password or one-time-code sign-in is enabled. The next section explains why this matters inside a wrapped app.
3. Skip Softr's PWA prompt.If you're on a plan that has the PWA install banner, leave it off (or expect it to be redundant) — people using your Android app are already installed, and a “install this app” prompt inside an app is confusing.
4. Create the build. Sign up, paste your published URL, set the app name and package ID, and upload one PNG icon at least 512×512 — every density and the splash screen are generated from it. Enable push if you want it (a OneSignal App ID, about ten minutes of setup).
5. Test the signed APK on a real phone. The build lands in minutes. Install it, then specifically walk the flows that matter for a portal: sign in, sign out, sign in again, open a gated page, close the app fully and reopen it. You should still be signed in.
6. Upload the AAB to Google Play.Under your own developer account ($25 one-time). New personal accounts face Google's closed-testing requirement before production; plan for that, or use an organization account.

The part that's actually Softr-specific: logins in a WebView

Most Softr apps are portals, which means most Softr apps have a login wall — and how each of Softr's sign-in methods behaves inside a WebView is the honest technical heart of this whole exercise.

• Email + password and one-time code: work normally. Softr sessions live in cookies on your domain, and the WebView persists cookies like a browser does. Users sign in once and stay signed in across app launches. This should be your primary method for a wrapped app.
• Magic links: work, with a workflow caveat. The link arrives by email, and tapping it opens the phone's default browser— not your app's WebView. The user ends up signed in to your portal in Chrome or Safari while the installed app still shows the login screen. Nothing breaks, but it's a confusing experience, which is why we recommend password or one-time-code login as the front door.
• Google sign-in: test before you rely on it.Google's OAuth policy restricts sign-in from inside embedded WebViews and can reject the login outright. If Google SSO is how your users expect to sign in, verify it on the free test build first — and keep email-based login enabled as the fallback either way.

None of this is a Code2Native quirk — it's how WebViews, mail clients, and Google's OAuth rules interact for any wrapped web app. The difference between a wrapped portal that feels solid and one that feels broken is usually just choosing the right Softr login settings before you build.

iOS: two honest paths, no Apple ID handover

Android is the clean story; iOS requires choosing a path. The zero-signing option is an iOS Web Clip — a signed configuration profile that installs your Softr portal to the home screen, full-screen with your icon, no Apple Developer account needed. For client portals and internal teams this is often the pragmatic answer, because you can distribute it by link today.

For the actual App Store, we build an .ipa in the cloud on real Apple silicon — and every cloud iOS .ipa build, signed or unsigned, is on the Pro plan and up. The default output is unsigned: you re-sign it with your own Apple Developer certificate and submit it yourself. Alternatively, upload your own .p12 certificate and provisioning profile and we sign it in the cloud for you. Either way, we never touch your Apple ID or App Store Connect, and we don't submit on your behalf — that last mile is yours. If you want a fully managed iOS submission, that's a different category of service at a different price, and we've compared it honestly in our MobiLoud comparison.

Who this suits — and who should skip it

Wrapping your Softr app makes sense if:

• A client or stakeholder expects the portal in the stores — “send me the Play Store link” is the requirement, and a browser URL doesn't satisfy it.
• You need push notifications — “a new document was added to your portal” lands as a push, which a home-screen PWA can't reliably do.
• You're an agency delivering Softr portals and want to hand clients a branded, installable app as part of the package.

Skip it (honestly) if:

• Your users are a small internal team who'll happily use a bookmark — Softr's built-in PWA (if you're already on Professional) or a plain browser tab is enough.
• You need offline access. A wrapped Softr app needs the internet, exactly like Softr's own PWA does — the data lives in Airtable or Google Sheets and is fetched live.
• You need deep native features — background location, offline-first sync, heavy camera workflows. That's native-rebuild territory in a different tool, at 10–50x the cost and time.

Your three real options, side by side

The pricing irony is worth naming: Softr's own mobile feature — the PWA — is gated behind a plan tier that costs more per month than a wrap that gets you further. If you're on Professional anyway, use both: PWA for casual visitors, wrapped app for the users you want on the stores and reachable by push.

FAQ

Can Softr publish my app to the App Store or Google Play?

No. Softr's own help docs are clear that it doesn't build native iOS or Android apps or publish to app stores — its official mobile answer is a PWA on the Professional plan and above. Getting onto Google Play means wrapping the published URL into a signed AAB and uploading it under your own developer account, which is what Code2Native does.

Does Softr login work inside the wrapped app?

Email + password and one-time-code login work normally — sessions live in cookies, the WebView persists them, and users stay signed in between launches. Magic links open in the phone's default browser rather than the app, and Google restricts OAuth inside embedded WebViews, so treat Google sign-in as something to verify on the free test build, with email login enabled as the reliable path.

Will the app update when I edit my Softr app?

Yes, instantly. The shell loads your live URL, so new pages, new blocks, and updated Airtable or Google Sheets data reach every installed device the moment you publish in Softr — no rebuild, no store review. You only rebuild for icon, name, package ID, or push-configuration changes.

What about iOS?

Web Clip for zero-signing home-screen installs — no Apple Developer account, no plan requirement. For the App Store, cloud iOS .ipa builds are on the Pro plan and up, whether unsigned by default (you re-sign with your own Apple Developer certificate and submit yourself) or cloud-signed with your uploaded .p12. We never touch your Apple ID and don't submit to the App Store for you.

What does this cost compared to Softr's own PWA?

Softr's PWA requires its Professional plan (~$139+/mo as of mid-2026) and still can't reach the app stores. Wrapping starts free: your first Android build costs nothing (one credit, watermarked splash screen). After that it's credit-based — Starter $29/month for 10 credits, Pro $99/month for 30 credits and cloud iOS .ipa builds, Agency $199/month for 100 credits plus Windows EXE output and white-label. Annual plans and the $49 urgent-build option are on the pricing page; Stripe and USDT are accepted, and a failed build auto-refunds its credit. The stores charge separately: $25 one-time for a Google Play developer account, $99/year for Apple's Developer Program.

Is the result a real native app?

It's a real, signed, installable Android app whose interface is your live Softr portal in a WebView, plus native push, icon, and splash. It is not a native rebuild, and nothing in your Softr project is converted. If your requirements include offline data or background native features, a wrapper is the wrong tool — we'd rather say so here than after you've built.