Fix cold start deep link handling #108
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add deep link caching in Superwall class for links received before SDK configuration - Implement _processPendingDeepLink() to handle cached links after configuration completes - Add handleInitialDeepLink() helper method for cold start scenarios - Update example app to handle initial deep links using appLinks.getInitialLink() - Move deep link setup before SDK configuration to prevent race conditions - Improve logging with more descriptive messages for debugging Fixes issue where deep links on cold start were not consistently triggering paywalls due to timing issues between app initialization and SDK configuration. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Remove custom caching mechanism in favor of native iOS SDK queuing - iOS SDK already has static Superwall.handleDeepLink() that queues links before configure - Android uses instance method but keeps existing behavior - Keep existing instance method API for backward compatibility - Add documentation about cross-platform behavior differences The iOS native SDK already handles queuing deep links received before configuration via the static handleDeepLink method and DeepLinkRouter.storeDeepLink(). This is much cleaner than implementing our own caching layer. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Keep existing Superwall.shared.handleDeepLink() API for consistency - iOS implementation now uses static Superwall.handleDeepLink() that safely queues links before configure - Android keeps existing instance method behavior - Example app uses getInitialLink() for cold start and handles before configure - Move deep link setup before SDK configuration to prevent timing issues The key insight is that iOS already has proper queuing via the static method, so we just need to ensure the Flutter wrapper uses it correctly. Much cleaner than adding new APIs. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Convert handleDeepLink to static method that bypasses shared instance - Safe to call before configure() as it directly uses hostApi without instance dependency - Update example app to use static Superwall.handleDeepLink() consistently - iOS: Uses static Superwall.handleDeepLink() that queues links before configuration - Android: Attempts immediate processing, gracefully handles if SDK not ready This provides a clean API where Superwall.handleDeepLink() can be safely called before configure() without worrying about shared instance initialization. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
- Add handleDeepLink() instance method back for backward compatibility - Add handleDeepLinkStatic() static method safe to call before configure() - Update example app to use static method for cold start scenarios - Move deep link setup before SDK configuration in example - Add getInitialLink() handling for cold start deep links Key changes: - iOS: Both methods use static Superwall.handleDeepLink() that safely queues links - Android: Both methods use instance method, gracefully handle if not configured - hostApi available immediately as it just creates method channel communication - Provides both instance (shared.handleDeepLink) and static (handleDeepLinkStatic) APIs This solves the cold start deep link issue where links weren't consistently triggering paywalls due to timing between app launch and SDK configuration. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
…ce method - Keep only the original shared.handleDeepLink() instance method for simplicity - Handle initial deep links after configure() completes in the completion callback - iOS: Uses static Superwall.handleDeepLink() native method that safely queues links - Android: Uses instance method after configuration - Move _handleInitialLink() call to configure completion to ensure SDK is ready This is the cleanest approach that leverages the native iOS queuing without adding complexity or breaking changes to the Flutter API. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
yusuftor
force-pushed
the
fix/cold-start-deep-links
branch
from
548f437 to
a2a184e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Deep links, especially on cold start, were not consistently triggering paywalls in the app. The issue was identified as a race condition where:
Root Cause
_handleIncomingLinks()was called afterSuperwall.configure()in the example appappLinks.getInitialLink()for cold start scenariosSolution
1. Deep Link Caching in SDK
_pendingDeepLinkstatic variable to cache links received before configuration_isConfiguredflag to track SDK configuration statehandleDeepLink()to cache links when SDK not ready_processPendingDeepLink()to process cached links after configuration2. Enhanced Configuration Flow
_isConfigured = truewhen configuration completes3. Cold Start Support
handleInitialDeepLink()static helper methodappLinks.getInitialLink()for cold start scenarios4. Improved Example App
initState()beforeconfigureSuperwall()_handleInitialLink()method to handle cold start deep links_handleIncomingLinks()call fromconfigureSuperwall()Testing
The fix addresses both warm start (app already running) and cold start (app launched by deep link) scenarios:
uriLinkStreamgetInitialLink()and processed after SDK configurationFiles Changed
lib/src/public/Superwall.dart: Added caching mechanism and configuration flow improvementsexample/lib/main.dart: Updated deep link handling order and added cold start supportBackward Compatibility
This change is fully backward compatible. Existing apps will continue to work without modifications, but can optionally adopt the new
handleInitialDeepLink()pattern for better cold start support.Next Steps
For apps experiencing cold start deep link issues:
appLinks.getInitialLink()handling for cold start scenariosSuperwall.handleInitialDeepLink()helper methodFixes the cold start deep link issue identified by Daniil, Duncan, and Yusuf.