As alluded to above, there are material differences between how app "header bidding" works and how it works in web. Specifically, in the app context, there is no browser (for the sake of this discussion - this isn't exactly true). Instead, ads in apps are often served through an SDK (software development kit - plugins that the app developer adds to their app for certain functionality). The SDK is written in the language of the app's operating system (again... more or less), and exposes certain functionality to the app developer. For example, the SDK can be called to initiate an ad auction and cache the resulting ad, so that it's available for the app without a wireless connection in the future. This means the developer doesn't need to implement this functionality and it also ensures a malicious app developer doesn't undermine the integrity of the calls being made by the SDK. Thus viewability, click, and similar pixels are only delivered when they should be, as regulated by the SDK.
Historically, mobile app advertising has been done through SDKs. Major app advertising providers have worked aggressively to distribute their SDKs, including the largest players - AdMob (Google), MoPub (Twitter), FAN (Facebook), Millenial (Oath), InMobi and AppLovin'. SDKs can be integrated into mediation platforms that can trigger ad calls and, based on the capability of the SDK platform, cache the results. Some SDKs can bid on a CPM basis, and some do not - meaning the mediation platform sometimes estimate that likely value of those SDKs based on historical data. The SDK then renders the resulting ad. This requires that the SDK be installed in the app to participate in the mediation.
Currently, app advertising includes highly custom integrations. This includes, for example, incentivized video views in exchange for in-game currency, moments, etc. Much like we're seeing in the web context, the appeal of header bidding will spread as far as it can. For simple display advertising, it is inevitable that a single SDK frontend for header bidding will grow materially through the app ecosystem, despite relatively limited traction today - this will likely change in 2018. Compelling existing apps to install new SDKs is always challenging, though as Prebid gets more partners, it will likely proliferate. In turn, this means that both TripleLift's standard exchange and Header Direct (as well as its potential competitors) will have an easier time accessing an increasingly large pool of apps without requiring app-by-app SDK installation. Some companies that rely on exclusive publisher relationships may not participate in this ecosystem, but much like header bidding on web, this is a tenuous position for such companies. It is also inevitable that header bidding SDKs will expand in the app functionality that they expose to developers, meaning SDKs will increasingly need to offer additional non-monetization functionality - or deliver particularly stronger CPMs when installed - to justify being installed as app header bidding catches on.