We have multiple apps in place for a company. Now we would like to write an 'Overview App' which should list all apps, differentiate between installed and not installed.
This can be achieved with an URL-Scheme, but:
We also want to check, if the latest version of each app is installed.
I first thought of using two schemes, one to check if the app is installed and a second with the version/bundle in the URL to check if it is the correct version.
What I found out yet:
As of iOS 9, third party applications are no longer able to query arbitrary URL schemes.
Info.plist Schemes cannot be edited on runtime
This will therefore not work in my opinion (Only if the overview app is updated with the new version scheme everytime one of the apps within is updated). The only alternative I could think of would be to implement a pod in each app which will on app start post the installed version/bundle with the device-id in an overview table which can then be accessed by the 'Overview App'.
This would be my very last solution if nothing else works, any inputs if I missed anything (with URL-Scheme, like Callback or something, or an other way) are highly appreciated.
Related
The debug mode shows two tests I don't quite understand
App Installed? Use Custom Scheme YES or NO
How do I make the answer YES for Use Custom Scheme ?
App Installed? Use Universal Links : YES or No
Again, How do I make sure I'm using Universal Links so the answer to the question is YES
To support Firebase Dynamic Links for all versions of iOS you need to implement both Universal Links and custom schema. FDL just decides for you that on older iOS versions it should use custom schema, because Universal Links are not supported (it appeared only in iOS 9).
So the answer is actually quite simple: you can't choose. Debug mode doesn't only show you what you can change, in this case it just shows you what is the actual flow in case app is installed or not. Here it just serves as explanation for you of how it works.
So if app is installed and iOS is lower than 9, it will always use custom schema. If the app is not installed, it will always ask user to install the app. There is nothing to change here, because this makes sense.
And if you are asking if you can do something else (apart from redirecting to AppStore) if app is not installed, you can also redirect user to custom URL:
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).
Until iOS 9, we were able to use canOpenURL method to check if there are apps who can handle specific URL schemes, thus it was widely used to check if a specific app was installed by user.
Now, since iOS 9, we have to declare upfront the URL Schemes that can be checked by the app. This is cool in general, but it means that for every release of a new app, we would have to update previous apps to be able to check if the new one is installed or not.
Is there any sane way to do it now?
I guess most of the ads and cross promotion services out there relies on this and had to adapt somehow, anyone knows how?
Thanks
Krystian
Ok, so to recap.
Currently, the only way to handle my scenario, is to assign a specific scheme per app in an orderly fashion, for example:
my.domain.app01
my.domain.app02
...
If you have apps already released, just update them to add a new, additional scheme.
Now in Info.plist file, you will have to add all of your existing and future schemes to LSApplicationQueriesSchemes list in Info.plist.
The idea is: even though you have 10 apps released, you add entries for let's say 40. This way, you will not have to update your app to add schemes for future apps, they will already be there and you will be able to detect them.
This of course covers my scenario, where I want to be able to detect my own apps and make use of them.
Remember, that your app can handle more than one scheme, so you can assign the internal scheme + use something better named to allow external access to your app.
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 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