This kind of possible attack is mitigated because after you download an app, it still has no permissions to do anything interesting - access to background location, contacts, camera, audio, etc. all require permissions that prompt the user for access.
So even if someone uses an Xcode that is compromised, there's not very much gain you are going to get by having malicious code in the app except for what that app is working with.
Unless they can trick the user into giving up their iTunes account details by showing a system-prompt-lookalike. The system already prompts for passwords at some pretty random times, so that might not be hard.
Or they could customise the exploit behaviour depending on the host application. Wait until some relevant app has been successfully exploited and is reporting in, then tailor an approach to steal whatever app-specific data is relevant (login details, etc) or even override the app's networking classes and MITM the outgoing connections.
On a side note, I would think it would be hard for an attack like this to succeed because as a developer builds an app, they are often monitoring network traffic or otherwise examining app activity... even in release mode at times.
Even if this were true (I don't really agree that it is, although I do agree that somebody will spot it sooner or later) then it would be easy enough to work around. Just have the exploit not phone home until after a certain fixed date, or a certain amount of time after the app was built, or not while a debugger is attached, or etc. In fact, since you've compromised the Xcode tools, just hide any reporting of your exploit's activity.
Just because you can't necessarily gain control over the whole device this way (it's one step towards that, but you'd need a secondary exploit) doesn't mean that it isn't a problem.