Over the years, despite continuous design improvements, iOS apps have been treated largely as data silos and have been unable to use data outside of the confines of their sandboxes. However, with the emergence of iOS 9, Apple was able to reimagine the way information from within the app was exposed to users. Its new strategy was pretty straightforward: let people search for what they are actually looking for.
Here’s a quick rundown of how deep linking in iOS, critical to Apple’s strategy on mobile search, has changed over the past 10 months.
iOS 9.0 – Introduction of Universal Links
In June 2015 at the Worldwide Developers Conference, Apple launched Universal Links, its long awaited foray into deep linking, with the premise that deep linking was a superior way to launch apps, navigate them, index content, and share results.
Pre-iOS 9.0, developers would use URI schemes to redirect the user to a specific piece of content within the app; this was the only available method to deep link in iOS and Universal Links made it easier for the users to navigate across — not just launch — apps with ease.
iOS 9.2 – The Fall of URI Schemes
With iOS 9.2, released in December 2015, Apple made changes to Safari which made it impossible to deep link to content within the app as the user was now redirected to the App Store regardless of whether or not the app is already installed. Developers were left with only Universal Links as an option to implement deep linking – a standard that Apple clearly wanted to push onto the community. This update hurt a lot of app developers, so we’ve created a guide if you’re still struggling to transition from URI schemes to Universal Links.
iOS 9.3 – The Trouble with Universal Links
With respect to deep linking specifications, nothing changed in iOS 9.3. However, around the time of iOS 9.3’s release, the rate of adoption for Universal Links significantly increased as bigger apps began to implement it. Deep linking via Universal Links received a great response from developers who had been trying hard to connect their in-app content to the world outside of their app.
One of the biggest advantages of Universal Links is that it is secure. Apple requires a configuration file to be uploaded on the domain name – called the Apple App Site Association (AASA) file. (You can use our new validator if you want to check to see if you AASA file is configured properly). Since the app owner has control over this, there is little chance that another app can associate itself with your links, which was not always the case while working with less secure URI schemes to launch apps.
However, despite the fact that Universal Links is secure, there are significant problems. For example, a poorly implemented Universal Link solution at Booking.com sent its app crashing on iOS 9.3 and exposed flaws in the iOS system.
Booking.com created an AASA file that was 2.3 MB in size, which was a bit too much to chew for iOS, resulting in app crashes and unresponsive links. Even though Booking.com quickly resolved the issue with a new, smaller AASA file, the lack of a gracious fallback for a system feature (i.e. web browsing) unearthed the vulnerabilities of the Universal Link system. The damage to Booking.com had already been done — thousands of users had already had negatives experiences due to Universal Links.
Apple is definitely moving fast with Universal Links in a bid to win the war on mobile search with Google, but it needs to be wary of the consequences that a hurried solution can have on the user experience. After all, user experience is something that Apple prides itself on, and it has yet to be proven that the usefulness of Apple’s Universal Links trumps the damage to user experience that comes with its adoption.
Digital & Social Articles on Business 2 Community(46)
