# How do you fix an Adalo deep link that still opens the PWA fallback?

Publish the latest web version after changing an Adalo deep link fallback, then verify the iOS and Android destinations with the native app removed.

- Canonical URL: https://adalocado.com/answers/publish-deep-link-fallback-changes
- Verification: Documented from current sources
- Topic: Publishing and Performance
- Skill level: Intermediate
- Last reviewed: 2026-08-24
- Index status: index-now

## Short answer

Save the new iOS and Android fallback URLs, publish a new web version of the Adalo app, and then test the deep link on each platform with the native app uninstalled. An unpublished change can leave the previous PWA fallback active.

When a deep link keeps using an old PWA fallback, separate configuration from publication. Save the platform-specific destinations, publish the current web version, and test the public link with the native app removed.

The source topic confirms this exact failure mode: the custom fallback was configured, but the tester had not published a new web version. Current Adalo documentation supports platform-specific fallback URLs and the web-publishing workflow. Test iOS and Android independently because each platform has its own destination.

## Intended outcome

A deep link sends users without the native app to the intended iOS or Android fallback instead of an older PWA destination.

## Requirements

- A deep link already configured for the target screen
- Public HTTPS fallback URLs for iOS and Android
- Access to publish the app's web version
- One iOS device and one Android device for platform-specific checks

## Step by step

1. **Set each platform fallback**

   Open the deep-link fallback settings and choose the custom redirect option, then enter the intended public HTTPS destination for iOS and Android separately.

2. **Publish the current web version**

   Save the fallback settings and publish a new web version so the public deep-link service uses the latest destinations rather than the previously published PWA fallback.

3. **Test without the native app**

   Remove the native app from the test device, open the shared deep link, and confirm that iOS and Android each reach the destination configured for that platform.

## Why it works

- Adalo applies a fallback only when the native app is unavailable. The forum author had configured custom store URLs but was testing the previously published web version, which still used the PWA destination.
- Publishing the web version updates the public behavior. Testing both operating systems is necessary because the fallback URLs are configured independently.

## Common failures

### The link still opens the PWA

Confirm that custom redirect is selected for the device's platform, save the latest URLs, publish the web version again, and retest with the native app removed.

### The link opens the wrong store or page

Check the iOS and Android fields separately and open each fallback URL directly in a browser to confirm that it is public and points to the intended destination.

### The fallback never runs

Verify that the native app is not installed. When it is installed and the deep link is valid, opening the app is expected behavior rather than a fallback failure.

## Testing checklist

- [ ] On iOS with the native app removed, open the deep link and confirm that it reaches the configured iOS fallback.
- [ ] On Android with the native app removed, open the same deep link and confirm that it reaches the configured Android fallback.
- [ ] Install the native app, open the deep link again, and confirm that it opens the intended in-app screen instead of either fallback.
- [ ] The latest web version is published after the fallback edit
- [ ] The iOS test reaches the configured iOS destination
- [ ] The Android test reaches the configured Android destination
- [ ] A device with the native app installed still opens the intended app screen

## Limitations

- Adalocado reviewed the current public documentation and the complete forum topic but did not reproduce the workflow in an Adalo project.
- Store availability, universal-link association, device settings, and cached browser behavior can cause failures that publishing the web version alone will not fix.
- Fallback behavior applies when the native app is unavailable; it does not replace the normal installed-app deep-link path.

## Community evidence

### [Deeplink fallback URL not working properly](https://forum.adalo.com/t/deeplink-fallback-url-not-working-properly/65791/3)

The source author reported that the custom fallback began working after publishing a new web version instead of testing the older PWA fallback. Boundary: This is one confirmed builder report and does not isolate every deep-link or store-routing failure.

## Sources

- [Adalo forum confirmed resolution](https://forum.adalo.com/t/deeplink-fallback-url-not-working-properly/65791/3)
- [Adalo Help: Deep Linking Redirection & Fallbacks](https://help.adalo.com/component-basics/inserting-and-editing-screens/deep-linking/deep-linking-redirection-and-fallbacks)
- [Adalo Help: Publishing to the Web](https://help.adalo.com/publishing-apps/publishing-to-the-web)

Markdown version: https://adalocado.com/answers/publish-deep-link-fallback-changes.md