Every year, when the new iOS update comes out, the Branch teams waits anxiously to hear their marching orders from the Apple team at WWDC. And this year was no different. At first, it seemed like iOS 10 didn’t include anything that would significantly affect us, but as the betas progressed, it became clear that we’d have to do a bunch of work in preparation for the update.
The major takeaway is: The Branch iOS SDK is ready for use in your iOS 10 apps today! But of course, you want to know all of the changes in detail, so this post summarizes all of the significant changes made by Apple, and the Branch response.
{{ script_embed(‘wistia’, ‘3islei6wfh’, ‘undefined’, ‘responsive’) }}
Support for App Extensions and iMessage Apps
Clearly, the biggest area of investment on iOS 10 was the completely revamped iMessage platform, along with a whole new App Store for these types of apps. The good news is that Branch iOS SDK 12.7 has full support for deep linking in iMessage apps. It’s a slightly different integration path, so we’ve written some materials on how to get started.
Unfortunately, iMessage doesn’t include support for URI schemes or Universal Links, so this integration will only work seamlessly for new installs. Re-engagement links won’t be able to open the already-installed iMessage app. Hopefully, Apple adds support for that soon!
Update to List On Spotlight for New Cloud Index
With a lot of help from the product managers at Apple who manage the Spotlight local and cloud index products, we’ve revamped our integration to use NSUserActivity indexing alone. You can find the updated documentation here. This new method of indexing ensures that your content is deduped across instances of your app, so that view counts properly increment and count towards improving your app’s content relevancy in the Spotlight cloud index.
Initialize your Branch Universal Object on view load with the flag enabled to automatically list on Spotlight, then trigger a view event on the object in theviewDidAppear lifecycle method. This will ensure the data gets sent to Apple appropriately, and that you aren’t punished for trying to hack it.
Handling of IDFA Blackout for Limit Ad Tracking
To the surprise of the advertising industry, Apple finally added a harsh restriction around the use of the IDFA (identifier for advertising) when the mobile user has opted into limit ad tracking. Now, if the toggle is selected, when you try to retrieve the IDFA, it’ll return all zeros instead of the normal hash. By analyzing current traffic and settings, we’ve noted that today, around 10-20% of users have this setting enabled so the impact will be limited. However, for those users, cross-app attribution with the IDFA will be impossible, impacting all of your advertising services significantly.
Branch, however, will be unaffected and your deep links and attribution will continue to work the same. We’ve been prepared for this for a while and are not dependent on the IDFA whatsoever for our service. You can read all about the details of how we do matching here. For install/re-install tracking analytics as well as credit attribution, we’ll use the IDFV (identifier for vendor), which remains the same across multiple installs of the same app.
The only potential impact is that for users with the limit ad tracking setting enabled, we won’t be able to use our massive pool of Branch cookies to IDFA bridges to match with 100% accuracy. To counteract that, you can use the Safari View Controller to assist with that in cases where a user clicked from Safari.
Ban Hammer on Hidden Safari View Controller Use
Branch was one of the original thought leaders behind the use of the shared cookie jar between the Safari View Controller and the Safari browser, to guarantee 100% match of attribution from the browser into the app. However, a week ago, Apple decided that they didn’t like this behavior and added a line to their App Store terms of use to block it.
If this sounds unfamiliar to you, then you’re not using it and you can ignore this section. The feature must be enabled by adding the SafariServices.framework file to your build. If you’re using SafariServices.framework for another aspect of your product, you can disable the use of the Safari View Controller by flagging with this simple method call:
100% matching is a bit of a misnomer for this service since it only works to track users who originate from the Safari browser on iOS 9 and iOS 10. According to our analysis, we estimate this to be more like 50% in aggregate across clicks. Fortunately for you, Branch has a massive database of cookies in other browsers paired with IDFA paired that will be used in the event that a user doesn’t come from Safari, so you still get 100% match in those circumstances.
Going forward, we’re working on a feature that we expect to deploy in v0.12.8 this week, where we’ll allow you to implement a visible Safari View Controller and trigger the 100% matching functionality in an Apple-compliant way.
Support for Attribution of Apple App Store Search Ads
Lastly, as you may have seen, Apple is planning to unveil App Store Search Ads in iOS 10 that allow you, as a developer, to promote your app to App Store queries. It’s not live yet in iOS 10, so we’re not announcing a feature around it yet, however, we plan to fully support you in your App Store Search Ads experience.
Here’s what you can expect from Branch when this feature is rolled out more publicly:
Automatic App Store Search Ad attribution
We’ll automatically track the install as referred by the ad, and tag it with the appropriate campaign name and keywords corresponding to the ad that drove the campaign.
Deep linking and new user personalization from Search Ads
Want to offer some sort of special feature to users who originate through these ads? Or route them to a particular landing page? You can do that with Branch.
All in all, iOS 10 is a huge step forward in the platform, and we’re excited about the potential. You can get back to being focused on your product, as your links are safe with us.