I am trying to set up App Links so that:
a) When I tap on a link on the Facebook app, it opens my app if installed
b) If not installed, Facebook should not prompt the user to be directed to the App Store, and instead open the link in the in-app browser
I have been experimenting with the al:web:should_fallback meta tag, but there have been some mixed results:
When al:web:should_fallback is set to false, scenario a) as above works correctly, as expected. Scenario b) is not fulfilled, as expected, because I've indicated that the system should not fall back to the web.
However, when setting al:web:should_fallback is set to true, even though the app is installed, scenario a) no longer works.
Why is this? I am under the impression that al:web:should_fallback controls scenarios for when the target app is not installed
Some setup details:
My website's meta tags are as follows (Actual values replaced by "_"):
<meta property="al:ios:app_store_id" content="_" />
<meta property="al:ios:app_name" content="_" />
<meta property="al:ios:url" content="_://_" />
There are no outstanding warnings on the OG Debugger
There is only one warning on the App Ads Helper, and this relates to Deferred Deep Linking, which according to the App Links iOS documentation, is no longer supported
Any insight would be greatly appreciated!
Related
I built a Todo App in Ruby on Rails (With a Passenger and Nginx), i used this app as a PWA with apple-mobile-web-app-capable and apple-touch-fullscreen meta tags on my iPhone (IOS 12.3.1). When I create tasks via the browser and switch back to the PWA, they are not displayed. If i close the app very often or wait a long time, they will be displayed in the PWA. I think IOS cached the Web-page. My question is how can I disable caching for the page ? I've already tried the following meta tags, they did not work. Does anybody know how to fix this?
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="pragma" content="no-cache">
I'm trying to set up a standalone PWA on ios and the web address still remains
I have included the following in the index.html
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="mobile-wep-app-capable" content="yes" />
And have
included
"display": "standalone"
in the site.webmanifest
The connection to our server is over https
Are there any other checklist items that need to be included to remove the url from displaying?
UPDATE - 14/05/19:
I believe the index.html and config was fine. I now believe this is an issue to do with routing
When you add a PWA to the homescreen in IOS it sets the entry URL to the PWA as the page you are currently on. In my case, when users first enter the app, they are at www.sitename.co.uk/login
and not at the root of the page
www.sitename.co.uk/
I stumbled across online that safari's full screen PWA apps will show the URL bar after a redirection to a different domain, to prevent phishing/ make the redirection clear to users.
I can only assume that, when you add the PWA, it adds the url as some sort of 'root' and when you try and navigate beneath the root it flags this up as unexpected behaviour
And causes this sort of behaviour
/login -> No URL
/ -> URL
/edit/resource -> URL
/login/resource -> No URL
This is annoying because
a) I would want the same PWA experience for a user regardless of what screen they added the app on
b) It would make far more sense to allow all routes on the domain of the PWA to be viewed without a URL.
maybe its a bit late for this, but you could try adding a scope attribute to your manifest. That way the address bar won't be shown on IOS as long as the host is the same specified in scope.
Check this out: https://developer.mozilla.org/en-US/docs/Web/Manifest/scope
Using Facebook App Links, How would i link a user from my website to my mobile app?
I've been trying to do it but i'm unable to do so.
I've tried adding meta-tags to my html test document, using pinterest as an example:
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<meta property="al:android:url" content="Pinterest://">
<meta property="al:android:package" content="com.pinterest">
<meta property="al:android:app_name" content="pinterest">
<meta property="al:web:url"
content="http://applinks.org/documentation" />
</head>
<body>
Hello, world!
</body>
</html>
I'm not a HTML developer. However for iOS, if you are expecting a redirection to App, then the solution would be to use URL types.
You can define a URL type in your iOS app by following steps -
1. Select your project
2. Select Target
3. Select Info Tab
4. Expand URL types option
5. Under URL schemes, specify your app URL. It can be any string.
Also in your Apps AppDelegate, you should implement either one of the following delegate methods and return true
application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool
or
application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject) -> Bool
Inside your HTML page, specify your redirect URL.
For eg. - If you specified your URL types as appName in your info list, then the redirect URL will be appName://
You can find more info here
Facebook App Links only work if the source app is configured to support them. In an ideal world, the source app would scrape the destination URL when opening it and automatically launch the appropriate app. Unfortunately not many app are set up to do this — even the main Facebook app on iOS doesn't anymore, and Safari never did (and probably never will).
Setting up a custom URL scheme for your app and then linking directly to it does work, but in iOS 9+, the user will be shown a confirmation message first. And if the app isn't installed, there will be an ugly error message instead. Universal Links on iOS 9+ are designed to solve this, but they aren't supported everywhere yet and can be turned off.
The solution is to use a combination of URL schemes and Universal Links:
You want to enable your website for Universal Links so that when a user opens a link to your website, they go directly into the app instead on iOS 9+.
And then have a URL scheme redirect that fires for anyone not on iOS 9. You'll probably want to put this behind a button or a link so that users without the app won't be immediately shown an error when loading the page.
This is the approach we take at Branch.io, and is fairly close to our free deepviews feature. Check it out...might save a bunch of work!
I developed an HTML5 webapp, and so far my local server tests worked fine (running in the desktop browser, iOS Safari browser, and homescreen bookmark webapp). This also holds true for the offline use (with the cache.manifest file).
When I uploaded the files to my website, I tested to confirm it still works on the desktop (Chrome shows the Application Cache logs), also works in iOS Safari. Both online and offline.
The Problem
When I bookmark the page from my website as a homescreen icon and try to launch it from there, the webapp freezes on the startup image.
What could be causing this particular issue?
Checklist:
HTML tag contains: <html manifest="cache.manifest">
HTML does contain: <meta name="apple-mobile-web-app-capable" content="yes">
HTML does contain: <meta name="apple-mobile-web-app-status-bar-style" content="black">
Not sure this would matter but: <meta name="viewport" content="width=1024, minimal-ui, user-scalable=no">
The apple-touch-startup-image and apple-touch-icon link tags are appended dynamically to the <head> tag via Javascript.
Only the necessary file-names in cache.manifest are included.
The webhost supports the manifest mimeType (no need to change .htaccess).
The website does use an .htaccess password authentication setting.
NOTE: I will investigate whether or not my use of apple-touch-startup-image & apple-touch-icon dynamically appended with jQuery could be the issue here.
It dawned on me once I listed the .htaccess password authentication bit in the checklist above.
It seems iOS's chromeless browser cannot initiate a username & password prompt at startup.
Sure enough, allowing full access to the page resolved the issue for the homescreen app. To do so, I've included this in a separate .htaccess file in the same directory the webapp is placed in:
Satisfy Any
That's it!
Although I'm not very fond of this solution, then again I wouldn't want to enter a username & password everytime I launch the webapp.
I have found one related question: Cannot get the new AppLinks to work on iOS or Android But I am not sure if it is entirely similar with the problem that I am facing. Thus, I created this question.
If I understand correctly from: https://developers.facebook.com/docs/applinks/ios
When I click on a proper applink with the proper meta data:-
Case 1: I have the app installed:
Expected Action 1: It will navigate to the specific page inside the app.
Case 2: I do not have the app installed:
Expected Action 2: It will direct me to the app store page of the app to download.
Here are the configurations that I have done so far:-
The App Link URL: http://watchoverme.parseapp.com/
The App Link Meta Data:
<html>
<head>
<title>Watch Over Me</title>
<meta property="al:ios:app_store_id" content="431208868"/>
<meta property="al:ios:app_name" content="Watch Over Me" />
<meta property="al:ios:url" content="watchoverme://promotion" />
<meta property="al:web:url"
content="https://itunes.apple.com/app/id431208868?mt=8" />
</head>
<body>
Yo!
</body>
</html>
On the app side, I have added the custom url scheme like the screen shot below:-
So far, I have tested a few scenarios below:-
Scenario 1: I created another simple app with a single Button to open the applink.
The code for the button:-
- (IBAction)appLinkTapped:(UIButton *)sender {
NSLog(#"appLinkTapped");
UIApplication *app = [UIApplication sharedApplication];
NSString *path = #"watchoverme://promotion";
NSURL *ourURL = [NSURL URLWithString:path];
/*
if(![app
canOpenURL:ourURL]){
path = #"http://watchoverme.parseapp.com/";
ourURL = [NSURL URLWithString:path];
}*/
[app openURL:ourURL];
}
Result 1: If I have the WatchOverMe app installed and I tap the button, I can open the WatchOverMe app. Great!. But if the WatchOverMe app is not installed and I tap on the button, nothing happens. Should I be directed to the iTunes App store to download the app? Or I did something wrong?
Scenario 2: I posted the link (http://watchoverme.parseapp.com/) on Facebook and try to tap on the link on my mobile.
Result 2: Whether I have the app installed or not, it only shows me the blank website.
The question: Am I missing something here on the configurations until it can not trigger the expected applink behavior above?
Thanks
Update #1
Thanks Ming Li for pointing me to the right direction. I want to understand better on how app link works. So, I have done more testings and here is what I have found:-
From the the screen shot above:
Case A: I share the app link using the Watch Over Me app (you will see "via Watch Over Me")
Result A: When I tap on the link on the Facebook App. If I have the Watch Over Me App installed, it will redirect me to the app. If I do not have the app installed, it will redirect me to the iTunes App store to download. It is working great!
Case B: I share the app link using status update only. (without via Watch Over Me)
Result B: It will only open the blank webpage.
So, the Applink only works when we post the applink via Facebook? And not posting the Applink via our status update?
Update #2
I have tested again on 1 September 2014. Both cases above have been working well! A big Thanks Ming Li.
For everyone else who doesn't work at Facebook and understand what they mean by "indicating that your app is mobile only" here is what I have found from testing:
It appears they are using the "al:web:should_fallback" meta property as a check for if your app is "mobile only" and has no web presence. This doesn't make sense as far as I can tell based on how the App Links spec defines it but what do I know.
Anyway, if you want your Facebook post to go straight to the deep link in your app and not open up the jarring webview with random app link UX treatments by Facebook then add the following meta property to your html page:
<meta property="al:web:should_fallback" content="false" />
Of course this now prevents you from sending users without the app installed to anything but the app store. However, since the webview is usually just a repeat of the Facebook post in the first place that's probably a worthwhile tradeoff.
Since you have not indicated that your app is mobile only, it would follow the "No" arrow from the original decision box, and show your webpage along with some call to actions for either open or install.
Facebook is always testing different UX treatments, so what you see may not be what other people see. I tried posting a status update with your url, and everything is working as expected.