We recently launched an HTML5 Web App (using JQuery Mobile), which has a slide down box encouraging users to bookmark the Web App on their home screens. Users can do this from Safari by clicking Bookmark and then "Add to Home Screen". Any thoughts on how we might be able to track the number of "installs". I don't believe we can add any tracking to the native iOS bookmarking behavior from within the HTML5 Web app.
Thanks
I'm not sure you can get an event whenever the user installs the web app on their homescreen. However, you can know if the user is in 'full screen' / 'web app' mode by checking the window.navigator.standalone property in Javascript. So you might be able to do a call to your statistics provider and provide them the standalone property as well.
You can at least detect whether the app is launched from the homescreen or via browser via the window.navigator.standalone flag. You could use it in combination with cookies or localstorage to ensure you count unique installs in your backend.
You can also try to store the result of window.navigator.standalone into Google Analytics
Related
I'd like to launch Whatsapp from my Flutter app for a specific contact on the user's device. I'm able to do that successfully using url launcher as described in many questions on the subject (like this one this one).
The way it works, it opens an in-app web browser, which then prompts the user to open Whatsapp. On iOS, it then prompts the user with a dialog "Open this page in WhatsApp?"
Is there a way to always allow that? So that the user doesn't have to hit that each time they want to connect to someone on Whatsapp from my app?
Use the LaunchMode enum which is used to state the desired mode to launch a URL.
Future<bool> launchUrl(
Uri url,
{LaunchMode mode = LaunchMode.externalApplication}
);
LaunchMode.externalApplication is supported on all platforms. On iOS, this should be used in cases where sharing the cookies of the user's browser is important, such as SSO flows, since Safari View Controller does not share the browser's context.
I plan to develop an app (not sure if I will go with PWA yet) which includes the following "wishlist" scenario:
The user is browsing a website he likes using safari, chrome or any browser
He clicks the share button in that browser, in order to send the webpage url to another app
He selects my PWA
This url is saved in the user's wishlist
Is step 3 possible?
Note: someone asked the exact same question here about Android: Can a progressive web app be registered as a share option in Android?
My question is just the same, except mine is about iOS. I couldn't find any answers to it.
What you're describing is covered by Web Share Target Level 2.
Currently, it can be used with Chrome on some desktop platforms and on Android for installed PWAs.
It's not available on iOS, unfortunately.
We're observing the following behavior with the Google OAuth change:
Webapps accessed via Safari in iOS 9+ can do a Google OAuth flow, same as ever.
Webapps saved to the home screen can also do the usual flow
Webapps saved to the home screen that have the apple-mobile-web-app-capable meta attribute do NOT -- they are blocked via the "disallowed user agent" error.
It seems that apps saved to the home screen that have the fullscreen meta tag report their user agent as Web/1.0 CFNetwork/758.5.3 Darwin/15.6.0, which is different than MobileSafari (it is also different than the user agent in an embedded UIWebView).
This is a bit of a bind, since enabling the apple-mobile-web-app-capable mode is the only way to do a few other things, such as autoplay audio, which we use to teach the kids math!
Anyone have ideas on a path out of this double-bind? Alternatives we can think of include:
Find a way for Google to distinguish fullscreen homepage webapps from embedded WKWebViews. (UPDATE: based on the user agents above, they can be distinguished. But Google may still want to block them.)
Coax Google to allow this user agent. Unfortunately, I think there is a rationale for blocking OAuth on fullscreen webapps -- without a location bar, the user can't verify they've been sent to a legitimate Google login page.
Coax Apple to report fullscreen webapps as MobileSafari rather than this user agent. (??doubtful)
Build a native or Cordova version of the whole app, just to work around this one issue.
Any thoughts?
Would like to know if expected behavior on deep linking using branch.io so when clicked on should check for app availability and prompt customer on iOS device to
Prompts to download app in App Store if not installed
Open in iOS app seamlessly if installed
If customer declines app download it will open in iOS mobile browser
My concern is this deep link behavior on a desktop experience. When a user clicks the same url I am being told this will take them to the iTunes app store resulting in a poor experience. Is this a correct statement? Is there any way to provide a better experience to the end user.
Thanks in advance!
I am being told if the same url is opened in Windows10 it will take me to the App
For example
1. Users opens email with deeplink url
2. what is expected behavior on mobile device with app installed that deep link
For iOS redirects, you'll have to set yourself up for Universal Linking per the documentation here:
https://dev.branch.io/getting-started/universal-app-links/guide/ios/
This is very important for redirect behavior on iOS 9 and later. Please note that not all 3rd party apps and browsers support Universal Linking functionality yet, so you should test on iOS from iMessage or Notes initially.
As for Desktop, you can set your Desktop redirect on the Link settings page - this will not take users to the App store/Play store on Desktop, but to the page you set. You can use the Branch hosted text-me-the-app page if you want to have this as your default for Branch redirects, or your site homepage, or any other page of your choosing. You can add Deeplink data that will be used for all redirects by adding key/value pairs in the SDK or manually when creating a marketing link from the Branch Dashboard. You can also set a $deeplink_path value that will be honored for a specific link, and you can further set a $desktop_url that will override defaults if you want a different redirect for a specific link.
There are many options and ways for you to configure how your redirects work - all of this is up to how you set your Link Settings on the Dashboard, and if you choose to override these defaults for any particular link. For example, you might have default redirects to the App store set for iOS and a desktop URL set to your main webpage on Link Settings. In this case, a link created without modifying these values will take the user to the App store on iOS (or the App if installed), and to the desktop URL specified in Link settings if clicked from Desktop. If, however, you want to override and set $desktop_url as something else for a given link, say, to a specific page on your webpage using the $desktop_url key, on iOS the redirects will be the same but on desktop you will be taken to the set $desktop_url. For any of these scenarios you can specify Deeplink Data to be passed through.
We have an iOS app that publishes certain activity to Facebook that contains links to pages on our domain. Our intention is for friends to click on those links and view them as webpages.
However, when you click on links in these published stories in the FB iOS app, it's auto launching our app instead of going to an embedded Web View or kicking out to safari.
Note: We still want to have single sign on (SSO), so just want to change the behavior of clicking links in published stories.
To clarify, this is what I'm talking about:
My app is able to publishes http://foo.com/123 into the FB newsfeed for a particular user that opts in.
That person's friends see the link, but when they click it, it just goes to http://foo.com/123 in the browser instead of launching my FOO app. This is because my app doesn't yet handle incoming context from FB iOS app.
I still want FB SSO to work from my FOO app. That is, when clicking on FB sign in in my FOO app, it jumps out to the FB iOS app (if installed) and does a single sign on and redirects back to my app. IOW, I don't want to break this authentication scenario that currently works.
What setting in the FB developers App Settings controls this? It's not clear from the documentation. I see sections for Native iOS app and Website which I currently have set but it's unclear which sub-setting affects the behavior in question. Also, it's not clear even if I was to find the setting, can I affect it without affecting SSO.
The setting you want in the Facebook App dialog is under the iOS Native section (see the screenshot below) - set both the highlighted sections to Disabled.
This won't affect Facebook login/SSO in the app, so you'll still be able to do the OAuth dances.