In addition to the other comments on this subthread, a point I think is worth making:

If you're providing both an app and a server for the app to talk to you, you control both ends of the TLS connection and can pin however you'd like; you're not limited to HPKP and key-continuity. Secure apps have been doing custom pins of TLS keys long before HPKP got rolled out.

I'm not sure I quite understand your point, but wouldn't an attacker with the ability to modify an app on someone's device have access to the plaintext anyway?

Oh sorry, I probably should have been a little clearer. I'm thinking of a different attack scenario where the attacker wants to MITM your app to inspect traffic and utilise your server-side API for unintended purposes. So it looks like:

Attacker --> Attacker's Phone --> App --> MITM proxy --> API/Server

So you could use this to pull down real-estate listings from a real-estate app in an easily parsed format (usually JSON). Or write an app that pull down the odds from various sports betting app APIs, detects arbitrage opportunities and automatically places bets using their APIs...

EDIT: Oh and on the plaintext thing, generally no. Most apps will use TLS for app-to-server comms. Pinning in this context means they bundle the cert (or signature) with their app. By the looks of this (http://security.stackexchange.com/questions/29988/what-is-ce...) it's a similar story with chrome: they pre-bundle some signatures. The alternative is to pin on the first interaction, but this leaves you potentially vulnerable if an attacker is listening in on that first interaction. It also raises the question: what happens if the website needs to revoke and re-issue? Wouldn't pre-bundling mean you'd have to wait for the next browser update (and for out of band commms to have occurred between google and the website)?

I might be misunderstanding you, but I don't think Public Key Pinning is intended to prevent this scenario at all. Public Key Pinning is a method for a client to authenticate a server. If you decompile the app and recompile it with the public key of your MITM server, the app would of course connect to your MITM server. Or, it seems to me, if you have that level of control over the client, you could just disable public key pinning checks completely.

Right, but the purpose of key pinning is to prevent a MitM from learning the plaintext, not Alice or Bob. There are any number of means an attacker could employ to reverse-engineer an API (decompilation, memory dumps, debuggers, ...). This is asking for more of a DRM-like solution (with all the issues that come with it).