Adding a single line can destroy the reputation of your app

On the 18th of december, there was an update for the ARD Mediathek app which I have installed with all the other updates. Normally, I won't notice any changes unless there are some fixes for errors I have received in the past or big new features are released. This time it was different.

The app update has broken the UX without even using it.

After the app update, every single link I clicked has opened a dialog to select which app to open the link. The first one was Chrome, the second the ARD Mediathek app. Even when I have choosen the ARD Mediathek app, the default home screen of the app was shown so there was no additional functionality. The app update has broken the UX without even using it.

I was a little bit frustrated and so I have uninstalled the app.

When I have looked at the ratings, I have noticed that I was not the only one who was annoyed. There was a lot of negative feedback about this misbehaviour.
This single change seems to have led to a lot of frustration.

The bad code line

On Android, you can define intent filters that open your app content using HTTP URLs via XML. You can either add an App link or a Deep link. The later one does not need a verification but may show a disambiguation dialog for the user to select which app to open the link.

You must specify a host which the app supports.

<activity> <intent-filter> ... <data android:scheme="https" android:host="www.example.com" /> ... </intent-filter> </activity>

You can add multiple hosts and wildcards (*).

Based on the settings in the app, the Supported links ¹ section for the ARD Mediathek app seems to look like this:

<activity> <intent-filter> ... <data android:scheme="https" android:host="*" /> <data android:scheme="https" android:host="beta.ardmediathek.de" /> <data android:scheme="https" android:host="www.ardmediathek.de" /> <data android:scheme="https" android:host="mediathek" /> ... </intent-filter> </activity>

The wild card(*) in the first data element is the one which is responsible for all the trouble. This single useless configuration line.

I don't know if the change was purposely or unintentionally. Based on the changelog and the useless functionality, I guess it was unintentionally. Maybe it was added by a framework update?!

We developers have such a powerful ecosystem in these days. We can see exactly what we commit to the repository. We can search online very quickly for the stuff and configs we don't know. Also if we break something - what happens to all of us - there is a quick feedback loop with error reporting or user feedback.

Learnings if the change was unintentionally

1. Know what you were doing / deploying
2. Set up and watch your feedback loop
3. Have a rollback strategy
4. Do not deploy before holidays

Learnings if the change was purposely

1. Communication
2. Communication
3. Communication

---

1. Besides the asterisk in the Supported links section, it also leaks the link to their beta website. Maybe the asterisk should be used for the subdomain part?