Ben does explain the background, as well. In brief, it seems to have started with a simple coding practice of just adding valid web links for apps that aggregate...like Booking .com, or my Newsify app example. That worked up to a point, but when the list got huge it then overloaded an iOS routine and either crashed things as he says so that the daemon couldn't disgorge the huge lump of info. Or maybe it was an unintentional loop, or an off-by-one, or a memory allocation glitch. So the effect spread beyond the app and affected Safari, and other things that the iOS touched for web links. If people did a clean install that really cleaned things up for the daemon, and avoided reintroducing the link-happy apps' oversized lists-o-links, it might work out. Whatever the case, here is Ben's explanation:
"What's Going On
In iOS 9 Apple introduced Universal Links, these allow app developers to associate their website and app, so links to the website can open the app up automatically if installed. For example, following a link to a Guardian article opens up the Guardian app to that specific article instead of their website.
App developers put an app association file on their website which lists which types of URLs the app can open. When you install an app, iOS downloads this associated file and updates your own database of what URLs your installed apps can open. The website and app listing in iTunes are linked by the developer - so it prevents anyone from hijacking your website with their app.
When you tap a link in iOS, the system looks through the database of installed apps supported URLs to see if it matches a pattern an installed app can handle. If nothing matches it opens it up as a standard app.
Why's It Broken
It looks like there's a bug in iOS that completely breaks the Universal Links if it gets served an app association file that's too large.
Benjamin Mayo of 9to5mac.com reported installing the Booking.com app consistently broke their test devices - which led Steve Troughton-Smith (who else...) to take a peep at their association file: [screenshot of the file, and screenshot of Twitter where Steve T-S states that the file was a 2.3MB download].
It seems that the large size of their file, due to it having every URL from their website inside it breaks the iOS database on the device. Apple allows you to have pattern based matching, so instead of having to include every hotel's URL in the association file, Booking.com could just put /hotel/* to match all the hotels on their site.
Whilst Booking.com aren't following the recommended approach, it's not their fault that a third-party can break a fundamental system feature like web browsing. Apple should be handling these edges graciously.
The worst part - deleting the app doesn't clear the Universal Link association. Because the OS process that handles the Universal Links has crashed, it appears unable to remove the corrupt database.
The Workarounds
Unfortunately there's no fix for this at the moment although a restart of the OS can temporarily restore links, and turning off JavaScript (Settings -> Safari -> Advanced) allows certain websites, such as Google search results to work again. Apple confirmed these workarounds to me, and hinted there may be a software update to resolve this;
'Be sure to keep your software up to date in case a future release addresses this issue.
We do have two workaround options. Restarting the phone may allow links to work, but the issue can come back. The other workaround would be [to] turn off JavaScript.'
Some users have been able to fix with an elaborate reboot cycle
Update One 13:00 March 28/03/2016: Booking.com have updated their association file - it's now only 4KB - this hasn't fixed the issue but should prevent new users that install from hitting the same problem. Even reinstalling the app and rebooting doesn't fix it - the swcd (shared web credentials daemon) crashes once it's got corrupt data in it."