Custom URL Scheme Failing within own app - ios

I have a custom URL scheme that I've been using successfully in my app during development for a few months now. We have some web pages that we load in some WKWebViews, and some of those links use our custom URL scheme to call our own app, which then takes action based on those URLs.
Today I deleted the app on my phone and reinstalled it in an attempt to work out a different bug I was having.
Suddenly, tapping on these links does nothing. I cannot find an error being thrown anywhere. Not in the console, not anywhere. I've attempted to dig way down into the various WKWebView delegate methods, but it seems like WKWebView isn't even trying to do anything with these URLs.
However, if I attempt to open one of these URLs in Safari, Safari will ask me if I want to open the URL in my app, which will then load and handle the URL.
Has anyone else seen this? Or have any ideas of where to look to track this down?
I've tried:
Removing and re-adding the URL scheme in my info.plist
Changing the scheme to a new value, then removing it and adding it back in info.plist
Deleting the app
Rebooting my phone

The issue has turned out to be something related to Turbolinks. Somehow there are situations where the page load event isn't firing, and Turbolinks then does not call code we need to activate some elements on the page.

Related

iOS WKWebView Handle File Download

I am facing the following problem:
In a web interface, file downloads are triggered with an anchor tag, like this:
<a href="/bla/blabla" download>..</a>
While Safari browser can handle this request and open a dialogue to handle the file, WKWebView treats this just as an ordinary link and does nothing with it. I want to be able to get the file handler dialogue that is normally there when using Safari.
Right now there are 2 problems and I do not see an opening there yet:
I can not detect a click on the element as it is treated just as a normal link. And I can not rely on the URL parameters to detect if it is a file since that is not constantly true.
Even if the URL is defined as a one leading to a file, I can not pass it to Safari since it does not share session info and cookies with my app's WKWebView.
Therefore, I would like to know if there is any opening in handling files in iOS WKWebView. Thank you.

Custom URL scheme without confirmation prompt (Swift)

I've found two options to open my app from a Safari web page: a custom URL scheme created in my app project's Info.plist or Apple's Universal Linking. Obviously the custom URL scheme is the easiest one to set up, but the problem I'm having with this is that Safari shows a confirmation window asking "Open myapp?" first and the user has to tap OK before the app actually opens. I want my app to open automatically as the scheme is opened, and I'm being told the only way to do this is through Universal Linking (please correct me if this is not true). If this is true, however, I would like to know if it's possible in any way to put the required apple-app-site-association file on a http:// domain instead of https://? According the official Apple documentation the format of a correct Universal Link starts explicitly with https:// but my domain name can't be loaded on https:// without redirecting a few times and that messes up the web services I've written to execute other tasks in my app. The two main questions I'm left with after this issue:
1) Is it really impossible to work around the confirmation prompt using a custom URL scheme (myscheme://)? If it's not impossible, how can I do this?
2) If I have to use Apple Universal Linking, can I use a http:// domain? If so, how do I do it? Right now if I load up the universal link, it just shows the dictionary inside the apple-app-site-association file, which I'm pretty sure is not supposed to happen. I'm told it's supposed to send a NSUserActivity object to my app delegate. How can I accomplish this with a http:// link?
It is not possible to trigger a custom URI scheme without showing an alert to the user. This used to be possible in iOS 8, but iOS 9 started showing the alert for all apps. And iOS 10.3 has extended that even to the App Store itself. You cannot bypass this. Universal Links were created to replace URI schemes for this behavior, so you do need to use them instead.
From your description, I believe you may be misunderstanding how Universal Links work. To answer the literal questions you asked first, no the Universal Link URL itself does not need to be on the https:// protocol, and yes, the apple-app-site-association must be served over https:// without redirects.
However, it sounds like you're trying to serve the content of the apple-app-site-association file for every Universal Link. That is not the correct implementation — the AASA file is hosted only at https://example.com/apple-app-site-association, and iOS automatically retrieves it when the app is installed. After that, any URL on example.com that matches the criteria in the AASA file will be eligible for Universal Links.
All of that said, you really don't want to built out this system on your own. I suggest looking into Firebase Dynamic Links or Branch.io (full disclosure: I'm on the Branch team).
Is it really impossible to work around the confirmation prompt using a custom URL scheme (myscheme://)? If it's not impossible, how can I do this?
That is possible with some hacky tricks and BAD user experience. It requires user to press "add to home screen" button, so I don't recommend this solution in most cases.
set your app scheme like myapp
create the following html file and put it into the web
window.onload = function() {
if (("standalone" in window.navigator) && window.navigator.standalone) {
window.location.href = 'myapp://open'
}
}
open the html file with safari and "add to home screen"
open the home screen icon and your native app will launch
The point is the meta tag.
<meta name="apple-mobile-web-app-capable" content="yes" />
Without this, safari will launch and confirmation prompt will appear.

Firebase Deeplink not redirecting to app if select goo.gl

I'm integrating firebase in application. I created universal link that worked for Android & iOS both.
This worked great. BUT I got scenario where I clicked on goo.gl (PFA) link which was displaying on launched app right-top side. And from then no matter what I do, Deeplink will never launch my application.
I checked to clear history of device-browser but it's same. Any suggestion how to get rid of this issue/feature ??
You're absolutely right: the forward button is horrible UI/UX. It's one of the big flaws with Universal Links identified in this blog post. There is no way to disable the forward button, and once it's triggered, you're screwed.
The easiest way to re-enable Universal Linking behavior after it is turned off is to long-press on the link. Your best bet at getting a clean shot is to paste the Universal Link URL into the stock Notes app and try long-pressing it from there.
Long hold on the url and there will be option to open in app.
Usually when you click the "forward" link to open the universal link in Safari, you can re-open the app by dragging the page down. A bar will appear with your app name and an "OPEN" button. This works as long as you're still in the same URL.
Unfortunately, for Firebase Dynamic Links specifically, the link will redirect you to another domain (for example, from https://z99zz.app.goo.gl/zzzz to https://z99zz-c.app.goo.gl/zzzz) and this breaks this feature. The solution is to either add ?d=1 to the original link (https://z99zz.app.goo.gl/zzzz?d=1, opens a link debug page), or just remove everything after the domain (https://z99zz.app.goo.gl/, opens an error page). Now when it opens in Safari, you can drag down and see the bar.
In addition to imgx64 post. I had a similar problem: Firebase redirected to z99zz-c.app.goo.gl/zzzz and in this case system was not redirected to my app. I added "applinks:mzn3g-c.app.goo.gl" as Associated domain in my target capabilities and this does the trick! Even if you redirected to domain with "-c" suffix iOS can recognize it and will redirect to your app and show suggestion in Safari

Deep linking in iOS 10 not working

I have an app that relies on deep linking using a custom scheme ://appName for some user email verification. The way it currently works is:
User enters email in app and hits send
Email is sent to user, user taps on "activate" button
Button opens valid website url which then redirects to deep link url, i.e ://appName/auth/tokenId
All was good, and this worked flawlessly on iOS 9 devices, but iOS 10 seemed to break it.
After further investigation:
appName://id=123 opens in iOS9, but in iOS10 safari displays that “the url can’t be shown” for the exact same URL.
They will both work however for the URL scheme alone (appName://)
You can even test this on your devices/simulator to see. Perhaps the change is in safari?
More investigation:
Almost sure its related to Safari.
Any ideas on how to resolve this?
Eventually tracked down this issue and got a response from the CEO of Branch. He said:
Ah interesting find! I just tested a few ways and it seems to reject
typed-in URI schemes with a deep link host & path, but you can still
trigger them in JS and click them on page. You just can't type it in
for some reason.
So beware of this if you are using deep linking in such a way on iOS 10!
I personally ended up just giving the direct deep link URL in the email, rather than embedding a redirect in a nice button. Something like this appName://gotoHere/here

Are URL Schemes on iOS case-sensitive?

The official Apple documentation doesn't seem to specify whether iOS URL schemes are case-sensitive or not.
Can I register myApp and still get opened for someone calling openURL: on MyApp://params?
They are not case-sensitive.
You can verify this by entering both sms:// and sMs:// into the URL box in Safari.
Also, it seems that third-party URL schemes in the Safari address bar now lead to a page not found error. This must be new in iOS 9.3.x, because it did not do this before. Entering the URL into another app (e.g. Notes) and then opening it still works.
Edit: the above hypothesis about iOS 9.3.x is actually a bit more nuanced...
They work if…
You are starting from a ​blank​ screen
A page is still loading when you request the custom URL scheme
They do NOT work if…
You are on a webpage that has fully loaded before you request the custom URL scheme
Go figure

Resources