Hacker News new | past | comments | ask | show | jobs | submit login
Apple's no internal client syndrome (monkeydom.de)
160 points by blasdel on Oct 26, 2012 | hide | past | web | favorite | 42 comments



This really is quite true. iOS development is moving at breakneck pace and the API quality is starting to show.

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.


    > 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 impressed that this is still the situation a year after iCloud's release. When iCloud was originally announced, we were faced with the decision to adopt it or continue with our own server-based syncing solution.

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.


As the post mentioned, game developers aren't really interested in the platform. As a result, they file less Radar reports and Gamekit continues to be buggy. I'd really like to see Apple up the ease-of-use of Radar (or something new).

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.


That may be true today but in a business that moves this fast you have skate ahead of the puck. And the quality of the engineering I'm seeing on Google's side in the last few releases of Android impresses me a lot more than anything I've seen come from Apple since iOS4.

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.


What engineering are you impressed with on Google's side? I'd love to see examples of things to help me erase my painful memories of developing on Android around 1.5/1.6/2.1.


Fragments and the ActionBar. The new holo styles and interface conventions. The flexibility of layouts and the way that activities work. There are some rough edges, to be sure, but it all seems a lot more forward looking than Apple's miniaturization of Cocoa.


Also the new interactive notifications in Jelly Bean are an idea that's long overdue. I think the ability of Android apps to integrate more deeply with the OS is really starting to pay off.


I agree that the flexible layout approach is pretty nice (and obviously we're seeing Apple move towards this direction with autolayout), but I'm not a big fan of the fragment API. They sounded better in theory than they've worked out in practice, IMO.

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.


Which APIs specifically are you missing that aren't in the compat libraries? I agree that Google should be putting in more effort here and not leaving it up to a third party to come up with a backported action bar implementation but so far I've had pretty good luck with the compat libs.

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.


  > The flexibility of layouts 
And yet somehow iOS6 Auto Layouts and Collection Views do not count? Interesting. I also expect Pass Kit to take off.


These both feel like hacks and since Apple can't ever be bothered to backport anything I can't use them until my clients are willing to commit to iOS 6-only releases. Thanks to the maps fiasco I don't see that happening until some time next year.


It's very scary to rely on something like GameKit that is unproven because all your bugs are showstoppers, and you need to wait on Apple to fix it. And it's not like you can escalate iOS bugs against Apple...


Yes, this is so true. I even wrote a blog post about how bad Core Data for iCloud is: (http://loneyeti.com/posts/17). We even see it on Apple's own implementation of features ahemiTunes Matchahem. They are just trying to do too much too fast.

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.


?!! iOS 5 betas were ridiculously buggy. Even the stock apps wouldn't launch. But all iOS 6 betas were rock solid. I was running beta 2 on my (main) iPad untill last week and had no problems with first or third party apps.

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 :)


Do you think these bugs could be fixed in parallel? i.e. Apple is rich, just throw more devs at it? Or are there interactions, so that adding more developers would make it later?


It would be nice if they bothered to fix Xcode so that it wasn't buggy, crashy, and a burden to develop with. They could do that in parallel.


Actually I think that the latest version seems better. Crashes are certainly less than daily recently (which shouldn't be regarded as good enough but it is a lot better than it was).

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.


I highly recommend AppCode from JetBrains. I only use XCode for IB and for project configuration now and I'm much happier.


I tried AppCode and I preferred Xcode, actually.


I think there are two seperate issues we shouldn't mix up: On the one hand Apple is moving at such a quick pace, that there is less time for quality control, and many bugs stay even between major releases.

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.


> Sending files with iChat on AIM often failed.

iChat still regularly fucks up Jabber.


I was about to add syncing features and I'm disappointed to hear that it's not all that it's cracked up to be.


Absolute truth. The more obscure the piece of software in the Apple kingdom, the worse it is. Their OS X server product alone is so unbelievably ratty it single-handedly defeats the notion that Apple doesn't ship garbage.

Apple's best code is in the space between Cupertino and new money. Everything else tends to lie fallow.


Dude, as an internal team trying to get OSX Server support was a joke. The answer was never anything other than crickets or "next major rev, maybe."


There is a similar problem for users of non San Fracisco Bay Area maps.

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.


There are problems but it's not all bad. Sure, some of Apple's technology pushes have turned out to be half-baked, especially those which seem to be more marketing or management driven, such as iCloud syncing, and of course the subject of this article, Game Center. On the other hand, Apple has added some nice incremental improvements recently which will no doubt make life considerably easier once everything is running on iOS 6 as the minimum. Examples include the UIView "auto-layout" system, NSAttributedString support throughout UIKit, UICollectionView, and so on.

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.


Even iOS 5 adds a lot of niceties for developers. I am absolutely in love with storyboarding and so are the non-programmers on my team.

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...


Storyboarding strikes me as an example of another problem; it's very nice, but so poorly documented that it can be unclear how to do anything non-trivial with it. There are also a few deficiencies which require ugly hacks.


I think the award in that category goes to NSIncrementalStore :) I could often guess what I had to do in an overridden method...but in some places, I am still scratching my head.


Part of the reason I don't even use storyboards is because of its lack of good UIView manipulation. I do a lot of things in container views and scrollviews that add UIViews as subviews. For the type of UI I'm looking for, storyboarding really doesn't cut it.


This article and the comments on this thread run into the same problem as the "maps are broken!" arguments did - Apple's overall reputation is mistaken for its actual track record. They have always had their problems, as had other software developers, and everyone just selectively piles on something at some moment in time.

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.


I tried to introduce my gf to Letterpress last night. Game Center stumped us. It wouldn't send an invite (email? Apple ID?) and we both wound up connected to strangers, which was totally confusing. And it looked like some sort of online gambling interface, which didn't help.


It looked like some sort of online gambling interface, which didn't help.

Nails what's horrible about it, thank you. I've always disliked its aesthetics but never realized before why it feels so extremely inappropriate.


It's remarkable how terrible the Game Center looks in Letterpress. Totally different and ugly aesthetic, stuck in randomly when you want to start games.


There's no evidence that the Game Center issues that arose the day Letterpress was released had anything to do with the game. iMessage had connectivity issues earlier in the day.


Apple would get a huge benefit from integrating their UI code bases, Cocoa and Cocoa Touch. I and a lot of other developers dream about the day Apple will deliver a modern and saner Cocoa implemented with CALayers.

If that happens they'd have the resources needed to properly fix these issues that haunt us all.


With well over $100 billion in the bank, their problem isn't one of resources.


They may have a lot of money in their bank accounts. But be sure, there aren't a lot of available developers capable of producing high quality objc code.

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.


Well, Apple's Chess app now supports Game Center in Mountain Lion, so at least there's some hope there.


I'm thinking now I should write an internal client for my APIs. I admittedly don't have one, and it would show me what's wrong with them.


yes. Absolutely. This is the number one rule of writing APIs.

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.


GameKit was written by the designer to solve a use case: His kids, playing in the backseat without, "Daddy, can you setup the game?"




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: