Different long URL based on device type.

[snorkrat]

I would love it if we could specify different (long) URLS based on device type.
This would be super useful for setting up a short url to download an app. Shlink would detect the device the user visits from, redirect on android would go to the play store, and the redirect on iOS would go to the app store.
A 3rd URL could be added for any device that isn't iOS or android - which could go to a landing page. Perhaps this could even be built into Shlink. We could specify a message to be displayed if the user is visiting from an "unsupported" device. These settings could all be in the "advanced options".

---

Added by maintainer to track progress

• Persistence of device long URLs.
• Define API contract for read operations.
• Define API contract for write operations (creation and edition).
• Document API contract changes.
• Allow "deleting"/"detaching" device URLs during edition, if explicitly provided with value null (or whatever is suitable).
• Conditionally redirect to proper long URL, based on user agent.
• Validate every device long URL if requested, during creation/edition. Not for now (https://twitter.com/shlinkio/status/1617113528162308097 and https://fosstodon.org/@shlinkio/109732478541676141)
• API tests
  • Short URL creation
  • Short URL edition (including "detaching" device long URLs)
  • Redirect to proper place based on user agent (including fallback to regular long URL if impossible to match)
• Document feature in website (Document device long URLs feature shlink.io#342)

[acelaya]

This would definitely be something nice to have. I can think on many services which do something similar.

As a starting point, I would support "android", "ios", "desktop" and "default", leaving the door open to make it smarter in the future.

In order to support this, I would extend the short URL creation to allow something like this:

{
    "longUrl": {
        "android": "optional string",
        "ios": "optional string",
        "desktop": "optional string",
        "default": "required string",
    }
}

The only one required would be the default one, which would be the one used if the visitor is not identified as none of the other explicitly provided ones.

Current approach of { "longUrl": "whatever" } would continue working for backwards compatibility, and behave as if only default was provided.

Then redirects would also change. Shlink would try to identify the visitor and determine the proper redirect to use. This part is tricky, but there are promising libraries focused on this topic (like https://github.com/WhichBrowser/Parser-PHP).

Apart from this, the database would also need changes, validation would be affected, and a couple of other things, but in general, I think it's doable and useful.

[snorkrat]

Thanks for checking this out and putting it on the roadmap. I think it would definitely fit in with, and improve what Shlink has to offer. The only other (self-hosted) solution that I found that does this is Yourls. However the UI and workflow is not half as nice as Shlink. And the functionality is only added by way of a plugin so it's a bit fiddly and not very smooth.

The proposed solution is perfect, and your right; it leaves the door open to make it smarter in the future. Eg: you could have "Microsoft, Amazon, Apple (instead of iOS), etc"

Looking forward to seeing this implemented, and thanks for the hard work. Shlink is definitely the best self-hosted URL shortener that I've tried!

[ouquoi]

This feature will be highly appreciate !
Thanks

[acelaya]

I need to look for an alternative to https://github.com/WhichBrowser/Parser-PHP, as it is not compatible with PHP 8.2, and the PR to fix it that someone provided is stuck with no review, which makes me think the project is not very much maintained.

[acelaya]

This one is better maintained, and more up to date https://github.com/serbanghita/Mobile-Detect

[acelaya]

After some considerations, I have decided to implement this in a slightly different way.

When creating/editing the short URL, the request will look like this:

{
    "longUrl": "required string",
    "deviceLongUrls": {
        "android": "optional string",
        "ios": "optional string",
        "desktop": "optional string"
    }
}

being deviceLongUrls and everything inside of it completely optional.

The reasons are:

• It's easier to model in a backwards compatible way, both at domain level and at persistence level.
• The device long URLs will have to be exposed also in some endpoint (I haven't decided yet if there will be a new dedicated endpoint, or if I will include this in some existing one).

[acelaya]

This feature is now implemented and will be released with Shlink 3.5.0

Right after, I will start working to integrate it in the next version of shlink-web-client.

[klinux]

When do you think that this feature will be in the shlink-web-client?

Thank you.

[acelaya]

Already implemented shlinkio/shlink-web-client#813

It will be released when this list is completed https://github.com/shlinkio/shlink-web-client/milestone/49

[acelaya]

shlink-web-client 3.10 has just been released supporting this feature. It's already applied on https://app.shlink.io