iOS 7 is the first Apple system where I felt royally screwed. My iPhone 4 became so slow as to be nearly unusable. Everything now takes seconds, swipes are being missed, even audio gets chopped up when I play back podcasts over bluetooth.
There are two reasons for me to be angry about this:
* Apple should never have released iOS 7 for iPhone 4 devices. iPhone 4 should have been listed as "unsupported". But had they done that, they would have ended up with a fragmented ecosystem, and unable to brag about how so-and-so-many percent of users upgraded to the latest iOS.
* There is no good reason for iOS 7 to be slower than iOS 6. The "it requires more processing power for animations" reason is bogus, because there are very few animated effects, and I switched off whatever I could anyway. The only reason every iOS release is slower than the previous one is because Apple does not care about optimizations. They can afford not to care because every new hardware device is much faster than the previous one. But that means some users get royally screwed.
I should have stayed with iOS 6 (there is no going back now), but more importantly, Apple should not have claimed that iOS 7 is supported on my device. For all practical purposes, it isn't — the experience is really bad. I've just compared it to an iPhone 3G running iOS 4.2.1, it's more responsive than iOS 7 on iPhone 4.
So, this forced migration to iOS 7 is something that makes me angry, because I'm that part of the userbase than is being dragged into it kicking and screaming.
Agreed, with reservations. iPhone 4 itself was a grossly mis-executed product, though it wasn't obvious at the time.
The core issue is that the iPhone 4's CPU and GPU performance are only marginally better than the 3GS it replaced, but it pushes 4x the number of pixels around.
At the time we weren't really pushing the performance envelope, so everything appeared fine. Now we are - it's trivially easy to hit the upper bound of iPhone 4's performance envelope, whereas the 4S (and the 5, 5S) have a lot more wiggle room.
More critically for app and OS developers, the GPU performance on iPhone 4 was woefully inadequate for the number of pixels it's tasked to render. IIRC the iPhone 4's GPU has a fillrate (i.e., max pixels rendered per second) that's about 13% higher than the total number of pixels it has. This is to say, if you draw even a trivial amount of stuff in the background, you're going to start dropping frames.
For the 4S, 5, and 5S, the lack of CPU performance can often be made up by moving things to the GPU judiciously. On the 4 we don't even have that.
Here's where I disagree:
> "There is no good reason for iOS 7 to be slower than iOS 6. The "it requires more processing power for animations" reason is bogus"
Of course it is, but no one stated that the slowness is due to animations. A large part of the slowness comes from the "blur everything!" design of iOS7, which is inherently GPU-heavy, and thus performs very poorly on the iPhone 4 and its shittastic GPU.
This really has little to do with optimization - iOS is on the whole a pretty performant OS and platform. This has everything to do with Apple deciding to include features that are beyond the performance envelope of a targeted device (or conversely, failing to drop support for a device when features move past its performance envelope).
I disagree with this reasoning. The number of pixels to be pushed around did not change from iOS 6 to iOS 7. It's still the same. The fancy graphics effects are reduced already by default, and you can reduce them even further. My phone doesn't do visibly anything different from what it did under iOS 6. And yet it is much, much slower.
I already did everything that the article you quoted suggests. My phone runs in high-contrast, super-accessibility, no-fx-please mode. And performance still sucks.
To give you an example: I sometimes press power-on, nothing happens for a second or two. Then I press the home button and after another two-three seconds I get… a screenshot, just as if both buttons were pressed simultaneously. Number of pixels, blur, seriously? We haven't even gotten to displaying the lock screen yet!
I still believe there is lots that can be optimized, but Apple chose not to do it. It wasn't laziness, it was a business decision — their time is better spent implementing new stuff — but that is a decision I disagree with. Or, more precisely — I disagree with this decision given that they called iPhone 4 "supported".
> I sometimes press power-on, nothing happens for a second or two. Then I press the home button and after another two-three seconds I get… a screenshot, just as if both buttons were pressed simultaneously.
Sounds like your phone's borked in some way.
That happens to me sometimes (1 in 10?) when bringing in legacy settings on to a new device.
I've helped upgrade several 4 (not 4s) users and they're happy. On all of them I turned off motion, turned off blur, turned off background updates, turned off auto music/app/updates downloads.
If a phone still has slowness, it's usually a bad setting brought forward. Seems to usually be in email or network settings.
I delete email accounts, reset network settings, and recreate email accounts, leaving iCloud as Push and all others as Fetch, Manual.
If that doesn't fix, I try again, this time "Erase all settings". (Not Content and settings.)
These are the same steps I use to get back battery life losses. Something goes wrong, runs in background, kills batt and slows phone.
Finally, one friend has Downcaster and always ends up with a full phone. Below a level of free memory the device definitely slows drastically. Touch and wait kind of slow, less than 2GB on 64GB device is noticeable, less than 500MB get to be a real problem.
Yea I was wondering where the cool promised effects were. I'm a light user of the phone and iOS7 was a noticeable improvement. UI is better, idle battery life doubled. But that's my particular use case. Could be the experience of non nerd users as well.
Partially agree. Your point stands since the iPhone 4's GPU was a very marginal improvement over the iPhone 3GS's. However, the iPhone 4's CPU was significantly faster - 50% in my tests which is in line with its raw clock speed increase across the same architecture (1 GHZ Cortex A8 vs 600 MHZ Cortex A8).
The core issue is that the iPhone 4's CPU and GPU performance are only marginally better than the 3GS it replaced, but it pushes 4x the number of pixels around.
As an iPhone 4 owner and longtime Apple owner (owned a Mac since 1988 when I was 5 years old and typing this on a 15" rMBP) I wholeheartedly agree.
It's really beyond shocking how badly the iPhone 4 works with iOS7 as compared to iOS6. I'm not sure it can really be adequately explained - you just have to try it for yourself. Even switching to the camera from the lock screen is nearly impossible at times.
I've recently been looking into downgrading the OS back to 6, but I'm probably out of luck since I don't have the SHSH blobs and APTickets for the older firmware.
Apple really needs to fix the performance issues for iPhone 4 owners or provide a supported way to downgrade to iOS6 (Note: Sibling noted that iOS7.1 fixes the issue... I really hope that's the case).
I'm not a heavy app user - stock apps and one or 2 others I only. With this in mind, there was very little wrong with my ios7 experience. Sure, it wasn't as fast as I wanted, but it wasn't a particular concern. I wonder if this is a higher tolerance from me, or a difference in how our devices were working.
I'll second you opinions. What shocked me was the number of simply broken things.
The keyboard is unreliable, which is unforgivable; it would hang and catch up, or just miss key presses. Worse, the unlock screen would have a landscape keyboard sometimes, despite it never leaving portrait. I literally just rotate the phone while hitting the lock button until it straightens out. It's like resetting an Etch-A-Sketch.
And don't get me started on the home button's behavior. The face has a //single button// and it's unpredictable. No idea if it's alt-tabbing or showing desktop. I suspect there's subtle and clever timing going on, but with the system overloaded/out of memory (apps are constantly resetting), I suspect iOS 7 can't manage (yet).
The keyboard is the same on the iPad 4, which at the time of the iOS 7 release was the newest model iPad. I get typos all of the time due to it missing key presses or hanging.
If it's any consolation, it's bad on an iPhone 5s too. I get constant crashes, animation glitches that need a reboot to fix, it's just unusable and there's no way back to iOS6.
I've used it on an iPhone 4, and I don't know how anybody copes. It feels like my 3G was on 4.2.1.
I've had it on the iPhone 5 since iOS7 released and have seen none of these issues. Not sure it's appropriate to claim that your experience is representative, especially since hardware-wise the 5 and 5c are practically identical.
Wake up your iPhone, go to slide to unlock, the screen times out and goes to black as you're typing your passcode. Happens to me and everybody I know, even after four OS updates. There's a heap of little bugs like that.
GPs claim was about the 5s, not the 5 or 5c, so I'm not how your reference to your experience on the 5 or the similarity between the 5 and 5c is supposed to rebut it.
I took the "there's no way back to iOS6" to mean that they'd run it on the phone before, which would mean they were on a 5. Thanks, Apple, for these wonderfully ambiguous names.
Remember they were still selling the iPhone 4 up until the day the released the 5s and 5c.
It would be very un-Apple-y for an OS to drop support for a product you were selling 2 days ago.
I'm sure that's why it was done. You're probably right that the 4 didn't have the GPU to support it and that from a technical perspective it didn't make much sense.
In Europe I think your consumer rights would be affected by this. I think it may be within your rights to demand a phone from them that worked with iOS 7.
> I'm still on iOS 5 so I can keep diving directions from google.
Google maps on iOS6+ is far better, IMO, than the Google-powered Maps app on iOS5- or the Apple Maps app on iOS6+ (the last of which has literally never given me correct directions the handful of times I've used it.)
Google maps run on iOS6 and iOS7. It's probably quite a bit better than the iOS 5 version.
I'm on iOS 6 (jailbroken) but my whole family is on iOS 7 -- and so far I'm happy I haven't upgraded. Because of iOS 7, I'm considering making the switch to Android for my next phone.
Pretty sure they purposely did it so it would slow down your "old" technology. I had the first iPhone that came out. As updates increased, the device's speed slowed.
Have you tried http://downgradeios7.com/? I don't know if it really works, but I've heard that people have had luck going backwards — not sure how though.
You can't unless you have an A4 device with an exploitable bootrom or SHSH blobs saved. You can't "downgrade" in a browser like that, it's completely impossible.
It's a completely different process to a restore. Star used a PDF exploit to work it's way up to a kernel exploit allowing for the patching out of various protections which allowed for a jailbreak. You could not have used this exploit kit to restore an iPhone in the way this video claims to.
The original ipad can only be upgraded to iOS 5.1.1, I think.
There are a couple implications. First of all schools (like where my kids go) that bit the apple and deployed ipads to all the kids can't install or upgrade software after February. So if you're selling apps to kids, get your profits while you can. After february if they spend all their budget on upgrading ipads to the latest hardware so they could eventually install apps, they're not going to have any money to spend on apps, so that is a double whammy on sales. Something tells me no one told the accountants and administrators that the depreciation period was so short; much like elementary schools reuse textbooks for 20 years I think they were a wee bit optimistic about ipad usable lifespan.
Another implication is if you have a use case for app-less (web based) ipads, the market is probably going to absolutely flood in a couple months with cheap ipads that can't run modern native apps. So if you're trying to develop an ipad app for cheap people, the wise choice at this time would be web based not native. Also a web based solution could be sold to android users or desktop users or whatever.
The TLDR is native iOS apps are going to die pretty soon. Which is too bad, it was an interesting technological idea.
In most cases, the developer just has to recompile the app and include iOS 7. Of course it get's a lot more tricky if one wants to start using new APIs introduced in iOS 7, and that's why most devs will drop support for older versions.
Support for iOS 7 can complicate things, but for -- I'd estimate -- 75%+ of developers it's simply tweaking a few things and then releasing an app that continues to support v5.0 and up at the very least.
This isn't as dramatic an announcement as some are making it out to be. Though maybe it should be, as the way to encourage both consumers and developers to stay up-to-date is to force them into it with limited support.
Agreed. It takes a while to figure out what iOS7 breaks in your app, but there are plenty of resources out there that tell you exactly how to fix all of the problems. Sliding content under the top menu was the big one for me, but it’s a one line fix. (Or three if you like your if statements on multiple lines.) Turning off the bright colors for links and buttons is another one liner. It was probably less than 20 lines of code and a day’s work to update my apps.
There are a bunch of new features that I’m adding. I especially like the ability to speak text with a Siri-like voice.
I think my interfaces fit into the iOS7 ecosystem, but until they start enforcing the policy on Feb 1, I won’t really know. Figuring out what the rules really mean is always a big unknown in the app review process.
The TLDR is native iOS apps are going to die pretty soon.
I was with you until this. The segment of the education market that bought the 2010 iPad will indeed have some early-adopter problems, but in my experience working with a K-12 education startup, the vast majority of installed iPads in schools are iPad 2s.
Native iOS apps will die when iOS dies, which appears to be about as "soon" in tech industry time as the sun running out of helium.
A few things people might be missing from this announcement.
1) Simply recompiling an application with iOS 7 SDK unlocks a different set of view metrics and subtle behaviors that are non-trivial to address. Developers need to make sure views lay out properly (accounting for the status bar, etc.) in both iOS 7 and iOS 5/6.
2) If you're a game company, chances are you can set your target device to iOS 5 and after making sure you account for the metrics changes you should be fine.
3) Clang/LLVM changes might cause a new crash when run on iPad 1, for example, because Apple won't be testing it anymore. You'll need to have this hardware around to verify everything runs if you want to support that device.
4) If the application is rarely updated or barely maintained, chances are it will be abandoned at this point. What used to be a simple bug fix here and there will now become a massive project.
5) Last and most important point, most software that IS maintained, or at least downloaded enough to warrant concern, I promise you that Apple's developer relations has a point person on top of it. All of your games and important tool makers are well aware of their need to transition to the new SDK if they haven't already. Perhaps a bug in 7.0 that will be fixed in 7.1 was keeping them from releasing an update.
5.1) If you have a game that is used on iPad 1, speak up and let the developer know so that they can make a decision to keep supporting it. OpenGL ES has been quite stable API-wise for quite some time so I suspect most games will continue to support iOS 5 for the foreseeable future.
Worth noting that first generation iPad, the current model until March 2011, will only run iOS 5.1.1 and has essentially been obsoleted by now.
Yes, it is theoretically possible to support earlier versions but Apple makes it practically very awkward: around half of the top apps don't support iOS 5. Apple's own apps apparently don't support iOS 6.
Apple does at least allow download of the last compatible version for iOS apps.
Unfortunately this also puts developers in a really tough spot if they have a large number of iPad (or other users of obsolete devices) as they are unable to ship updates to that obsolete version and they are forced to either disable this download completely abandoning the customers or have it available and be unable to make any bugfixes or other updates
There are two reasons. First, the original iPad was somewhat underpowered. There is a reason the iPad 2 felt so much faster.
The second reason is because of the iPad mini. The non-retina Mini is an iPad 2, just in a smaller package.
I know some developers were complaining after the retina Mini was announced because Apple didn't update the non-retina version to the A7, so the effectively still have to support the iPad 2.
Doesn't requiring the new build pipeline plus 'optimized for iOS 7', mean you can't support most older iOS devices anymore? I know that is how the build pipeline stuff worked for desktop OS X apps - they tended to deprecate the ability to build for older OS versions when you installed the latest rev of XCode.
If so, how far back does it go? Like, if I compile an iOS7 optimized app, will it work on iOS6 devices? What about iOS5? Do they schedule the support deprecation based on lifetime (i.e. all devices released in last 2yrs will work) or is it just based on software versions?
iOS apps in Xcode have a "Base SDK" (which is the actual SDK you're building against: must be iOS 7.0 from Feb 1). But you then also set a "deployment target", which is effectively the oldest version of iOS you still want to support. Set this to iOS 6, for example, and you'll be supporting both versions, even after Feb 1.
One of course needs to be careful about using new APIs/features in this situation (detect whether a certain method/selector exists before using it, for instance) – as we don't want to throw runtime errors on the older OS.
There's an OS X app I found not too long ago that helps immensely with checking the deployment target against the actual APIs used in order to make sure you correctly avoid unavailable stuff: http://www.deploymateapp.com
My copy of Xcode 5 supports Mac OS X deployment targets back to 10.4. Presumably the only reason it doesn't go any farther than that is because nothing prior to 10.4 ran on Intel, and Xcode doesn't ship PowerPC compilers these days.
On the iOS side, my copy of Xcode 5 supports deployment targets back to iOS 4.3. I think that may be similar to the reason for stopping at 10.4, but with ARMv6/7 instead of PowerPC/Intel.
The hard part is finding a device that can run 4.3 for testing. Technically, you could launch an app that supports iOS 2 or 3 all the way to iOS 7, the hardship is testing! Unlike Android post-Froyo, Apple's emulators have never been that accurate. in both cases, memory and device limits on older hardware become the significant bottlenecks.
That and with every OS X update you lose another simulator major version each year. Typing from memory, so I could be wrong: 10.6 had everything. 10.7 lost 3.x, 10.8 lost 4.x and 10.9 lost 5.x simulation. I had to install VMs to run emulators, how sad is that?
All this would be fine if Apple allowed developers to downgrade as post-Xcode 5 hinted, an option removed when the jail breaking started.
Until recently, Xcode always offered a (non-functional since iOS 4 or so) way to downgrade your device.
Now, they didn't document it as such, but why else would you make a menu that shows only past versions of an OS and let's you "Restore" such a release? ;-)
No, you can build against the iOS 7 SDK and still support older versions of iOS. With Xcode 5 you can only build against iOS 7. You can also have entirely separate functionality for different OS versions in the same app bundle.
I've never tried it, but as far as I'm ware, you could theoretically build agains iOS 7 and have the app run on iOS 2.0, assuming the App Store still works.
Deployment targets earlier than 4.3 require armv6 libraries to support all devices, which Apple no longer ships. One can build an armv6 slice using an older toolchain and lipo it with armv7/armv7s slices built against 7.0, but it's not clear if Apple will accept such binaries as App Store submissions.
I currently have an app in the store that has been optimized for iOS 7 but works as far back as iOS 5.1. You could probably support earlier versions as long as you verify the OS supports a feature/method before calling it.
"Previous versions of your apps are now available for re‑download by users who have already purchased them, allowing customers to use your apps with older devices which may no longer be supported by the current version of your app. If you do not wish to make these versions available, you can manage the availability of your apps' previous versions in the Rights and Pricing section of the Manage Your Apps module in iTunes Connect."
I'm also interested in the answer to this. Building for Android allows you to target a wide range of versions even if your build target is the latest; is there any analogue to this in the iOS world?
You can build for ios 7 at the same time as ios 6. They tend to assume you'll only want to target the latest, but it can be done without much trouble, esp. if you already have a tested older project and are willing to put more time in to testing. I'm supporting an app which supports ios 5-7 at present but we tend to test only on 6-7, and have changed some of the UI to match better with ios7.
The issues tend to be with matching chrome if you have custom controls, but if you don't have many custom controls, you'd probably be fine. I imagine it's not very different from the story for Android.
You can do it in iOS world too. But the iOS7 is little different. I recently updated my app with iOS7 support. Many places in the code I had to write something like
if(version >= 7) {
// some code which only works on iOS7
// or some workaround for iOS7
} else {
// code which works in older version
}
Previously I never had to write such code to support iOS6 and iOS5 together.
But the situation is much better than Android world. I also have the Android version of the same app (http://www.avabodh.com/lekh)and I have to write lot of version specific if-else in the code.
if ([object respondsToSelector:@selector(selectorYoureCalling:)]) { //it Does! }
To check if the iOS version your app is installed on has the method and then use it if it does. It's pretty easy to keep things backwards compatible as long as you add fallbacks for functionality that's not present it older versions.
What does that mean for third party applications? Like those built using Adobe Air, which as far as I'm concerned, does not use Xcode. Will an application that complies with the iOS 7 guideline be rejected just because it was not compiled under Xcode?
These tools will have to be updated to emit binaries with load commands that link against iOS 7 versions of UIKit in order to be in compliance. This is similar to the regulation change in March 2013 that mandated support for iPhone 5's larger display dimensions.
Basic guidelines of "no using the old UI widgets (grey keyboard, old tabs, old back arrows)" and, old by now, supporting iPhone 4 and iPhone 5+ screen sizes with optimized graphics. Same goes for iPad except there's only one resolution to support even though it comes in two resolutions across two sizes.
"iOS 7 Optimized" is Apple's way of saying "built with the iOS 7 SDK".
Apps that are built for iOS 7 get the new shiny keyboard and some different behaviour when run on iOS 7, but can still run fine on older versions of iOS if the app developer is willing to support older versions of iOS. This is done by setting an option called "deployment target" to an older iOS version when building in Xcode (and testing a ton on older versions of iOS, and not calling newer APIs on versions of iOS that don't support them).
So this announcement means Apple is dropping support for older versions of Xcode (with older iOS SDKs), but older versions of iOS are still technically supported as long as you're building with the iOS 7 SDK.
There are two reasons for me to be angry about this:
* Apple should never have released iOS 7 for iPhone 4 devices. iPhone 4 should have been listed as "unsupported". But had they done that, they would have ended up with a fragmented ecosystem, and unable to brag about how so-and-so-many percent of users upgraded to the latest iOS.
* There is no good reason for iOS 7 to be slower than iOS 6. The "it requires more processing power for animations" reason is bogus, because there are very few animated effects, and I switched off whatever I could anyway. The only reason every iOS release is slower than the previous one is because Apple does not care about optimizations. They can afford not to care because every new hardware device is much faster than the previous one. But that means some users get royally screwed.
I should have stayed with iOS 6 (there is no going back now), but more importantly, Apple should not have claimed that iOS 7 is supported on my device. For all practical purposes, it isn't — the experience is really bad. I've just compared it to an iPhone 3G running iOS 4.2.1, it's more responsive than iOS 7 on iPhone 4.
So, this forced migration to iOS 7 is something that makes me angry, because I'm that part of the userbase than is being dragged into it kicking and screaming.