No, you write for the minimum API level your app requires. In a lot of cases, this is 2.3.3! If you want to target a wide audience and still use some 3.0/4.0 features, there are nifty polyfills available, too. Google is further improving this by extracting many of the super useful APIs out into a version-agnostic package that is updated independent of carrier say-so. Your API level 10 apps will run quite happily on Gingerbread, Honeycomb, and JB devices. Furthermore, Google supports multiple APK deployments, so you can actually build your application with different features for different API levels, and publish them under the same entry in the Play store; each device is routed to the proper APK.

However, despite all of this, you are talking about the exact same thing that Marco is. He says you "ideally" want to target iOS7, but you can't afford to do so if it means cutting out your iOS6 users. His conjecture is that since the established players are stuck on iOS6 (Gingerbread), the up-and-comers will have a shot to disrupt the market among the iOS7 (Jelly Bean) users. The assertion, flat out, is that "the big players being unable to upgrade their iOS6 software to meet iOS7 standards due to legacy support requirements is good for the app ecosystem", which is a pure RDF spin on the whole fragmentation issue that the Apple ecosystem loves talking about so much.

Marco's baseline assumption, if you read his full argument, is subtle. While it contains a few elements (as you've cited) of legacy support concerns - his principal thrust is not so much that you "can't afford to do so if it means cutting out your iOS6 users", rather, he primarily postulates:

"I don’t think most developers of mature, non-trivial apps are going to have an easy time migrating them well to iOS 7. Even if they overcome the technical barriers, the resulting apps just won’t look and feel right. They won’t fool anyone."

That is - the legacy app writers are going to have a huge challenge in trying to make their iOS 6 apps look "good" on iOS 7 - this is not a problem for someone starting from a greenfield scenario.

I really do think I get the thrust of his argument. I just don't think it holds up.

Let me ask this - why wouldn't app makers just migrate their apps to an iOS7 look and let the (by the arguments in this thread) vanishingly small non-iOS7 contingent deal with something that doesn't fit the theme of their system? If 90% of your userbase is going to be running iOS7, wouldn't it make more sense to just let 10% of your userbase have an app that doesn't feel like it matches the system (but definitely looks nice) rather than risk someone coming along and making a nicer-looking version of your app to steal the other 90% of your userbase?

The only way this becomes an actual talking point is if there is some reason that vendors can't upgrade their software to iOS7 guidelines, and that's the point at which you begin to experience fragmentation.

>Let me ask this - why wouldn't app makers just migrate their apps to an iOS7 look and let the (by the arguments in this thread) vanishingly small non-iOS7 contingent deal with something that doesn't fit the theme of their system?

It's not really about iOS 7 guidelines, it's about iOS 7 APIs, and you can't use iOS 7 APIs on iOS 6 devices. So if you still want to support iOS 6, your code has ifdefs everywhere and is a mess.

I don't know if his argument holds up either. I think he's approaching it with some baggage as the former proprietor or Instapaper. He frequently, on his podcasts, discussed his timing as to when he could simply "Require 5.x" as the iOS based on his user base.

That's the other problem with abandoning even a small percentage of your customer base - even though their existing app will continue to work the way it always has, the fact that they can't continue to upgrade to newer features, might results in negative reviews.

I agree with you, btw - that any app maker worth their salt, if they truly believe that 90% of the iOS userbase will be on iOS 7 in 3-6 months, should be prepared to completely abandon iOS 6 (except for those few that are targeting the iPhone 3GS and older iPod/iPad customer - big fish/small pond competitive technique) and focus all of their energies on iOS 7 development.

Ironically, this creates a positive feedback loop - as no more apps are being written for Pre iOS 7, people more quickly migrate to iOS 7, resulting in more developers completely focussing on iOS 7....

Marco's counterpoint might be, "The set of interest/resources/skills/focus that allowed a developer to build a leading iOS 6 App, might not be present for the new 7.0 paradigms, with their 3-D Z-axis geometry stacking of translucent tiles, inclinometer responsiveness, background processing. Someone who has an entire week at WWDC (yes, the videos are available - but nothing replaces 30-40 hours of onsite time) + all the developer networking (and drinking) that takes place might drive ahead and find the "Sweet Spot" in this new world.

Take, for example, Instapaper - perhaps a hungry up-and-comer will deliver a fully featured, iOS 7 ready read-it-later app, complete with background loading, fully 3D Sheet sliding of documents, light/colorful/iOS 7 palette brilliance etc... several months before Instapaper could be rebuilt. It's also possible (probably, as it turns out) that the original author of Instapaper didn't have the energy to rebuild Instapaper because they'd moved onto other things- And we haven't touched on this, "Upgrading an Existing App to iOS 7 gains a vendor no revenue (unless they have some IAP model)" - but does gain vendors of new iOS 7 apps lots of revenue.

In other words (and this hasn't been voiced yet) - there is a lot of incentive for NEW iOS 7 apps, but, unless you are a top 5,000 App on the AppStore, much less incentive to put a lot of energy into rewriting/upgrading an existing app to iOS 7.