Oh, and I forgot - there are actually 4 more configurations to test (for a total of 12). I forgot "iPhone only" on an iPad (retina and non-retina) on iOS 6 and 7. Yes, there is an Apple bug on iOS 7 for "iPhone only" on iPad *sigh*...
On Fri, Dec 20, 2013 at 2:50 AM, Shazron <shaz...@gmail.com> wrote: > 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. >