I am working with universal app links. I had put my apple-app-site-association on my server root https://www.example.net/
It works fine for all links except https://www.portal.example.net/
When i validate this link in https://search.developer.apple.com/appsearch-validation-tool it gives fetch request timeout.
Note : In portal we redirect page to website homepage (https://www.example.net/)
This is expected, due to the design of the Universal Links specification.
Here's why: https://www.example.net/ and https://www.portal.example.net/ are completely different subdomains of https://example.net/.
The Universal Links specification says each subdomain must be verified with its own apple-app-site-association file, which means a file hosted at https://www.example.net/apple-app-site-association will not work for any link on https://www.portal.example.net/. Redirects are not followed.
To fix this, simply host a file at https://www.portal.example.net/apple-app-site-association with no redirects.
Related
I'm trying to open an App from a Web Page link, it works like a charm on an HTTPS domain, but when I try on a HTTP (unsecure) domain the universal link isn't working.
Anyone know if I'm missing a configuration?.
Thank you!.
If I am understanding correctly, you have an app for which you are enabling Universal Links. When the associated-domain that you are using for Universal Linking is secured by SSL, everything is working properly. When you attempt to use a link domain that is not secured by SSL, however, it is not working.
Assuming I have understood correctly, the issue you are encountering is most likely Apple's requirement that the AASA file be served securely on your link domain. As per Apple's documentation (here: https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html):
After you create the apple-app-site-association file, upload it to the root of your HTTPS web server or to the .well-known subdirectory. The file needs to be accessible via HTTPS—without any redirects—at https:///apple-app-site-association or https:///.well-known/apple-app-site-association. Next, you need to handle universal links in your app.
I am trying to set-up universal links for an iOS app.
The Apple search validator keeps failing when I try to validate the file apple-app-site-association with error message:
Unable to parse that webpage URL. Try a different URL.
The file content is correct, I tried with already validated files from other websites but it seems the crawler fails to access the website generally.
The domain and website are hosted on a shared server at 1and1.com without SSL. The file is not signed.
Any idea why that is?
This is the "App Search API Validation Tool", not the "Universal Links Validation Tool" (which doesn't exist from Apple). The results from this tool have no connection to whether Universal Links work or not.
That said, you must have SSL in order for Universal Links to work. That is the number one requirement. If you can't/don't want to set this up, look at an external link hosting service like Firebase Dynamic Links or Branch.io (full disclosure: I'm on the Branch team)
In reference to "you must have SSL in order for Universal Links to work. That is the number one requirement." This is no longer a requirement.
If your app runs in iOS 9 or later and you use HTTPS to serve the apple-app-site-association file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it.
I have read a lot of articles regarding universal links but still i need to be clear regarding few things.
I have to add universal links to http://www.domain.com but due to certain reasons i will not be able to make my website SSL certified or even put apple-app-site-association with https in root folder. So I thought of doing this in a different way, i will put apple-app-site-association file in the root of a subdomain, lets say https://www.app.domain.com/apple-app-site-association
Then i will open every universal link with that subdomain whenever universal link is available and redirect https://www.app.domain.com to http://www.domain.com if universal link is not available.
Questions in my mind :-
apple says - file needs to be accessible via HTTPS—without any redirects—at https:///apple-app-site-association.
In this line what does apple mean by without any redirects ?
when apple does not find any universal link related to a particular URL, will it itself redirects it to safari.
Is this a safe way to add universal links or is it necessary to have our main domain on https or at-least apple-app-site-association on https
This should work fine. To explicitly answer your questions:
'Without redirects' means when iOS requests https://www.app.domain.com/apple-app-site-association, it must find the file at that address. You can't have a redirect of any kind (Javascript, 301, 302, etc)
If a URL is not valid for Universal Links because you didn't cover it using the inclusion rules in the apple-app-site-association file, it will be opened using Safari. If the URL is on another domain without a valid apple-app-site-association file (e.g., http://www.domain.com/), then it will also be opened in Safari.
Yes, it's fine. Definitely a workaround, but not unsafe.
You should also investigate a hosted deep linking service like Branch.io (full disclosure: I'm on the Branch team) or Firebase Dynamic Links. These will give you all of the same benefits (plus a bunch more flexibility, to be honest) without any of the setup headaches.
We experienced ways where a 302 on iOS works.
In general I fully agree that Apple officially does not seem to support any redirect.
The following cases have been tested on an iPhone 6 running iOS 11.
These cases work :
Website in Chrome on iOS: User clicks on link A and a 302 redirects him to a Universal link B.
Website in Safari on iOS: User clicks on link A and a 302 redirects him to a Universal link B.
Gmail App on iOS: User clicks on link in email and Gmail opens external Chrome browser, which opens a Google link which redirects to link A which redirects via 302 to Universal Link B. (this case works only if Chrome is installed and in Gmail Settings the user explicitly changed the default browser to Chrome)
These cases DO NOT work:
Apple Mail: User clicks on link A in email and external Safari is opened. 302 happens and opens Universal link B. Result: App does not open
Gmail App: User clicks on link A in email and Gmail inAppBrowser (probably WKWebview?) is opened. Gmail redirects EVERY link from an email over a google server, as a second step link A is opened (dont know via 302 or other method) then 302 happens and opens Universal link B. Result: App does not open
Unfortunately you can see that in some cases it does NOT work. As these cases, Apple Mail and Gmail on iOS are very important for most of us here, I think this is a showstopper and you should not use it.
We tested with Adjust links and therefore in cases where the app does not open Adjust opens the AppStore to download the app.
For all Adjust interested: We tested by opening a link https://app.adjust.com/... which has a 302 on the respective Universal link https://XXXXXXX.adj.st/... on which our app listens.
I'm having trouble getting Heroku custom domain to play well with the Facebook oauth login
I am getting the error
Given URL is not allowed by the Application configuration.: One or more of the given URLs is not allowed by the App's settings. It must match the Website URL or Canvas URL, or the domain must be a subdomain of one of the App's domains.
which is examined in various threads including the Facebook one
https://www.facebook.com/help/community/question/?id=542958419109491
So far, my setup is this
the root
http://domain.com is redirect to to http://www.domain.com
The cnames have been changed for www.domain.com so it is an alias for my heroku app. Shows up fine.
https://devcenter.heroku.com/articles/custom-domains There does say
"Zone apex domains (aka “naked”, “bare” or “root” domains), e.g., example.com, using conventional DNS A-records are not supported on Heroku. However, there are alternative configurations that allow for root domains while still being resilient in a dynamic runtime environment."
but I don't know how this effects FB login
When I click the facebook login, it'll throw that error. I've tried various setups in my app settings including with and without the www
Right now, I've left it as
App domain: domain.com
Site URL: http://domain.com
Mobile site URL: http://domain.com
Embedded browser OAuth Login is enabled
(I've tried www for all the options above, but maybe there is a combination I haven't tried. I'm really just doing it randomly not knowing why one would work over another)
If I can't resolve this, I might try opening an issue on Facebook tomorrow.
This final combination seemed to work as my site is coming from www.domain.com
App domain: domain.com
Site URL: http://www.domain.com
Mobile site URL: http://www.domain.com
Embedded browser OAuth Login is enabled
Redirect uri in Advanced setting also added http://www.domain.com
I am an ios app developer. We have implemented a custom URL scheme 'my_app://section_name' or so where if the link is opened in the user's mobile browser, it will redirect the user to a specific section in the app.
We would like to be able to tweet these URLs and have users on their mobile device click on them to open up the app, however it just can click once
(when you click close , maybe you click wrong then you want to click it second but it does not work )
I hope this isn't too silly of a question. Thanks
Make sure to check the tweet body after it have been posted.
This may be due of an URL shortener, especially if the tweet is posted from the iOS 5 Twitter framework.
I'm having a similar issue with url schemes. We can include them in emails and text messages, and they highlight and work properly.
Unfortunately, when we do the same with a tweet, the iOS Twitter client fails to recognise the special URL scheme and so the user cannot tap on it to open our app.
Pretty big oversight, methinks. Anyone else had any joy including special URL scheme links in tweets?
A solution that you should consider involves not sharing the URI scheme directly, but rather creating a page on your web server to handle this. In fact, if you want to be able to share full URI schemes with paths, you're better off building a web server to dynamically generate a page with a URI scheme redirect.
This is a over-simplified representation of what we built at Branch. This includes some code to get you started though the web server will require a bit of setup not described here.
instead of testapp://some.data.here, you'll link to http://yoursite.com/hosted-redirect/some.data.here.
your server should listen at the route /hosted-redirect, grab some.data.here and build the following page (body here):
(source: derrrick.com)
So your server will have to generate and respond with this page, filling in some.data.here, anytime http://yoursite.com/hosted-redirect/some.data.here is requested.
A lightweight node app could do this with a single file.