Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

dantastic

macrumors 6502a
Original poster
Jan 21, 2011
572
678
We have an app developed for iOS6/7 that we now need to support on iOS3+.
The app uses ARC and a bunch of other helpful things added to the frameworks over the years so backporting is obviously not an option.

We are toying with the idea of writing a iOS3+ compatible version from scratch. Apart from the discussion whether it is worth it or not, is it possible?

First of all, can I submit an app to the store that support only iOS3-iOS5?
The intention is if you are running a newer version of iOS you will be asked to download the newer version of the app.
Can I do it with the current version of xcode?
The oldest test devices we have is a 3gs and a iPad1 - they are running on higher versions of iOS, I assume they are easily downgraded with the help of jailbreaking? Sorry, not too familiar with jailbreaking.
 
No, all apps submitted to the App Store must support iOS 7, so you can't make it for iOS 3 - 5 only.

I'd like to point out that as of right now, 97% of iOS devices are running iOS 6 or 7 - the remaining 3% are running iOS 5. There's absolutely no point in supporting iOS 3 or 4 because approximately nobody is using them, and those that are will likely update to something newer before your app is released.

I think iOS 5 supports ARC although I can't remember for sure. You can support iOS 3 (or 5) through 7 all in a single app if you want.

Or you could make a web app so that you don't have to worry about approval from Apple.
 
So the answer is since 1 Feb Apple are only accepting submissions created on xcode5.
xcode5 can build for targets 4.3+.

Thanks for that. Now I will hop over to some other forum to boost my thread count by providing irrelevant answers to questions.
 
You can manually enter 3.0 in that target field.

I've created a new project and just added in armv6, armv7, armv7s and tried to build against 3.0 as a target. It's not happy about it but it does allow me to build if I up the target to 3.2. 3.2 is good enough for our needs.

I'll see if I can get a device running on 3.2 now for some more testing.
Cheers!
 
ARC isn't supported below iOS 4. Also, 'weak' isn't supported in iOS 4, so if you need to use unsafe_unretained instead and be careful of dangling pointers.
 
iOS 3 devices run armv6 code. But Xcode 5 does not include an armv6 compiler or libraries. So you would have to build an armv6 app using Xcode 4.4 or earlier, and somehow lipo a slice into an Xcode 5 build without voiding the codesigning. Not sure if this would result in a binary that would pass upload verification.
 
iOS 3 devices run armv6 code. But Xcode 5 does not include an armv6 compiler or libraries. So you would have to build an armv6 app using Xcode 4.4 or earlier, and somehow lipo a slice into an Xcode 5 build without voiding the codesigning. Not sure if this would result in a binary that would pass upload verification.

So that's just a straight up no-go so really. We were hoping to be able to snare the (very few remaining) armv6 devices.

A bit of a google on the topic would suggest adding the armv6 compiler to xcode5 would be a bit of a struggle.
 
So that's just a straight up no-go so really. We were hoping to be able to snare the (very few remaining) armv6 devices.

A bit of a google on the topic would suggest adding the armv6 compiler to xcode5 would be a bit of a struggle.

Yup, you can "hack" an armv6 compiler to even Xcode 5.1 if you want to. There are several threads on this; for example, http://stackoverflow.com/questions/...mv6-and-armv7s-for-release-build-in-xcode-4-5

I myself, who provide iOS4.0+ and armv6 support in all my AppStore apps (even in the ones I've submitted after Feb/01, that is, Apple's enforcing compiling for iOS7), separately compile the armv6 in Xcode 4.4 and use lipo to manually add the armv6 binary to the armv7 binary compiled for iOS7 under Xcode 5.1. It's working wonderfully and requires little overhead, asuming you only need to do it before app submissions and not otherwise.

----------

iOS 3 devices run armv6 code. But Xcode 5 does not include an armv6 compiler or libraries. So you would have to build an armv6 app using Xcode 4.4 or earlier, and somehow lipo a slice into an Xcode 5 build without voiding the codesigning. Not sure if this would result in a binary that would pass upload verification.

1, it has nothing to do with code signing as you change the binary in the .xcarchive file (the one created when you archive a project), not in the one actually (later) sign with your AppStore distribution profile.

2, Apple currently does allow lipo'ed, armv6-compatible apps. I have many of them in the AppStore, even ones recently (after 01/Feb) submitted.

----------

Why do you state that you NEED to? I can't think of any reason other than you have some random customer that is adamant about not upgrading, but even that seems very farfetched.

Why for example I do this?

1. I have most iDevice models ever released and very often hand them out to my customers (I do contract work directly for companies, the result of which, then, is submitted to the AppStore) so that they can test my apps on them too. I prefer not to leave any of my devices unable to be handed out :)

2. it's a definite business / competitive advantage in the AppStore to be the only app in its category to have not only 4.3+, but even 4.0-4.2.1 + armv6 support. Anyone looking for an app in the category on his/her iPhone 3G will only be able to install mine and not those of the competition. I think this is worth the additional effort of separately compiling (for distribution) my apps under Xcode 4.4 for armv6 and manually adding the resulting armv6 binary to the iOS4.3+/armv7/armv7s fat binary produced by Xcode 5.1.
 
2, Apple currently does allow lipo'ed, armv6-compatible apps. I have many of them in the AppStore, even ones recently (after 01/Feb) submitted.

Good to know. (At least regarding Apple's current approvals to date.)

Why for example I do this?
...
Anyone looking for an app in the category on his/her iPhone 3G will only be able to install mine and not those of the competition.

Assuming that the additional revenue from that 1 or 2% of potential iOS customers makes it worth your time... more than spending the time improving other marketable features of your apps. For an app grossing enough, possibly so.

Also, if you had an older version of the app already approved and in the store long ago, it may still be available for those few customers to download.
 
Assuming that the additional revenue from that 1 or 2% of potential iOS customers makes it worth your time...

Compiling (archiving) in Xcode 4.4. and manually lipo'ing the binaries takes 5 minutes at most. It really isn't time-consuming. And as I try to support 4.3.x too (that is, I refrain from using any iOS5+-only functionality or, if I do it, I do it conditionally), supporting 4.2.1/armv6 doesn't require much additional work, in addition to supporting 4.3. (There have been very little API and/or behavior changes between 4.2.1 and 4.3.x - the change between 5 and 4.3.x have been far more substantial.)

Also, if you had an older version of the app already approved and in the store long ago, it may still be available for those few customers to download.

Yup, they're still accessible, but, given that providing armv6 support is so easy, I deemed it preferable to support not only 4.3.x/armv7, but also 4.2.1/armv6. As I stated above, there are virtually no differences between the behavior of those OS versions - if you make sure your app runs OK on 4.3, you can be pretty sure it won't have problems on 4.2.1 either, on armv6 devices. Unless you use stuff missing from armv6 devices entirely (256+ MB RAM, OpenGL ES 2.0 etc.), obviously.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.