The use case is, essentially, this:
the user create some content and uploads it to our server.
our server responds with the URL.
the user sends the URL (eg via text message) to another user.
the other user clicks on the URL. If they have the app installed, they should be taken to the content in the app. If they don't have it, they should still be able to view the content on our site (eg in safari).
This is easy enough, and we have that working, except our URLs are long and we'd like to use shortened URLs. With shortened URLs, the problem is it always opens in Safari, instead of the app, unless we setup a custom domain. (This is described in many places, including here: iOS Universal Links and URL Shorteners).
The docs for google URL shortener indicate that they have overcome this somehow:
Even though App Indexing for iOS is available only in limited release, you can still enable iOS app deep links with goo.gl by implementing App Indexing for iOS. While these deep links may not begin appearing in Search results, they will start working with goo.gl links.
So I installed the app indexing for iOS into our app on a test device and ran it. Then I created a short link but it still opens in my browser, not my app.
Does this really work as advertised? Do I have to wait longer? Install the indexer on more apps? Will a created link open in the app right away, or does the content have to be indexed?
...Or am I missing something else?
Related:
Google app indexing for iOS and universal links
UPDATE:
The only way I can see this actually working without a custom domain is if Google added every app they indexed to their apple site association file. All I see is google apps there, so obviously that's not the case.
Stack overflow won't let me link it because it thinks it's a link shortener, but it's close to this:
https://goo. gl/apple-app-site-association
You are exactly right: for this to work, Google would need to add your app to their apple-app-site-association file. Unfortunately that would be impossible even if Google wanted to do so, because Apple puts a size limit of 128 kb on that file.
Integrating the App Indexing SDK was a good thought, but doesn't solve this issue either.
What you need is a (free) service like Branch.io (full disclosure: I'm on the Branch team). This is specifically designed for exactly what you're trying to accomplish, and takes care of all the housekeeping tasks you are running into. You'll be able to create branded short URLs that take you to your app (if installed) or website fallback (if not installed), and the AASA file will be generated automatically for the short URL domain.
Related
I need to open my particular UIViewController when the following link is clicked on the Safari browser:
http://my.sampledomain.com/en/customer/account/resetpassword/?id=24&token=8fbf662617d14c10f4a11f716c1b2285
When this link is clicked on the browser, I need to open my application on a particular screen and retrieve the data from this url. For example:
id = 24
token = 8fbf662617d14c10f4a11f716c1b2285
...and pass it to that particular UIViewController.
How can i do that?
What you are describing is called Deep Linking. It's a very common app feature to implement — most apps have it — and conceptually, it seems like an easy thing to build. However, it's complicated to get right, and there are a lot of edge cases.
You basically need to accomplish two things:
If the app is installed: open the app and route users to the correct content inside it.
If the app is NOT installed: forward users to the App Store so they can download it. Ideally, also route users to the correct content inside the app after downloading (this is known as 'deferred deep linking').
While not required, you'll also probably want to track all of this activity so you can see what is working.
If the app is installed
Your existing custom URI scheme fits into this category. However, Apple has decided that custom URI schemes are not a good technology, and deprecated them with iOS 9 in favor of Universal Links.
Apple is right about this. Custom URI schemes have a number of problems, but these are the biggest:
There is no fallback if the app isn't installed. In fact, you get an error.
They often aren't recognized as links the user can click.
To work around these, it used to be possible to use a regular http:// link, and then insert a redirect on the destination page to forward the user to your custom URI scheme, thereby opening the app. If that redirect failed, you could then redirect users to the App Store instead, seamlessly. This is the part Apple broke in iOS 9 to drive adoption of Universal Links.
Universal Links are a better user experience, because they are http:// links by default and avoid nasty errors. However, they are hard to set up and still don't work everywhere.
To ensure your users end up inside the app when they have it installed, you need to support both Universal Links and a custom URI scheme, and even then there are a lot of edge cases like Facebook and Twitter which require special handling.
If the app is NOT installed
In this case, the user will end up on your http:// fallback URL. At this point, you have two options:
Immediately forward the user directly to the App Store.
Send the user to your mobile website (and then use something like a smart banner to give them the option of going to the App Store).
Most large brands prefer the second option. Smaller apps often go with the first approach, especially if they don't have a website.
To forward the user to the App Store, you can use a Javascript redirect like this:
<script type="text/javascript">
window.onload = function() {
window.location = "https://itunes.apple.com/app/id1121012049";
};
</script>
Until recently, it was possible to use a HTTP redirect for better speed, but Apple changed some behavior in Safari with iOS 10.3, so this no longer works as well.
Deferred deep linking
Unfortunately there's no native way to accomplish this last piece on either iOS or Android. To make this work, you need a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do.
Bottom line
Deep linking is very complicated. Most apps today don't attempt to set it up by building an in-house system. Free hosted deep link services like Branch.io (full disclosure: they're so awesome I work with them) and Firebase Dynamic Links can handle all of this for you, and ensure you are always up to date with the latest standards and edge cases.
See here for a video overview an employee at Branch made of everything you need to know about this.
I am planning to use app link from FBSDK to invite using my iOS app via email.
I know if my iOS app was installed on the device it will be opened when I select the link and handle invite token in URL.
But how about if my app was not installed?
After user install it from App Store can I handle invite token also?
Hope anyone used to work with this scenario can help me.
There are a lot of reasons why what you're trying to do won't come out the way you want it to. Let's dive in...
App Links don't work anymore
Facebook created App Links in 2014 as an open standard to solve the limitations of URI scheme deep links. App Links have two main components:
A set of meta tags to add to the web page destination of a standard http:// link. These tags specify the custom URI scheme location of corresponding content inside the native app, and the behavior that should occur if the app is not installed.
A routing engine for use inside apps that support opening links. This engine checks the destination URL for App Links tags before opening it, and then launches the corresponding app or executes the specified fallback behavior.
App Links were supposed to be an open-source standard to change the world, making app-to-app deep linking simple and universal. Unfortunately Facebook has decided they actually don't want that world (it's much better for them to keep users inside the Facebook app — see Instant Articles if you don't believe me), meaning the App Links standard is essentially dead. It's no longer supported on the iOS Facebook app, and Applinks.org isn't even a separate website now.
App Links were not designed to work with email (or essentially any app except Facebook)
Even if it were still supported by Facebook, the App Links standard has a critical flaw: it requires work by both the origin and destination apps. While the meta tags component saw wide adoption, the only major implementations of the routing engine were in the core Facebook and Messenger apps.
To function as you want, where deep linking can occur from links in emails, the routing engine component would need to be implemented in any email app where your link could possibly be clicked. This was never going to happen for apps like the default iOS Mail app from Apple, or the Gmail app, for example.
App Links had no meaningful support for deferred deep linking
Deferred Deep Linking (Deep Linking refers to using a link to open your app directly to a specific piece of content, and Deferred means that it works even if the app isn't installed first) requires a remote server to close the loop. You can build this yourself, but you really shouldn't for a lot of reasons, not the least of which being you have more important things to do. You'll notice that neither of the two App Links components included a remove server to retain link data through install, so deferred deep linking was never properly supported in the core App Links standard. Facebook ads make use of the partial support for deferred deep linking offered by the FBSDK in conjunction with App Links, but this only works when the link/ad is clicked within a Facebook app and the receiving app has the FBSDK integrated.
Deferred deep linking is tough anyway
Moving on from App Links, deferred deep linking is still complicated. URL schemes don't work, because they always fail with an error if the app isn't installed. Apple's newer Universal Links in iOS 9+ get closer in that they at least don't trigger an error if the app isn't installed, but you'd still have to handle redirecting the user from your website to the App Store. You can't pass context through to the app after install with Universal Links, so you wouldn't be able to send the user to the correct item, and they actually aren't supported in a lot of places.
Deep linking out of email on iOS is very hard
Almost all email links involve some sort of click tracking, which is always implemented as a link wrapping redirect. This isn't technically a problem if the user doesn't have your app installed, but if they do, Universal Links don't work with wrapped links. If you're building it yourself, you'll either need to completely disable click tracking in your emails, or accept that deep links won't work there.
Bottom Line
App Links were never the solution you needed. A free service like Branch.io (full disclosure: they're so awesome I work with them) or Firebase Dynamic Links is what you need. Both services support deferred deep linking, out of Facebook or almost any email app. Branch is more powerful and offers far more features, and works with major email senders to offer a solution for deep linked email (the only one on the market today).
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.
This is the first time I upload an app to apple app store. After weeks for reviewing, finally, I get my app listed on apple app store. But the problem is, now seems like my app app-store page is only viewable from iTunes. When I try to open it in a browser, it will shows "Connecting to the iTunes Store...". Why is it my app can't be the view from the browser? Why did another app can? How to fix it?
Short answer: It seems, you cannot fully predict the behavior of an app store link for a certain user. You being redirected doesn't mean other people will be redirected right away as well. Your app's country/language availability, users' app store region and language settings, the specificity of the app store link (which has optional components and alternative styles), and the browser cache all seem to have a say.
Added details: After experimenting with this a lot, it seems to me that the behavior of the link (or rather the response from the Apple server to requesting it) depends on the language/country version being requested, my own current country/language defined in iTunes/my app store account, plus some caching issues. So, whether a preview page is shown in the browser, or iTunes is attempted to be opened right away depends on several factors and doesn't always have the same result (for different users). In fact, two consecutive attempts to open the same URL can have different redirect behavior.
I noticed that a full app store link like https://itunes.apple.com/us/app/keynote/id361285480 more likely leads to the preview web page, if the app is available in the language/country referenced ("us" in the example) and there is no prior request cached in which I clicked through to the app in iTunes. If the app isn't available in the referenced location, or any other information is missing in the link for the Apple server to identify a particular language version on the preview website, or there is cached data that makes Apple confident enough to redirect you to iTunes directly (or it's Friday 13th and the moon is right behind the sun by pure chance...) then you may see a redirect instead.
For posting app store links in the likes of Facebook, Apple's app linker seems to produce URLs with the nicest preview snippets (and not: "Connecting to the iTunes store"), when putting in the right country. So, these generated URLs seem to be most complete/specific.
If your app is intended for a specific region, AppStore connect will still give you a URL with .../us/... in it. Changing it to the respective local region seems to fix the problem for me.
For an example,
given URL: https://apps.apple.com/us/app/yourcompany/id123456
If the app is for Norway region, change the URL to: https://apps.apple.com/no/app/yourcompany/id123456
Is it possible to read the contents of another application installed on an iPhone? What about from an extension or keyboard?
I'm trying to come up with something that 'checks' other apps to see if they have any deep links (like Twitter's Twitter://timeline that takes users straight to the timeline in the Twitter app).
Is there any smart way to check a given app for deep links?
Is it even possible to peek at another app's contents from within my app? I suspect no.
If no, what about making a keyboard or extension of some sort that I can access from an app like Twitter and see its contents, such as a URL deep link?
You don't have much options, you may use -canOpenURL:, but, since iOS9, must include special credentails listing all the custom schemes you want to check.
You can't read other app's contents on a non-rooted device unless this app is sharing a keychain (so it can exchange data via the shared keychain). The same thing goes with extensions.
iOS has some high bars on security, so, don't expect much or even, anything.
Something you may want is IntentKit. Also there are ideas around the web about standard url query format like MobileDeepLinking.