20 ms·

Frustrated with iCloud, Apple’s developer community speaks up

220 points by jfcouture 14y ago

savrajsingh 14y ago
Sounds like an opportunity for Dropbox. Go Dropbox!
- pilif 14y ago
  Many points of the article are related to conflict resolution and CoreData sync, both of which features that are a) incredibly hard to get right and b) practically unsupported by Dropbox. Dropbox' method of conflict "resolution" is to keep to files around and its method of synching databases is to not do it. There are other places where Dropbox has advantages over iCloud (like doucments being shared between applications, even though the dropbox api seem to move away from that and on to sandboxed application folders), but for the points made in the original article, Dropbox provides no help at all.
- Ovid 14y ago
  No, the article covers this. Dropbox is great, but it is based on document syncing. Apple has document syncing working just fine. Like database synching, Apple and Dropbox both have issues. To get a hint of the problem, you can read this post about why git+Dropbox is problematic: http://www.unityisplural.com/2012/02/git-dropbox-bad.html http://www.unityisplural.com/2012/02/git-dropbox-bad.html (I've used git+Dropbox and have gotten corruption issues in my git repo). Further, by pushing an app relying on Dropbox, you're telling your users to sign up for an extra service to use your app. That's bad.
  - mikeash 14y ago
    It's true that git+Dropbox isn't resilient in the face of multiple simultaneous writes, but I think the problem is overstated. You might see an inconsistent state, but you'll never get corrupted data because of it. You might corrupt the repository on Dropbox (has happened to me a couple of times), but this is trivially fixed by deleting and recreating it. I'd never use it for a large team, but for a couple of collaborators, or syncing a repository between multiple computers for a single developer, it's a nice and easy solution.
saosebastiao 14y ago
The unexpected appleID problem is, in my opinion, a world stopping bug...the kind that would cause a code red meltdown if it wasn't fixed 24 hours. This bug has been reported for years, with no resolution. The apple stores pretend the problem doesnt exist or they give you the runaround because their product that "Just Works" doesnt have a fix for it yet. My wife, who was a hopeless apple junkie, has decided that her current iPhone5 will be her last apple product...with her continued frustration with AppleId authentication being the straw that broke the camels back.
- larrik 14y ago
  I read the whole article, and I read all the HN comments (so far), but I still have no idea what the "unexpected appleID problem" is. Care to explain, for the unintiated like me?
  - saosebastiao 14y ago
    When it prompts you to log in, it will pull up your appleID for you, but it gets it wrong. It will pull up some random other appleID...sometimes an old one you created for iTunes using a hotmail account you haven't checked since 2004, but sometimes a completely random other person's appleID. The authentication is unpredictable too...my wife has successfully signed on to her current account using an old password and successfully signed on to an old account using her new accounts password. Most of the time she can't sign on at all.
    - vacri 14y ago
      How is that even possible? What could be the possible rationale for keeping old passwords stored? Crazy.
      - larrik 14y ago
        Normally it would to be prevent users from reusing their most recent N passwords, for security. I don't believe Apple does that anywhere, though.
hp50g 14y ago
Apple's dalek lawyers will emerge chanting litigate! Litigate! Litigate! Serious Apple have always done a crappy job of online services - why would you expect any more.
potatolicious 14y ago
I've worked with iCloud in conjunction with Core Data. It's as broken as the article describes, and in fact has gotten worse over time. No one really fully knows WTF is going with iCloud - documentation is basically nonexistent, support unavailable, implementation broken in trivial ways, and error messages inscrutable. I was at an Mac/iOS conference recently where the Core Data iCloud talk morphed from a standard talk into a "here's the mic, anybody have any idea what's going on with this thing" affair. Helpful, but indicative of the state of things. IMO, from having studied this for many, many hours over many moons, is that what Apple is trying to do is fundamentally hard, if not entirely unfeasible. They're trying to replace a smart server with one that's dumb as a doorstop. More specifically, they're trying to emulate a CRUD web service with a file sync engine. Conflict resolution is left up to individual clients, since the server doesn't do any "thinking". Likewise, there is no canonical, authoritative state of the store, since the server doesn't "think", only the clients do. Apple was hoping that by shoving a bunch of diffs of your database onto the server, that clients can reliably reconstruct a sane database by playing them back - except that multiple clients are updating the diffs simultaneously and there is no server-side conflict resolution. Oh, and if stuff fails, there are no regular snapshot states to fall back to, because iCloud is a file store, not a database engine. Your whole store is now corrupt. Enjoy. Oh, and there's no way to nuke the database and start over - there are metadata files that are undocumented or that we don't even have sandbox access to, that interfere with completely destroying the database. At this point you might think "Fine! I'll go to my Settings -> iCloud -> Manage Storage menu and delete everything associated with that app and start it off on a clean slate!" And then you find out that, even today, in iOS 6.1.3 land, there is a bug from iOS 5.0 where if you delete an app's iCloud bucket it can never be created by that app, on that account, ever again. I wish I were exaggerating. In perpetuity. Presumably some state gets fucked and now this app is forever more unable to store anything on iCloud. To make even the most trivial experiment on the iCloud API involves creating a brand new app. iCloud (in so far as it relates to Core Data and document storage) isn't just buggy, isn't just poorly implemented - it's non-functional.
- aidos 14y ago
  Good lord, that sounds like a complete mess. I haven't been anywhere near it as a developer so I can't really speak on how bad it is from that point of view. As a user though I have absolutely no idea what is going in with Apple syncing. My wife has an iphone / mac syncing explosion that I simply can't fix. I just don't have any idea where the data is or why everything is duplicated in her iphoto collection. Or what's going to happen in when you remove something from one place. Most of all I cannot for the life of me explain to my wife why it is that when she lost her phone and restored a previous backup to a new one it DELETED ALL HER RECENT PHOTOS from off her mac without warning. Gone, forever. I watched it happen before my very eyes and it's made me want to never buy another apple product again.
ericcholis 14y ago
If I'm not mistaken, there seem to be better cross platform options in Parse and Dropbox. A case can be made for the "walled garden", iCloud doesn't seem to be one of them.
- potatolicious 14y ago
  There is indeed an opportunity here for other cloud providers - but "better" is fuzzy. The nice thing about iCloud is that once you set it up on a device, there is no need to configure it or authenticate ever again. It "just works" (if it actually worked). With Dropbox, either you are storing everything for all of your users (and paying for it), or you integrate into the user's Dropbox account - which would necessitate a fancy ol' login/authentication system. Far from seamless, and relies on your users subscribing to something that is popular but far from ubiquitous. So... either pay through the nose for all your users' storage, or force them to jump through some circus hoops on their own. Neither are great.
  - lake_rogue 14y ago
    The biggest reason we wanted to use iCloud is: background syncing (i.e. not just when the app is in the background, when the app isn't even running). For apps that get a fair bit of off-line data creation this is a nice feature. There's no way for a third party library to do this (at least not through iOS 6.1.3 SDK).
- zoul 14y ago
  The great advantage to iCloud (whatever issues there are) is that it’s already there, integrated to the system. There’s almost nothing your users have to do in order to use it, quite unlike Parse and Dropbox. Granted, “almost everybody” has a Dropbox account and it’s free, but the nice thing about Apple devices is that they mostly work (or used to work?) even for people who know almost nothing about computing.
- kyrra 14y ago
  While Dropbox is the most popular shared-drive mechanism out there, there are alternatives to it. 1) Google Drive - took my a long time before I even tried it, but it works about as flawless as dropbox for my needs. I actually like it a lot as I use Google Docs heavily, so it makes it easier to use those tools. 2) SkyDrive - offers the most base storage than the other. Has nice support for MS Office products. 3) AeroFS[1] - While it's still in beta, it looks promising (it has limited (android) to non-existant (iphone) support). [1] https://aerofs.com/ https://aerofs.com/
smackfu 14y ago
It's interesting how the iCloud branding plays into this. Because Apple includes so many services under the umbrella term iCloud, it can lead to a very different impression of the service between the users and the developers. All the talk about "iCloud is broken" is about one specific part, Core Data syncing. The rest, like online backup and document syncing and calendars, seems to work most of the time. I actually saw some comments elsewhere along the lines of "iCloud works fine for me as a user, so it's probably just bad developers who can't get it to work, not any issue with Apple."
- mikeash 14y ago
  Even more than that, iCloud Core Data syncing appears to be so broken that approximately nobody is able to even ship an app that uses it. Thus, users are never exposed to the brokenness because it's so broken you can't give it to them.
- rada 14y ago
  The rest, like online backup and document syncing and calendars, seems to work most of the time. Those 3 things are broken as well. Lost all my data twice.
  - crazygringo 14y ago
    But only most of the time. Last week, my iPhone inexplicably deleted all the pages in my Notes application that I made in February 2013, around 20 of them. Fortunately, they're still there in my synced e-mail account, but there appears to be no way to sync them "back" onto my iPhone. And then last month, syncing my iPhone with iTunes inexplicably deleted the 40GB of my music from my iPhone. I hadn't done anything differently from the hundreds (?) of other times I've synced. I just had to go one-by-one and re-check all the playlists I sync, and wait a few hours for all the music to be re-copied. But still. As easy as Apple products are to use, I'm always afraid something is going to go horribly wrong, in a way I never was with PC's, for example -- they were harder to use, and did less, but you could at least be reasonably sure of what was going on behind the scenes.
- asparagui 14y ago
macarthy12 14y ago
Expect Parse to be bought soon..
saurik 14y ago
When ever this topic comes up, including at iPhone conferences I attend, no one seems to have ever heard about Simperium, which pretty much has as their mission statement to solve this problem and seems to have actually done so quite well (yet people are mentioning, quite often, only tangentially-related companies like Dropbox); I believe they are even a Y Combinator funded company... I would be fascinated by an explanation of "what they could be doing differently so that people would use them".
- potatolicious 14y ago
  > "I would be fascinated by an explanation of "what they could be doing differently so that people would use them"." I've also never heard of them until now. Perhaps they should show up to said conferences, or at least keep tabs on Core Data-related talks at conferences and give the organizations/speakers a heads up.
- zalambar 14y ago
  I've talked to folks from Simperium before and think that they have a good idea but I remain skeptical of their approach . In particular their Core Data syncing strategy. As I understand it Simperium observes changes to the Core Data models you specify, maps those changes to operation transforms, and distributes the transforms across whichever clients have subscribed to the service. That's great if all your app needs is simple data replication to multiple clients. Unfortunately operational transforms are not necessarily snapshots of database transactions and conflict resolution strategies do not guarantee a valid database. Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients. Conflict resolution is then performed between operations rather than transactions. Simperium can probably take steps to minimize that case but as long as I can construct transactions which cannot be expressed as a single operation this will happen. Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules. For example two clients can each add a child object to a "has one" association. Both "create" operations can be applied without conflict but the parent object no longer passes the application's validation rules. This doesn't make operational transform based synchronization untenable but it does imply a new set of constraints on how applications should model their data in order to successfully apply operations from other clients. That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail. Otherwise I fear such a service is another iCloud like trap which will eventually (though perhaps less frequently) hit catastrophic edge cases from which there is little hope of recovery.
nicholassmith 14y ago
There's been quite a few articles from people far smarter than I about it, and most of them agree that whilst doing a server backed database synch service is hard, it shouldn't be this buggy at this stage. It's like Game Center, Apple doesn't bother with any apps that really use it so there's many, many problems reported on a consistent basis, and they don't seem to use iCloud for anything involving Core Data so they're not dog fooding and having engineers swear at code. No swearing means no one is motivated to go back and try improve it.
timjahn 14y ago
I feel like I'm the only person that has had zero trouble with iCloud. My phone backs up to it regularly (without my having to do anything whatsoever) and I've transferred my entire phone settings (and my wife's) more than once to brand new devices via iCloud. In my experience, it truly does "just work".
- madeofpalk 14y ago
  Right. So as a consumer, it's mostly painless. For developers, it's fundamentally broken as potatolicious describes https://news.ycombinator.com/item?id=5454729 https://news.ycombinator.com/item?id=5454729
  - timjahn 14y ago
    Gotcha. I guess I just don't see what all the fuss is since it works flawlessly for me.
    - evan_ 14y ago
      Lots of things fall under the iCloud umbrella. A lot of them DO work. Just as you only think about the parts that work, ios developers think about the parts that do not work- so to you iCloud works and to them it doesn't even though you're talking about different things in the system.
- mikeash 14y ago
  That's because the parts that are broken are so broken that developers can never even get to the point of shipping software to you that uses them.
bane 14y ago
It might be nice if Apple's legendary attention to detail extended beyond the logo. [1] 1 - http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golden-ratio/ http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golde...
- ianstallings 14y ago
  And that's the problem in a nutshell. If it's consumer-facing it's years in development and polished. If it's for us lowly developers, well don't hold your breath.
  - jfim 14y ago
    The in-joke we had as Mac developers many years ago was that Macs are very user friendly. The problem is that developers aren't users.
robomartin 14y ago
I am one of those developers who don't jump on the bandwagon right away. Experience has taught me to be very cautious. It also comes from doing a ton of work on mission-critical systems where you don't do stuff like install the latest software updates without massive testing on off-line systems. Yes, sometimes I miss out on really neat developments. iCloud is one of those cases where I am glad for being a slow adopter. My mental red flags went up as soon as iCloud came out. Not one of my apps uses it. On the end-user front iCloud is also an absolute mess. I probably have a dozen i-devices on the same account (testing, etc.). Crap appears and disappears from devices seemingly at random. The worst of it was what is happening with my wive's iPhone and mined. We share an iPad at home. Now contacts are getting deleted from her phone and mine at random and so are notes. It's at the point where she is not using notes any more because --her words-- they disappear within a hour or two of writing them. Of course, turning off iCloud is the solution. The problem is that this isn't as simple as throwing the switch. If you turn off iCloud on your device it might actually delete things that it shoved into the iCloud service. And then it deletes the info from your other devices. And it does this in some amazingly weird ways. Without telling you what it is about to delete. For example, I have never explicitly stored contact information on iCloud. Never. I type new or updated contact information into the phone. That's where it belongs. In fact, I never even use my iPad for this. Yet, some contact information for some strange fucking reason is sent over to iCloud. The first time I turned off iCloud piles of contact data evaporated from my phone. I had to turn the damn thing on again to get it back. I haven't had the time to research how to fully disable iCloud on ALL of my devices while, at the same time, keeping or merging the state of my data on that particular device. As a developer I managed to avoid iCloud. As a user I was not that fortunate, I succumbed to the new shinny thing on the shelf. Now I want nothing to do with it. Thank you Apple. Any ideas on how to do this?
- imissmyjuno 14y ago
  The only thing I can think of is to set up contact, calendar etc. sync to Google (via ActiveSync or otherwise). Calendars won't magically transfer over since they're assigned to a particular calendar, on iCloud in your case, but contacts should get pushed to Google. That'll at least give you a backup of your contacts, and setting up the other devices the same way should sync them all up. Can anyone else chime in? Does this sound reasonable? I've had everything on my iPhone synced up to Google services for about 4 years now and it's never caused any issues.
jimbokun 14y ago
Anyone using TouchDB as an alternative to iCloud core data syncing? https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS Of course, you would need to support some form of CouchDB server for this to work, deal with authentication, etc.
- oohaba 14y ago
  In my last startup, I used TouchDB and found that 95% of the time, it worked great, and 5% of the time, the app would grind to a screeching halt. Reading documents from the local TouchDB store would block the main thread until the upstream CouchDB server would reply with the document's current revision, even if the local store already has an existing version of the document. Using GCD to wrap around these document transactions was still clunky at best and resulted in a poor overall UX. YMMV, perhaps these issues could have been worked around if I had had a more realistic deadline and stayed in touch with the community. The maintainer, Jens Alfke, is very active.
  - jchrisa 14y ago
    Thanks for the heads-up. We are very responsive to issues filed via the Github issue trackers, or brought up on the mailing list. My guess is this has been fixed since then (we've rewritten a lot of that code path), but if it isn't fixed, you can find a link to all of the relevant bug trackers on our Google Group splash page: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase
ianstallings 14y ago
Frustrated with just iCloud? No I'd go further. I'm frustrated with the whole iOS platform. It's like writing an app in the 1990s. Sure it works. But it's painful as hell. So much so that I've decided this latest project on iOS was probably my last unless something big changes. And just for the record I have a few flagship apps in the app store with millions of active users and I've worked quite extensively with the platform. So it wasn't a case of trying it and then giving up in frustration. It's more like watching your peers blow past you because your toolset is from yesterday and their's is from tomorrow.
- jawngee 14y ago
  And just for the record I have a few flagship apps in the app store with millions of active users Source please. because your toolset is from yesterday and their's is from tomorrow This is why I don't believe your first point without sources to verify. Eclipse+Android SDK is hardly from tomorrow. Windows 8 possibly. What else does that leave? Nada.
  - ianstallings 14y ago
    Oh okay so because I think the toolset is crap you want to call me out. No problem. Here's two that have over a million users below. Oprah Magazine (1M+ subscribers): https://itunes.apple.com/us/app/o-oprah-magazine-archive-dec/id573221573?mt=8 https://itunes.apple.com/us/app/o-oprah-magazine-archive-dec... Esquire Magazine (1M+ subscribers): https://itunes.apple.com/us/app/esquire-magazine/id433020707?mt=8 https://itunes.apple.com/us/app/esquire-magazine/id433020707... Those are just two that I have built. I have an enterprise platform that I architected from the ground up that companies like pfizer use for it's whole workforce. I have ones written for Disney, Hearst, GE, MaryKay, Hallmark, Sesame Street, etc, etc. The one I'm building now is ready to scale to ~5M users right out of the gate and I believe we will succeed. Now put your apps up and let me pick through them and tell you why you're wrong because I just don't believe your work is credible.
    - druiid 14y ago
      Hey man, not sure how worried about your info getting out there, but generally when people troll for 'proof' here I ignore it. Essentially it's just one more avenue for people to use against you, especially in regards to linking a name/identity to work and I generally (personally) try to keep them separate. Your choice, just something to think about... also, don't feed the trolls etc ;)
daleharvey 14y ago
I have been surprised at the relative lack of interest from developers about first class syncing support, when mobile blew up I expected a flurry if libraries and tools that I could use to have my app work offline and sync data wherever I am. Sometime last year I gave up waiting and started working on PouchDB (http://pouchdb.com/ http://pouchdb.com/), its based on CouchDB's syncing model (and syncs with CouchDB) and works anywhere that Javascript runs (the browser + node), there is an iOS / OSX equivalent (https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS). PouchDB isnt quite ready for production but its getting close, I would love any feedback on it, although I expect most people commenting on this would be more interested in TouchDB
- DeepDuh 14y ago
  I'm very interested in this, in fact I'm planning on rolling an iOS based couchDB solution for a company sometime this summer. Could you comment on some key differences between pouchDB and touchDB? Did you also try to simply run ARM compiled couchDB on iOS? If yes, how was the performance there? I've read that initializing takes about 10 seconds - I'd be willing to swallow that if the subsequent interactions are smooth. How about the initial replication of larger databases? Do you roll out an initial version directly in your app or do you have some file based download of a snapshot?
  - daleharvey 14y ago
    The key differences between touchDB and pouchDB is that touch is written for ios and pouch is written for web browsers, if you are building for ios and not using phonegap then I suggest using touchdb. It is also the more mature of the 2 but hopefully we arent too far behind with pouch. I used to work for Couchbase on the arm compiled couchdb mobile versions, mainly android but either way I wouldnt hugely recommend using them, they always worked against the grain of the platform, never had great performance and due to those reasons they didnt really get widely adopted and therefore I wouldnt trust their stability across a variety of platforms and use cases. The problems with arm compiled couchdb is the reason TouchDB was made, and similiarly with PouchDB / TouchDB for android and CouchDB I hope we get to the point were there is an out of the box sync solution that works great on every platform, it doesnt feel too far away. For large initial datasets I have tried taking a dump of the database and importing it on first load, it worked however replication has been more than sufficient for my use cases right now. Once pouch has stabilised and released there are a lot of low hanging fruit that can be done to optimise replication (and in particular for first load).
acdha 14y ago
My trust of iCloud disappeared when a restore from backup lost all important data (passwords, Google Authenticator keys, etc.) with no indication. The backup was listed as successful, the restore was listed as successful and yet the only data I needed it to restore was lost. This was also when I learned that Google's process for restoring lost two-factor credentials ultimately ends in an email form which sends to higgins-prod-lost-hard-landing@google.com which been bouncing since 2011. Thank FSM I had some some backup codes printed…
- ajanuary 14y ago
  Google explicitly opted out of backing up authenticator keys. iCloud would be worse if apps /couldn't/ opt out.
  - smackfu 14y ago
    I don't think that's right. Secure things in iOS are in the Keychain, and the Keychain is only backed up if you do an encrypted backup via iTunes. Other backup methods (iCloud and non-encrypted iTunes) just leave it out of the backup. The scary thing is that you hope your apps can handle the case where they have local data but no authenticated user for it. Some of them just treat no authenticated user the same as a first start and reinit the local data.
    - acdha 14y ago
      I think the main problem is that there's zero UI indication that your backup is incomplete and the Apple store staff aren't instructed to ask/communicate that. It'd be a very different story if using iCloud or iTunes without a password triggered a “Because our programmers are lazy, we're not backing up your sensitive data” message.
    - dunham 14y ago
      The backup, encrypted or otherwise, doesn't contain the actual keychain file itself, but rather a plist export of a subset of the keychain. Things that are marked as kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly are never included in this backup file. Google's GTMOAuth library uses this value for its keychain records.
doe88 14y ago
I think the reason developers (myself included) try, and re-try to make it work (Coredata + iCloud), despite all the bad experiences and bad stories is that everybody would like badly that it worked. Because if it worked it would be awesome, when I test it and that it works it's really really nice, but I lost confidence in the overall reliability so in the end I never take the risk to ship it.
- alttab 14y ago
  That's like staying with an abusive spouse because he bought you a nice dinner once.
  - rimantas 14y ago
    Except that fixing abusive spouse is nearly impossible, but fixing buggy service is possible (though it may be hard in this case).
    - gurkendoktor 14y ago
      Not only that - for Game Center it seems that this has actually happened.
JonnieCache 14y ago
Anyone care to speculate as to why apple can't seem to do web services with even a modicum of success? (Remember ping?)
- vor_ 14y ago
  Apple is strong when they have total control, but web services require dealing with large-scale chaos.
- chiph 14y ago
  My theory is that the culture of internal secrecy at Apple prevents the teams from collaborating. So you get products that work fine in isolation. Also a factor would be date-driven-development. Steve would want to demo a new offering at WWDC, so everything was driven by making that date. My hope is that now that one person (Jonathan Ive) has been put in charge of product development, things might get better.
- jmathai 14y ago
  For the same reasons Microsoft hasn't been terribly successful online? It's a different game played by different rules. Interestingly, I'd like to watch and see how Google does moving into the physical goods space.
  - skc 14y ago
    Erm, excuse me? For one, Windows Azure is a pretty big deal. Secondly, XBox Live is a pretty big deal. Third, Bing might be struggling to gain traction but it most certainly works. So can you point me to a Microsoft web property or service that is as wonky as iCloud at all?
    - jmathai 14y ago
      I'm not saying they've found zero success. XBox live is probably the biggest. At Microsoft's size they aren't really looking for "pretty big deal" successes. Bing is probably around 15% market share. A home run for most but not (yet) for MS. I can't really comment on Windows Azure. I'll take your word for it but I think Amazon is eating Google and Microsoft's lunch here. This isn't a fight for second place.....
outside1234 14y ago
I don't mean to be flip but how could you think a company that has to take down their store to change the product inventory would be a good bet to build solid web services?
- vor_ 14y ago
  To my knowledge, that only occurs during a keynote that introduces new products. I suspect it's intended to generate excitement.
- smackfu 14y ago
  OTOH, the number of leaks via prematurely updated store pages that you see on other manufacturers indicate that it's not as easy as you would think.
  - coolsunglasses 14y ago
    It's called staging and scripts.
    - smackfu 14y ago
      I just wonder what the practical effect of Apple's online store being down is... it looks bad, but does it actually cost them any sales?
      - gurkendoktor 14y ago
        When I still had Mac blogs in my RSS reader, the store closing down for a few minutes would actually cause wide coverage with a follow-up post on what how their inventory has changed.
lake_rogue 14y ago
I tried to add iCloud features to an app as part of a contract gig. It was disastrous. The paying customer knew we were capable, but began to wonder what was going on with us -- it was frustrating to have our client lose a bit of respect for us when the cause was the brokenness of iCloud. They, understandably, thought there was no way that something so heavily promoted by Apple could be such a lemon. And in spite of having heard mumblings of iCloud bugs, we wrote it off as amateur iOS developers. We ultimately abandoned iCloud prior to release (going with simple Python based server for data storage) -- reading the other posts I'm glad we didn't try to convince ourselves that the 'almost stable' behavior was just a quirk of our devices having been used in development mode.
gdubs 14y ago
Core Data now provides NSIncremental store, which lets you use any web API as your persistent data store. It's possible to roll your own alternative to iCloud in this way, if you choose.
- jemeshsu 14y ago
  Core Data + NSIncremental store with a web api backend does not solve the problem of offline sync. It is possible to roll your own, its hard to get it right. It is complicated by iOS restriction of not able to run your own daemon. But then if I have the resource to roll my own then I would not complain about Apple. Dropbox does not come close as alternative. Dropbox as of now is file-based sync. Core Data iCloud sync is trying to sync an always opened SQLite3 database file, they do it through database log files. Possible alternatives are TouchDB, Simperium, Firebase but then you have to change your app from not using Core Data. Or rewrite your app to use file based storage as what 1password did. The key is offline sync. File based cloud sync is solved problem. So maybe the way to go is persistent store of client app has to use files.
  - gdubs 14y ago
    Very true. The pain point seems to be largely the database merges; it's possible to roll your own db while using iCloud mainly as a key/value store for synching user preferences and status between devices. This is particularly useful if you support more than just apple devices... Edit: regarding offline sync (which I didn't address) something like AFIncremental store is a good example of how a local persistent store can be maintained in tandem with the online store. (But, as you say, non- trivial and hard to get right.)
- gurkendoktor 14y ago
  We've tried to use NSIncrementalStore and we found it quite tough. Documentation is sparse. You buy yourself into the SQL-ish interface of NSFetchRequest throughout the app. There are fun bugs to discover like this one: https://github.com/stackmob/stackmob-ios-sdk/blob/master/CoreData/Classes/SMIncrementalStore.m#L299 https://github.com/stackmob/stackmob-ios-sdk/blob/master/Cor... And once you discover that you can't fix all the problems that Apple is struggling with, you have dug yourself into a VERY deep hole :)
mayop100 14y ago
(Shameless plug) Firebase is an alternative to iCloud for many apps. It's built as a database, rather than a file store, so it's ideal for storing structured data. Conflict resolution is something we've been thinking hard about from day 1, and we think we have a pretty solid story [1]. We launched native iOS support a few weeks ago [2]. You can also access your data from JavaScript or from a REST API. Android and other platforms are in the works. We're a platform-independent service, and since you (the developer) is paying for the storage, we have the right incentives to give you maximum access to your data (unlike iCloud), and a good developer experience. We've also put a ton of work into making it easy to learn and easy to use. See, for example, our quick tutorial [3]. If you've used Firebase as a substitute for iCloud, we'd appreciate your thoughts in the comments! 1. https://www.firebase.com/docs/transactions.html https://www.firebase.com/docs/transactions.html 2. https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sdk.html https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sd... 3. https://www.firebase.com/tutorial/ https://www.firebase.com/tutorial/
- ok_craig 14y ago
  Hey, I've been using Firebase for a web client I've been working on for a bit and I like it a lot! Would you consider updating your transactions page with an example of a text change? Such as adding a word in the middle of a paragraph. I'm not quite sure how that would work.
  - mayop100 14y ago
    Collaborative text editing generally requires a bit more than a simple transaction to work well (Operational Transforms are generally involved). You can use transactions as a basis for this though. We've got some examples coming out soon to show how to to do this. Stay tuned...
visarga 14y ago
As an Apple user, I have often consulted discussions.apple.com to find fixes for problems. A lot of times there were thousand post long threads with no official answer. It is a wasteland. I know they don't answer questions, but they could make an exception for the most important common issues. It's as if they put their fingers in their ears and sing "la la la" while we try to communicate bugs. How can the richest computing company not answer questions put by thousands of users who have banged their head in the same bug? It's insulting to have this circus happening on their doorstop.
robomartin 14y ago
I went to disabled iCloud on one of my Macs and I got this warning: "If you turn off Documents and Data, all documents stored in iCloud will be deleted from this Mac" Let's get past the jaw-to-the-floor, how-dare-you, !!!$$%#$## moment. They are morons and don't respect your data. So, how do you figure out just what is in iCloud? I don't see an easy iCloud viewing option in Finder. Doing some digging this is what I found: - Open Finder - Fire-up "Go To Tolder" - Enter ~/Library/ - Go into "Mobile Documents" That's what's on iCloud. You have to manually dig through it all and figure out what's there. If you delete anything there it will be deleted from all of your sync'ed devices, including your local Mac. It will also end-up in the trash folder. You could copy it all to a USB drive, memory stick, or, better yet, Dropbox. Then you can completely disable iCloud knowing your data is safe and iCloud will never cause you further grief.
- grandinj 14y ago
  You are not parsing the message correctly. It says nothing about deleting data from your other devices.
  - IheartApplesDix 14y ago
    Yeah, that's just a hidden surprise for you to discover next time you sync, as I unfortunately discovered when it deleted my entire schedule from a corporate Exchange Account. So not only does it apply to your iDevice, it also applies to any accounts that you've linked to the device and conform to the latest generation of CYA extensions for the Enterprise.
Philadelphia 14y ago
Tuesday's article on The Verge [1] was a lot clearer about the distinction between the various components that fall under the iCloud brand and what the problems are with the Core Data synchronization piece. [1]http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-just-work http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-...
shurcooL 14y ago
The document storage of iCloud is broken from a design viewpoint: I don't want to store/find things based on app, but rather by date/time created, content type, name, etc. If I have many apps that do the same thing, I'd have to go through each one to remember where I saved something. No, just no.

220 points by jfcouture 14y ago

savrajsingh 14y ago

Sounds like an opportunity for Dropbox. Go Dropbox!

pilif 14y ago
Many points of the article are related to conflict resolution and CoreData sync, both of which features that are a) incredibly hard to get right and b) practically unsupported by Dropbox. Dropbox' method of conflict "resolution" is to keep to files around and its method of synching databases is to not do it. There are other places where Dropbox has advantages over iCloud (like doucments being shared between applications, even though the dropbox api seem to move away from that and on to sandboxed application folders), but for the points made in the original article, Dropbox provides no help at all.
Ovid 14y ago
No, the article covers this. Dropbox is great, but it is based on document syncing. Apple has document syncing working just fine. Like database synching, Apple and Dropbox both have issues. To get a hint of the problem, you can read this post about why git+Dropbox is problematic: http://www.unityisplural.com/2012/02/git-dropbox-bad.html http://www.unityisplural.com/2012/02/git-dropbox-bad.html (I've used git+Dropbox and have gotten corruption issues in my git repo). Further, by pushing an app relying on Dropbox, you're telling your users to sign up for an extra service to use your app. That's bad.
- mikeash 14y ago
  It's true that git+Dropbox isn't resilient in the face of multiple simultaneous writes, but I think the problem is overstated. You might see an inconsistent state, but you'll never get corrupted data because of it. You might corrupt the repository on Dropbox (has happened to me a couple of times), but this is trivially fixed by deleting and recreating it. I'd never use it for a large team, but for a couple of collaborators, or syncing a repository between multiple computers for a single developer, it's a nice and easy solution.

saosebastiao 14y ago

The unexpected appleID problem is, in my opinion, a world stopping bug...the kind that would cause a code red meltdown if it wasn't fixed 24 hours. This bug has been reported for years, with no resolution. The apple stores pretend the problem doesnt exist or they give you the runaround because their product that "Just Works" doesnt have a fix for it yet. My wife, who was a hopeless apple junkie, has decided that her current iPhone5 will be her last apple product...with her continued frustration with AppleId authentication being the straw that broke the camels back.

larrik 14y ago
I read the whole article, and I read all the HN comments (so far), but I still have no idea what the "unexpected appleID problem" is. Care to explain, for the unintiated like me?
- saosebastiao 14y ago
  When it prompts you to log in, it will pull up your appleID for you, but it gets it wrong. It will pull up some random other appleID...sometimes an old one you created for iTunes using a hotmail account you haven't checked since 2004, but sometimes a completely random other person's appleID. The authentication is unpredictable too...my wife has successfully signed on to her current account using an old password and successfully signed on to an old account using her new accounts password. Most of the time she can't sign on at all.
  - vacri 14y ago
    How is that even possible? What could be the possible rationale for keeping old passwords stored? Crazy.
    - larrik 14y ago
      Normally it would to be prevent users from reusing their most recent N passwords, for security. I don't believe Apple does that anywhere, though.

hp50g 14y ago

Apple's dalek lawyers will emerge chanting litigate! Litigate! Litigate! Serious Apple have always done a crappy job of online services - why would you expect any more.

potatolicious 14y ago

I've worked with iCloud in conjunction with Core Data. It's as broken as the article describes, and in fact has gotten worse over time. No one really fully knows WTF is going with iCloud - documentation is basically nonexistent, support unavailable, implementation broken in trivial ways, and error messages inscrutable. I was at an Mac/iOS conference recently where the Core Data iCloud talk morphed from a standard talk into a "here's the mic, anybody have any idea what's going on with this thing" affair. Helpful, but indicative of the state of things. IMO, from having studied this for many, many hours over many moons, is that what Apple is trying to do is fundamentally hard, if not entirely unfeasible. They're trying to replace a smart server with one that's dumb as a doorstop. More specifically, they're trying to emulate a CRUD web service with a file sync engine. Conflict resolution is left up to individual clients, since the server doesn't do any "thinking". Likewise, there is no canonical, authoritative state of the store, since the server doesn't "think", only the clients do. Apple was hoping that by shoving a bunch of diffs of your database onto the server, that clients can reliably reconstruct a sane database by playing them back - except that multiple clients are updating the diffs simultaneously and there is no server-side conflict resolution. Oh, and if stuff fails, there are no regular snapshot states to fall back to, because iCloud is a file store, not a database engine. Your whole store is now corrupt. Enjoy. Oh, and there's no way to nuke the database and start over - there are metadata files that are undocumented or that we don't even have sandbox access to, that interfere with completely destroying the database. At this point you might think "Fine! I'll go to my Settings -> iCloud -> Manage Storage menu and delete everything associated with that app and start it off on a clean slate!" And then you find out that, even today, in iOS 6.1.3 land, there is a bug from iOS 5.0 where if you delete an app's iCloud bucket it can never be created by that app, on that account, ever again. I wish I were exaggerating. In perpetuity. Presumably some state gets fucked and now this app is forever more unable to store anything on iCloud. To make even the most trivial experiment on the iCloud API involves creating a brand new app. iCloud (in so far as it relates to Core Data and document storage) isn't just buggy, isn't just poorly implemented - it's non-functional.

aidos 14y ago
Good lord, that sounds like a complete mess. I haven't been anywhere near it as a developer so I can't really speak on how bad it is from that point of view. As a user though I have absolutely no idea what is going in with Apple syncing. My wife has an iphone / mac syncing explosion that I simply can't fix. I just don't have any idea where the data is or why everything is duplicated in her iphoto collection. Or what's going to happen in when you remove something from one place. Most of all I cannot for the life of me explain to my wife why it is that when she lost her phone and restored a previous backup to a new one it DELETED ALL HER RECENT PHOTOS from off her mac without warning. Gone, forever. I watched it happen before my very eyes and it's made me want to never buy another apple product again.

ericcholis 14y ago

If I'm not mistaken, there seem to be better cross platform options in Parse and Dropbox. A case can be made for the "walled garden", iCloud doesn't seem to be one of them.

potatolicious 14y ago
There is indeed an opportunity here for other cloud providers - but "better" is fuzzy. The nice thing about iCloud is that once you set it up on a device, there is no need to configure it or authenticate ever again. It "just works" (if it actually worked). With Dropbox, either you are storing everything for all of your users (and paying for it), or you integrate into the user's Dropbox account - which would necessitate a fancy ol' login/authentication system. Far from seamless, and relies on your users subscribing to something that is popular but far from ubiquitous. So... either pay through the nose for all your users' storage, or force them to jump through some circus hoops on their own. Neither are great.
- lake_rogue 14y ago
  The biggest reason we wanted to use iCloud is: background syncing (i.e. not just when the app is in the background, when the app isn't even running). For apps that get a fair bit of off-line data creation this is a nice feature. There's no way for a third party library to do this (at least not through iOS 6.1.3 SDK).
zoul 14y ago
The great advantage to iCloud (whatever issues there are) is that it’s already there, integrated to the system. There’s almost nothing your users have to do in order to use it, quite unlike Parse and Dropbox. Granted, “almost everybody” has a Dropbox account and it’s free, but the nice thing about Apple devices is that they mostly work (or used to work?) even for people who know almost nothing about computing.
kyrra 14y ago
While Dropbox is the most popular shared-drive mechanism out there, there are alternatives to it. 1) Google Drive - took my a long time before I even tried it, but it works about as flawless as dropbox for my needs. I actually like it a lot as I use Google Docs heavily, so it makes it easier to use those tools. 2) SkyDrive - offers the most base storage than the other. Has nice support for MS Office products. 3) AeroFS[1] - While it's still in beta, it looks promising (it has limited (android) to non-existant (iphone) support). [1] https://aerofs.com/ https://aerofs.com/

smackfu 14y ago

It's interesting how the iCloud branding plays into this. Because Apple includes so many services under the umbrella term iCloud, it can lead to a very different impression of the service between the users and the developers. All the talk about "iCloud is broken" is about one specific part, Core Data syncing. The rest, like online backup and document syncing and calendars, seems to work most of the time. I actually saw some comments elsewhere along the lines of "iCloud works fine for me as a user, so it's probably just bad developers who can't get it to work, not any issue with Apple."

mikeash 14y ago
Even more than that, iCloud Core Data syncing appears to be so broken that approximately nobody is able to even ship an app that uses it. Thus, users are never exposed to the brokenness because it's so broken you can't give it to them.
rada 14y ago
The rest, like online backup and document syncing and calendars, seems to work most of the time. Those 3 things are broken as well. Lost all my data twice.
- crazygringo 14y ago
  But only most of the time. Last week, my iPhone inexplicably deleted all the pages in my Notes application that I made in February 2013, around 20 of them. Fortunately, they're still there in my synced e-mail account, but there appears to be no way to sync them "back" onto my iPhone. And then last month, syncing my iPhone with iTunes inexplicably deleted the 40GB of my music from my iPhone. I hadn't done anything differently from the hundreds (?) of other times I've synced. I just had to go one-by-one and re-check all the playlists I sync, and wait a few hours for all the music to be re-copied. But still. As easy as Apple products are to use, I'm always afraid something is going to go horribly wrong, in a way I never was with PC's, for example -- they were harder to use, and did less, but you could at least be reasonably sure of what was going on behind the scenes.
asparagui 14y ago

macarthy12 14y ago

Expect Parse to be bought soon..

saurik 14y ago

When ever this topic comes up, including at iPhone conferences I attend, no one seems to have ever heard about Simperium, which pretty much has as their mission statement to solve this problem and seems to have actually done so quite well (yet people are mentioning, quite often, only tangentially-related companies like Dropbox); I believe they are even a Y Combinator funded company... I would be fascinated by an explanation of "what they could be doing differently so that people would use them".

potatolicious 14y ago
> "I would be fascinated by an explanation of "what they could be doing differently so that people would use them"." I've also never heard of them until now. Perhaps they should show up to said conferences, or at least keep tabs on Core Data-related talks at conferences and give the organizations/speakers a heads up.
zalambar 14y ago
I've talked to folks from Simperium before and think that they have a good idea but I remain skeptical of their approach . In particular their Core Data syncing strategy. As I understand it Simperium observes changes to the Core Data models you specify, maps those changes to operation transforms, and distributes the transforms across whichever clients have subscribed to the service. That's great if all your app needs is simple data replication to multiple clients. Unfortunately operational transforms are not necessarily snapshots of database transactions and conflict resolution strategies do not guarantee a valid database. Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients. Conflict resolution is then performed between operations rather than transactions. Simperium can probably take steps to minimize that case but as long as I can construct transactions which cannot be expressed as a single operation this will happen. Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules. For example two clients can each add a child object to a "has one" association. Both "create" operations can be applied without conflict but the parent object no longer passes the application's validation rules. This doesn't make operational transform based synchronization untenable but it does imply a new set of constraints on how applications should model their data in order to successfully apply operations from other clients. That may not be a popular sales pitch but I'm reluctant to feed structured data through a service that doesn't at least discuss the model and its constraints in some detail. Otherwise I fear such a service is another iCloud like trap which will eventually (though perhaps less frequently) hit catastrophic edge cases from which there is little hope of recovery.

nicholassmith 14y ago

There's been quite a few articles from people far smarter than I about it, and most of them agree that whilst doing a server backed database synch service is hard, it shouldn't be this buggy at this stage. It's like Game Center, Apple doesn't bother with any apps that really use it so there's many, many problems reported on a consistent basis, and they don't seem to use iCloud for anything involving Core Data so they're not dog fooding and having engineers swear at code. No swearing means no one is motivated to go back and try improve it.

timjahn 14y ago

I feel like I'm the only person that has had zero trouble with iCloud. My phone backs up to it regularly (without my having to do anything whatsoever) and I've transferred my entire phone settings (and my wife's) more than once to brand new devices via iCloud. In my experience, it truly does "just work".

madeofpalk 14y ago
Right. So as a consumer, it's mostly painless. For developers, it's fundamentally broken as potatolicious describes https://news.ycombinator.com/item?id=5454729 https://news.ycombinator.com/item?id=5454729
- timjahn 14y ago
  Gotcha. I guess I just don't see what all the fuss is since it works flawlessly for me.
  - evan_ 14y ago
    Lots of things fall under the iCloud umbrella. A lot of them DO work. Just as you only think about the parts that work, ios developers think about the parts that do not work- so to you iCloud works and to them it doesn't even though you're talking about different things in the system.
mikeash 14y ago
That's because the parts that are broken are so broken that developers can never even get to the point of shipping software to you that uses them.

bane 14y ago

It might be nice if Apple's legendary attention to detail extended beyond the logo. [1] 1 - http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golden-ratio/ http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golde...

ianstallings 14y ago
And that's the problem in a nutshell. If it's consumer-facing it's years in development and polished. If it's for us lowly developers, well don't hold your breath.
- jfim 14y ago
  The in-joke we had as Mac developers many years ago was that Macs are very user friendly. The problem is that developers aren't users.

robomartin 14y ago

I am one of those developers who don't jump on the bandwagon right away. Experience has taught me to be very cautious. It also comes from doing a ton of work on mission-critical systems where you don't do stuff like install the latest software updates without massive testing on off-line systems. Yes, sometimes I miss out on really neat developments. iCloud is one of those cases where I am glad for being a slow adopter. My mental red flags went up as soon as iCloud came out. Not one of my apps uses it. On the end-user front iCloud is also an absolute mess. I probably have a dozen i-devices on the same account (testing, etc.). Crap appears and disappears from devices seemingly at random. The worst of it was what is happening with my wive's iPhone and mined. We share an iPad at home. Now contacts are getting deleted from her phone and mine at random and so are notes. It's at the point where she is not using notes any more because --her words-- they disappear within a hour or two of writing them. Of course, turning off iCloud is the solution. The problem is that this isn't as simple as throwing the switch. If you turn off iCloud on your device it might actually delete things that it shoved into the iCloud service. And then it deletes the info from your other devices. And it does this in some amazingly weird ways. Without telling you what it is about to delete. For example, I have never explicitly stored contact information on iCloud. Never. I type new or updated contact information into the phone. That's where it belongs. In fact, I never even use my iPad for this. Yet, some contact information for some strange fucking reason is sent over to iCloud. The first time I turned off iCloud piles of contact data evaporated from my phone. I had to turn the damn thing on again to get it back. I haven't had the time to research how to fully disable iCloud on ALL of my devices while, at the same time, keeping or merging the state of my data on that particular device. As a developer I managed to avoid iCloud. As a user I was not that fortunate, I succumbed to the new shinny thing on the shelf. Now I want nothing to do with it. Thank you Apple. Any ideas on how to do this?

imissmyjuno 14y ago
The only thing I can think of is to set up contact, calendar etc. sync to Google (via ActiveSync or otherwise). Calendars won't magically transfer over since they're assigned to a particular calendar, on iCloud in your case, but contacts should get pushed to Google. That'll at least give you a backup of your contacts, and setting up the other devices the same way should sync them all up. Can anyone else chime in? Does this sound reasonable? I've had everything on my iPhone synced up to Google services for about 4 years now and it's never caused any issues.

jimbokun 14y ago

Anyone using TouchDB as an alternative to iCloud core data syncing? https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS Of course, you would need to support some form of CouchDB server for this to work, deal with authentication, etc.

oohaba 14y ago
In my last startup, I used TouchDB and found that 95% of the time, it worked great, and 5% of the time, the app would grind to a screeching halt. Reading documents from the local TouchDB store would block the main thread until the upstream CouchDB server would reply with the document's current revision, even if the local store already has an existing version of the document. Using GCD to wrap around these document transactions was still clunky at best and resulted in a poor overall UX. YMMV, perhaps these issues could have been worked around if I had had a more realistic deadline and stayed in touch with the community. The maintainer, Jens Alfke, is very active.
- jchrisa 14y ago
  Thanks for the heads-up. We are very responsive to issues filed via the Github issue trackers, or brought up on the mailing list. My guess is this has been fixed since then (we've rewritten a lot of that code path), but if it isn't fixed, you can find a link to all of the relevant bug trackers on our Google Group splash page: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase

ianstallings 14y ago

Frustrated with just iCloud? No I'd go further. I'm frustrated with the whole iOS platform. It's like writing an app in the 1990s. Sure it works. But it's painful as hell. So much so that I've decided this latest project on iOS was probably my last unless something big changes. And just for the record I have a few flagship apps in the app store with millions of active users and I've worked quite extensively with the platform. So it wasn't a case of trying it and then giving up in frustration. It's more like watching your peers blow past you because your toolset is from yesterday and their's is from tomorrow.

jawngee 14y ago
And just for the record I have a few flagship apps in the app store with millions of active users Source please. because your toolset is from yesterday and their's is from tomorrow This is why I don't believe your first point without sources to verify. Eclipse+Android SDK is hardly from tomorrow. Windows 8 possibly. What else does that leave? Nada.
- ianstallings 14y ago
  Oh okay so because I think the toolset is crap you want to call me out. No problem. Here's two that have over a million users below. Oprah Magazine (1M+ subscribers): https://itunes.apple.com/us/app/o-oprah-magazine-archive-dec/id573221573?mt=8 https://itunes.apple.com/us/app/o-oprah-magazine-archive-dec... Esquire Magazine (1M+ subscribers): https://itunes.apple.com/us/app/esquire-magazine/id433020707?mt=8 https://itunes.apple.com/us/app/esquire-magazine/id433020707... Those are just two that I have built. I have an enterprise platform that I architected from the ground up that companies like pfizer use for it's whole workforce. I have ones written for Disney, Hearst, GE, MaryKay, Hallmark, Sesame Street, etc, etc. The one I'm building now is ready to scale to ~5M users right out of the gate and I believe we will succeed. Now put your apps up and let me pick through them and tell you why you're wrong because I just don't believe your work is credible.
  - druiid 14y ago
    Hey man, not sure how worried about your info getting out there, but generally when people troll for 'proof' here I ignore it. Essentially it's just one more avenue for people to use against you, especially in regards to linking a name/identity to work and I generally (personally) try to keep them separate. Your choice, just something to think about... also, don't feed the trolls etc ;)

daleharvey 14y ago

I have been surprised at the relative lack of interest from developers about first class syncing support, when mobile blew up I expected a flurry if libraries and tools that I could use to have my app work offline and sync data wherever I am. Sometime last year I gave up waiting and started working on PouchDB (http://pouchdb.com/ http://pouchdb.com/), its based on CouchDB's syncing model (and syncs with CouchDB) and works anywhere that Javascript runs (the browser + node), there is an iOS / OSX equivalent (https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS). PouchDB isnt quite ready for production but its getting close, I would love any feedback on it, although I expect most people commenting on this would be more interested in TouchDB

DeepDuh 14y ago
I'm very interested in this, in fact I'm planning on rolling an iOS based couchDB solution for a company sometime this summer. Could you comment on some key differences between pouchDB and touchDB? Did you also try to simply run ARM compiled couchDB on iOS? If yes, how was the performance there? I've read that initializing takes about 10 seconds - I'd be willing to swallow that if the subsequent interactions are smooth. How about the initial replication of larger databases? Do you roll out an initial version directly in your app or do you have some file based download of a snapshot?
- daleharvey 14y ago
  The key differences between touchDB and pouchDB is that touch is written for ios and pouch is written for web browsers, if you are building for ios and not using phonegap then I suggest using touchdb. It is also the more mature of the 2 but hopefully we arent too far behind with pouch. I used to work for Couchbase on the arm compiled couchdb mobile versions, mainly android but either way I wouldnt hugely recommend using them, they always worked against the grain of the platform, never had great performance and due to those reasons they didnt really get widely adopted and therefore I wouldnt trust their stability across a variety of platforms and use cases. The problems with arm compiled couchdb is the reason TouchDB was made, and similiarly with PouchDB / TouchDB for android and CouchDB I hope we get to the point were there is an out of the box sync solution that works great on every platform, it doesnt feel too far away. For large initial datasets I have tried taking a dump of the database and importing it on first load, it worked however replication has been more than sufficient for my use cases right now. Once pouch has stabilised and released there are a lot of low hanging fruit that can be done to optimise replication (and in particular for first load).

acdha 14y ago

My trust of iCloud disappeared when a restore from backup lost all important data (passwords, Google Authenticator keys, etc.) with no indication. The backup was listed as successful, the restore was listed as successful and yet the only data I needed it to restore was lost. This was also when I learned that Google's process for restoring lost two-factor credentials ultimately ends in an email form which sends to higgins-prod-lost-hard-landing@google.com which been bouncing since 2011. Thank FSM I had some some backup codes printed…

ajanuary 14y ago
Google explicitly opted out of backing up authenticator keys. iCloud would be worse if apps /couldn't/ opt out.
- smackfu 14y ago
  I don't think that's right. Secure things in iOS are in the Keychain, and the Keychain is only backed up if you do an encrypted backup via iTunes. Other backup methods (iCloud and non-encrypted iTunes) just leave it out of the backup. The scary thing is that you hope your apps can handle the case where they have local data but no authenticated user for it. Some of them just treat no authenticated user the same as a first start and reinit the local data.
  - acdha 14y ago
    I think the main problem is that there's zero UI indication that your backup is incomplete and the Apple store staff aren't instructed to ask/communicate that. It'd be a very different story if using iCloud or iTunes without a password triggered a “Because our programmers are lazy, we're not backing up your sensitive data” message.
  - dunham 14y ago
    The backup, encrypted or otherwise, doesn't contain the actual keychain file itself, but rather a plist export of a subset of the keychain. Things that are marked as kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly are never included in this backup file. Google's GTMOAuth library uses this value for its keychain records.

doe88 14y ago

I think the reason developers (myself included) try, and re-try to make it work (Coredata + iCloud), despite all the bad experiences and bad stories is that everybody would like badly that it worked. Because if it worked it would be awesome, when I test it and that it works it's really really nice, but I lost confidence in the overall reliability so in the end I never take the risk to ship it.

alttab 14y ago
That's like staying with an abusive spouse because he bought you a nice dinner once.
- rimantas 14y ago
  Except that fixing abusive spouse is nearly impossible, but fixing buggy service is possible (though it may be hard in this case).
  - gurkendoktor 14y ago
    Not only that - for Game Center it seems that this has actually happened.

JonnieCache 14y ago

Anyone care to speculate as to why apple can't seem to do web services with even a modicum of success? (Remember ping?)

vor_ 14y ago
Apple is strong when they have total control, but web services require dealing with large-scale chaos.
chiph 14y ago
My theory is that the culture of internal secrecy at Apple prevents the teams from collaborating. So you get products that work fine in isolation. Also a factor would be date-driven-development. Steve would want to demo a new offering at WWDC, so everything was driven by making that date. My hope is that now that one person (Jonathan Ive) has been put in charge of product development, things might get better.
jmathai 14y ago
For the same reasons Microsoft hasn't been terribly successful online? It's a different game played by different rules. Interestingly, I'd like to watch and see how Google does moving into the physical goods space.
- skc 14y ago
  Erm, excuse me? For one, Windows Azure is a pretty big deal. Secondly, XBox Live is a pretty big deal. Third, Bing might be struggling to gain traction but it most certainly works. So can you point me to a Microsoft web property or service that is as wonky as iCloud at all?
  - jmathai 14y ago
    I'm not saying they've found zero success. XBox live is probably the biggest. At Microsoft's size they aren't really looking for "pretty big deal" successes. Bing is probably around 15% market share. A home run for most but not (yet) for MS. I can't really comment on Windows Azure. I'll take your word for it but I think Amazon is eating Google and Microsoft's lunch here. This isn't a fight for second place.....

outside1234 14y ago

I don't mean to be flip but how could you think a company that has to take down their store to change the product inventory would be a good bet to build solid web services?

vor_ 14y ago
To my knowledge, that only occurs during a keynote that introduces new products. I suspect it's intended to generate excitement.
smackfu 14y ago
OTOH, the number of leaks via prematurely updated store pages that you see on other manufacturers indicate that it's not as easy as you would think.
- coolsunglasses 14y ago
  It's called staging and scripts.
  - smackfu 14y ago
    I just wonder what the practical effect of Apple's online store being down is... it looks bad, but does it actually cost them any sales?
    - gurkendoktor 14y ago
      When I still had Mac blogs in my RSS reader, the store closing down for a few minutes would actually cause wide coverage with a follow-up post on what how their inventory has changed.

lake_rogue 14y ago

I tried to add iCloud features to an app as part of a contract gig. It was disastrous. The paying customer knew we were capable, but began to wonder what was going on with us -- it was frustrating to have our client lose a bit of respect for us when the cause was the brokenness of iCloud. They, understandably, thought there was no way that something so heavily promoted by Apple could be such a lemon. And in spite of having heard mumblings of iCloud bugs, we wrote it off as amateur iOS developers. We ultimately abandoned iCloud prior to release (going with simple Python based server for data storage) -- reading the other posts I'm glad we didn't try to convince ourselves that the 'almost stable' behavior was just a quirk of our devices having been used in development mode.

gdubs 14y ago

Core Data now provides NSIncremental store, which lets you use any web API as your persistent data store. It's possible to roll your own alternative to iCloud in this way, if you choose.

jemeshsu 14y ago
Core Data + NSIncremental store with a web api backend does not solve the problem of offline sync. It is possible to roll your own, its hard to get it right. It is complicated by iOS restriction of not able to run your own daemon. But then if I have the resource to roll my own then I would not complain about Apple. Dropbox does not come close as alternative. Dropbox as of now is file-based sync. Core Data iCloud sync is trying to sync an always opened SQLite3 database file, they do it through database log files. Possible alternatives are TouchDB, Simperium, Firebase but then you have to change your app from not using Core Data. Or rewrite your app to use file based storage as what 1password did. The key is offline sync. File based cloud sync is solved problem. So maybe the way to go is persistent store of client app has to use files.
- gdubs 14y ago
  Very true. The pain point seems to be largely the database merges; it's possible to roll your own db while using iCloud mainly as a key/value store for synching user preferences and status between devices. This is particularly useful if you support more than just apple devices... Edit: regarding offline sync (which I didn't address) something like AFIncremental store is a good example of how a local persistent store can be maintained in tandem with the online store. (But, as you say, non- trivial and hard to get right.)
gurkendoktor 14y ago
We've tried to use NSIncrementalStore and we found it quite tough. Documentation is sparse. You buy yourself into the SQL-ish interface of NSFetchRequest throughout the app. There are fun bugs to discover like this one: https://github.com/stackmob/stackmob-ios-sdk/blob/master/CoreData/Classes/SMIncrementalStore.m#L299 https://github.com/stackmob/stackmob-ios-sdk/blob/master/Cor... And once you discover that you can't fix all the problems that Apple is struggling with, you have dug yourself into a VERY deep hole :)

mayop100 14y ago

(Shameless plug) Firebase is an alternative to iCloud for many apps. It's built as a database, rather than a file store, so it's ideal for storing structured data. Conflict resolution is something we've been thinking hard about from day 1, and we think we have a pretty solid story [1]. We launched native iOS support a few weeks ago [2]. You can also access your data from JavaScript or from a REST API. Android and other platforms are in the works. We're a platform-independent service, and since you (the developer) is paying for the storage, we have the right incentives to give you maximum access to your data (unlike iCloud), and a good developer experience. We've also put a ton of work into making it easy to learn and easy to use. See, for example, our quick tutorial [3]. If you've used Firebase as a substitute for iCloud, we'd appreciate your thoughts in the comments! 1. https://www.firebase.com/docs/transactions.html https://www.firebase.com/docs/transactions.html 2. https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sdk.html https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sd... 3. https://www.firebase.com/tutorial/ https://www.firebase.com/tutorial/

ok_craig 14y ago
Hey, I've been using Firebase for a web client I've been working on for a bit and I like it a lot! Would you consider updating your transactions page with an example of a text change? Such as adding a word in the middle of a paragraph. I'm not quite sure how that would work.
- mayop100 14y ago
  Collaborative text editing generally requires a bit more than a simple transaction to work well (Operational Transforms are generally involved). You can use transactions as a basis for this though. We've got some examples coming out soon to show how to to do this. Stay tuned...

visarga 14y ago

As an Apple user, I have often consulted discussions.apple.com to find fixes for problems. A lot of times there were thousand post long threads with no official answer. It is a wasteland. I know they don't answer questions, but they could make an exception for the most important common issues. It's as if they put their fingers in their ears and sing "la la la" while we try to communicate bugs. How can the richest computing company not answer questions put by thousands of users who have banged their head in the same bug? It's insulting to have this circus happening on their doorstop.

robomartin 14y ago

I went to disabled iCloud on one of my Macs and I got this warning: "If you turn off Documents and Data, all documents stored in iCloud will be deleted from this Mac" Let's get past the jaw-to-the-floor, how-dare-you, !!!$$%#$## moment. They are morons and don't respect your data. So, how do you figure out just what is in iCloud? I don't see an easy iCloud viewing option in Finder. Doing some digging this is what I found: - Open Finder - Fire-up "Go To Tolder" - Enter ~/Library/ - Go into "Mobile Documents" That's what's on iCloud. You have to manually dig through it all and figure out what's there. If you delete anything there it will be deleted from all of your sync'ed devices, including your local Mac. It will also end-up in the trash folder. You could copy it all to a USB drive, memory stick, or, better yet, Dropbox. Then you can completely disable iCloud knowing your data is safe and iCloud will never cause you further grief.

grandinj 14y ago
You are not parsing the message correctly. It says nothing about deleting data from your other devices.
- IheartApplesDix 14y ago
  Yeah, that's just a hidden surprise for you to discover next time you sync, as I unfortunately discovered when it deleted my entire schedule from a corporate Exchange Account. So not only does it apply to your iDevice, it also applies to any accounts that you've linked to the device and conform to the latest generation of CYA extensions for the Enterprise.

Philadelphia 14y ago

Tuesday's article on The Verge [1] was a lot clearer about the distinction between the various components that fall under the iCloud brand and what the problems are with the Core Data synchronization piece. [1]http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-just-work http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-...

shurcooL 14y ago

The document storage of iCloud is broken from a design viewpoint: I don't want to store/find things based on app, but rather by date/time created, content type, name, etc. If I have many apps that do the same thing, I'd have to go through each one to remember where I saved something. No, just no.