Some context: On the web and (since recently, with T192779 and this patch) in the Android app, we do actually send the full url of the referrer as part of the request for the actual article being opened. For the web, that's of course simply part of the HTTP standard. It is then stored temporarily as part of the webrequest table (in the referer field), and processed further to e.g. generate the referer_class field in the pageview_hourly table, or the external referrals data exposed in this dashboard or the public Clickstream datasets.

I think it might make sense for the iOS app to also populate the referer field in requests (like Android does now, if possible also for external referrers), so as to benefit from all these established tools and processes. That said, a separate EL schema to log all the iOS-specific sources in more detail (Spotlight search etc.) could surely make sense too. Perhaps we should track this in two separate tasks.

Thanks for the context @Tbayer !

And I agree these are two different tasks. The first one, as stated by @JMinor in the task description, is to record from where people invoke the iOS app. This can be solved by adding a "source" field to the MobileWikiAppiOSSessions table.
The second task, according to the context given by @Tbayer , is to add "referrer" to the API requests to retrieve the articles. We should probably chat with Android engineers to get more details.

This information would help us increase the iOS app users.