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.
Related
In Apple's guidelines about Offering account deletion in your app, it states the following:
If people need to visit a website to finish deleting their account,
include a link directly to the page on your website where they can
complete the process.
However, in the FAQ section of the same page, it states:
If my app links out to the default web browser for account creation,
does it still need to offer account deletion within the app?
Yes. Additionally, note that linking out to the default web browser to
sign in or register an account provides a poor user experience and is
not appropriate, per App Store Review Guideline 4.
Given the above information, would having a button in the app that says "request account deletion" that opens a website to complete account deletion requests be compliant with Apple's guidelines? In other words, is it ok to just have a website for the account deletion request process (link to this website will be available from the app), or is it required that the account deletion request process be completed on the app itself?
Everything needs to happen within the app, either natively or via an embedded browser for both user sign-ups and user account deletion.
From my experience, Apple doesn't like "Request" or "Deactivate" as a default modus operandi and prefers only "DELETE" and "IMMEDIATELY"
See https://developer.apple.com/design/human-interface-guidelines/patterns/managing-accounts/
If you help people create an account within your app or game, you must
also help them delete it, not just deactivate it. In addition to
following the guidelines below, be sure to understand and comply with
your region’s legal requirements related to account deletion and the
right to be forgotten.
Also see https://developer.apple.com/support/offering-account-deletion-in-your-app/
If my app links out to the default web browser for account creation, does it still need to offer account deletion within the app?
Yes. Additionally, note that linking out to the default web browser to
sign in or register an account provides a poor user experience and is
not appropriate, per App Store Review Guideline 4.
See the responses below from Apple on both issues.
Guideline 4.0 - Design
We noticed that the user is taken to the default web browser to sign
in or register for an account, which provides a poor user experience.
Next Steps
To resolve this issue, please revise your app to enable users to sign
in or register for an account in the app.
You may also choose to implement the Safari View Controller API to
display web content within your app. The Safari View Controller allows
the display of a URL and inspection of the certificate from an
embedded browser in an app so that customers can verify the webpage
URL and SSL certificate to confirm they are entering their sign in
credentials into a legitimate page.
and
Guideline 5.1.1(v) - Data Collection and Storage
We noticed that your app supports account creation but does not
include an option to initiate account deletion that meets all the
requirements. Specifically:
Your app only offers to deactivate the account. Temporarily deactivating accounts is not sufficient to meet the account deletion
requirement.
The process for initiating account deletion must provide a consistent,
transparent experience for App Store users.
Next Steps
It would be appropriate to revise your app to address the issues
identified above and resubmit your app once the account deletion
option meets all the requirements.
If you believe your current account deletion option meets all the
requirements, either because your app operates in a highly-regulated
industry or for some other reason, reply to this message and provide
additional information or documentation.
Resources
Review frequently asked questions and learn more about the account deletion requirements.
Yes you have to provide account deletion or account deactivate option on website as well.
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
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
Keychain access groups and application groups are both segregated using the app's team id.
Named pasteboards are also sandboxed using the team id.
Kerberos SSO seems to work well, but opening the KDC to the internet is a security hazard so it can only really be used together with a VPN.
The Shared Web Credentials API works well between native apps, but has intrusive popups showing up every time you attempt to access or even just check for the existence of credentials.
libdispatch can send messages to arbitrary apps, but the payload is limited to 64 bits and the recipient app must be currently running.
No unique device identifier that could be used to derive a key for a cloud-based encrypted KVS can ever be shared between apps not on the same team id.
…is there any way to share credentials (or any data, for that matter) between applications signed with different team ids, on recent versions of iOS? Apple doesn't allow migrating IAP, Passbook, etc to new team ids and it's blocking my team from implementing SSO between apps with historical team ids (M&As, etc).
You can open the app with deeplink that will reopen the other app with the infos you want to pass along. That's good for login but can be cumbersome if you want to pass a lot of infos back and forth.
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.