DeepLink initially opens app to a non-existing screen (iOS only)

[BennyG93]

Report

Plugin Version

"expo": "~50.0.17",
"react": "18.2.0",
"react-native": "0.73.4",
"react-native-appsflyer": "^6.14.3",

On what Platform are you having the issue?

iOS

What did you do?

We generate a branded OneLink link either manually in the AppsFlyer dashboard or programatically using generateInviteLink().

It will look something like: https://invite.pickem.social/WGMu/j8ekkwge

We share that link with to test the deep linking feature of OneLink.

What did you expect to happen?

When the app is already installed, we expect the app to be automatically opened, the deep link to be resolved, and then our custom logic is executed based on the data retrieved from the query params.

What happened instead?

On Android devices this works exactly as expected, the app initially opens to the home screen, the deep link is resolved along with the query param data, and we navigate the user to the expected location based on the data.

On iOS, when the app is launched from the link, it tried to open to a page that matches the URI in the OneLink URL, for example /WGMu/j8ekkwge

Please provide any other relevant information.

When reviewing the logs of the device, we can see the data from the params in the link is available, but because the app is initially opened to this non-existing page, our code is not executed, and we cannot navigate the user to correct location.

We noticed that the data from the OneLink link is resolved differently when comparing the logs of a Android device and iOS device

iOS logs:

Android Logs:

The main difference (I think) is that the "link" value in android is pickem:// which results in the app opening to the home page initially, but on iOS the "link" value is the full https:// url which results in the app opening to the path in the URI .

[github-actions]

👋 Hi @BennyG93 and Thank you for reaching out to us.
In order for us to provide optimal support, please submit a ticket to our support team at [email protected].
When submitting the ticket, please specify:

• ✅ your AppsFlyer sign-up (account) email
• ✅ app ID
• ✅ production steps
• ✅ logs
• ✅ code snippets
• ✅ and any additional relevant information.

[idolago94]

The same issue.
@BennyG93 Have you found a solution?

[BennyG93]

Hey @idolago94, I believe we know the issue, although we have not had the time to implement it ourselves.

On this Expo page about Customizing links, they state the following:

"Expo Router will always evaluate a URL with the assumption that the URL targets a specific page within the app."

So we think it must be expo itself reading the URL and by default trying to navigate to a screen at the location defined by the URI.

On this same page, they suggest some solutions, but we haven't tried any of them yet, hope that helps!

[idolago94]

Hey @idolago94, I believe we know the issue, although we have not had the time to implement it ourselves.

On this Expo page about Customizing links, they state the following:

"Expo Router will always evaluate a URL with the assumption that the URL targets a specific page within the app."

So we think it must be expo itself reading the URL and by default trying to navigate to a screen at the location defined by the URI.

On this same page, they suggest some solutions, but we haven't tried any of them yet, hope that helps!

The link Ben shared here should work. The issue is that AppsFlyer does not provide an option to retrieve the link’s information using a function that takes the link as input and returns its data. Instead, they only provide the onDeepLink event. However, this is not useful in this case because Expo provides a function that is supposed to return the intended path.

It would be very helpful if they added such a capability to the SDK or even via an API.

[Georg7]

@idolago94 Does that mean that there is no way to generate a OneLink URL that goes to a specific route?

Our issues is the same: The deeplink ends up on my-app://123/ route - 123 is our OneLInk template id. Something really seems off here. We've updated the fallback route in the template settings and set the same fallback route in the af_dp parameter when generating the link.