I am investigating using Universal Links in Push Notifications for Deep Linking into an iOS app. This is so I can future-proof for web.
A lot of the examples and tutorials assume the user will select a universal link from a web-site to deep link into an app.
I want to use Universal Links in Push Notifications instead of the regular URL Schema approach.
I have read the Apple docs
https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html
However, I am unclear on at this point if I am just using the Universal Link to open the App via a Push Notification, do I still need to set up all the configurations such as creating and uploading an apple-app-site-association file to the root of the web server.
Is this approach to using Universal Links in Push Notifications to Deep Link into an area of the app a recommended approach since Apple seems to be discouraging the use of URL Schema's in general or are Push Notifications a special case?
Push Notifications and Universal Links are two different animals although they both serve to get the user into the application.
With a Universal Link, Safari on the iOS device is opened first in case the app isn't installed. If the app is present, the user is immediately bounced to the app from Safari with the URL passed to the AppDelegate method application(_:continue:restorationHandler:). If the app isn't present, Safari opens the URL of the Universal Link. Setting up the apple-app-site-association file is necessary here to validate that you own the destination URL in question and can redirect users from the web site to the app instead. Universal Links are better for user-initiated interaction (clicking a link in an email, etc.)
Push notifications on the other hand communicate directly with the device over TCP/IP to pass the message from APNs to the iOS device (see APNs Overview for more info). Safari isn't involved and the user taps the notification on the iOS device (for example) to open the notification and go to the destination. Your destination isn't passed by URL like with Universal/deep links, but with extra JSON in the notification payload that you can process in your app (see Creating the JSON Dictionary for this structure). There is no apple-app-site-association with push notifications as there is no web site involved. You are communicating directly from APNs to your app and using certificates typically to ensure that only you can open your app with a push notification. Remote push notifications are great for developer-initiated interaction to engage the user.
Hope that helps clarify things!
Related
clevertap Deeplink notification is redirecting to safari instead of mobile app when app is in background ,
Can any one help on me on this
I believe you are trying to understand why your Deeplink is opening in the browser first and then redirecting you to the Application
If a deep link starts with HTTPS on iOS devices, the default behavior
is to open that link in the browser. If you have implemented a
universal link, safari will show you a banner at the top asking if you
want to open it in the app.
You can read about it more here:-
https://developer.apple.com/documentation/xcode/allowing_apps_and_websites_to_link_to_your_content/defining_a_custom_url_scheme_for_your_app
If you would like to open the app directly from the push notification
using an HTTPS link, you should not include the URL in the deep link
input field. You can instead pass the HTTPS: deep link as a custom
key-value pair, then In you app you can read the custom key-value pair
and decide the redirection logic, or if you don't wanna pass URL, you can also pass an identifier which needs to be handled in your app.
Please check this image for more Information:
I'm trying to implement Firebase Dynamic Links in an iOS app. The goal is to have a clean URL for marketing purposes so folks can share links on social media. The idea is folks will share the clean URL that starts with my domain name.
When the app is installed following a click on that link, we want to be able to track who referred the app install by looking at the payload delivered by Firebase. I think this goal is similar to Firebase's use case to convert web users to mobile app users.
An example link I would like to provide for sharing on social media is: http://example.com/my-payload-here
I've tried several cases but I'm not able to get the behavior I'm looking for in any case. Has anyone implemented this successfully before?
Here is my test procedure:
Uninstall the app
Send the link to be tested in an iMessage to myself
Tap the link on my iOS device (not using a simulator)
Install the app from the App Store
Launch the app after download completes by tapping "Open" button in the App Store
Below are my findings:
Short link generated from the Firebase Console (https://xyz.app.goo.gl/ABCD) - Link opens in App Store. I install the app. When I launch the app after installing, the payload is not delivered. If I quit out of the app, go back to the link in iMessage, and launch a second time, the payload is delivered.
Long link identical to the "Long Dynamic Link" from the Firebase console for the link generated in #1 (https://xyz.app.goo.gl/?link=http://example.com/my-payload-here&isi=12345&ibi=com.example.MyApp) - behavior is identical to #1
Short link using my domain (http://example.com/redirect/my-payload-here, configured to 301 redirect to URL in #2) - Opens in App Store. I install. When I launch the app after installing, the payload is not delivered. If I quit out of the app, go back to the link in iMessage, and launch a second time, the link still goes to the App Store.
Some questions I have:
Why isn't the payload delivered on the first launch for cases 1 and 2?
How can we make this launch the app and deliver the payload instead of going to the App Store?
I've also consulted the Firebase flowchart for the deep link in case 2.
Google Firebase team added support for custom subdomains to Dynamic Links.
You can now specify up to five custom page.link subdomains for your Dynamic Links. Short links using these new custom subdomains look like the following example: https://example.page.link/abcXYZ
Firebase Dynamic Link domains assigned on projects couldn't be deleted at this time.( firebase team is working on it.)
You can now whitelist the URL patterns that can be used as a Dynamic Link's deep link (link) or fallback link (ifl, ipfl, afl, ofl). If you define a whitelist, Dynamic Links won't redirect to URLs that don't match a whitelisted pattern.
You can try both of these features in the Firebase console.
This is not currently possible with Firebase. If you need whitelabeled URLs, you either need to build it yourself or use a more powerful link platform like Branch.io (full disclosure: I'm on the Branch team).
To answer your questions specifically:
I have implemented Firebase Dynamic Links in a testbed app and can confirm that linking through installation the first time does work for both long and short URL variants. There is likely something wrong with your AppDelegate config, so we can take a look at that if you want to share code.
Firebase does not support custom domains at this time. In theory (if you can solve the first issue above) you could get this working for first install by using a redirect like you have tried. However, you'll never be able to get it to launch the app with Firebase link data once the app is installed. This is because Universal Links work based on the domain of the link, and don't even request the web destination. Even if you enable Universal Links manually on your own domain, the app will open immediately without ever calling Firebase and the link data will never be set.
After contacting apple support, it appears that passbook push notifications can only deep link to native iOS apps, not to a browser. I'm looking to deep link to an actual URL that opens in safari (the actual browser is irrelevant).
Scenario: user received a push notification through passbook. User taps on notification. Notification deepkingks to a browser web URL
Has somebody found a work around? Thanks!
I am developing an application that does exactly 2 things.
1) Opens a UIWebView
2) Uses push notification
I am opening a UIWebView where i load an external URL , and there the user can subscribe to various kinds of events. After he subscribes he can get push notifications about them.
I am asking because some people told me that their apps got rejected when they were just loading an external URL , because apple said it could better be a web page and not an iOS app.
But in my case where i use push notifications? Does it count differently?
The reason why WebView only apps are beeng rejected is because they dont use any of the features that the framework is offering. I got in an application that had only one view for log in, and after log in, the response was URL from server that I was showing in WebView.
You will never know unless you try, but I think it will get in.
I have successfully submitted 3 apps which are all WebViews but with Push Notification functionality. As long as you have Push Notifications in your app you will meet the guidelines of having framework dependant features in your app rather than just being a simple WebView in a mobile app.
"Your app did not include iOS features. App Store apps should use native iOS buttons and include iOS features other than just web views, push notifications, or sharing."
source: Apple rejecting Ionic apps, date: Jan, 2019
“Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience. Specifically, we notice that most of the app content links out to Safari. As such, the experience it provides is similar to the general experience of using Safari. Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store. … the App Store does not accept or distribute web apps.”
source: App Store Rejection 4.2 - Design: Minimum Functionality, date: Dec 2020, But seems it was resolved.
Conclusion: YMMV = Your Mileage May Vary.
This may be a pretty basic question, but here goes. I develop an iPhone app that is a third-party client for a popular webapp. This webapp has it's own iPhone app to which it publishes push notifications. Is it possible for my app to register to receive push notificatons Sent by the webapp and intended for the webapp's native iPhone app? Or is this prevented by certificate magic as I suspect?
Apple allow you to have apps with either a generic app ID in the format:
12345678.*
Or an explicit app ID in the format:
12345678.com.myCompanyName.myAppName
However, they only allow applications with explicit app IDs to register for APN (Apple Push Notification) Service. Therefore it is not possible for more than one specific iPhone app to receive the same notification.
As Farcaller says, this is not a technical limitation but an imposed one.
Hope that helps
From the technical point of view, you can register at another server with device token. You just need to know, where to register and what protocol does it use. Still you wouldn't be able to receive notifications, as they are routed depending on the application id, and you can't mimic that.