Skip to content

FAQ

What are the differences between the regular and the pro version?

The pro version includes the source code and contains the Windows automatic launcher system which enables your projects to mimic mobile deep link control (activation after the app is launched) out of the box without a single line of code. This feature also enable direct deep linking testing on the Unity editor on Windows (Mac support coming soon).

How to do redirect to store when app/game isn't installed?

To achieve the redirect to store when the app isn’t installed, you need two things, a website, and an app with Domain Association and deep linking. When the user clicks on a web link if the app is installed it will automatically open the app. If the app isn’t installed, or the user chooses to open the link in the browser (both android and ios allow such choice) you can either:

  1. On your website automatically redirect the user to the store (not checking if the app is installed or not)

  2. Try to check if the app is installed, to achieve it you will need to:

    a) Try to redirect the user to your app deep link (myapp://), if the user has the app installed, it will either open automatically or ask the user if he wants to open it

    b) If it fails (e.g use a 3 seconds timeout), redirect to the store

Warning

This deep link behaviour can vary depending on the target platform and browser!

My domain association isn't working.

There are a couple of reasons why domain association can fail:

  1. Your website is not https, both Google and Apple require your website to be https
  2. Your apple-app-site-association (AASA) or assetlinks file isn't being served without redirects. Vendors require that your configuration file to be served without any redirects, in order to test this you can use any online http tool (e.g reqbin.com)
  3. Your AASA file has incorrect appID configuration, double check it.
  4. Your assetlinks file has incorrect sha256_cert_fingerprints or package_name configuration.
  5. Your plugin integration is malfunctioning (although rare), to ensure that everything is working as expected, configure the plugin with a deep link and test it on an device.

The best way to double check everything, is run our demo scene on your target device and see if the activations appear as expected. In order to do this simply drag our scene to the Build Settings -> Scenes in Build, and place the Demo scene in the first position. This step is important since it ensures that the integration is working as expected. Possible issues that can cause this on your code are:

  1. The GameObject where you are making the LinkActivated registration is destroyed before any activation occurrs. We suggest you to do this configurations on DontDestroyOnLoad GameObjects.
  2. The GameObject where you are making the LinkActivated registration is yet to be created, to ensure this does not happen, place the event registration at your application boot phase. (Do note that the plugin caches the last request, so you can delay the activation as much as you wish).

  3. Your code is throwing an exception on the LinkActivated handler and it's failing silently, the plugin protects the handler activation with a try/catch block to avoid crashes, double check your logs, common issues we found throughout the years are:

    a) Trying to access a query string that doesn't exist.

    b) The GameObject not being ready to process a LinkActivated handler call, note that the plugin can fire the activation at the moment you register an handler if there is any requests cached.

My Mac build isn't working, module/library not found on the logs

If you are building via xcode, double check that the UniversalDeepLink.framework is present on the Build Phases -> Link Binary with Libraries. If not extract the zip under Assets\Plugins\ImaginationOverflow\UniversalDeepLinking\libs\Standalone\UniversalDeepLink.framework.zip to your xcode solution folder and add it to the linked libraries. Although rare this can happen on recently released xcode versions or when something fails(e.g missing permission) in the plugin automatic process.

If you are building directly on Unity on a Mac, it's probably an optool issue (the tool we use to inject the library on your app),Assets\Plugins\ImaginationOverflow\UniversalDeepLinking\libs\Tools\optool. Ensure that the utility has execution permissions (on a terminal chmod +x optool) and on newer macOs versions follow this guide to allow unidentified apps to run

Signing on macOS

Our framework isn't signed for security and compatability reasons, so when you are submitting your project for apple store will be required to sign the UniversalDeepLink.framework.

The plugin works by registering your apps, on the target operating system, as a way to process some links (deep links or web links), there are cases of apps that open links internally on custom web views. These web views resolve any links internally not asking the target operating system on the best app to handle them. On these situations the plugin won't work as expected because the app X is bypassing the contract that allow deep linking and domain association to exist. Unfortunately, neither you or we can do anything regarding these situations.

Change the "Open with IO Launcher" on Windows Standalone with launcher

When you open a deep link on a Windows standalone target, the browsers will use the metadata of the launcher to prompt the user if he wants to open your product. For example, in chrome it will prompt Open IO Launcher. To change this prompt you have two alternatives:

  1. Use the Resource Hacker tool and change the File description property.
  2. Use the launcher source included in the plugin to make a new launcher with your custom metadata.

After you changed the launcher by either one of the above options, make a new build to a new target folder or simply change your target folder name. This will force the update of the launcher metadata.

There are a lot of misconfigurations that can happen when adding support to domain association, so the first step is to always follow the documentation.

Warning

If you already tested normal deep linking (with custom schemes) you can skip the below step!

First off let's establish that the plugin is working correctly with your code, and the best way of accomplish that is to change gears and configure a deep link to your application, for example, configure the plugin to active your application with a deeplink which scheme is testdeeplinl. After you build your application with it use our test tool to test it, if clicking on Test opens your application, the integration is working as expected and we can check everything regarding domain association.

Troubleshooting steps for domain association:

  • Always use our test tool to test the integration, it was purposely built for that, so if it works in it, the integration is correct!

Note

Your application won't activate if you use the browser address bar, this will always navigate to a web page on your domain, only operations like button clicks will trigger your app activation!

  • Ensure that you don't have any deep link configuration with web links! If you have http or https schemes under the plugin Deep Link Configuration it can cause issues with the domain association

  • Remove all paths restrictions from the domain association configuration, apple-app-site-association and assetlinks.json, this will reduce the number of variables that could be wrong with the configuration.

Warning

Remember to add the path restrictions back, on Android the path is directly translated to the property path pattern. On iOS the plugin path restrictions are ignored so you should configure them in the apple-app-site-association file!

  • Ensure that your apple-app-site-association file and assetlinks can be accessed without any redirects, tools like reqbin show you if you are making any redirects, note that redirects are forbidden.

  • Double check all ids and generated information on apple-app-site-association and assetlinks files.

  • Domain association works by the target device making a request to your site in order to confirm that you own it (that is the purpose of the AASA and asset links file) so make sure that there isn't anything preventing that (e.g VPNs)