Problem with iOS DeepLinks - Request to Support Universal Links

[junalmeida]

trafficstars

When using iOS DeepLinks along with OneSignal using a valid LaunchURL, it does not work as expected.

Steps to reproduce:

Configure deeplinks to respond so some url, for example: example.com/page/:data (:data as a parameter) Create a contact with some url as an example: https://example.com/page/1234 Go to that contact and click at that url and see your page working as expected. Send a notification through onesignal with the same url - you will see that url opening in a InAppBrowser. The expected behavior should be the same behavior of the contact test.

[Nightsd01]

@junalmeida This is not a bug - by default the SDK will open URL's with an in-app web view. You can turn this behavior off however by setting kOSSettingsKeyInAppLaunchURL to false in the iOS Settings during initialization

[junalmeida]

@Nightsd01 turning off this option does not solve the problem. Instead, I am redirected to the url in Safari web browser. This behavior is not consistent when using Android. In Android both scenarios works as expected.

[Nightsd01]

@junalmeida Are you sure that you've correctly set up the deep link with the system (iOS)?

If you set kOSSettingsKeyInAppLaunchURL to false, the SDK will simply call UIApplication.shared.openURL, which respects deep links. The fact that it's opening the URL in safari indicates that, for whatever reason, the system doesn't think it's a deep link in iOS.

[Nightsd01]

https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html?utm_source=revxblog

[junalmeida]

Well, I am pretty sure that I followed the docs in the right way, but it is difficult to debug, However, when I test this case using the "Contact" trick, everything works as expected. May I share with you the real scenario? This is the url of ios server side configuration: https://dev-samara.azurewebsites.net/apple-app-site-association This is the entitlements configured:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>aps-environment</key>
	<string>development</string>
	<key>com.apple.developer.associated-domains</key>
	<array>
		<string>applinks:dev-samara.azurewebsites.net</string>
	</array>
</dict>
</plist>

[Nightsd01]

@junalmeida There's a lot more you have to do to get deep links to work (Apple calls them Universal Links).

Did you implement the AppDelegate code in ObjC/Swift yourself, or are you using some dependency to set up the deep link?

[junalmeida]

@Nightsd01 Reading the link you just provided, this statement called my attention:

It’s important to understand that if your app uses openURL: to open a universal link to your website, the link does not open in your app. In this scenario, iOS recognizes that the call originates from your app and therefore should not be handled as a universal link by your app.

So, if SDK calls openURL as you said, I guess that this might be the problem.

[junalmeida]

@Nightsd01 As I am using the ionic deeplinks plugin, I guess that the AppDelegate was handled by it. And it is working when I click the contact trick:

[Nightsd01]

@junalmeida Good observation!

Here is what I would recommend: deep links are really only useful for other apps or a website to be able to open your app directly. But for push notifications, deep links are unnecessary since the push notification will already be launching your application.

Instead of using deep links, I would recommend using your existing deep link navigation logic to determine what should happen when a user taps a notification. So in short, don't set the launch URL, use the additional data field and handle the navigation appropriately.

[junalmeida]

@Nightsd01 Actually I am using deeplinks in production already, but with custom URLs (samara://etc). I have a requirement to allow the same notification to work using Google Chrome at a PC, so I decided to implement deeplinks using real urls. The problem is that I will need to send different push notifications, one exclusively for iOS. This is an overhead in my implementation.

[Nightsd01]

@junalmeida Unfortunately I don't think our SDK even can know if something is a universal link or something else. I do not see how our SDK could actually solve this problem but I will do some research.

It kind of obviates the entire purpose of deep links if they are getting launched by the app itself.

In any case, I would recommend using different notifications for Chrome vs. the app itself.

[junalmeida]

@Nightsd01 Is there a way to catch the notification and cancel the LaunchURL action for ios only?

[Nightsd01]

@junalmeida you would have to modify our iOS SDK to do this (Objective-C).

[Nightsd01]

@junalmeida we’ve decided that in the next few weeks we will be adding a delegate method in our native iOS SDK that will allow developers to override the SDK’s launch of the URL at runtime. Something like shouldOpenURL(url) -> Bool

That way the developer can see at runtime if it’s one of their deep links and if so, allow them to handle it themselves.

We are also considering an alternative idea where developers can set a “deep link scheme” property on the SDK during initialization. This way the SDK can detect deep links and handle them appropriately.

[junalmeida]

@nightsd01 that delegate would be awesome.

I am not sure I understood well about the alternative idea on deep link scheme, but using deeplink custom scheme is not a problem, all works well. The problem is when I use a deep link with real url on https scheme.

[junalmeida]

@Nightsd01 any update on this?

[CarioniStefano]

No update I suppose

[iggyto]

@Nightsd01 any updates on this? We see a shouldOpen completion in the .h file, but don't know how to use it...

[bagbyte]

I'm having the same issue, on Android it works fine, but on iOS it doesn't.

To verify the deeplink of my app are correctly configured, I've followed those steps:

1. Paste the Launch URL used in the notification in a note
2. Click on the URL
3. The app is opened and I'm redirected to the correct page within the app

When I click on the notification, instead, the app is opened, but then the URL is opened in Safari.

Note 1: I'm using kOSSettingsKeyInAppLaunchURL: false Note 2: I've been following the steps in the documentation to create the OneSignalNotificationServiceExtension, but the app wouldn't build due to some errors, Googling them I've found out I had to link 2 extra Libraries (CoreGraphics and WebKit) in the Build Phases of the OneSignalNotificationServiceExtension Note 3: From my Podfile.lock I can see the version of OneSignal installed is the 2.14.3

Can you please reopen this issue?

[bagbyte]

@Nightsd01

Update

The same URL works perfectly when used in an In-App button (the deep link works), but when used in the Launch URL of a notification, it doesn't (it keeps opening Safari)

[mhicks-e2log]

Also having this same issue. Have confirmed that deep linking with universal link works but when clicking on the notification from OneSignal it launches in Safari.

FWIW, I found this post with similar issue: https://stackoverflow.com/questions/57492989/how-do-i-open-https-url-from-one-signal-push-notification-within-my-webview-reac

I just feel like having to handle this with custom data fields seems overly complex.

[jfishman1]

These were the steps I took to reproduce this issue:

SDK 3.0.0 Beta 1

Within Xcode Signing & Capabilities click + Capability and search for/add Associated Domains to your project.

Within the Associated Domains of Xcode add: applinks:yoursite.com

My site is https://onesignaldemo.github.io so my Associated Domains contains: applinks:onesignaldemo.github.io

Create a file called apple-app-site-association (no file extension) and add the following code:

{ "applinks": { "details": [ { "appIDs": [ "99SW8E36CT.com.onesignal.momenta" ], "paths": [ "*", "/", "/posts/*", "/checkout" ] } ] } }

Upload this file to your server so it is accessible at the root directory of your site. For example: https://onesignaldemo.github.io/apple-app-site-association

App Delegate code is setup like the example here: https://documentation.onesignal.com/docs/links-deep-links-and-urls#ios-universal-links

I send a push with Launch URL: https://onesignaldemo.github.io/checkout

Click it, opens the app and shows this:

Clicking "Open" takes me to my site in Safari Clicking "Cancel" does nothing.

If using the site url itself in the launch URL: https://onesignaldemo.github.io

It opens safari then links back to the app.

Current workaround.

Do not use Universal Links within OneSignal's Launch URL

set the launch url link to have a protocol link:// instead of https://

It can then be handled programmatically with the code shown here: https://documentation.onesignal.com/docs/links

[davicedraz]

I was facing the same problem here, with my ionic app.

Previously, I was passing the deeplink through an https:// URL. The expected behavior of deeplink is that the app would redirect to a specific app page, but instead the InAppBrowser was always called.

So, as it says here in the documentation, the solution for me was to change the deeplink protocol. Instead of using web_url, now I send it as app_url and works fine.

[nunoarruda]

Same issue here. I'm listening to deep/universal links events with https://capacitorjs.com/docs/apis/app#addlistenerappurlopen

Tapping a push notification on Android triggers deep/universal links:

Tapping a push notification on iOS doesn't triggers deep/universal links:

Clicking on regular HTML links works fine on both Android and iOS.

[selcuk-sahin]

For anyone having the same problem, Our solution was to set launchURL for web and app differently. Like:

• launchURL for web => https://www.example.com/1
• launchURL for app => app://example.com/1

I noticed the schema ('app' above) didn't matter as intent was to open app anyways. From this point, our app handles both URL's as we expected.

[mguay22]

This is also an issue for me. Universal links do nothing when paired with the url parameter. The same link works perfectly fine when clicked on through SMS, etc.

I've had to resort to passing the ID I need to open the correct screen through the data parameter.