iOS 7 only is the only sane thing to do(berzniz.com)
berzniz.com
iOS 7 only is the only sane thing to do
http://berzniz.com/post/72083083450/ios7-only-is-the-only-sane-thing-to-do
81 comments
What percent of your user base is still using 5.1?
The truth is that the original iPad had very little RAM. I imagine there is a very good reason that iOS 6 (and up) didn't make it onto that device.
The truth is that the original iPad had very little RAM. I imagine there is a very good reason that iOS 6 (and up) didn't make it onto that device.
I wish other developers would adopt such a considerate attitude. Alas, my personal experience is that many simply abandon users who dare to have a device more than a couple of years old. My worst personal experience being an app that became obsolete, only to be replaced by an app that doesn't support my version of iOS.
Obsoleting an app is a problem, but -- at least in the PC space -- people who do not upgrade from e.g. XP to Win7 are unlikely to pay for new apps - so, if you care about getting paid, there's no point in supporting XP home users (enterprise is different, and I do not wish to go into that).
Does anyone here know if that's also true for iOS devices? I'm quite sure that the big app spenders would be the people who continuously upgrade. There might still be a significant population who does not upgrade to make financial sense for still targeting 5.1 with new apps. I don't know, but my guess would be "not so much".
Does anyone here know if that's also true for iOS devices? I'm quite sure that the big app spenders would be the people who continuously upgrade. There might still be a significant population who does not upgrade to make financial sense for still targeting 5.1 with new apps. I don't know, but my guess would be "not so much".
Well, I can only speak for myself, but I definitely would keep buying apps if given the opportunity. There are plenty of apps I've wanted to purchase, but haven't been able to - whether there are enough like me that would make the extra market lucrative enough is another matter.
If I started developing tomorrow, and have no 5.1 device, how can I do QA? I have an iPhone 4 that was never upgraded, but I can either keep it as is or upgrade to 7
Apple is making it really hard to support a version that you didn't target from day 1. And it is hard to target older versions from day one
Apple is making it really hard to support a version that you didn't target from day 1. And it is hard to target older versions from day one
If you're serious enough to want to target 5.1, you'd get a device that supports it. They're pretty trivial to come by at bargain prices.
Of course that's true. If you are serious enough, you can develop for any device. The question is, does it make sense from any perspective?
Realistically speaking, it's going to cost me a $1,000-$10,000 more to develop for 5.1 rather than develop just for 7 (extra device, extra design, extra testing time, potentially extra development time). If you didn't originally develop for 5.1 and it doesn't cost you as much, you are not serious (or severely underestimate your costs).
I'm not developing apps for iOS, but I'm not sure if I started tomorrow, and released (say) in two months, that it would be financially justified to target 5.1
Realistically speaking, it's going to cost me a $1,000-$10,000 more to develop for 5.1 rather than develop just for 7 (extra device, extra design, extra testing time, potentially extra development time). If you didn't originally develop for 5.1 and it doesn't cost you as much, you are not serious (or severely underestimate your costs).
I'm not developing apps for iOS, but I'm not sure if I started tomorrow, and released (say) in two months, that it would be financially justified to target 5.1
I still support iOS 5.1 for the same reason on my main app, but it's getting harder to do so. The status bar change with iOS 7 introduced a ton of conditional code for me because iOS 5 doesn't support autolayout and unfortunately that's the easiest way to deal with the topLayoutGuide.
I saw somewhere that Apple doesn't allow new apps to target less than iOS 7. Is that correct?
Depends what you mean by "target". You can specify the whatever minimum OS version you want for an app.
You have probably heard something like "[After Feb 1] new apps [...] must be built with the latest version of Xcode 5 and must be optimized for iOS 7."
That only means you must use the latest dev kit and satisfy some other requirements. It does not mean that you need to disable support for older OSes.
You have probably heard something like "[After Feb 1] new apps [...] must be built with the latest version of Xcode 5 and must be optimized for iOS 7."
That only means you must use the latest dev kit and satisfy some other requirements. It does not mean that you need to disable support for older OSes.
It is not trivial to support ios7 with the latest gui elements (ios7 sdk) and also support prior versions. Practically speaking you will need to support only ios7+ after feb1, which for me is a lot of development work which is not worth doing with the income my apps give. I am therefore no longer supporting my apps.
Ahh I see, thanks!
Great points, except for "@2x only." If your app supports iPads, then the iPad 2 and iPad Mini (first generation) are both non-Retina screens and are still available for sale directly from Apple. Given Apple's 3 year support cycles, iOS 10 will be the first iOS that can fully drop support for non-retina displays if the iPad 2 and original iPad mini are discontinued by the end of this year.
Our app is iPhone only, but this is a great point to remember for anyone thinking about dropping the non-retina image.
People with non-retina iPads can and will download your app.
Non-retina iPads use retina assets for iPhone apps.
Ah good too know. I guess that is new in iOS 7.
My memory is fuzzy, but I think it happened around iOS 5.
Nope, it's an iOS 7 feature. Retina iPads have done this since iOS 5, since that is when the iPad 3 was introduced, but non-retina iPads used non-retina graphics until iOS 7.
See http://www.iphonehacks.com/2013/07/ios-7-uses-retina-assets-... and http://bendodson.com/weblog/2013/10/16/dropping-non-retina-s...
See http://www.iphonehacks.com/2013/07/ios-7-uses-retina-assets-... and http://bendodson.com/weblog/2013/10/16/dropping-non-retina-s...
That must be my confusion. Thanks for the info.
Unfortunately, an app cannot be made `-568h` only. And -[UIImage imageWithName:] does not support `-568h` infix.
Which is pretty lame considering xcassets supports an image 'subtype' called R4 that's designed for 4" screens.
There's nothing stopping you from swizzling that method for one that does, though. I've done it without any apparent problems.
It's also really trivial to support both retina and non-retina so I don't understand the point at all..
Seems more like iOS 7 is the only convenient thing to do. That's fine, but the current title makes it read more like a weak attempt to justify not wanting to support older versions.
Pull To Refresh - available in iOS 6.
UIViewController Containment APIs. iOS 5.
Custom Tab Bar. iOS 5
Custom Navigation bar. iOS 5
HTML Strings. iOS 7
@2x only. iOS 7
Flat out. iOS 7
viewDidUnload. iOS 6
AutoLayout. iOS 6
UIDynamics. iOS 7
Receding keyboard like the messages app. iOS 7
UIViewController Containment APIs. iOS 5.
Custom Tab Bar. iOS 5
Custom Navigation bar. iOS 5
HTML Strings. iOS 7
@2x only. iOS 7
Flat out. iOS 7
viewDidUnload. iOS 6
AutoLayout. iOS 6
UIDynamics. iOS 7
Receding keyboard like the messages app. iOS 7
Note that Apple now keeps the previous version of the app around for users on older OSes. Of course they won't get any of the upgraded features, but at least there's still something there for them - and you won't have to worry about all that messy code for supporting multiple versions.
My next app updates will also be iOS7 only, since I know the iOS6 version will still be around. Makes it much easier to decide to use newer features.
My next app updates will also be iOS7 only, since I know the iOS6 version will still be around. Makes it much easier to decide to use newer features.
Yeah, that's a great feature.
One open issue is that from time to time a breaking change to our API is needed and a force-upgrade is forced on the app users. We try to avoid it, but it happens.
The next time this happens, it's really goodbye iOS 6 users.
One open issue is that from time to time a breaking change to our API is needed and a force-upgrade is forced on the app users. We try to avoid it, but it happens.
The next time this happens, it's really goodbye iOS 6 users.
This year, Apple's "12 Days of Gifts" app only runs on iOS7. I don't know if that was intentional, but it seems likely.
Slightly off topic here. I'm a bit baffled by that app. It's a fugly - it seems like a pre ios 7 app that was resurrected in a few days and isn't very Appley at all. I wouldn't call is skeuomorphic, but it isn't the new(ish) flat look. The main screen's background just looks like someone forgot to include the artwork. Its a flat grey though, so must have been chosen. The clunky FAQ page isn't nice either, and a straight link to a web page would have been nicer IMHO.
Yeah, that was the ultimate kick in the teeth from Apple for all us pre-iOS7-ers - 'sorry, you don't even get our free stuff anymore, luddites'
Apple only offers older versions of your app to users that have previously purchased it. New users will still get the traditional "this app requires iOS 7" failure message.
I believe you can purchase apps you haven't purchased before. The writer of the article I read on this tried it. I've downloaded free apps whose latest versions weren't compatible on my device, and got the older version that works for my old (iOS 3.2) device a couple of months ago.
Did you make the "purchase" from your device or from iTunes on your computer? It's never worked when I've tried from a device.
I purchased them from a device. In my case, it was a first gen iPad which was still in its original OS version (3.2 I believe).
There isn't anything in this article that explains why you can't support both. The only sentence about this is "We can’t leverage what iOS 7 has to offer and a lot of the UI is compromise.", which doesn't cite any difficulties they've run into. The only iOS 7 features they mention are UIDynamics and the receding keyboard—the rest are iOS 5/6 features.
I agree that the article could've gone into more depth about the difficulties they faced, but most developers will agree "a lot of the UI is compromise" is the key point. Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
> Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
Assuming you want it to look exactly the same on both. I have an app that offers a flat, stylised look on iOS 6 and a completely native iOS 7 look on iOS 7.
Assuming you want it to look exactly the same on both. I have an app that offers a flat, stylised look on iOS 6 and a completely native iOS 7 look on iOS 7.
> Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
It's just a little more work. Facebook looks the same on iOS 6 even now that it supports iOS 7.
If you are mostly using native UI with only a few customisations, I don't see the problem.
It's just a little more work. Facebook looks the same on iOS 6 even now that it supports iOS 7.
If you are mostly using native UI with only a few customisations, I don't see the problem.
The problem is a lot of iOS 6 apps don't use mostly native UI. The article touches on this when talking about all their custom code because previous iOS components were not as easily customizable. My next update will be iOS 7 only, at which point I plan to drop a lot of custom code and switch back to mostly native UI.
Yes, UIKit only became easily customisable in iOS 5 and the OP's app was written for iOS 3.
But even then you can port it to native UIKit (which is a good idea either way), and then make iOS 7 frameworks optional, and add a few UIAppearance calls for iOS 6. The last two pieces are extra effort that might not worth it for < 30% of your users, but it's still completely possible.
But even then you can port it to native UIKit (which is a good idea either way), and then make iOS 7 frameworks optional, and add a few UIAppearance calls for iOS 6. The last two pieces are extra effort that might not worth it for < 30% of your users, but it's still completely possible.
> Supporting iOS 6 and 7 visuals at the same time just means your app looks out of place in both versions.
If you're using the native UI stuff, it will, generally, look native on both versions. If you're doing your _own_ UI, of course, it gets messier.
If you're using the native UI stuff, it will, generally, look native on both versions. If you're doing your _own_ UI, of course, it gets messier.
There are some excellent 3rd-party frameworks and libraries for doing spring-based animations that work on previous versions of iOS. My favorite (that I still use and favor above UIDynamics even on iOS 7-only apps) is JNWSpringAnimation which uses CAKeyframeAnimations to do amazing springy, bouncy animations. The same code is wholly portable to Mac apps as well which is an awesome bonus.
https://github.com/jwilling/JNWSpringAnimation
https://github.com/jwilling/JNWSpringAnimation
You're fortunate you can afford to expend development effort/money on an update that won't bring in any more users. Im still licking my wounds from the app store change that came with ios6, sales are way way down to the extent that significant development work to these apps cannot be justified. With the pre ios6 app store I could make a case for it but not today.
Sheesh. Am I the only one still using a first-gen iPad stuck with iOS 5? Just a couple weeks ago my sister wanted to install an app that turned out to be iOS 7 only. Grr.
No. And I hope there are a lot of first-gen iPads still in use, since the alternative would mean millions of abandoned pieces of hardware, rather than just millions of us abandoned users. If only I'd had the hindsight to stick with iOS 4 - at least my tablet would then be usable without inducing stress, fury, and bitter regret.
I feel your pain. I'm finding even the web browser on the first gen ipad isn't working on some sites I visit.
sigh..
sigh..
Interesting - I did not know about the new receding keyboard functionality.
For those curious, you can simply set a boolean on any UIScrollView or subclass to make the keyboard recede like in the Messages app.
For those curious, you can simply set a boolean on any UIScrollView or subclass to make the keyboard recede like in the Messages app.
scrollview.keyboardDismissMode =UIScrollViewKeyboardDismissModeInteractive
https://developer.apple.com/library/ios/documentation/UIKit/...
https://developer.apple.com/library/ios/documentation/UIKit/...
I wonder, what do they consider very painful regarding to having this functionality on iOS < 6. Sure it's not just setting a single property, but [UIView endEditing:] and UIScrollViewDelegate protocol was available since iOS 2.
What is a receding keyboard? Your comment is like
/**
* Recedes keyboard.
*/
void recedeKeyboard() {Except he explains that it works like it does in the Messages app. If you're not familiar, the keyboard in Messages slides down/recedes when you start scrolling through past messages so that it's not in the way and you can see more content. Give it a try if you have an iOS device, it's a very useful interaction.
Actually, that doesn't seem very sane to me. Why are we doing additional work for functionality that we already created, and losing support for people on older versions? Sure if you are a making a new app it makes sense to use great new features. It doesn't make sense to delete code that is working and redo it just because the new way is easier. 0 effort >>>> small effort times 10.
When you introduce new people to the development team, less code means less issues.
Old code had nasty things like traversing the UIView hierarchy and removing unwanted UIViews.
Old code had deprecation warnings.
Old code is not optimized. Apple are doing a much better job at creating great working UIKit controls for us.
Any day that I delete code is a good day.
Old code had nasty things like traversing the UIView hierarchy and removing unwanted UIViews.
Old code had deprecation warnings.
Old code is not optimized. Apple are doing a much better job at creating great working UIKit controls for us.
Any day that I delete code is a good day.
"It doesn't make sense to delete code that is working and redo it just because the new way is easier."
Less code to maintain >>> custom written code that might be prone to break on newer versions of the OS. It's definitely what I would do.
Less code to maintain >>> custom written code that might be prone to break on newer versions of the OS. It's definitely what I would do.
While I agree that less code is better, is it the highest ROI on your time compared to actually improving the app, or maybe making a new one? It might break in the future, it might not. What you change it to might break in the future too. Why not wait until it breaks to rip out and rewrite working code?
The sweet point for me has been iOS 6-7 support. There's little that iOS 7 has that I need to use, so a few conditionals here or there haven't been a huge deal (tintColor has been the only significant one). This contrasts immensely with trying to support back to iOS 5 where so many new things were added after (e.g., autolayout) that you end up with huge chunks of redundant code that differ only in the approach taken to get the end result.
My apps' interfaces are entirely customized, so everything looks roughly the same across the major versions. I've shifted to a flatter appearance since iOS 7, but I've held onto certain things from older ones that I like better such as borders on buttons where the button status is not clear from the context, filled toolbar icons (I hate the stenciled ones), and a shadowing level somewhere between iOS 6 and 7.
My apps' interfaces are entirely customized, so everything looks roughly the same across the major versions. I've shifted to a flatter appearance since iOS 7, but I've held onto certain things from older ones that I like better such as borders on buttons where the button status is not clear from the context, filled toolbar icons (I hate the stenciled ones), and a shadowing level somewhere between iOS 6 and 7.
I was a bit on the fence about iOS versions before because I still have a first-generation iPad (iOS 5.1 maximum) and I wanted to make games for it. I have a new iPhone 5S as well.
I originally wrote game code with OpenGL ES, and then tried very hard to make the same code work on a Mac with regular OpenGL. It took more time than it should have to see results and it wasn’t that fun. About all I can say is that I learned a lot and OpenGL clearly runs efficiently.
After seeing Sprite Kit (Mac OS X Mavericks and iOS 7 only) and working with it, I am now completely devoted to these latest OSes. That framework has solved virtually all of my Mac/iOS parity issues, while allowing code to be almost identical in ways that really impressed me. Sprite Kit requires far less effort and it produces far greater results. About the only downside I see is that there would be no hope of porting my code to something like an Android phone (and I don’t happen to care about that).
It doesn’t hurt that Mavericks is free so about the only device left out in the cold is my old iPad. I decided that I was probably holding myself back by trying to support it anyway; the device is quite slow compared to almost any other iPad. I will likely just buy a new iPad.
I originally wrote game code with OpenGL ES, and then tried very hard to make the same code work on a Mac with regular OpenGL. It took more time than it should have to see results and it wasn’t that fun. About all I can say is that I learned a lot and OpenGL clearly runs efficiently.
After seeing Sprite Kit (Mac OS X Mavericks and iOS 7 only) and working with it, I am now completely devoted to these latest OSes. That framework has solved virtually all of my Mac/iOS parity issues, while allowing code to be almost identical in ways that really impressed me. Sprite Kit requires far less effort and it produces far greater results. About the only downside I see is that there would be no hope of porting my code to something like an Android phone (and I don’t happen to care about that).
It doesn’t hurt that Mavericks is free so about the only device left out in the cold is my old iPad. I decided that I was probably holding myself back by trying to support it anyway; the device is quite slow compared to almost any other iPad. I will likely just buy a new iPad.
I've done the same for the app that I work on, but not because I needed an if-else for the UI code. The biggest problem for me was that every now and then, I'd get a bug that shows up on a device, but not the simulator. If this happens even once, it is one time too many for a small team without a lot of leftover devices to sport old iOS versions on.
"This was one feature we really wanted and implementing this was painful as hell. I can’t believe it’s now just a boolean value away." - So awesome yet so frustrating! haha
Right to the point information. GREAT.
I've been programming on a daily basis for iOS even before the SDK came out (ohhh those reverse engineering days...!). Two years ago I left the job and since then I've always wondered what were the relevant changes in the SDK, just in case I get back to programming iOS again. And here we have it!
I've been programming on a daily basis for iOS even before the SDK came out (ohhh those reverse engineering days...!). Two years ago I left the job and since then I've always wondered what were the relevant changes in the SDK, just in case I get back to programming iOS again. And here we have it!
[deleted]
> When we added pull to refresh to our app there weren’t many apps using this technique and it added a premium feel to our app.
This makes me want to vomit. I can't wait until implementing flashy UI is so trivial and common that shallow things like this don't actually affect an application's perceived value. I don't remember the transition to GUI in the 80s as being as shallow as the mobile app market is.
This makes me want to vomit. I can't wait until implementing flashy UI is so trivial and common that shallow things like this don't actually affect an application's perceived value. I don't remember the transition to GUI in the 80s as being as shallow as the mobile app market is.
Its not shallow, it makes the app easier to use and therefore better designed.
Also, perception is reality.
Also, perception is reality.
I contest the idea that any two apps are so similar that something as trivial as list-refresh mechanism could push one over the top.
I look forward to competing with you one day!
Seriously though, you contest the idea that an interface with interactions which hide complexity and have been shown to be pretty intuitive could be decisive in how users value a product?
Seriously though, you contest the idea that an interface with interactions which hide complexity and have been shown to be pretty intuitive could be decisive in how users value a product?
No, I agree that in the current mobile app world UI flourishes really do make a difference in how users perceive an application. I'm hopeful for the day when such flourishes are so common that they are no longer perceived as valuable and we can get back to working on things that matter.
This isn't just a cosmetic thing; it makes it substantially easier to perform an operation (in this case refreshing) and to see the status of that operation.
Don't bet on UX enhancements ever going away, by the way; people come up with new things all the time. Pull-to-refresh didn't come from any platform vendor; it came from a third party Twitter client.
Don't bet on UX enhancements ever going away, by the way; people come up with new things all the time. Pull-to-refresh didn't come from any platform vendor; it came from a third party Twitter client.
> I don't remember the transition to GUI in the 80s as being as shallow as the mobile app market is.
Then you weren't there. I'm pretty sure the first caveman to use a different pigment in cave paintings got the same shallow reactions.
Then you weren't there. I'm pretty sure the first caveman to use a different pigment in cave paintings got the same shallow reactions.
There are STILL programs out there that claim to have a GUI, but the so-called "GUI" is really just a window frame around a terminal emulator.
Your vitriol is completely misplaced.
Pull to refresh isn't flashy, shallow or trivial, and it shouldn't bring on emesis: It is a simple, convenient user interaction that saves putting a big refresh button or the like.
Pull to refresh isn't flashy, shallow or trivial, and it shouldn't bring on emesis: It is a simple, convenient user interaction that saves putting a big refresh button or the like.
I'm using MOAI. Implementing flashy UI's is so trivial, its not even funny. What I'm finding though, is that its very much better to keep things simple, and well .. for my clients at least, its working.
I think that not writing iOS/ObjectiveC/AppStore/Apple-specific code, period, is even saner.
Are the multiplatform techno like flex, cordova/phonegap, haxe... already out of question ?
Well, it depends on your needs, but really I have yet to see an app made with any of them which isn't an unpleasant user experience.
http://theweathertron.com/
Done with (IIRC) PhoneGap, AngularJS and ClojureScript. The actual utility as a weather app is debatable (I like it), but the UI is beautiful and responsive, especially considering it's PhoneGap!
Done with (IIRC) PhoneGap, AngularJS and ClojureScript. The actual utility as a weather app is debatable (I like it), but the UI is beautiful and responsive, especially considering it's PhoneGap!
"Requires iOS 6.0 or later" - ARGH!
There's really nothing sane about iOS/the iPhone when the government has full control over it.
The only sane thing to do is have it recycled.
The only sane thing to do is have it recycled.
I think a reasonable prime directive for API developers is that if hardware can do something then software shouldn't be prevented from running on it. Sure there are arguments for speed/responsiveness but most of these are straw men because the real bottlenecks are somewhere else (reading from flash memory, internet lag etc). The only real hardware constraints I hit daily are limitations in OpenGL or limited ram (which wouldn't be an issue if proper virtual memory had been in place from the beginning so we didn't have to use mmap).
This kind of software "truthiness" is taking us further and further from computer science.