Why all my iOS Apps are on hold - or iCloud sucks Part II
createlivelove.com
createlivelove.com
Edit: I found this quite recent post with similar issues http://www.jumsoft.com/2013/01/response-to-sync-issues/
The real problem here is the combination of iCloud and Core Data (for non-Apple folks, the built-in persistence/object model framework).
In a somewhat simplified way, Core Data is a data store most commonly backed by SQLite. It's used everywhere from your mail app to the Facebook app. It's handy and convenient when it isn't trying to kill you - it's one of the more complex frameworks that Apple ships, and the documentation is extremely poor for it. It also doesn't help that there is a lot of quirky behavior that's more or less tribal knowledge to long-time Apple devs and WWDC attendees, and is has enough concurrency gotchas to fill a container ship.
So, Core Data is not the simplest piece of code to work with from the get-go, and then you pile iCloud on top.
iCloud is conceptually pretty simple - there's a directory on your file system that is replicated to Apple's servers, and back down to each one of your devices. When files change the OS sends notifications to your app informing you of such. If you're using iCloud as a distributed file system (a la Dropbox), it's easy to integrate.
The trouble with this model is that Core Data stores can be in fact quite large. If you have a 30MB database of, say, recipes on your disk, you really don't want to resend the whole thing every time your user alters a row. Apple special-cases Core Data stores in iCloud by sending only deltas, but the implementation is utterly broken:
- There is no baseline state(s). The database is literally the playback of every delta, with no canonical snapshots. Ever.
- iCloud is really bad at sequencing the deltas, especially if (somewhat) concurrent changes are happening. Core Data is also terrifyingly bad at conflict resolution when deltas from different devices don't line up.
- The above points means that it's trivially easy to break your entire database, as your deltas no longer play back to a sane database file. When this occurs there is no way to roll back your database, since there is no concept of a snapshot or last known good state.
- This is compounded by some really horrible API design on Apple's part. When your iCloud database becomes corrupt it fails silently, with absolutely no API that allows one to determine said broken state. Your app literally stops working with none of the OS making a single peep, and no way for you to proactively check your database's state. iCloud seems to print some debug things into your console indicating this failure, but neither your app nor your users have access to it. This manifests in your app (and in tech support requests) as "iCloud just stopped syncing" - your device stops transmitting deltas and simply works off of the last locally-cached good state, all without telling the dev or the user.
- This is further compounded by the fact that the entirety of Core Data+iCloud was rushed out the door. Documentation was non-existent even up to the day the new version of iOS went out to the public. There was literally only one source of information: a thread on the Apple dev forums that Apple engineers would sometimes pop into.
- This is further compounded by the fact that even the Apple engineers themselves seemed to have no idea how to implement an app with iCloud + Core Data. The example code (provided deep, deep within aforementioned thread) made 90 degree turns seemingly every few days. The same sample would have dramatically changing implementations from week to week. The Apple engineers in the thread seemed as mystified as the people trying to use the framework.
- The poor documentation and poor state of sample code, as well as what is IMO a fundamentally broken architecture means that iCloud + Core Data remains a complete nightmare to this day. I think the poor architecture is really the core of this here - while Apple could have provided better docs and better support, I believe the fundamental architecture choices made here means Core Data + iCloud would never have been workable.
- The icing on top of the cake was an extremely egregious bug that existed at launch (unsure now, you couldn't pay me enough money to work with that API ever again). "Okay, so our deltas are completely fucked" you say, "Why don't we just delete the app's entire iCloud bucket and start over?"
A jolly good idea until you realize that a bug in iOS/iCloud means that when you delete an app's iCloud storage "bin", it cannot be recreated by that app, ever again.
Compare this to something like google docs, which has ways of handling reverts and simultaneous editing.
That said, I would not use it in conjunction with iCloud. That's where all the trouble is.
Cocoa Touch + Obj-C is a very nice platform in a lot of ways but I'm losing faith in Apple's software architects. Contrast this with Android and even though I think Java is a poor choice for mobile development their engineering teams really seem to know what they're doing.
That's a mistake at a level above engineers and software architects (or at least a mistake so far - if, hypothetically, Intel managed to crack their mobile CPU problem the choice of Java would turn out to be very smart). This is the dual of Apple's situation with iCloud. The strategic choice to start building out cloud services to support their ecosystem is clearly the right one, it is the implementation that has missed the mark (so far).
This is why writing something like a Twitter client is actually much easier in Android but doing something really interesting like realtime multimedia or highly responsive, complex UIs is difficult to the point of impossible in some cases.
I think Android and WP's XML-based structural layouts are far, far easier to work with, understand, modularize, and reuse.
Autolayout, on the other hand, has a more general approach of establishing relationships between properties of views. Baseline alignment then just falls out: make view1.baseline = view2.baseline, or view1.top = view2.top for top alignment if you prefer. Equal widths fall out too: view1.width = view2.width. If you want a vertical stack you can write view1.bottom = view2.top. If you want a fixed aspect ratio (say, 4/3), you can write view1.width = view1.height * 4/3.
The result is that it's possible to directly express complex layout ideas. For example, "make three buttons baseline aligned, 10 pixels apart, all of them equal width, none of them clipping their labels. If they cannot fit, then in turn: shrink the padding down to 4 pixels, don't require them to be equal width, truncate the first button's label, or lastly then grow the window / make the view scrollable, until they fit."
That's an unrealistically elaborate example, but with autolayout it can be done entirely in IB, without any code at all. I am guessing with Android it would take a fair amount of manual work.
So my view from a distance is that the autolayout approach is more general and elegant, while the Android approach may handle simple cases easily, but is more ad-hoc and random.
It's true that AutoLayout's systems of interdependent linear equations are strictly more powerful than Android's structural layouts but they're a far more awkward solution to the vast majority of common UI layout problems. In practice Android UIs are far, far easier to write and maintain. Debugging the kind of complex AutoLayout schemes you describe can quickly become a nightmare. The structural approach taken by Android and WP is far more natural for the kinds of UIs you actually find in the field.
Also, Android's CSS-like style system makes it far easier to define app-wide constants like grid spacing, margins, button padding etc and to change them in one place.
For example, Skype: http://i.imgur.com/4XwVmjy.jpg
Responsive design is one of Android's most fundamental design principles. It just took a while (and a few million tablet sales) for developers to take the platform seriously.
Most new android apps are responsive these days. And those companies that maintain their existing apps are busy adding big screen support.
I'm glad to hear that companies are busy adding big screen support, though that support is arguably coming late. The main point is that an Android app's interface could be stretched across anything, and this has certainly been a design obstacle in the past.
I just posted two screenshots showing otherwise.
> Android's fragment API makes it a lot easier than he iPad to adapt to a proper tablet UI if you want.
And this is just ridiculous. Regardless of whether you prefer iPads or Androids, iPads are most decidedly easier to design tablet UIs for because there are so few screen sizes.
I've built complex tablet apps with both SDKs. Have you?
Given how much work they spent trying to reinvent iCloud you would think they would have made it more seamless for developers. Apple really needs to take some of the open source CoreData wrappers (which make life so much easier) and add them to the framework.
The biggest joke is that WebObjects EOF on which CoreData is based used to be really simple. Not sure what happened.
And I my suggestion for your issue (which I have seen in the past but definitely isn't consistent) is to try restarting Xcode and getting rid of preferences.
If iCloud was hitting on all cylinders, then Apple could kill MS Surface by having seamless sync between laptops and tablets. Instead of a chunky tablet/laptop that's mediocre at being both, you can have a fabulous tablet and a great ultra-lightweight laptop and not have to worry about syncing. Need to pass around something to show a coworker? It could just work.
This is a sign that Apple is either not hitting on all cylinders, or bit off more than it could chew. (To be fair, distributed data is, and always has been, quite a hard problem.) Apple could be moving in for the kill. Instead, they're recovering from stumbles while their opponent has left themselves wide open.
I add a Safari bookmark on one and it appears instantly on the other. Likewise for contacts, calendars, apps, music and any iCloud enabled app e.g. Coda.
Then just add Dropbox and Evernote and you're laughing.
Using the document model (as long as it's not a Core Data document) with iCloud is fine, as is the Key-Value store.
Using Core Data on its own is also fine, it's a great framework and we use it a lot.
We were recently acquired by Automattic, and we're now putting more resources into the project (for example to make it work on Android as well). If cost for the hosted service is a concern for you, you can get in touch and we'll work something out (info@simperium.com).
Oh, one more thing: Did you ever load multiple TouchDBs? I'm thinking the overhead per DB (not per server) should be pretty small, no?
Background: I'd like to build an application where I separate entities into multiple couchDBs, partly since it saves me view definition code, partly because it gives me more flexibility for per-document access permissions.
- is document based
- can easily replicate to laptops and embedded devices
- has all the security I want, e.g. encryption, per document security
- has the bindings I want and/or a new binding can easily be implemented ad-hoc
Given the advantages and disadvantages I'm leaning towards CouchDB and rolling my own security wrapper. IMO that's still better than going with an RDBMS and then implementing replication[1]. How do you see this?
[1]edit: and also giving up the document based approach, thus not having arbitrary mapping from the get go.
I think the real downsides are scaling and performance but there are options at least. Given that TouchDB is essentially couchdb mapped onto sqlite I do wonder if there are going to be good options to map couchdb replication onto postgres in future.
The use cases I have in mind don't need the DB to scale to more than a few ten thousand users. Should be ok with a two or three replicated nodes I think, from my experience with Lotus Notes.
Thanks, I see. Ok, if it's just string or binary based it will work from a correctness standpoint. I'd expect big performance problems with ad-hoc views (if they even exist here), but these shouldn't be used in production anyways. Also, I'd expect replication to take quite a bit longer because it needs to map every document with changes, so there's going to be a tradeoff between initialization time and replication time between the two approaches.
I'm thinking it's going to be beneficial for larger databases to have a TouchDB 'server' somewhere, which constantly replicates with CouchDB and sends the devices a complete snapshot sqlite file for the initial setup. After that, they can talk to CouchDB directly. Otherwise it could take like half an hour to initialize a 50MB DB on a device, which is not really feasible.
Yes definitely do that. I bundle the sqlite in the app store updates and then mount that as an external db and pull from itself - its a bit awkward but it worked. I had to write the external db stuff, but it was pretty easy.
Edit: potatolicious has a pretty great explanation. It looks like it's mostly CoreData issues. But for those cases, Dropbox wouldn't do any better, right?
Or maybe the article's implying no one really knows?
I won't argue that CoreData has its pitfalls, but at the end of the day, many of us both write our own syncing solutions, and successfully use iCloud. Neither of these things is actually all that hard, and you certainly don't need to use iCloud to have your apps featured.
The OP said you can roll your solution using iCloud and it will work and they are 100% correct.
The OP said you don't need iCloud to be featured and they are 100% correct.
Which point is wrong exactly ?