Even if this wasn't the case, it's always possible that some new chunk of code you're adding requires a library that doesn't exist on down-level OS versions. Or the new code doesn't properly check existing libraries for the availability of classes or methods (e.g. some UIKit classes only exist in iOS 4.0 and up. To ensure that your app doesn't crash on older versions, you need to test for the existence of the class you want to instantiate). If any of these conditions hold true, crash city.
I own every iPhone that Apple has released, and I keep my original iPhone on 3.1.3 for precisely this kind of scenario. In fact, just yesterday I had to fix a couple iOS 3.1.3-specific bugs, and couldn't have done it without that original iPhone.
Long story short: if you're going to claim you support a particular platform, you better test on it. If you can't or won't test on it, then don't support that platform as a deployment target.
You can create AVDs (Android Virtual Device) that have different hardware capabilities (RAM, Camera, SDCard, Screen Sizes etc.) and run different versions of Android - 1.6 to 2.3 as of now. This makes testing your app very easy - you just set a minimum SDK version and if your app doesn't do weird things (uses features that don't work on a version of Android and declares support for that version)- most times it works very well.
API Levels - API changes are mostly additive and old APIs are carried forward as-is. http://developer.android.com/guide/appendix/api-levels.html
More than anything though - the developer can just push a beta in the Market and receive excellent feedback from users - user submitted stack traces, device info, feedback etc. can be very valuable in identifying and fixing compat issues.
I guess they assume everyone will upgrade, but a lot of people don't or can't.
Actually this appears to be false now. I just fired up my iOS Simulator, and in the "Hardware" menu I can select which OS version I want, either 3.2, 4.0.2, 4.1, or 4.2.
Just install Xcode 3.2.2, which does include support for the Simulator 3.1.3.
You can get it from http://connect.apple.com/ - select Developer Tools, find 3.2.2. in the page, download it, and install it to a directory other than the default /Developer, so your existing tools won't be affected. You might want to skip the installation of the developer utilities, since the ones from the current Xcode will be more up to date.
But you still are missing an important point. The Simulator is not an emulator. It does not run the same instruction set as the device itself. So the best way to test is still with actual devices running the versions of the OS you are interested in testing.
However the bugs I had would have been picked up in the simulator.
Thanks for the pointer for the older version of Xcode. That would have been great but at this point I may as well do my 3.1.3 testing on the device.
This post shows that iPhone has the same problem: every iOS version is a fragmentation point. If you want to support version X1, X2, X3, X4 etc. of iOS you have to make sure it works on all those versions, just like if you want to support version X1, X2, X3, X4 etc. of Android, you have to make sure it works on all those versions.
The post shows another thing: that while Google makes it easy for developers to support all OS versions by providing decent development tools (i.e. emulator that supports older OS versions) and providing developer-friendly phones (so that you can install different versions on the device).
In contrast Apple makes it difficult by forbidding developers to downgrade their phones for testing or providing emulators for older devices so developers have to jump through major hoops to make sure that their software runs on devices that are still being used by a nontrivial amount of users.
To summarize: in practice supporting multiple version of Apple's iOS is harder than supporting multiple versions of Android due to Apple's shitty developer tools and their general shitty attitude to developers, at least according to that one developer.
- Resolution differences, and no real scalable interface APIs.
- HTC vs Blur vs Samsung's distribution of Android. They all dick with stuff their own way.
- Physical buttons on each device. Some are overly sensitive capacitive buttons, clicky buttons, or high latency. Each require model specific code.
You can verify this by searching the release notes for apps in the Market. There's commonly caveats for certain models.
Keep in mind, Apple occasionally charges for iOS upgrades, so requiring an upgrade effectively increases the cost of your application by a nontrivial amount. Not all users want to upgrade, especially when upgrades degrade performance and have limited new features for older devices.
Apple attributed the fee to strange accounting rules (something dealing with when revenue is recognized - I don't exactly recall off hand) - rules which were recently changed. Just an excuse to milk some more cash out of iPod touch users? Maybe - I won't argue with you on that. But as of iOS 4.0, Apple no longer charges iPod touch users for updates.
"Not all users want to upgrade, especially when upgrades degrade performance and have limited new features for older devices."
Here is the real roadblock to updating. 4.0 has rendered my 3G frustratingly unusable. In my mind, those who haven't updated fall into three camps:
1. Those who jailbroke and haven't gone through the hassle of updating
2. Those who could care less about new features/aren't aware there is an update
3. As you mentioned, those who have older devices and don't want to update because of performance or development reasons
You don't believe me? Go on and try to stream a video on a Android 1.6 VM.
BTW: I'm developing a iPhone App in my spare times and a Android at work.
I'm currently really only supporting iPad because of that... but of course Apple will change the screen size on iPad 2.0 when that comes out. Aargh.
Went and bought an iPod-touch so I can test the 960x640 res if I ever get enthusiastic enough about it....
...then it turns out that Apple's implementation of multi-tasking is going to be a nightmare of a whole new dimension... lovely.
There are best practices on Android development to minimize fragmentation issues.
And no, you don't have to handle 100 versions of Android when developing.
If you restrict your app to run only from 2.1 and above, you got 80%+ of phones covered.
* It would be so much easier choosing an ISP if AOL was the only ISP in America.
* It would be so much easier being a mechanic if the only automobiles were Fords, and they only made 2 models.
* It would be so much easier developing video games if people weren't allow to configure their own systems. Then I wouldn't have to worry about all sorts of machines with various levels of beefiness in the hardware department.
Whining about Android fragmentation while praising lack of choice with Apple as 'simplicity' just seems childish.
I only have to test my app on my iPhone 4 and 2nd gen iPod touch.
Same thing applies to beta testing on iOS, but since Apple don't allow beta app, developers have to issue adhoc build.
My point was that you don't need to test on ALL different Android devices - just a few which seems to be similar with iOS from what you said. If you want to test lots of real devices - it's actually easy with Android - push the beta in the Market and let users do the compatibility testing.
If it is, I don't have to test on the previous 2 devices.
'Of course this was a time when Apple approved an update fast and it went out before I could test and I had not fixed all the issues.'
'I must have fumbled in the SVN check in.'
I fail to see what this got to do with iPhone vs. Android. It could have happened with both platforms.
It just isn't possible to make the case that this aspect of android doesn't make things harder and still retain any semblance of honesty or credibility.