Bug or Feature request? The AppsFlyerTracker methods continueUserActivity:restorationHandler: and handleOpenUrl:options: dont return meaningful info

[doogilasovich]

The two methods for handling deeplinks in the ApplsFlyerTracker are incomplete, in that they do not return meaningful BOOL data on whether the URL was handled by the SDK.

- (void) handleOpenUrl:(NSURL *) url options:(NSDictionary *)options;
- (BOOL) continueUserActivity:(NSUserActivity *) userActivity restorationHandler:(void (^)(NSArray *))restorationHandler NS_AVAILABLE_IOS(9_0);

• handleOpenUrl: offers no return value at all.
• continueUserActivity: seems to always return YES, even if the URL is not a valid onelink URL

It would be useful for the calling logic to know whether the URL was appropriately handled by the AppsFlyer SDK or if it should be forwarded to other services that the calling app may be using (iOS native deeplink scheme, bitly, etc).

I would expect that these methods to determine if the URL is valid, and return these results synchronously and immediately.

The UIKit UIApplicationDelegate expects to know whether the URL was handled appropriately, but the ApplsFlyer SDK offers no meaningful way to report this.

Apple Docs:

• continueUserActivity
• openURL

[rromanchuk]

@doogilasovich NO OTHER LINKS BESIDES ONELINK 🤫

[cassianomonteiro]

+1 This is critical when we're also handling our own deeplinks.

[joshuapoq]

Missing this causes a conflict with Firebase if AppsFlyer receives the handleURL with another link before it resolves the one link on first time install. So I would argue not having this check is a bug in AppsFlyer that needs to be fixed.

Order of events:

1. Launch onelink with app uninstalled then install app.
2. On launch both AppsFlyer and OneLink are initialised.
3. Firebase comes back first and calls UIApplication.shared.open(installLink).
4. AppsFlyer receives this and begins resolving the URL.
5. AppsFlyer resolveDeeplink returns no error or deeplinkValue because it's not for AppsFlyer.

AppsFlyer never returns the onelink due to this interruption.

If we wrap the handleOpenURL in a check to make sure the URL is for AppsFlyer then AppsFlyer returns the onelink and the app navigates as expected on install.

EDIT: The link being sent by Firebase looks like an internal install link. It's happening every time but I'm not sure why it's being opened: {app-scheme}://google/link/?request_ip_version=IP%5FV4&match_message=No%2@pre%2Dinstall%20link%20matched%20for%20this%20device%2E

[kattouf]

We also faced this problem, it would be great to see fix in upcoming releases