
Frustrated with iCloud, Apple’s developer community speaks up - jfcouture
http://arstechnica.com/apple/2013/03/frustrated-with-icloud-apples-developer-community-speaks-up-en-masse/
======
potatolicious
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_.

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

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

~~~
potatolicious
I work on a fairly complex Core Data implementation in a heavily multi-
threaded app.

It requires a lot of discipline, and we rely on a lot of learning-through-pain
since the documentation beyond the most basic implementation is mostly non-
existent.

Core Data is pretty simple if you do all of your work on the main thread, but
then your'e also blocking your main execution loop for operations that can
take a long time. A large save will _easily_ reach into >200ms land on an iOS
device, and your app will feel like crap.

Thread safety in NSManagedObjectContexts is somewhat documented, but has a lot
of quirkiness to it. There is some general knowledge around what is and isn't
thread-safe, but almost nothing surrounding _how_ to build a multithreaded app
and not be murdered by Core Data. Much of this is trial and error and
observing what open source projects are doing.

Once you settle into a decent threading scheme that won't kill you (probably
with multiple NSManagedObjectContexts) you have to worry about communicating
changes across multiple contexts - then you delve into parent-child contexts,
where the document gets even more bare. Then you get into propagation delays
when crossing context boundaries.

Keeping your code clean through all of this is also a challenge. There are
also runtime issues - our implementation in Core Data experiences unbounded
growth in memory usage on iOS5, but not in iOS6, forcing us to manually
mitigate memory use (which Core Data is _supposed_ to take care of), creating
even more thread-safety concerns.

All in all, it's a pain, but it's also the only realistic object store/graph
on the platform.

~~~
gurkendoktor
> A large save will easily reach into >200ms land on an iOS device, and your
> app will feel like crap.

Can you give an order of magnitude at this would happen? I usually only have
50-200 entities in my database in total, saving maybe half of them at the same
time. Yet libraries like RestKit insist on a two-context setup to avoid the
saving delay you mention. I'm not sure if I should fight the libraries and go
back to a single-threaded setup (that I understand) or just go with the
parent/child context flow.

~~~
delackner
Fetch and save operations get pretty slow with even just 10,000 entities (if
you touch all those entities). It gets a little better if you pre-fetch all
the entities rather than one at a time, but the save is still very slow.
Breaking that out into a backround thread is feasible, but as the previous
commenter mentions, then you risk momentary divergence between the UI and the
backend.

~~~
seivan
Index properly. Save in a queue.

~~~
delackner
This is fetching every entity by its indexed key. My understanding of saving
in a background queue is that during that 1-2 seconds, the ui will still be
using the pre-modification data set, so very briefly the ui may appear
incorrect, no? Not a huge deal, but if the ui will be wrong, then for our app
that would still force us to pause the ui until the save finishes.

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

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

~~~
imissmyjuno
That's the downside of keeping your data in a service. This is a conceptual
problem due to the lack of agreed upon data protocols. Google Reader has
highlighted the issue well, and more services are to follow I'm sure. This is
an issue that never existed for files since they by definition conform to a
specific format.

RSS and CalDAV are examples of web data formats which do work. I'd like to see
more formats like that, or perhaps an ability to fall back to export data as
files from web services.

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

~~~
rada
_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
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.

------
mayop100
(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...](https://www.firebase.com/blog/2013-03-20-new-firebase-ios-sdk.html)

3\. <https://www.firebase.com/tutorial/>

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

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

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

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

~~~
gurkendoktor
I was a test zealot all my academic life (it's perfect for building
compilers). But in my experience as an iOS contractor, most apps are polished
Thin Clients for a remote backend. Which incidentally is the only thing that
Objective C is really awesome for. As soon as I write _any_ interesting logic,
it is actually a _bug_ , because it should be pushed into the backend. After
all, it must behave the same on Android and on the web client.

That leaves us with bug classes like: multithreaded Core Data misuse, "UI can
be broken by using three fingers exactly like this", popping a navigation
controller as a reaction to a network operation while it is currently being
pushed (based on network latency), networking code that does not properly
handle session extensions while multiple concurrent threads are in progress,
labels use the wrong font, code uses UIKit on the main thread, ...

Good luck writing tests for that _and_ being more cost-effective than code
reviews & manual testing.

------
robomartin
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
You are not parsing the message correctly. It says nothing about deleting data
from your other devices.

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

------
bane
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...](http://www.tuaw.com/2011/06/24/the-icloud-logo-and-the-golden-
ratio/)

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

------
acdha
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
Google explicitly opted out of backing up authenticator keys.

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

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

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

~~~
smackfu
Interesting.

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

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

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

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

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

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

~~~
skc
Apologies, I was assuming we were talking about the technical chops of the two
companies when it comes to building web scale services.

~~~
jmathai
Apologies not needed. That raises a question though.

I was implying that Apple and Microsoft don't do as well building web
services. I wouldn't argue that Azure can't scale but the overall approach
seems to be a little bit "unfinished".

Let me explain, the only true cloud computing environment that really solves
90% of any companies needs is AWS. Somehow Amazon understands what the
developer community needs. I'm really perplexed by Google not getting this
right.

Apple doesn't and I don't believe Microsoft does either.

I don't think this is about technical chops. It's something else that I can't
put my finger on.

Similar to how I don't understand how Amazon crushed Best Buy so quickly.

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

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

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

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

~~~
Terretta
Someone can't use an iPhone because they're juggling Apple IDs?

First, it supports multiple IDs, the limit is one ID per storefront or sync.

Second, if this isn't about multiple IDs but about multiple addresses for a
single ID, and if you don't like it supporting the old addresses, go to
<http://appleid.apple.com> and manage them. You can update, edit, and remove
old email addresses, decide what your primary one is, etc. I find it helpful
to ensure 100% of all services across all devices are using the same exact ID
aka email address; one way to enforce this is to be sure your appleID account
only has one listed.

On the other hand, if she has inadvertently created multiple IDs over the
years, she needs to either settle on one ID per service (my wife has one for
music, one for apps, one for iCloud), or she needs to ditch the extra ones and
standardize on a single one.

To tell if they're the same or multiple accounts, again, go to
<http://appleid.apple.com/> and log in with the one you think is the master,
be sure the others are listed. If not, they're separate IDs.

None of this stops her from using her phone. Conveniently, all these phones
fine with or without the ID.

FWIW, on my Galaxy Nexus I find managing multiple Google Accounts and cloud
data sync more precarious. Sure, there's an easy radio button to pick accounts
in the Google Play store, for example, but once I made sure I'm using the same
ID across devices I've never had a bookmarks, contacts, calendar, or messages
sync issue with iCloud, while I am having to go in and reset sync settings for
bookmarks, contacts, etc., every couple weeks on Jellybean. And I usually
don't know the sync is broken again until I notice something's missing, check
sync settings, and see the broken sync alert.

~~~
saosebastiao
She doesn't use multiple IDs. She only uses one. But in order to make things
work, she has tried everything in the book, including trying to sign into her
old account when this stupid bug pops up.

And no, she can't use the phone as it was advertised. She has multiple apps
that use iCloud for storage, and every time this happens, she just stops using
the apps, as it can literally take hours of trying before she can successfully
sign into iCloud.

~~~
Terretta
> _She doesn't use multiple IDs. But... trying to sign into her old
> account..._

Sounds like more than one. She needs to quit using the phone with "old" IDs,
she's confusing herself and the device.

Get logged into <https://appleid.apple.com/> and get it sorted out there. If
you can't log into that, get on phone with Apple support until you can. As
long as you didn't two step auth it, the phone support can and will help.

I'm not trying to debate, btw, I'm trying to legitimately help. Like most of
us here, we end up being the support person for our family's devices, and I
have seen people get themselves in a jam w/ the ID before. Clearly defining
the Primary Apple ID won't be resolved until it's clearly resolved in the web
interface.

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

~~~
DeepDuh
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
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).

~~~
jchrisa
The TouchDB project was started at Couchbase, and since then we have ramped up
our investment in mobile sync. The key thing about this project is that its
designed to be tiny and boot fast. So it is written in Objective-C (and Java
for Android.)

We are renaming TouchDB to Couchbase Lite (still 100% open source), and have a
bunch more tools for it:

Couchbase Lite container for PhoneGap:
<https://github.com/couchbaselabs/LiteGap>

Couchbase Lite for iOS: <https://github.com/couchbase/couchbase-lite-ios>

Community mailing list: <https://groups.google.com/forum/#!forum/mobile-
couchbase>

We are 100% serious about building the best damn database for mobile. Bonus
points that it will seamlessly interact with other projects like PouchDB and
friends via the sync protocol originally written as part of Apache CouchDB.

------
outside1234
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?

~~~
smackfu
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
It's called staging and scripts.

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

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

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

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

------
Philadelphia
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-...](http://www.theverge.com/2013/3/26/4148628/why-doesnt-icloud-just-
work)

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

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

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

------
doe88
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
That's like staying with an abusive spouse because he bought you a nice dinner
once.

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

~~~
gurkendoktor
Not only that - for Game Center it seems that this has actually happened.

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

------
macarthy12
Expect Parse to be bought soon..

------
savrajsingh
Sounds like an opportunity for Dropbox. Go Dropbox!

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

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

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

