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.
>

Reply via email to