I have one wish: that the iOS programmers at Apple learn how to write efficient concurrent code and that they stop leaning on the next, faster, generation processor so hard that any phone that is just one generation older than the leatest and greatest becomes slow as shit.
My iPhone used to be fast. Most things used to be snappy. Now it is slow as shit. From the address book lookups (which I have timed to usually clock in at 8-9 seconds, but which can take as long as 20 seconds) to the atrocious piece of penguin dung that is the podcast app. Seriously, Apple could not have created a shittier app if they had hired a bunch of Microsoft engineers to bang their foreheads on keyboards for 88 hours.
iOS software is fucking slow.
(Firing Scott Forstall to stop the skeuomorphic wankery was a good start. Now they need a real software engineering director to beat some sense into the engineers and to make sure they have "Concurrency 101" under their belt before writing another line of code)
The Address Book was built before 3rd party apps were even considered (remember all apps were web apps at launch) and was optimized for fast syncing. At the lowest level it stores an address record, and any required diffs in SQLite.
Every time the AB is accessed, all the diffs get reapplied. Normally this wouldn't be a problem, as people don't edit their address books often enough to generate a ton of entries.
Unfortunately the old Facebook iOS app and a few others that allowed you to "keep your contacts up to date" would hit every single contact in your Address Book every time the app was activated with a hidden ABPersonViewController. The allowsEditing property was set to YES every time, which generates a new diff with no (or a minor) change.
Diffs were sycned back to the computer, but AFAIK "merges" only happend on OS upgrades, since it was unlikely a user would be making millions of edits.
(this is all roughly from memory based on a painful debugging session with our iOS guy and a few back and forth tickets with Apple looking into extremely slow AB access for some users.)
While I feel your frustration with iOS apps in general, concurrency is not a silver bullet. I can't say anything specifically about what's making certain iOS applications slow, but I actually think it's probably more related to Core Data and file IO.
I can also say their new concurrency technology (Grand Central Dispatch) is one of the most brilliant pieces of technology I've seen in a while. The reasons why are pretty technical, but I think many people who have experience in concurrency would agree that it's pretty good.
No, concurrency is not a silver bullet, but when your programmers consistently make beginner's mistakes the software really sucks.
You do NOT allow the UI thread to hang on blocking calls. That's UI programming 101. And Apple engineers are unique in how consistently they fail to follow even this most rudimentary of rules.
Sorry. Have you see the source code of any part of the iOS system? No I don't think you have. Give me some reference to somewhere that the UI thread hangs. Not blocking the UI is taught to everyone who writes apps for the app store, so my assumption is that the guys who wrote the app store code know a little better than we do.
Connected to AirPlay, and you hit 'play'? Good luck if there's any kind of network problems, because it's going to freeze your music app for 10 or 20 seconds until it either works or times out. Everything to do with AirPlay is snychronous, which is a big no-no when most operations seem on the order of seconds...
Take a step back, observe what the app does. Whether it blocks on slow system calls or coarse grained locks is irrelevant. The point is, the GUI thread hangs. That isn't supposed to happen. Quite a bit of Apple software does this. This suggests that this is somewhat systemic.
I think we can do without the condescending tone. I think most people here are fully capable of distinguishing applications from OS. However, when Apple provide a suite of apps that are shipped with the OS it is reasonable to expect that those apps work.
Tangentially, I want proper support for background processes. Ask me if I'm Ok with letting the ABC app to continue running in the background and for how long. There's a lot of useful things that cannot be done on iOS because of existing backgrounding restrictions, which seem like a knee-jerk reaction to whatever performance problems they have with the OS.
OT, but you nailed it on the Podcast App - in fact, it is the first time that I've unequivocally been able to say that Apple released an absolute crap application that really had no future it was so bad. I spent two-three hours with that app trying to understand it's "model" and deal with all the bugs before I finally gave up. It was fundamentally bad.
On the Pro-Side - it opened me up to the really nice alternatives, like DownCast and iCatcher! that are absolutely fantastic.
Optimising code costs money, may make the code base harder to maintain and does not help much with selling new devices. I really hope there will be a future shift in making money from software, not hardware. Right now the opposite seems to be happening. :(
From my perspective Apple makes almost all their iPhone money from the software. The phones are lovely hardware, but look at the original iPhone and 3GS. They were plastic soap bars. It didn't matter because the software was phenominal. I think their problems with iOS are crucial. If they let the quality of their software slip for too long they'll be in serious trouble. I still think they've got maybe 2 years lead over the competition in their overall OS, services and applications portfolio, but that's less of a lead than they had 2 years ago.
I doubt you are hitting any processing bottleneck. More likely memory capacity/bandwidth and possibly flash storage speed bottlenecks. Probably on an A4 based iOS device? I agree Apple should do a better job for these older devices however they can't let the world revolve around 3 generation old platforms either. With the A5 and especially the A6 it's less of an issue because both have hit a 'good enough' point where they shouldn't be too starved on memory capacity/bandwidth unless iOS/apps dramatically change in the next 2-3 years.
> Apple learn how to write efficient concurrent code
Sorry but what ? Apple has one of the best concurrency implementations on ANY platform. GCD is superbly designed and combined with blocks makes concurrency trivial.
The biggest problem is that developers often try and over optimise.
> which I have timed to usually clock in at 8-9 seconds, but which can take as long as 20 seconds
Then we are observing very different realities. Beginner's mistakes have been evident for years and years in the iTunes (desktop) application where the GUI thread is routinely blocked by anything from network activity to slow disk IO.
With the latest generation of iOS, these problems have started cropping up elsewhere in iOS apps. For instance if you use the podcast app as intended, and download content directly on your iPhone, the UI has a tendency to block on IO operations that should have taken place in the background. The UI will hang and refuse to scroll. Also, the player has become really temperamental -- often refusing to accept volume control inputs via the screen for many seconds after laboriously starting to play a stream.
(And why the hell did Apple have to split up the iPod application in the first place. Now you have iTunes U, which is sluggish and buggy, you have Podcasts, which is sluggish and buggy etc. WHY!?)
I don't know if it was because I was running out of disk space, but taking photos and texting became absolutely terrible on my iPhone 4. iOS 6 made it even slower.
I have had pervasive problems with Address Book stores on Macs for years now. Psychotically slow operations, ten-second hangs, sync failures, endless sync failure loops, and general thrashing are not hard to find on any system handling more than a few thousand cards.
If there are substantial Notes? Good night. Supercomputers brought to their knees.
My iPhone used to be fast. Most things used to be snappy. Now it is slow as shit. From the address book lookups (which I have timed to usually clock in at 8-9 seconds, but which can take as long as 20 seconds) to the atrocious piece of penguin dung that is the podcast app. Seriously, Apple could not have created a shittier app if they had hired a bunch of Microsoft engineers to bang their foreheads on keyboards for 88 hours.
iOS software is fucking slow.
(Firing Scott Forstall to stop the skeuomorphic wankery was a good start. Now they need a real software engineering director to beat some sense into the engineers and to make sure they have "Concurrency 101" under their belt before writing another line of code)