For example, if you open a PDF in Safari, you have the option to open in iBooks - I believe a number of apps have this ability.
How does one "register" the ability of your app to handle such files, and is it possible so that by "long pressing" a link in Safari, you can get the option to open the URL in your app instead of in Safari?
Yes, it is possible.
look at the documentation on "Registering the File Types Your App Supports"
here is a link: https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/DocumentInteraction_TopicsForIOS/Articles/RegisteringtheFileTypesYourAppSupports.html
For the first part, you are going to want to take a look at Registering Your Support of File Types to add your app to the system list of apps that can open specific document types. That is handled by the system.
For the second part, I could be mistaken, but I don't believe you will be able to get that "long press" functionality as it would require changing Safari. If you control the content of the web page however, you could add a Custom URL Scheme to your app which would allow you to launch it from a web page.
Related
we are currently in the process of linking our web portal to our native app (iOS). In the first step, we will try to implement some Deeplinks.
Therefore it is planned to host the "apple app site association file" on the domain (e.g portal.example.com) and provide deeplinks with the help of Universal Links. However, before we start the implementation, there are some questions left:
Let's say we have only 3 URLs that should deeplink to the app. Each of them will get an own row in the paths section:
portal.example.com/functions/firstfunction
portal.example.com/functions/secondfunction
portal.example.com/functions/thirdfunction
If the User now opens the first URL, he will be asked if he wants to open it in the app, right? Let's pretend the user accepts and opens the URL in the app. What happens if he then goes back to the portal and tries to open the second URL? Will he be asked again, or will the app remember the decision and open any URL from the aasa file in the app?
What happens if we use wildcards and write the path like this:
"portal.example.com/functions/*"
Thank you and bg!
Let me first correct you:
If you use 'universal links', and you open any url, then it will not first ask you that "open in app" and then if denies then to webpage.
But it will be work in this manner:
You must be opening URL in iOS device's safari browser(it will not work for other browsers).
It will first open the webpage. If it finds 'apple-app-site-association' file on that website + It also finds the app with same path in its associated domains section installed on device. Then it will show top bar like below image:
Now, if use clicks on this OPEN button, then only your app is going to be opened. If you come back from app to website, this will remain as it is on top.
Answer to your second question: If you provide only specific domains, then the above popup will be visible only for specific webpages. If you are using wildcards, then all webpages which comes under that wild card, will have top bar like above image.
One more thing to note while you are developing above feature: Universal links get associated while you install the app OR update to new version. So, while developing app - let you have installed app without any associated domains, now you added associated domains in app, and installed app again(via xcode) on your device, and open the webpage in safari. Then above will not work. To make it work, either you have to remove/uninstall the app first and then install it again OR you have to change the version.
I implemented universal link to my iOS app. It directs user to application if url has this "www.websiteurl.com/suburl/*.com" pattern.
I want this work only if user click this url from google search result. If user is already in website I want to open url in website either not open the application. How can I prevent it?
edit: I implemented Support Universal Links documentation.
Yes, this is possible, but I don't recommend it. If the user has the app installed, it seems like you should want to open the app as soon as possible since it is a much better experience. Anyways, here's my solution.
Option 1
Short answer: Wrap your website links in javascript
Why? according to the Apple standards of Universal Links, a link must be clicked on by a user to trigger the Universal Link, therefore if you set up all of your links on your website to be handled by javascript, the app will never open from inside your website.
Therefore, change
Link
Into a javascript call
Link
And open the link from javascript
function clickLink(link) {
window.open(link);
}
Option 2 (Better option)
Use a third-party like Branch links for all of your deep linking so that you can pass more context from web to app allowing the user to continue the same experience on mobile that they were just having on the web. Native is a much better experience 99.9% of the time and it converts users at a much higher rate than web.
I have Universal Linking setup in my app.
Now when browsing my website in Safari and visiting a UL registered link, it opens in safari and asks me if I want to open in my App.
Is there a way that it always opens in the app? No prompt to open in app, just open when it is installed, else continue in safari.
There are two different issues here:
1. In Safari, the URL of a Universal Link needs to be on a different domain/subdomain than the page on which it appears
Apple is very conservative with where Universal Links are allowed to work. One of the limitations in Safari is not allowing the app to open if the user is already browsing the same site (this sort of pages sense — if the user made the effort to open a site in Safari instead of the app, it could be annoying if every single link on that site tried to open the app, especially if the app isn't properly configured for deep link routing).
The workaround is to use a separate domain/subdomain for links you want to open the app. For example, if your site is on example.com, point any link you want to open the app to link.example.com and then redirect users without the app back to the main website or onward to the App Store. This is actually the system we built at Branch.io (which you could consider using instead of re-building it yourself!)
2. What you have described is not Universal Links behavior
Universal Links do not ask the user for confirmation before opening the app, even the first time. They always open the app immediately without even requesting the web page, until/unless the user explicitly disables them (which is actually rather easy to do). What you're describing is the behavior of custom URI schemes, so I suspect you may have a some sort of automatic redirect to the app's URI scheme on the page the Universal Link points to. This is actually not the best idea in most cases, since users without the app will see a nasty error message.
I am trying to implement Branch marketing links in my app. I want for example to be able to create a link to share with users that will route them to a particular screen in the app. I noticed from the Branch docs that for some apps the link just opens the app store and not the actual app (even if it is installed). Being based in Asia I have the feeling that most of our customers will be wanting to share the link via an unsupported app such as Line. If a user is redirected to the app store via the link and then taps “open app”, what happens? Is the link meta data lost? Does the meta data only remain if the link is opened in an app such as mail or notes?
Alex from Branch.io here:
This list in the Branch documentation gives a partial list of apps that support Universal Links, but unfortunately it is not complete. We've tried to cover the most common apps.
Line is using a custom webview (not SFSafariViewController). It doesn't support Universal Links for the initial click, but this is one of the edge cases where Branch can detect the originating app and do some custom behavior. For Line, we trigger your app's URI scheme. This means the behavior your users see when clicking a Branch link from within Line is the same as Universal Links, even though Universal Links isn't actually the protocol being used.
If you want to handle other apps where Branch doesn't have a workaround like this, you could try enabling the deepviews feature. This will cause the link to open a content preview with a button to launch the app (or forward to the App Store if not installed).
When a user with the app already installed clicks the Open button on the App Store page, all the meta data is preserved and they will still be deep linked. Branch doesn't know (or care!) what happens between when the user clicks the link and the app launches, so that gives you plenty of flexibility.
Universal Links have some restrictions - not from Branch but from Apple's implementation. One of these restrictions is Universal Links cannot be opened from SFSafariViewController.
From Branch's docs, Line is not explicitly mentioned but other popular messaging apps may be of interest. I don't have Line myself but whether Line launches websites in it's own browser or the Safari app may give you a clue.
Facebook Messenger - works conditionally
WeChat - works conditionally
Twitter - works conditionally
LinkedIn - works conditionally
Any app using SFSafariViewController - works conditionally
I'm totally new in iOS development. I'm developing an app processing some strings in UItextview. After the process, I want show "Open In.." menu with all applications can receive text values.
To explain more. What I mean is like this in Android http://developer.android.com/training/sharing/send.html
I took a quick look at the link you posted.
Apple enforces a "sandbox" around apps which greatly limits what you can do.
Off the top of my head here are a few ways to do it:
Define a custom URL scheme in each of your apps. One app would open a URL using the other app's URL scheme, and that would open the other app and pass it the URL.
For a family of apps from the same company you should also be able to set up a common base "bundle ID" and use that to read and write shared entries to the keychain. The keychain is limited to fairly short bits of data however. (It's intended for password strings and the like.)
I haven't used it before, but you should also be able to use the UIDocumentInteractionController class to pass a copy of a document between apps. As I understand it, the sending app presents a document and asks the user to pick an app with which to open the document. When the user picks a target app, the system creates a copy of the document in the target app's documents directory and then tells the target app to open it.