I'm trying to follow the convention described in this answer to manage both an app store and enterprise version of the same app but am seeing some really interesting behavior.
As described in the linked answer I've created a new scheme, defined a new 'Enterprise' build configuration and set up the enterprise scheme to use a separate and new bundle id. Both schemes point to the same target which relies on the new build config to toggle behavior. I am successfully able to generate an enterprise build and distribute it over-the-air, however, when I install both versions of the same app on the same simulator or phone the enterprise version actually runs the app store version of the app. Any changes that I make that are enterprise specific do not get reflected. Even when I close the app - the iOS7 animation back to the home screen animates back to the app store icon - not the enterprise one.
Obviously I want to be able to maintain these as separate versions that run independently. I feel like I must be fundamentally misunderstanding targets and schemes to get this kind of behavior. Any help would be greatly appreciated.
Pretty interesting bug.
What was happening was:
We were using facebook login to authenticate with our own services on the enterprise version.
The FB SDK would take over and kick out to a web/view or the fb app, depending on it's own logic. Critically - we were using the same facebook "app" configured on their developer site.
When fb returned it would call the url scheme denoted by fb{app_id}
iOS decided (consistently) to open the app that was first-installed that would respond to that URL scheme. In most cases this was the app-store version NOT the enterprise version.
The solution for this - maybe obviously at this point - is to use two different facebook apps so that iOS can route the returning OAuth response to the proper app. In keeping with the answer that I was originally working off this is best done by...
Creating a new user defined build setting entitled FACEBOOK_ID
Use your production app id for Debug and Release, while using the new id for Enterprise.
In your info.plist, change the value of your FacebookAppID to be ${FACEBOOK_ID}
In your URL Types, change the facebook scheme to be fb${FACEBOOK_ID}
This should successfully route your facebook login.
Keep in mind this is a general potential bug for ALL deep links - not just facebook login.
It is easier to use URL Scheme Suffix instead of separate Facebook apps. With URL Scheme Suffix you can add suffixes to the bundle id, for example: com.example.App.live and com.example.App.beta. That way the Facebook url scheme knows which app to open after authentication.
See the documentation on Facebook's developer site for more into: https://developers.facebook.com/docs/ios/troubleshooting#sharedappid
Related
So I have implemented Firebase Dynamic Links in my app. I thought that I had them set up correctly, because they work for my own personal device and the simulators perfectly. I released the update to the app, but when two of my friends tried to open them after updating to the new version, it takes them to the Firebase website citing an error. I click the same link and it opens my app and handles the link.
Firebase has added the apple app site association to my domain prefix, I have added the a--link in my app's capabilities, I am truly at a loss as to why this may be. Even if they click the link from notes, it does not give them the option to open the link with my app like it will for me.
Is there anything that I could be overlooking? Happy to supply any relevant details but I feel like I have to be missing something.
App Links:
applinks:share.***.app
URL Type is set up in Target Info.
Custom Dynamic Domain is set in info.plist.
For others that come across this, it seems to be an open Apple bug: http://www.openradar.me/radar?id=4999496467480576
After several days, the user's apps downloaded the proper AASA and the deep links began to work. There doesn't seem to be a workaround with Google Dynamic Links, but Branch.io offers forced URI redirect mode to avoid this issue.
I am new to adding universal links to iOS applications. I have read some materials but still have a few questions below. Any pointer will be greatly appreciated!
When exactly Apple will crawl my domain and inspect the [domain]/apple-app-site-association content? I have a new domain, and I'm wondering how Apple's crawler can discover it?
What's the recommended way to test universal links locally before publishing the first version of my app?
Is version control for universal links not possible? For example, the app 1.0 version only supports \item universal link, but app 2.0 version supports one more schema \details . If I specify both paths in apple-app-site-association, then the 1.0 app will break when user navigate to \details. (Edit: I noticed that if the app appropriately set it to be unhandled, then we can still fall back to browser.)
Thanks!
When a device downloads an app, it looks for an entitlements file to list out your associated domains. When it finds that your app has associated domains, it will check those domains for the aasa and download it onto the device. The aasa for that app will only be downloaded on install and update so changes you make will not effect all of your apps.
For testing you can host your AASA on a testing domain or on your production domain. It's up to you but you have to remember to update your entitlements file when you push it to production to ensure that you have the right domain configured. Every time you rebuild the app, it should re-download the aasa so testing shouldn't be too difficult. Always remember to paste the link in notes and not type it into Safari. Universal links only work when they are tapped, not typed in.
For your example you should make sure your new AASA is published at the exact time you publish your app. You should probably use a separate testing domain to host your AASA. You can just include both domains in your entitlements.
Branch actually has testing environment and AASA hosting built in if you'd prefer not to handle all of that on your own. They also leverage URI schemes in cases where Universal Links don't work.
Hi we are using Dynamic Links on iOS and Android to pass though query parameters for various marketing and share links. The query parameters are passing through correctly on iOS when a user already has our app installed. However we are not seeing the query parameters come through or the specific dynamic links passed through to us on new iOS app installs that first travel through the iTunes store. We do not have this problem with Android via Google Play. Is this a known issue with Firebase on iTunes/iOS?
We have debugged our code on our end and are uncertain whether there is something different we need to do in the initialization of our code for brand new installs on iOS? It is also very difficult to test this out as it requires one to create a brand new production build and do an install from the App Store. In our testing we are uninstalling the app locally and then reinstalling from the app store. Note that since we have installed the app before, the app store shows a download from Cloud icon as the option even though we are installing the brand new version. We wonder if this perhaps is the issue?
Any help you can provide in debugging and solving this issue and any tips on how to test without going through the app store would be appreciated.
Can you check you have a custom URL scheme defined for your app (as well as the universal links that you've got working?)
The current way Dynamic Links is working is:
Store the parameters server side before redirecting to the app store
On startup, check if its first run. If so, check to see if there are matching server side paramters.
If there are, call openURL on a custom URL scheme matching your bundle ID (com.foo.bar etc.) and pass the parameters through
So, if the "first open" check is failing it wont do it, or if it can't pass through the parameters (due to missing custom URL scheme).
We have a need to support 100+ domains in our entitlements file for Universal Links.
Example:
applinks:test.myapp.com
applinks:blah.myapp.com
applinks:foo.bar.com
etc...
I know that *.myapp.com will be supported in iOS 9.3, but is there a way to do this elegantly for customers using iOS 9.0 to 9.2 without having to manually add 100+ entries to the entitlements file? Is there a way to do this without having to rebuild and re-release our app every time we need to add a domain to the list?
Thanks!
The new wildcard support in iOS 9.3 is designed for exactly the situation you're describing, so there isn't really a solid alternative in earlier OS versions.
If you don't want to worry about continually updating the list of subdomain applinks entries (or even if you do, but need to wait for App Store review), the best workaround is probably hosting fallback pages on each subdomain with a call-to-action the user can use to continue into the app. That would work as follows:
Assume that you have applinks:mydomain.com configured.
User opens a link to new.mydomain.com/exciting-page (which is NOT covered by the entitlement above).
User sees a custom interstitial, functionally similar to something like this. On this interstitial is a link pointing to mydomain.com/new/exciting-page
User opens the link and the app launches.
The only thing I am not sure about is whether mydomain.com and new.mydomain.com count as 'different domains' for the purpose of Universal Links, since Universal Linking functionality is disabled in Safari for links within the same domain (source). If this turns out not to work, you could easily use something like applinks:mydomain.io and a link to mydomain.io/new/exciting-page in step 3 instead.
I'm using the latest facebook iOS SDK (supporting SSO) to connect my iPhone app with facebook. So far so good..
Since my current app is free with ads, I would like to create another version without ads (which i will charge for). I prefer not to use the in-app purchase approach.
The problem i'm facing is that with the facebook SSO, I need to bind the iOS application to a URL which is based on the facebook app ID. Since I have only one facebook app to be used by both of the iphone apps, the two iOS apps are binded to the same URL and therefore when both of them are installed on a device the callback from facebook to my app does not work (or opens the other app instead).
Is there a solution for that besides creating another facebook app dedicated to the new version of the iphone app?
Thanks.
I had to use FBLoginView in my app, and none of this solutions worked. The only missing thing was that i needed to add a new entry in the plist file: FacebookUrlSchemeSuffix (documented here, in the Step 2).
Suppose that your App ID is 123456, what i had to do was:
1) In your facebook app, add a URL Scheme Suffix in the iOS section:
2) In both of your applications, go to the app's .plist, and add the following entry:
Note that the Value must be one of the URL Scheme Suffixes added.
3) Also change your URL Scheme for Facebook in the .plist file to fb. For example, fb123456client
In the latest Facebook iOS SDK on Github there's a method called authorize:delegate:localAppId: initWithAppId:urlSchemeSuffix:andDelegate:. You can use the localAppId urlSchemeSuffix parameter to distinguish multiple iOS Apps that use the same Facebook application id. The method documentation says:
urlSchemeSuffix is a string of lowercase letters that is appended to the base URL scheme used for SSO. For example, if your facebook ID is "350685531728" and you set urlSchemeSuffix to "abcd", the Facebook app will expect your application to bind to the following URL scheme: "fb350685531728abcd". This is useful if your have multiple iOS applications that share a single Facebook application id (for example, if you have a free and a paid version on the same app) and you want to use SSO with both apps. Giving both apps different urlSchemeSuffix values will allow the Facebook app to disambiguate their URL schemes and always redirect the user back to the correct app, even if both the free and the app is installed on the device.
urlSchemeSuffix is supported on version 3.4.1 and above of the Facebook app. If the user has an older version of the Facebook app installed and your app uses urlSchemeSuffix parameter, the SDK will proceed as if the Facebook app isn't installed on the device and redirect the user to Safari.