Compare native-only, web, and store-then-web fallbacks

Make fallback policy explicit and observe native availability separately from the final launch result.

Choose fallback behavior according to the product task. A workflow that requires native functionality may disable fallback; a profile link can allow a web destination; an installation-oriented CTA can opt into a store attempt before the web fallback.

Reusable Flutter example

import 'package:deeplink_x/deeplink_x.dart';

enum DemoFallbackPolicy { disabled, web, storeThenWeb }

Future<bool> openTelegramWithPolicy(DemoFallbackPolicy policy) {
  final action = Telegram.openProfile(
    username: 'durov',
    fallbackToStore: policy == DemoFallbackPolicy.storeThenWeb,
  );

  return DeeplinkX().launchAction(
    action,
    disableFallback: policy == DemoFallbackPolicy.disabled,
  );
}

The example app's FallbackPolicy and FallbackPreset enums belong to the example UI; they are not package APIs. DemoFallbackPolicy above is a local illustrative enum.

Current example presets and defaults

The screen starts with Telegram profile and the Web policy. Presets are:

Preset	Action and default destination
Telegram profile	`Telegram.openProfile(username: 'durov', fallbackToStore: storeFallback)`
Instagram profile	`Instagram.openProfile(username: 'instagram', fallbackToStore: storeFallback)`
Google Maps location	`GoogleMaps.view(coordinate: const Coordinate(latitude: 35.6892, longitude: 51.3890), fallbackToStore: storeFallback)`

The public profile identifiers are demonstration destinations, not official DeeplinkX support channels.

Selected policy	`disableFallback`	`fallbackToStore`	Intended attempt sequence
Disabled	`true`	`false`	Native action only.
Web	`false`	`false`	Native action, then the action's documented web fallback.
Store then web	`false`	`true`	Native action, then matching native store attempts, then web fallback if earlier attempts fail.

Observable behavior and limits

The screen checks whether the provider supports the current platform, then checks installation when appropriate. It presents that status separately from the configured policy and last launch result. Choosing a different preset or policy clears the prior result.

launchAction returns one final Boolean. The playground cannot infer which internal stage succeeded. A successful store handoff completes the operation; it does not wait for installation or resume the original profile/map action afterward. Browser fallback is independent of native installation.

Automatic store fallback uses the utility's native store-selection behavior. If no store attempt succeeds, launchAction can continue to the action's fallback link. Handle unexpected browser-launch errors in the application.

Configuration

Use the Telegram guide, Instagram guide, and Google Maps guide. Include required provider and store entries from the example Android manifest and iOS Info.plist.

UI behavior

Default Telegram/Web constructs fallbackToStore: false and passes disableFallback: false.
Disabled passes disableFallback: true; Store then web opts into store fallback without disabling normal fallback.
Each preset constructs the correct action and destination.
Unsupported native status remains distinct from not installed.
Success/failure presentation reflects only the final returned result; it never names an inferred winning stage.
A successful store attempt stops the operation; failure can proceed to the web fallback.
Repeat launches while pending are suppressed.

Source code

All use cases · Installed-app checks · Map selection