I'm using AppsFlyer to test retargeting feature. I've implemented deep-linking using Firebase.
I launch the app on my device using Xcode and click the link below which launches the browser and redirects to AppStore. Since I'm running the debug build directly on the device, it detects as "App not installed".
How can I make sure the link directly opens my App and not redirect to the App store ?
The link is of format:
https://Mycompany.onelink.me/12345678?pid=twitter&c=Paywall&af_dp=MyApp%3A%2F%2FUpgrade&af_web_dp=https%3A%2F%2Fwww.MyCompany.com%2Ffeatures-and-benefits%2Fmobile&is_retargeting=true
In general, you need to configure Universal Links / URL Schemes in your xCode project. Most developers choose Universal Links as they are more secure and work better for most use-cases.
You will also need access the Configure OneLink page on the AppsFlyer dashboard, in order to create a unique OneLink ID for your application, set up the subdomain for your OneLink and input some additional data that is used for authentication (as Universal Links are secure).
You can find all the detailed info and instructions here: https://support.appsflyer.com/hc/en-us/articles/208874366
As this requires a setup on both the client side and and server side, you can request some assistance with the server side configurations and additional instructions on client side configurations at support#appsflyer.com
Related
We can send a link to someone formatted as okta:// and it will launch the Okta mobile app, but I would like to know if there is a way to deep link to a specific app in Okta mobile?
Something like okta://appname
or better yet would be okta://appname/specificpageinapp
I have tried all sorts of options, but none seem to work.
The Okta Mobile app doesn't support deep linking as you described.
You may be able to deep-link directly into native iOS applications using a similar URL Scheme (exampleapp://page/example). If the native iOS app is integrated with Okta, this might work as you expect.
However, it sounds like what you might actually want to do is link directly into the embedded web view of a web application in Okta. If that is the case, I suggest reaching out to Okta support with a feature request and the use case that you're trying to solve, so that it can get the attention of the product manager for the Okta Mobile app.
I enabled Associated Domains in Capabilities in Xcode, and it creates a ".entitlements" file as expected. But it also modified a project.pbxproj file, adds com.apple.SafariKeychain = {enabled = 1;}
So I am just curious, why it is enabled, is it useful for some reason?
I couldn't find any documentation about this.
Note: Updated for iOS 12
That entitlement is used for multiple purposes. It covers any feature where your app needs to establish a verified connection to a web domain. This verification is accomplished by placing a static JSON file (called apple-app-site-association) at the root level of your domain which contains your app's fully-qualified App ID, with keys and configuration to enable specific functionality.
It covers a few actual iOS features:
Shared Web Credentials. The identifier com.apple.SafariKeychain actually refers to the original purpose of the Associated Domains capability, which was to enable native app access to credentials stored in iCloud Keychain for your web domain. If a user has already logged in to your web site and saved their password in iCloud Keychain, this feature allows your native app to use those stored credentials.
Password AutoFill. Available in iOS 12. Password AutoFill takes the behavior added to web sites with Shared Web Credentials, and extends it into native apps in a robust way. By establishing Associated Domains for you app, and adding metadata to your text fields, iOS can automatically enter saved web credentials into your native app. when creating a new account or changing passwords, Password Autofill can offer strong password suggestions, based on your organization's password rules. It can also assist the user by automatically filling in a multi-factor authentication code sent via text message, if it can find a field designated for entering that information.
Universal Links. At its simplest, this feature is a secure replacement for the old custom-scheme-based method of launching one application from another, or from a web link. When used to its fullest, it allows you to draw parallels between the information architecture of your website and your native app. When a user taps a web link for your domain, your native app can be launched in order to handle that link. If the app is not installed, a Smart Banner will be presented with a link to the App Store.
Web Browser–to–Native App Handoff. This is a passive version of Universal Links. If a user is browsing your website on a macOS or iOS device, and you have created a site association for the page they're viewing, they will see a Handoff icon on their iOS lock screen which will let them open your app and, optionally, navigate to the native version of the web page they were viewing.
So, now twitter from 25 sep supports universal linking, it means that when UIWebView hits https://twitter.com/oauth/authorize?oauth_token link, it tries to open a twitter app, and if it is there, then it redirects me to auth page with auth error, so I wonder, how can I disable it from code, without uninstalling twitter app, or how I can enable universal linking auth in my xamarin ios app? Is it possible at all?
(similar question but for native: Disable Twitter Universal Deep Links)
Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.
I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....
Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.
Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
I have an iOS app that communicates with a web service, this product will be licensed to customers for their employees. Each customer will have to install the web service on their own server and provide an IP/URL for the iOS app to communicate with. Right now, the web service URL is coded in the app. I won't know the customer's web service URL before giving them the compiled app.
I don't know enough about enterprise distribution to know how to do this. Do if I need to compile the app for each new customer with their specific web service URL, then give them the app? Or is there is another way this should be done? I was thinking a plist file or manifest that can be configured with the URL but I'm not sure. How do they update that and get the app to use that? I had a developer make this app for me and they said the URLs shouldn't be in manifest/plist files.
I can't find any information about this on the apple developer site or on this site.
You can just add text field in your app settings or at the start where user can define its server URL like www.abc.com For all your customer rest of your path (webservices/yuorservice or what ever you use)will be same . Then you get this url and save in your user defaults to use it for the future for that user.
Using this approach you only need to compile app one time for all the customers.
App has no knowledge of manifest file
Your developer is right--you should not include any app-configuration information in the manifest file, since the app has no knowledge of the manifest file or web page that it was downloaded from. Here is a link to an answer I gave regarding this topic.
Enterprise deployment rules
Apple only allows enterprise deployment internally within a company. So, distributing an App through your enterprise license to multiple companies is prohibited.
Approach
I can think of one option that might work for you, given that you have a URL that should change for different customers.
This assumes that you will employ a login.
Devices
Your login web service response to the device can include the URL that is configured for that customer. This URL can be one piece of data inside a configuration file in JSON format.
Web Server Admin Page
You can optionally employ an Admin page, also accessible through login, where your customer can set the URL, and any other settings. The advantage of including an admin page for your customers is that they are able to manage the product on their own, without the need for additional product support.
In the Facebook App Settings ☞ Advanced ☞ Authentication I can pick "Web" or "Native/Desktop" as App Type. The info bubble says:
Only select Native/Desktop if you are a Native iOS or Android app,
device, or Desktop app
Actually I am none of those but my app is a Native iOS App as well as a Facebook Page Tab.
Question: Which App Type should I pick?
I did some research and found the following in the Facebook Android Tutorial (under Troubleshoot):
App type Web vs Native/Desktop. Does it matter?: No, it does not
matter. However it's recommended to use the type 'Native/Desktop' for
your app.
What does it mean it does not matter? That does not make sense to me. Why should I have a choice then?
I did some more research on SO and found this statement by #Igy (dev support engineer at Facebook):
If the app's type is set to 'Native / Desktop' it's assumed you
distributed the app's secret key with the binary, and thus the app
access token isn't trusted (and 'getAccessToken' in the PHP SDK will
only work when real users log in, it can't fall back to the app token)
Finally I found this in the Facebook documentation:
Note: Applications that are configured as Native/Desktop apps will not
be able to make API calls that require an application access_token.
I do need to make API calls which require an access token from my page tab app, hence my conclusion is to pick "Web" as the App Type, although I'm having a native iOS app using the same app ID as the page tab app. But will that have any drawbacks on the iOS app?
TL;DR: use 'web' unless you're putting the app secret into the iOS / Android binary
The primary difference (and also the reason that it says 'it doesn't matter' while also giving a recommendation) is that if you choose 'native/desktop' mode, it's assumed that you distribute the app binary with the application secret embedded and the app secret is considered untrusted.
In this configuration, API calls which use the app secret (e.g. creating test users, making API calls on behalf of the app itself like changing app settings, posting achievements, etc) will not work.
If your app doesn't need to use the app secret / app access token, setting it to native/desktop increases the security somewhat as there's one less attack vector for your app.
If you're distributing the app secret with your code you MUST use that option or users could easily determine the app secret and hijack the app itself.