# Fallbacks, installation checks, and results

Canonical HTML: https://p-hatan.com/deeplink-x/guides/fallbacks-and-installation-checks/

DeeplinkX 1.5.8.

For a normal action, DeeplinkX checks native availability and attempts the applicable native transport. If it cannot launch that path, `fallbackToStore: true` permits matching configured store actions. If no store handoff succeeds, the action's web fallback can be used when implemented. `fallbackToStore` defaults to `false`.

```dart
Future<bool> openProfileOnWebIfNeeded() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter', fallbackToStore: false),
);

Future<bool> preferStoreIfNeeded() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter', fallbackToStore: true),
);

Future<bool> tryNativeOnly() => deeplinkX.launchAction(
  Telegram.openProfile(username: 'flutter'),
  disableFallback: true,
);
```

`disableFallback: true` suppresses both store and web fallback. It does not resume the action after the user installs an app. A successful store handoff ends this launch attempt.

### Reading installation checks

Use `isAppInstalled` when your UI has a useful installed-app decision. Native availability can be affected by missing query declarations, unsupported platforms, and provider identifiers. HTTPS links can be handled by a browser without a native installation. Distinguish loading, installed, not installed, and unsupported states where your UI exposes them.

### Reading a Boolean result

`true` means the launch path reported a successful handoff, which can include a fallback. The destination app resolves recipients and routes, and the user completes the interaction. `false` means no supported attempted path reported success; show an appropriate retry or alternative in your application's UI.

Wrap launches in asynchronous error handling when your UI needs to handle unexpected platform/plugin failures. Some native launch failures become `false`; fallback calls can also propagate errors.

### Troubleshooting sequence

1. Verify the chosen constructor and parameters against the currently published version.
2. Check native support for that provider on the actual platform.
3. Confirm only the necessary scheme/package/intent declarations are present in the correct configuration file and location.
4. Check provider credentials, identifiers, region, coordinate system, and licensing requirements.
5. Exercise native-only, web-fallback, and store-enabled policies separately on the target device.
6. Check the final handoff feedback and provide a retry or alternative when launching fails.