I'm definitely all for customers first - the proposal is based on the practicality factors I've previously stated: http://markmail.org/message/mldr2mzrpf233h2r
It's hard to vouch for a release "runs on iOS 5.0" when we can't test on it, internally I've already asked around but no dice, and I suppose the co. can spring for a used one off Craigslist ($250-300 for an iPhone 4S), but the a factor here is testing time as well. It's a good thing iOS 5 didn't run on the 4" iPhones (5/5s/5c), if not a device in that form factor running iOS 5 would be required for testing, however an iPad 1 needs to be found for iOS 5 testing as well (since the iPad 1 cannot be upgraded from 5.0, and has no camera so we need to test that path as well). I'm entirely ignoring iPod Touches that can run 5.0, but then we've been ignoring those anyway so far with iOS testing. So -- more testing. Here's an example - for the StatusBar and Keyboard plugins I had to test on iOS 6 (3.5" and 4") and iOS 7 (3.5" and 4"). And also the iPad 6.0 (retina and non-retina) and iPad 7.0 (retina and non-retina). So for a feature, I had to test it in 8 configurations. There were quirks like you wouldn't believe - and bug fix turnaround time was not fast. But this is atypical -- the other core plugins have an easier go at testing since all you are testing generally is the APIs (save Camera and Capture) Further answers inline: On Thu, Dec 19, 2013 at 3:01 PM, Marcel Kinard <cmarc...@gmail.com> wrote: > I'm gating this based on the following understandings, please point out > any errors: > - Xcode 5 can target iOS 5.0 and 5.1 > Yes, this is through the "Deployment Target" Build Setting. The app itself must be compiled using the iOS 7 SDK (with the Feb 1 2014 upcoming rule). The app still needs to be tested at runtime however, it might crash if it tries to run any iOS 7 API on an iOS 5 device (which we try to guard against in runtime code). - Xcode 5 has emulators for iOS 5.0 and 5.1 > No it does not include the iOS 5 emulators. If you upgraded from Xcode 4 to 5, in 10.8 Mountain Lion, you will get the iOS 5 emulators. If you installed in 10.9 Mavericks, you can only install Xcode 5 (Xcode 4 is not allowed to install), so you won't get the iOS 5 emulators nor an option to download them. > - the fat binary support in Xcode 5 can generate 32-bit code that can run > on iOS 5.0 and 5.1. [1] > Yup 5.1.1 min for 32 bit, and 7.0.3 min for 64 bit. I suppose the App Store will filter for these - I hope! But it will be a support nightmare somehow or rather - it's not like the App Store will say - "Hey, you can install this, really, just update from 7.0 to 7.0.3 first". > - there isn't code that needs to be ripped out or a bunch of conditional > branches that need to stay in especially if iOS 6 is supported, it's really > a matter of test effort to cover iOS 5.x > > True - 50% or more testing. This will get complex with plugins I suppose - third party ones might not be so careful but that's out of our control (we will have to trust the plugin.xml declarations). I'm not quite sure all our core plugins are backwards compliant, but we'll find out if we test on iOS 5.x > [1] per the Xcode release notes, it actually looks like the min target for > fat binaries is iOS 5.1.1. This pokes at least one hole in my argument if > the desire is to generate only a fat binary. > > I understand the thought process around supporting iOS n and n-1. And the > desire to set a cutoff at a 5% global average usage. But Asia isn't > average, and averages can hide things. My suggestion is to align more (not > entirely) with what the current Xcode supports as deployment targets with > emulators. Apple seems to keep the cutoff level in Xcode moving up. To keep > balance, I also wouldn't suggest to do something unnatural (i.e., iOS 4.3). Unfortunately, as previously stated Xcode 5 has already dropped iOS 5 emulator support.
