You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2013/09/18 00:45:50 UTC

Dropping iOS 5.0 support

On the eve of the launch of iOS 7, I filed this issue:
https://issues.apache.org/jira/browse/CB-4863

I left the "Fix version" empty for now...

Re: Dropping iOS 5.0 support

Posted by Kerri Shotts <ke...@photokandy.com>.
Just to note:

On my particular machine (OS X Mavericks), Xcode 5 does not provide iOS 5.0
and 5.1 simulators. The minimum version is 6.0. From a quick google search,
it also appears that iOS 5.x simulators are out-of-reach -- they apparently
aren't supported under ML or later

So Xcode 5 will support different simulator sets based on the user's OS.
Which does tend to poke a hole in the argument -- at least for those devs
who have upgraded their OS.

All that said, if iOS 5 is important to a dev, they should have a physical
device with iOS 5 on it, so it's not a fatal flaw in the argument either
way.



___________________________________
Kerri Shotts
photoKandy Studios, LLC

On the Web: http://www.photokandy.com/

Social Media:
          Twitter: @photokandy, http://twitter.com/photokandy
          Tumblr: http://photokandy.tumblr.com/
          Github: https://github.com/kerrishotts
                        https://github.com/organizations/photokandyStudios
          CoderWall: https://coderwall.com/kerrishotts

Apps on the Apple Store:

https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828

Books:
          http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book
          http://www.packtpub.com/phonegap-social-app-development/book


On Thu, Dec 19, 2013 at 5:01 PM, Marcel Kinard <cm...@gmail.com> wrote:

> I know I'm going to look like a whacko and this will probably go over like
> a lead balloon, but I'll say it anyway: I'd like to see iOS 5 stay in
> Cordova for the next while. This is with my customer hat on, not my Cordova
> developer hat on.
>
> The reason is because our distribution has customers internationally,
> including Asia. In Asia there are higher concentrations of iOS devices that
> aren't upgraded like other geographies, which there becomes a significant
> amount of end-user devices instead of a trivial amount. iOS 5 end users are
> important to app developers in Asia using our distribution - they want to
> support these end users.
>
> I'm gating this based on the following understandings, please point out
> any errors:
> - Xcode 5 can target iOS 5.0 and 5.1
> - Xcode 5 has emulators for iOS 5.0 and 5.1
> - the fat binary support in Xcode 5 can generate 32-bit code that can run
> on iOS 5.0 and 5.1. [1]
> - 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
>
> [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).
>
> On Dec 19, 2013, at 1:32 PM, Shazron <sh...@gmail.com> wrote:
>
> > Starting Feb 1st, 2014, Xcode 5 is required:
> > https://developer.apple.com/news/index.php?id=12172013a
> >
> > This is the perfect time to drop iOS 5.0 support, and support arm64. I
> > would say the Jan 2014 release should have this change.
>
>

Re: Dropping iOS 5.0 support

Posted by Shazron <sh...@gmail.com>.
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 <sh...@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 <cm...@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.
>

Re: Dropping iOS 5.0 support

Posted by Shazron <sh...@gmail.com>.
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 <cm...@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.

Re: Dropping iOS 5.0 support

Posted by Marcel Kinard <cm...@gmail.com>.
I know I'm going to look like a whacko and this will probably go over like a lead balloon, but I'll say it anyway: I'd like to see iOS 5 stay in Cordova for the next while. This is with my customer hat on, not my Cordova developer hat on.

The reason is because our distribution has customers internationally, including Asia. In Asia there are higher concentrations of iOS devices that aren't upgraded like other geographies, which there becomes a significant amount of end-user devices instead of a trivial amount. iOS 5 end users are important to app developers in Asia using our distribution - they want to support these end users.

I'm gating this based on the following understandings, please point out any errors:
- Xcode 5 can target iOS 5.0 and 5.1
- Xcode 5 has emulators for iOS 5.0 and 5.1
- the fat binary support in Xcode 5 can generate 32-bit code that can run on iOS 5.0 and 5.1. [1]
- 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

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

On Dec 19, 2013, at 1:32 PM, Shazron <sh...@gmail.com> wrote:

> Starting Feb 1st, 2014, Xcode 5 is required:
> https://developer.apple.com/news/index.php?id=12172013a
> 
> This is the perfect time to drop iOS 5.0 support, and support arm64. I
> would say the Jan 2014 release should have this change.


Re: Dropping iOS 5.0 support

Posted by Tommy-Carlos Williams <to...@devgeeks.org>.
+1


On 20 Dec 2013, at 4:32 am, Shazron <sh...@gmail.com> wrote:

> Starting Feb 1st, 2014, Xcode 5 is required:
> https://developer.apple.com/news/index.php?id=12172013a
> 
> This is the perfect time to drop iOS 5.0 support, and support arm64. I
> would say the Jan 2014 release should have this change.
> 
> See:
> https://issues.apache.org/jira/browse/CB-4863
> https://issues.apache.org/jira/browse/CB-5286
> 
> 
> 
> On Tue, Sep 17, 2013 at 3:45 PM, Shazron <sh...@gmail.com> wrote:
> 
>> On the eve of the launch of iOS 7, I filed this issue:
>> https://issues.apache.org/jira/browse/CB-4863
>> 
>> I left the "Fix version" empty for now...
>> 


Re: Dropping iOS 5.0 support

Posted by Shazron <sh...@gmail.com>.
Starting Feb 1st, 2014, Xcode 5 is required:
https://developer.apple.com/news/index.php?id=12172013a

This is the perfect time to drop iOS 5.0 support, and support arm64. I
would say the Jan 2014 release should have this change.

See:
https://issues.apache.org/jira/browse/CB-4863
https://issues.apache.org/jira/browse/CB-5286



On Tue, Sep 17, 2013 at 3:45 PM, Shazron <sh...@gmail.com> wrote:

> On the eve of the launch of iOS 7, I filed this issue:
> https://issues.apache.org/jira/browse/CB-4863
>
> I left the "Fix version" empty for now...
>

Re: Dropping iOS 5.0 support

Posted by Shazron <sh...@gmail.com>.
D'oh my maths issa bad. 50% increase in testing, of course.


On Wed, Sep 18, 2013 at 1:31 PM, Shazron <sh...@gmail.com> wrote:

> Developer neglect, really. Seeing as I don't really have a work iOS 5
> device to test on. If I did, testing would add another platform, so 33.33%
> increase in testing time :p
>
> Also, any code changes _have_ to take into account older platforms,
> whether the API exists, and guard against it during runtime. For example:
>
> https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=blobdiff;f=CordovaLib/Classes/CDVViewController.m;h=e994f35bc051f328b6cc09e7ee6ba41b51591c4b;hp=6facdc1191facf6e967111c47ce8baf382912d6c;hb=215da06ae3224fa0e20a541f3b17e1ec468c5320;hpb=14d79b481d2fe6d4cfc0036ced9bc9c99f8c504a
>
> Even so, before committing the changes, you would still have to test on
> the other platforms (ideally on device) but more likely on Simulator.
> Seeing as Xcode 5 removes the old SDKs (unless you copy it in yourself),
> this is one more added complication - but iOS 6 Simulator is included, but
> that can't test everything - Camera for example.
>
> Any corporate users chime in here regarding the enterprise needing support
> of iOS 5 still? (Since Enterprise apps are not required to use Xcode 5 I
> think, unlike apps headed for the App Store)
>
>
>
> On Wed, Sep 18, 2013 at 1:19 PM, Marcel Kinard <cm...@gmail.com> wrote:
>
>> Out of curiosity, what would be your back-of-the-napkin calculation on
>> the cost per Cordova release to keep iOS 5 support?
>
>
>

Re: Dropping iOS 5.0 support

Posted by Shazron <sh...@gmail.com>.
Developer neglect, really. Seeing as I don't really have a work iOS 5
device to test on. If I did, testing would add another platform, so 33.33%
increase in testing time :p

Also, any code changes _have_ to take into account older platforms, whether
the API exists, and guard against it during runtime. For example:
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=blobdiff;f=CordovaLib/Classes/CDVViewController.m;h=e994f35bc051f328b6cc09e7ee6ba41b51591c4b;hp=6facdc1191facf6e967111c47ce8baf382912d6c;hb=215da06ae3224fa0e20a541f3b17e1ec468c5320;hpb=14d79b481d2fe6d4cfc0036ced9bc9c99f8c504a

Even so, before committing the changes, you would still have to test on the
other platforms (ideally on device) but more likely on Simulator. Seeing as
Xcode 5 removes the old SDKs (unless you copy it in yourself), this is one
more added complication - but iOS 6 Simulator is included, but that can't
test everything - Camera for example.

Any corporate users chime in here regarding the enterprise needing support
of iOS 5 still? (Since Enterprise apps are not required to use Xcode 5 I
think, unlike apps headed for the App Store)



On Wed, Sep 18, 2013 at 1:19 PM, Marcel Kinard <cm...@gmail.com> wrote:

> Out of curiosity, what would be your back-of-the-napkin calculation on the
> cost per Cordova release to keep iOS 5 support?

Re: Dropping iOS 5.0 support

Posted by Marcel Kinard <cm...@gmail.com>.
Out of curiosity, what would be your back-of-the-napkin calculation on the cost per Cordova release to keep iOS 5 support?

Re: Dropping iOS 5.0 support

Posted by Andrew Grieve <ag...@chromium.org>.
I don't see a compelling reason to keep supporting it given that pie chart.


On Tue, Sep 17, 2013 at 7:02 PM, Michal Mocny <mm...@chromium.org> wrote:

> https://developer.apple.com/devcenter/ios/checklist/
>
> I imagine the number of iOS5 users will drop even further within the coming
> weeks.
>
> We dropped Android 2.2 when it had similar usage, if I recall (though thats
> down significantly more now).
>
>
> On Tue, Sep 17, 2013 at 3:45 PM, Shazron <sh...@gmail.com> wrote:
>
> > On the eve of the launch of iOS 7, I filed this issue:
> > https://issues.apache.org/jira/browse/CB-4863
> >
> > I left the "Fix version" empty for now...
> >
>

Re: Dropping iOS 5.0 support

Posted by Michal Mocny <mm...@chromium.org>.
https://developer.apple.com/devcenter/ios/checklist/

I imagine the number of iOS5 users will drop even further within the coming
weeks.

We dropped Android 2.2 when it had similar usage, if I recall (though thats
down significantly more now).


On Tue, Sep 17, 2013 at 3:45 PM, Shazron <sh...@gmail.com> wrote:

> On the eve of the launch of iOS 7, I filed this issue:
> https://issues.apache.org/jira/browse/CB-4863
>
> I left the "Fix version" empty for now...
>