Frustrated with iCloud, Apple’s developer community speaks up

http://arstechnica.com/apple/2013/03/frustrated-with-icloud-apples-developer-community-speaks-up-en-masse/

by jfcouture • 13 years ago

220 186 13 years ago

Sounds like an opportunity for Dropbox. Go Dropbox!

pilif• 13 years 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• 13 years 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 (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.

mikeash3• 13 years 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.

saosebastiao5• 13 years 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.

larrik2• 13 years 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?

saosebastiao5• 13 years 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.

Terretta6• 13 years ago

If trying to juggle more than one apple ID in the same storefront is breaking the camel's back, she's in for a world of soul crushing disappointment with any less UX polished product -- which is pretty much all the rest of them.

saosebastiao5• 13 years ago

With my much less polished Android UI, at least I can use my phone.

joenathan3• 13 years ago

You should qualify that statement, while no system is perfect, Apple seems to be the only one with a fundamentally broken cloud model.

hp50g• 13 years 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.

potatolicious6• 13 years 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.

aidos2• 13 years 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.

blub• 13 years ago

You mean all iPhoto photos, al photos in the photos folder on the mac or something else?

crag2• 13 years 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."

Let me tell you it's not exactly happy land for us consumers either. Apple's "cloud" is a mess. And don't even get me going about the "new" and "improved" iTunes. Frankly I pity developers, cause Apple's mess is giving them a bad name.

I can't think of 1 icloud enabled app (on Windows or Mac) that I've used that worked well. The apps themselves are fine, it's the cloud integration that fails. I mean just look at Apple's own forums.

After 10 years as a Mac user, I'm actually considering moving back to Windows. I'm just over it. It's like every new OS (or app) something goes missing. I'm tired of spending hours searching for replacements for features Apple has removed. And I'm tired of being force-fed services and apps (that Apple's PR states is "gonna change my life") still in beta.

Ok ok //end rant

kbatten• 13 years ago

Were you using timemachine, and if so did the photographs get removed from there as well? No matter what, that sounds like an incredibly poor user experience.

seivan5• 13 years ago

I just hope people can differentiate between Core Data and iCloud from both your comment and the article.Core Data isn't broken. It might be somewhat magical, but it's not broken.

pifflesnort7• 13 years ago

I think there's a good argument for it being broken:

1) Core Data objects are not NSObject objects. You can't treat them remotely like normal objects: https://developer.apple.com/library/mac/documentation/Cocoa/...

2) Core Data requires making your model mutable, and spreading dependencies on Core Data's abnormal objects throughout your entire code base.

3) Since the abnormal objects are spread throughout your code, and they're tied to non-thread-safe NSManagedObjectContexts, concurrency becomes rather difficult. You have to deal with multiple managed object contexts becoming out-of-sync across threads. Most people just give up and perform expensive operations like -save on the main thread.

4) Core Data merges the concepts of your on-disk model with your in-memory model, despite the fact that the two problem domains have very different requirements in terms of API design, data longevity, relational design, etc. This leads to code that is neither a clean in-memory model, nor a clean on-disk model.

5) Since Core Data objects are abnormal objects, one must produce a considerable amount of boilerplate just to define new model objects. What time you save upfront using a GUI to design your original model, you spend 10-fold in maintaining the code to support it, and in being handicapped by the contraints Core Data places on your code.

6) NSPredicate is awful. It's a brain-dead query language that often make it impossible to cleanly normalize your data store. Aggregate operations are expensive and often require O(n) cost, the query language is poorly documented and poorly specified.

Core Data is a very poorly fit abstraction, but it probably works well enough for simple use-cases. Once you move into concurrency, complex/large models, aggregate operations/projections across your data, or have to deal with it failing, it falls over.

After using it myself for a large project and struggling with all of these issues (and more), and watching another team do the same on their own project, I'd never make use of it again. SQL (via sqlite) is a far better abstraction for managing on-disk data, especially when doing so in a highly concurrent application where one can rely on SQLite's transaction support.

raverbashing5• 13 years ago

From what I've heard iCloud is primarily Java (and some C++)

Not that I'm blaming the technology specifically, but my impression is that Apple is being naive.

Of course you can build with Java, but if you knew better and have the resources Apple has, you would be aiming somewhere else. Google can do this because the infrastructure is there.

Not in the case of Apple

And as this shows, the concept itself of how the service works is broken. This is smelling of 'walled garden fundamentalism' + 'technical ineptitude'

dpratt• 13 years ago

You realize that a plurality of Google's backend is built in Java, right?

I know it's fashionable to hate on Java, for a lot of good reasons, but I think it's naive to dismiss the power of the platform itself.

We may all have (completely valid) complaints about the outdated and verbose syntax of the language, but the actual JVM itself is fantastic. There are more scalable, fault-tolerant, high performance Java systems out there than the rest of the implementations on all other platforms, combined.

kybernetyk• 13 years ago

After seeing the fate of mac.com and me.com I didn't even consider using iCloud for 'cloud storage'/sync for our Mac app. (We went with Dropbox).

Apple has a long story of half-finished features they try to force onto developers and users. And if that doesn't work the technology gets killed off.

The only downside of not using shiny but questionable new features is that your app won't get featured in the App Store.

potatolicious6• 13 years ago

> "The only downside of not using shiny but questionable new features is that your app won't get featured in the App Store."

This is a pretty huge downside. The App Store is a huge mess - there is effectively no web frontend for it, it's tied deeply into a desktop application, and it's obtuse. This makes marketing nigh impossible and results in Apple having an enormous, and disproportionate, ability to pick winners and losers.

Being featured is a Big Deal(tm).

lake_rogue3• 13 years ago

Perhaps rather than killing the technology off this time they tried to get rid of the person in charge of the technology.

Of course, if this isn't fixed soon...

pifflesnort7• 13 years ago

Core Data is barely functional locally, requiring an enormous amount of invasive runtime hooks to create the appearance of a "transparent" (it's anything but) object store on top of Objective-C objects.

The fact that anyone, anywhere (including Apple), actually expected Core Data to work as a distributed object store is totally beyond my comprehension.

pooriaazimi• 13 years ago

vor_: unfortunately, you're hellbanned.

> I have no experience with iCloud, but I'm pleased with Core Data for managing a persistent object graph. It automatically handles version migrations, undo, and faulting, and some interfaces can be populating with almost no code via bindings. I'm happy with it. Still, I'll be very interested to watch the Core Data presentations at WWDC.

seivan5• 13 years ago

Never had any issues. I guess what I build is not complex enough.

lobster_johnson2• 13 years ago

Really? Not had any problems with Core Data on top of the default SQLite store (not iCloud, mind you). The interface is very reasonable, since it doesn't pretend to be transparent, and in my experience it works as documented. Care to go into detail?

mdellabitta• 13 years ago

I think Core Data did that back when it was EOF: http://en.wikipedia.org/wiki/Enterprise_Objects_Framework

Aloisius• 13 years ago

Having dug through iCloud's underlying structure, I can tell you what they're doing is very close to what Microsoft's Sync Framework does - right down to the naming of some of the columns in the underlying database.

In fact, if I didn't know better, I would think it was a peer implementation of the Sync Framework (which considering the iCloud server is hosted on Microsoft Azure which has native support for Sync Framework built into hosted SQL Server, isn't too far fetched).

The difference is that Microsoft's Sync Framework seems to work.

joelreymont• 13 years ago

How do you know that the iCloud server is hosted on Microsoft Azure?

gte910h• 13 years ago

iCloud + CoreData = Pain and Tears and Blood

I just change the topic to a different backing store when the client wants "cloud persistance" and says "iCloud" without understanding the pain they're asking for.

I agree, completely non-functional

sampsonjs• 13 years ago

That's funny, I had no clue how it's supposed to work as a user either. Or at least not in the 10 minutes I was willing to give it. The Steve Jobs' Dropbox story is even more hilarious in retrospect. Hilarious at the time too, because Jobs had no intention of providing his product(iCloud) to the philistines who use Windows.

stcredzero• 13 years ago

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

"Distributed Databases are Hard" has been a mantra for many decades, probably getting close to a half century. We have known, basically forever, that this is hard on a fundamental level. (Google "Two Generals" problem.)

> 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

This is called a variety of things. One of the terms is "transactional replication." It can get very very sticky when there is more than one party originating write transactions, though.

ericcholis• 13 years 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.

potatolicious6• 13 years 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_rogue3• 13 years 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).

zoul4• 13 years 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• 13 years 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/

aidos2• 13 years ago

I can vouch for AeroFS. We're using it internally for sharing large documents around and it make it really painless.

smackfu7• 13 years ago

I'm not too familiar with Parse, but Dropbox is not solving the same problem as the feature of iCloud that developers are complaining about. Whole file syncing is comparatively easy from the server side. If there a conflict between the server-side file and the client-side file, the app has to work out how to handle it. Core Data (basically a local database) syncing tries to handle conflict resolution automatically, since it has knowledge of the data structures. That's tricky, and that's the part that doesn't work well.

I haven't seen many complaints about iCloud's file syncing features, which are what Dropbox is the direct competitor to.

smackfu7• 13 years 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."

mikeash3• 13 years 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• 13 years 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• 13 years 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• 13 years ago

Loosely, there are two iClouds, one for Apple apps and another that is 3rd-party developer facing. This article sums it up fairly well: http://thenextweb.com/apple/2013/03/27/which-icloud-actually...

macarthy12• 13 years ago

Expect Parse to be bought soon..

saurik2• 13 years 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".

potatolicious6• 13 years 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• 13 years 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.

saurik2• 13 years ago

> Saving a Core Data transaction on one client may generate multiple operations which are replayed interleaved with operations from other clients.

Interesting; I've implemented OT myself, and this is not a fundamental failing of the concept: in fact, even fairly simple implementations like ShareJS do not succumb to this fate (the easy way to model it is that you end up with larger macro-operations that are capable of transforming eachother's components, while still having to be played back one macro-op at a time; you also just stop playback while a transaction is in progress). I am totally willing to believe that Simperium's implementation (which I believe thinks about the separate objects as separately transformable documents) may have issues here, though.

> Worse a client can apply operations without conflicts only to find that its models no longer pass its own validation rules.

This is certainly true, but is endemic to the entire idea of offline synchronization and has nothing to do with operational transforms: you simply can't do this without accepting "a new set of constraints on how applications should model their data in order to successfully apply operations from other clients"; this is clear from CAP (as rather than become unavailable when the network is offline/partitioned, we have to lose some consistency).

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

This is totally fair. (I can entirely appreciate it as well, as it reminds me of all of my complaints regarding how seldom you would hear companies like Parse and StackMob attempt to drill in how important security should be while using their services, at best leaving it as an appendix in their documentation. I believe they have at least been getting somewhat better about this since my talk on the subject at last year's 360|iDev.)

nicholassmith• 13 years 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.

timjahn2• 13 years 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• 13 years 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

timjahn2• 13 years ago

Gotcha. I guess I just don't see what all the fuss is since it works flawlessly for me.

mikeash3• 13 years 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• 13 years 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-golde...

ianstallings8• 13 years 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• 13 years 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.

robomartin3• 13 years 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?

imissmyjuno3• 13 years 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.

robomartin3• 13 years ago

I might try that.

Frankly, I'm just thinking of writing an app to export everything to a MySQL database on one of my servers and do my own version controlled backup. Not sure Apple would ever approve such an app, but I can certainly write it and use it internally.

A long time ago I learned there is nothing more important than ensuring your data is safe. I learned this the hard way in college when a drive failure evaporated six months of hard coding...and I had zero backups. You don't do something like that twice.

With iCloud Apple has given us a tool that is so badly done it has the potential to evaporate our data. Amazing.

There's a reason Microsoft code runs the IT infrastructures of small, medium and massive corporations. They get it. They don't engage in making petulant adolescent choices for their users. Crap like removing "Save As" from applications and forcing duplication --and even storage-- of files on iCloud from your desktop.

I've been using Apple products since the first Mac. I could not see any way to trust Apple with enterprise data. No way.

I really don't know what Apple is about any more.

jimbokun• 13 years ago

Anyone using TouchDB as an alternative to iCloud core data syncing?

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• 13 years 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.

jchrisa2• 13 years 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

ianstallings8• 13 years 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.

zoul4• 13 years ago

This sounds unfair. I have been developing for the platform right from the start and I am very happy about the whole toolchain. My only real gripes are with the review process, nothing else. (I have never used iCloud as a developer, so I can’t comment on that.)

JonnieCache2• 13 years ago

What is this toolset of tomorrow your peers are using to blow past you, if you don't mind me asking?

ianstallings8• 13 years ago

I mainly mean my web-developer peers. Their toolsets are moving so rapidly that I see them surpassing us in the next 2-3 years unless we make some huge improvements. Just my opinion.

potatolicious6• 13 years ago

I'm not OP, but one key complaint I have is that there isn't much in the way of testing. Unit tests are somewhat well-developed, integration testing is a complete mess.

Much of the iOS community still creates software by the seat-of-your-pants model (i.e., write code, boot it up, does it look like it works? ship it). Engineering rigor is still a concept relatively foreign to iOS, and it shows. Apple has little-to-no built in support for anything that smells like TDD.

When you're talking to your server-side peers who have good test coverage, good regression testing, and more generally just sound engineering processes, you can't help but get bit jealous.

coldtea2• 13 years ago

>It's more like watching your peers blow past you because your toolset is from yesterday and their's is from tomorrow.

And what would that "toolset of tomorrow" be? Surely not Android's joke offerings, or Windows 8 same old...

ianstallings8• 13 years ago

HTML5 and all the surrounding technology is very exciting IMHO. They have the best tools and are quicker to adapt new techniques because of they get to work with a net (the fact that they can rollback quickly if needed). I get a little jealous when I see how quickly they can get something up and running that would take me a few days.

jawngee• 13 years 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.

ianstallings8• 13 years 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...

Esquire Magazine (1M+ subscribers): 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.

qdog• 13 years ago

Maybe he means Ubuntu for mobile? I kid, I kid!

Having started working on Android recently, if Android is tomorrow, the future sure is dystopian.

tvon• 13 years ago

Well, I don't really agree, but I will say that the iOS testing world has a lot of catch-up to do. Ruby developers (as an example) have much, much, much better testing tools. There is no doubt about that. The hoops you have to jump through to create acceptance tests are quite annoying, especially when you can't even test UIAlertViews, or basic things like Airplane Mode...

stevenwei2• 13 years ago

I don't think that's a fair comparison. Testing GUI code has always been a lot trickier than testing backend code, and iOS apps tend to be GUI-oriented while Ruby projects tend to be backend-oriented.

That's not to say that the iOS testing tools are great, but I've never had a particularly pleasant time testing GUI code on any platform.

gurkendoktor6• 13 years ago

Why not jump into RubyMotion and use these testing tools?

And Apple's WWDC session about acceptance tests using Instruments UI Automation specifically handles UIAlertView.

I think the problem is that iOS apps are getting dumber and dumber while their UI bling gets more complicated/asynchronous. The value of tests is too low for The One Widely Accepted Testing Framework to emerge.

daleharvey2• 13 years 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/), 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).

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

DeepDuh2• 13 years 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?

daleharvey2• 13 years 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).

acdha2• 13 years 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• 13 years ago

Google explicitly opted out of backing up authenticator keys.

iCloud would be worse if apps /couldn't/ opt out.

smackfu7• 13 years 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.

doe88• 13 years 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• 13 years ago

That's like staying with an abusive spouse because he bought you a nice dinner once.

rimantas• 13 years ago

Except that fixing abusive spouse is nearly impossible, but fixing buggy service is possible (though it may be hard in this case).

JonnieCache2• 13 years ago

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

chiph• 13 years 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.

jmathai3• 13 years 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.

skc2• 13 years 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?

outside1234• 13 years 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?

smackfu7• 13 years 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• 13 years ago

It's called staging and scripts.

lake_rogue3• 13 years 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.

gdubs2• 13 years 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• 13 years 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.

gdubs2• 13 years 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.)

gurkendoktor6• 13 years 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/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 :)

mayop1002• 13 years 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

2. https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sd...

3. https://www.firebase.com/tutorial/

ok_craig• 13 years 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.

mayop1002• 13 years 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• 13 years 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.

robomartin3• 13 years 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• 13 years ago

You are not parsing the message correctly. It says nothing about deleting data from your other devices.

IheartApplesDix• 13 years 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• 13 years 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-...

shurcooL• 13 years 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.

Frustrated with iCloud, Apple’s developer community speaks up

Related Stories