Build and publish iOS and Android apps using Adalo's no-code platform. Covers setup, authentication, database config, and app store submission for solo.
No need for Swift or Kotlin to ship a mobile app. Adalo lets you create functional iOS and Android apps using drag-and-drop components, native forms, and real databases. Then, publish directly to app stores. This guide covers building and launching a working app from scratch.
Who this is for: Solo founders needing to validate a mobile product quickly without hiring developers or spending months learning native frameworks. If you've used Webflow or Bubble, you'll recognize the model β but Adalo focuses solely on native mobile experiences, not repurposed web wrappers.
What Adalo Actually Does (and Where It Breaks)
Adalo is a no-code platform for building mobile apps with native UI components. Unlike Progressive Web Apps that pretend to be mobile, Adalo creates actual iOS and Android packages you can submit to the App Store and Google Play. The editor uses a component-based system: screens, lists, forms, buttons, custom actions.
According to Adalo's official documentation, the platform supports native device features, including camera access, geolocation, push notifications, and biometric authentication. Your app connects to Adalo's managed database (PostgreSQL) or external APIs via custom integrations.
Here's the thing: it struggles with complex conditional logic, offline-first architecture isn't supported, and performance degrades with data sets above a few thousand records. If you're building a fintech app with heavy transaction processing or a social network expecting 100K+ users, look elsewhere. For MVPs, simple CRUD apps, or niche tools with under 10K users, it works.
The free tier allows building unlimited apps but doesn't include app store publishing. Paid plans start at $36/month for hobbyists and $52/month for production apps (according to Adalo's pricing page, 2026). Publishing requires the paid plan β there's no way around it.
Setting Up Your First App Project
Create an Adalo account and start a new app. Choose between starting from scratch or using a template. Templates are pre-built apps (marketplace, directory, social feed) with working screens and data models. They're useful for seeing how components connect, but starting blank for your first build is recommended for better understanding of the structure.
After project creation, the screen editor opens up. The left sidebar shows your app's screens; the center canvas displays the active screen; the right panel controls component properties and data bindings.
Add your first screen: click "Add Screen" in the left sidebar. Name it "Home" or something specific to your app's function. Every screen needs a defined role β login, list view, detail view, settings. Adalo doesn't enforce a navigation structure, so you manually link screens using buttons and actions.
The default app includes a "Welcome Screen" β delete it. Start with the actual functionality. If you're building a task manager, your first screen is the task list. If it's a booking app, it's the calendar or service selector.
Set up your data collections before building UI. Click "Database" in the top toolbar. Collections are your data tables β each collection has properties (fields). Create a collection called "Tasks" with these properties:
- Title (text)
- Description (text)
- Completed (true/false)
- Created Date (date & time)
Every collection automatically includes a unique ID and creation timestamp. Add a "User" relationship if you plan multi-user functionality, but skip it for single-user MVPs.
Now connect your screen to data. On your Home screen, add a "List" component from the left toolbar. In the right panel, set the list's data source to the "Tasks" collection. The list shows all records by default β you can add filters later (e.g., show only incomplete tasks).
Inside the list, add a "Text" component to display the task title. Select the text, then in the properties panel, click "Magic Text" and choose "Current Task > Title". Magic Text dynamically pulls data from your collection. Repeat for description or other fields.
Add a button to create new tasks. Place it outside the list (Adalo's UI is strict about component hierarchy). Set the button's action to "Link to Screen" and create a new screen called "Add Task". On that screen, add a "Form" component and connect it to the Tasks collection. The form auto-generates input fields for each property.
Set the form's submit action to "Create Task" then "Link to Home". Test it using Adalo's preview mode (icon in top-right). You should be able to add a task and see it appear in the Home list.
This basic pattern β screen with list, button to form screen, form creates record β handles 80% of simple apps. The complexity comes from actions, conditional visibility, and data relationships.
Building Core Features: Authentication, Actions, and Conditionals
Most apps need user accounts. Adalo includes built-in authentication with minimal setup. Add a "Sign Up" screen using the template from the screen selector β it includes email/password fields and a pre-configured submit button.
The signup form automatically creates users in Adalo's "Users" collection. Link your Home screen to the signup screen by setting the app's initial screen (in app settings) to force login. Adalo handles session management β once logged in, users stay logged in until they sign out or you revoke the session.
To associate tasks with specific users, edit your Tasks collection and add a "Relationship" property linking to Users. On your Add Task form, add a hidden field that sets the task's User relationship to "Logged In User". Now each task belongs to whoever created it.
Filter your Home screen's task list to show only the current user's tasks: click the list, go to filters, add "User > is > Logged In User". Without this filter, all users see all tasks β a common mistake.
Custom actions let you build multi-step workflows. Example: mark a task complete and send a notification. Add a button to each list item labeled "Complete". Set its action to:
- Update Current Task > set Completed = true
- Send Notification to Logged In User with message "Task completed"
- Go back
Actions execute sequentially. If one fails (e.g., notification service is down), the chain stops. There's no try-catch or error handling β you get a generic error message.
Conditional visibility hides/shows components based on data state. Select your "Complete" button, enable "Visible?" conditional, and set: "Current Task > Completed > is not > true". The button only appears for incomplete tasks. For completed tasks, show a "Reopen" button with reversed logic.
Adalo doesn't support complex conditionals (AND/OR logic requires workarounds using helper fields or multiple visibility rules stacked). If you need "show if A AND (B OR C)", you'll restructure your data model or accept UI compromises.
External integrations use Adalo's API connector or Zapier. The API connector allows calling REST endpoints β useful for payment processing (Stripe), email (SendGrid), or custom backends. Configure it under Integrations > External Collections. Provide the endpoint URL, method (GET/POST), headers, and map the response to Adalo data fields.
This can be used to connect Adalo apps to Firebase for real-time chat (Adalo's native chat is limited) and to Airtable for shared databases between mobile and web tools. The connector is finicky with authentication β OAuth flows require custom workarounds, and webhook responses must return JSON in Adalo's expected format.
Publishing to App Stores (The Part That Usually Fails)
Adalo generates app binaries, but you handle app store submission. This is where most builders get stuck β App Store Connect and Google Play Console have their own bureaucracy.
First, configure your app's publishing settings in Adalo. Under "Publish" > "iOS", set your app name, bundle identifier (reverse domain format: com.yourcompany.appname), and upload required assets: app icon (1024x1024px), splash screen, and screenshots for each device size.
Apple requires a paid developer account ($99/year). Google Play charges a one-time $25 fee. Both require business verification if you're collecting payments or handling user data beyond basic auth.
Download your app binary from Adalo's publishing dashboard. For iOS, you get an .ipa file; for Android, an .aab (Android App Bundle). Upload these to their respective consoles.
Common rejection reasons for Adalo apps:
- Insufficient app description or missing privacy policy (required if you collect any user data)
- Broken links or placeholder content in test builds
- Missing age rating or content warnings
- Apps that replicate web content without adding mobile-specific value
That last one is subjective but real β Apple rejects "wrapped websites". Adalo apps are native, but if your app is just a form that could be a webpage, expect scrutiny. Add features like push notifications, camera access, or offline capability to show native functionality.
Google Play is more lenient but slower. Expect 3-7 days for first-time review versus Apple's 24-48 hours. Both stores reject apps with missing or incorrect privacy policies β write one that accurately describes data collection, even if it's minimal. Tools like Termly generate compliant policies for free.
Once approved, updates go through the same review process. Adalo's "Publish Update" pushes changes to your live app after re-submission. Plan a 2-3 day buffer for updates to clear review.
Progressive Web App (PWA) publishing is an alternative if you want to skip app store gatekeeping. Adalo supports PWA export β users install via browser instead of downloading from a store. You lose discoverability (no App Store search) but gain control and zero publishing fees. For B2B tools or internal apps, PWAs work fine.
What Nobody Tells You About Adalo's Limits
Database performance collapses around 5,000 records per collection. Honestly, production Adalo apps that scale past 8K users hit constant timeouts until old data is archived. Adalo's Postgres backend isn't optimized for large datasets or complex queries. Pagination helps, but list rendering slows with 100+ items.
There's no version control or rollback. If you break something in the editor, you'll manually rebuild it. Duplicate your app before major changes β Adalo lets you clone projects, effectively creating backups.
Custom code is limited to CSS and JavaScript snippets for styling. You can't add native Swift/Kotlin modules or modify the generated app package. If you need a feature Adalo doesn't support (e.g., Bluetooth, AR, complex animations), you're stuck.
Pricing scales with app users, not downloads. The $52/month plan includes 200 app users. If 500 people install your app, you pay $172/month. "Users" means distinct accounts, not active users β deleted accounts still count. This makes user management critical. Implement account deletion flows and periodically prune inactive users.
Adalo's marketplace includes paid plugins (Stripe checkout, Google Maps, AI chat) built by third-party developers. Quality varies wildly. Test any plugin in a duplicate app before integrating β some are abandoned or poorly documented.
Offline mode doesn't exist. Your app requires internet connectivity for every action. Users in spotty coverage zones (subways, rural areas) get frequent errors. Cache data using Adalo's "Set Screen Data" action to store values temporarily, but it's not true offline-first architecture.
The editor occasionally corrupts projects β screens might lose component wiring or actions reset to default. Adalo support usually restores from backup within 24 hours, but expect downtime. Don't build mission-critical apps on Adalo if you can't tolerate occasional outages.
Common Mistakes That Kill Adalo Projects
Over-nesting components breaks performance. Adalo's rendering engine struggles with lists inside lists inside conditional wrappers. Keep component hierarchies flat. If you need nested data (e.g., tasks grouped by project), restructure to multiple screens rather than one complex view.
Skipping user testing before publishing. Adalo's preview mode doesn't replicate real device behavior perfectly. Test on actual iOS and Android devices using Adalo's mobile preview app before submitting to stores. Layout breaks, button sizing issues, and broken navigation might not appear in desktop preview.
Ignoring data relationships. Beginners create separate collections for related data instead of using relationships. Example: creating "UserProfiles" and "Users" as separate tables instead of adding profile fields to the Users collection. This doubles database calls and complicates queries. Use relationships for one-to-many (user has many tasks) and many-to-many (users belong to many groups) connections.
Hardcoding values instead of using data. Typing text directly into components when it could come from a database is wrong. Even static content (help text, feature lists) should live in a "Content" collection so you can update it without redeploying.
Not planning for scale from day one. Adding user roles or payment tiers after launch requires rebuilding data models. Decide early: single-user or multi-user? Free or paid? Admin controls or user-generated content? These architectural decisions are hard to reverse once you have production data.
FAQ
Can I migrate my Adalo app to real code later?
No clean path exists. Adalo doesn't export source code β you'd rebuild from scratch in Swift/Kotlin or React Native. Treat Adalo as an MVP tool, not a long-term platform. If the app gains traction, budget for a custom rebuild within 12-18 months.
How do I handle payments in Adalo apps?
Use Stripe's payment link integration or the Adalo Stripe plugin ($20 one-time). Configure products in Stripe, then use Adalo's "Open Link" action to direct users to Stripe checkout. Stripe handles payment processing and redirects back to your app. Store subscription status in your Users collection via webhook or manual sync.
What's the realistic user limit before Adalo breaks?
1,000-2,000 active users depending on feature complexity. Apps with heavy list views, frequent database writes, or real-time updates hit limits sooner. Monitor app performance using Adalo's analytics dashboard β if load times exceed 3 seconds regularly, you're at capacity.
Can I white-label Adalo apps or resell them?
Adalo allows white-labeling on the Business plan ($200/month). You can remove Adalo branding and use custom domains for PWA versions. Reselling requires each client to have their own Adalo account and subscription β you can't build once and deploy to multiple clients under one license.
Your Next Step: Build the Simplest Possible Version
Don't start with your full product vision. Build one core workflow: user signs up, completes one action, sees a result. For a task manager, that's create account > add task > view task list. For a booking app, it's browse services > select time > confirm booking.
Spend two hours today setting up that single flow in Adalo. Skip settings screens, user profiles, or advanced filters. Get the basic CRUD (create, read, update, delete) working first. Once data flows correctly, layer in features one screen at a time.
Test on your phone before adding complexity. Install Adalo's preview app, scan your project's QR code, and use the app like a real user. You'll immediately find UX issues invisible in desktop preview. Fix those before building more.
Set a deadline: publish an MVP within two weeks. Adalo's whole value is speed β if you're spending months perfecting an Adalo app, you've missed the point. Ship it, get feedback, and iterate or rebuild in custom code if it gains users.
For more insights on optimizing your app development process, check out our article on Notion vs. Evernote: Which Tool Ships Faster? to see how different tools can impact your workflow. Additionally, if you're considering other platforms, you might find our comparison of Webflow vs. WordPress: Which is Best for Solos? helpful in making your decision.
Pricing accurate as of publication (September 2026). Vendor pricing changes without notice β always confirm the current amount on the provider's own site before deciding.
Editorial note: This article was produced with AI assistance and reviewed by Javier Valencia. Verified facts are distinguished from editorial opinion throughout the text. External sources linked are independent of NewsTide.
Sources
More in Indie Hacking
πͺπΈ Also available in Spanish: Leer en espaΓ±ol