Apple's no internal client syndrome
rant.monkeydom.de
rant.monkeydom.de
Most people outside of mobile dev don't know this, but when iCloud shipped in iOS5 the API support was woefully not ready - heck, even Apple's own 1st-party apps that exploit iCloud had notorious syncing issues. To this day iCloud + Core Data support is buggy, poor, and more or less undocumented (the go-to guide for using it is a thread on the forums dozens of pages long full of angry devs and overwhelmed Apple engineers).
There are a number of rather egregious bugs still in the API today that date from iOS3, including one date parsing one that any iOS dev worth their salt has run into first-hand - every time a new release happens people circle back and are continually disappointed that major, easy to hit API bugs are left unattended for so long.
It really does seem like Apple is having trouble keeping up.
I remember when the iOS4 beta came out for developers - it was an incredibly solid beta, and the OS was stable and highly functional months before it was due. Compare with iOS5 and iOS6, the betas of which have both been notoriously buggy, crashy, and downright unusable right up until release. Devs have had to struggle with horrible stability and broken APIs in all beta builds right up until the day the GM drops.
It could be worse. Definitely not the worst API I've ever touched. But still, troubling.
It's becoming a trend that iOS devs are forced to struggle with the ecosystem, but like I've been saying, from my experience the revenues are strongly tilted in favor of iOS. While we complain about certain aspects of iOS, on a whole, (at least from anecdotal evidence) it's still better than the problems that other platforms face.
My hunch is the sheer volume of Android sales and Google's engineering edge is going to turn the tide but external factors could trump all.
> The flexibility of layouts
The inability to nest fragments in other fragments makes doing certain things like fragment based tabs or viewpagers rather awkward. And since the fragment lifecycle almost but doesn't quite match up with the activity lifecycle, some extra careful bookkeeping is required to make sure state is transferred properly upon rotation since the entire thing gets destroyed and recreated.
Anyway, the biggest problem for me on Android is that although the new APIs in 3.0 and 4.0 are pretty sweet, I can't use most of them due to having to maintain compatibility back to 2.2 (Froyo). ActionBarSherlock and the compatibility library help a bit, but it's not quite the same.
I also agree that there are some rough edges in the fragments API but it's nothing like the mess that view controller containment is on iOS.
> To this day iCloud + Core Data support is buggy, poor, and more or less
> undocumented (the go-to guide for using it is a thread on the forums dozens
> of pages long full of angry devs and overwhelmed Apple engineers).
I'm glad we stayed with our own approach, as iCloud + Core Data has never reached the level of stability for me to be comfortable deploying it. By now it's a moot point though, since we now have an Android version to sync against, which eliminates iCloud as a solution entirely.
Bug reporting is annoying as there is no way to search and see if it has already been reported, you just have to fill out an time consuming submission form and get asked to check it 6 months later when it doesn't matter to you any more.
Does the iCloud Core Data support include ordered sets yet? It didn't in iOS 5 (properly documented so I wouldn't call it a bug) but I might move iCloud integration back up my action list if supports that - must check again.
The rest of the comment is valid and I quite agree with you, but this one was (according to my experience at least) so wrong that I couldn't resist :)
A lot of people criticize Apple for not being very innovative lately, but I'm on the opposite side of the spectrum. I wish they would slow down and take a breath and realize that they don't need to implement major changes every year. I almost wonder if Steve Jobs was pushing too hard for things to be released before he died.
On the other hand Apple has never been good with networking software. For example, File Sharing is slow and used to be very unreliable. The built-in FTP support in OS X was a joke. Sending files with iChat on AIM often failed. Mobile Me was never really successful. More recently there is FaceTime, where my Mac just randomly fails to connect. Every time I synced bookmarks with iTunes between Safari on the Mac and on my iPhone I ended up with duplicates on both devices. And now we have iCloud syncing, which is incredibly unreliable.
iChat still regularly fucks up Jabber.
Apple's best code is in the space between Cupertino and new money. Everything else tends to lie fallow.
There is a general problem with non-SF parts of the world as well. I've noticed that many web apps work better in San Francisco than anywhere else the country. The situation in other parts of the country is different. For example, Houston has much more geographic dispersion per capita. The concentration of VC money in the SF Bay Area means that other parts of the country don't benefit from "eat your own cooking" as much. I think there's an opportunity there.
Things aren't all that different from the OS X days, where there was often a mixture of good and bad. Letting Apple know when things aren't working right is the first step to improvement.
And as badly designed Game Center may be, I have been playing Letterpress all day on it with only one hiccup. It can't be _unusably_ bad anymore on iOS6. The author of Letterpress found nice words for it too[1].
[1] http://www.cultofmac.com/197905/tweeties-creator-has-a-new-i...
With the release of Letterpress, a spike in Game Center activity has brought about some talk about how it sucks/breaks easily, and thus Apple's overall QA is going down the toilet.
Criticism is healthy, but let's not forget that the past was not at all perfect or ideal.
Nails what's horrible about it, thank you. I've always disliked its aesthetics but never realized before why it feels so extremely inappropriate.
If that happens they'd have the resources needed to properly fix these issues that haunt us all.
So yeah, they need all developers they already have in other to fix their code bases instead of throwing shiny new features just to capture the markets attention.
People say things like you said thinking that by just throwing money at developers problems automagically vanish. In reality, that's not how real engineering solutions are developed.
If you use an api of any kind, from open-source code API's, to proprietary black box HTTP api's -- you can _definitely_ tell when the api developers have a strong understanding of the use cases, and when they don't. The best way to get a strong understanding of the use cases is to write a client.
This is what "dog fooding" means.