Adalo Help Guide: Common Issues and Fixes

Adalo is a capable no-code app builder, but a few issues come up again and again once you move past a simple prototype. This guide walks through the six that generate the most support threads, with a real fix for each, and ends with an honest note on when it makes more sense to stop debugging and hand the work off. Details below reflect Adalo as of mid-2026, so check the current docs before you change settings. If you are weighing whether to keep building yourself or move to a done-for-you setup, our overview of how Rehost works covers the trade-off.

The six issues at a glance

Before the deep dives, here is the whole guide in one view. Each issue has one root cause and one fix to start with.

1. The app feels slow

Slowness is almost never the platform itself. It is usually one screen asking the database for too much at once. The common culprits, in order of how often they bite:

• Many queries on one screen. Every list, count, and visibility check is a separate read. A dashboard with eight lists fires eight queries before anything paints. Split the screen, or move secondary data behind a tab or a button.
• Long lists with no limit. A list that loads every record will crawl once you have a few thousand rows. Set a list limit (start around 20) and let users page or filter instead of scrolling everything.
• Heavy images. Full-resolution uploads get downloaded on every view. Compress to roughly 100 to 200 KB before uploading.
• Deep relationship lookups. Filtering a list by a relationship two or three hops away forces extra reads. Flatten the data so the value you filter on lives on the record itself.

Fix the screens with the most lists first. That is where the time goes.

2. Push notifications stopped working

Push is the single most common "it worked yesterday" complaint. Run through this checklist before assuming a bug:

• Test on a published native build, not the preview. Push does not fire in the web previewer. It needs the real app installed from TestFlight, the App Store, or Google Play.
• Confirm the user granted permission. If a user tapped "Don't Allow," the device blocks delivery until they re-enable it in their phone settings. Your app cannot override that.
• Check the target user. Notifications go to a logged-in user record. If the action targets the wrong user or no user, nothing arrives.
• Re-check your provider keys. If you use OneSignal, a regenerated App ID or REST API key will silently break delivery. Re-paste both into Adalo's settings.
• Apple credentials expire. Push can stop with zero app edits when an APNs certificate or key lapses. Renew it and republish.

3. Apple or Google rejected the app

Rejections feel personal but they cluster around a few guideline numbers.

Reply to the reviewer in Resolution Center with exactly what you changed. A clear note often clears a resubmission faster than the next build.

4. Visibility conditions are not behaving

The usual surprise: when you add more than one condition to "Sometimes Visible," Adalo treats them as AND. Every condition must be true for the element to show. Builders who expect OR logic get an element that never appears.

• For AND, stack conditions on one element as normal.
• For OR, duplicate the element and give each copy one condition. Stack the copies so whichever one qualifies shows.
• Empty is not zero. A blank number field and a field set to 0 are different. Test for both if either should hide the element.

5. Database relationships return the wrong data

The most common relationship mistake is building it from the wrong collection, which inverts the data flow and leaves lists empty or duplicated. The mental model that prevents it:

• Read the relationship as "parent has many children."
• For "Users have many Orders," create the relationship from the Users collection, not Orders.
• Then a list of a user's orders filters cleanly on "Logged In User > Orders."

If a relationship already points the wrong way, rebuilding it correctly is faster than patching filters around the mistake.

6. External collections show no data

External collections connect Adalo to an outside API such as Xano. When they go blank, work through these in order:

• ID format. Adalo expects numeric IDs. UUIDs, text IDs, and IDs with special characters are not supported and will return nothing.
• Plan level. External collections require a paid plan (Professional or higher as of 2026). On a lower plan they simply will not load.
• Response shape. The API must return a JSON array of objects with the exact field names you mapped. One renamed field breaks the mapping.
• One failed call freezes the screen. A single bad request can stall everything. Test the endpoint on its own first, and check it in an incognito window to rule out caching.

When to stop fighting the tool

Adalo is a fine fit for a focused internal app or an early test of an idea. The trouble starts when a real business depends on it and you become the unpaid operations team: re-checking push every release, babysitting App Store reviews, and explaining to your own staff why a screen is slow. If you are spending more hours maintaining the app than running the business it serves, the tool is no longer saving you anything.

That is the build-vs-buy line. You can keep absorbing the upkeep yourself, or hand the whole job to someone whose actual job it is.

FAQ

Why does my Adalo app load slowly even though it is small?

Size of the app matters less than how many queries a single screen runs. A screen with several lists, counts, and relationship lookups fires a separate database read for each one before it can finish loading. Reduce the lists per screen, set list limits, and compress images, and most slowness clears up.

Why do my Adalo push notifications work for some users and not others?

The most common cause is permission. A user who declined the notification prompt is blocked by their device until they re-enable it in phone settings. Other causes are testing in the previewer instead of a published build, or an action that targets the wrong user record.

Can I fix an Adalo App Store rejection myself?

Often yes. Most rejections come from a missing privacy policy, broken iPad layout, no in-app account deletion, or too little native functionality. Address the specific guideline Apple cited, explain the change in the Resolution Center, and resubmit. If the same app keeps getting rejected for different reasons, that is usually a sign the wrapper itself is the problem.

Is it worth migrating off Adalo?

It depends on how much upkeep the app demands and how central it is to the business. A weekend project is fine to keep. An app real customers rely on, where you are constantly firefighting, is usually cheaper to hand to an operator than to keep maintaining yourself. Run your own numbers before deciding.

The bottom line

Almost every Adalo issue has a real fix: trim queries per screen, publish a native build for push, satisfy the specific store guideline, use duplicate elements for OR visibility, build relationships from the parent collection, and feed external collections clean numeric IDs. The harder question is whether you should be the one doing all of that. If maintaining the app has quietly become a second job, let Rehost run it for you. We are a done-for-you operator based in Los Angeles that designs, builds, hosts, monitors, and operates a custom app for you, so your team never logs into a dashboard or debugs a visibility condition again. Plans start at $950/month with no setup fee, billed by monthly active users, and you own the app, the App Store and Google Play accounts, the domain, the code, and the data, all portable if you cancel. Check the math on our app calculator, see the full pricing, then tell us what you are building and we will take it from there.