Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frustrated with iCloud, Apple’s developer community speaks up

arstechnica.com

Post reply on HN
Print view View original

111–120 of 192 posts

Re: Frustrated with iCloud, Apple’s developer community speaks up

#111

Post by seivan »

pifflesnort wrote: post #102
rbritton wrote: post #87

Earlier quoted context omitted.

Adding on to your #3, concurrency became MUCH, MUCH easier in iOS 5. Core Data gained the concept of a background/main thread context and the two methods -performBlock: and -performBlockAndWait:. See: https://developer.apple.com/library/mac/ipad/#documentation/... and http://www.cocoanetics.com/2012/07/multi-context-coredata/

This requires performing all mutation on dedicated code paths. If you require non-asynchronous completion, you have to use the 'wait' variant, but this introduces deadlock risk between threads. This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model. Compare to SQLite, where one can simply open and commit a transaction synchronously o…

Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc?

And yes, you can still not use a persistent store manage context on multiple queues.

Please stop using the word thread and use the word queue :)

Re: Frustrated with iCloud, Apple’s developer community speaks up

#112

Post by jmathai »

JonnieCache wrote: post #47

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

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.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#113

Post by pifflesnort »

phil wrote: post #109
pifflesnort wrote: post #77

Earlier quoted context omitted.

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,…

That's a pretty carefully thought out list of grievances. What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects. Core Data does solve a few tough problems well. Faulting, uniquing, and cross-context change merging are probably the top…

> What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects.

Well, keep scrolling :~)

Especially 'Custom Instance Variables' and 'Custom Accessor Methods' and 'Validation Methods'. I don't think it's controversial that defining derived instance variables, accessor methods, or other derived state on model classes is an unusual or unwarranted desire, yet doing so with Core Data requires considerably more effort and complexity than a simple model object.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#114

Post by pifflesnort »

seivan wrote: post #111
pifflesnort wrote: post #102

Earlier quoted context omitted.

This requires performing all mutation on dedicated code paths. If you require non-asynchronous completion, you have to use the 'wait' variant, but this introduces deadlock risk between threads. This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model. Compare to SQLite, where one can simply open and commit a transaction synchronously o…

Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc? And yes, you can still not use a persistent store manage context on multiple queues. Please stop using the word thread and use the word queue :)

> Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc?

The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> Please stop using the word thread and use the word queue :)

Why? Queues are M:N mapped to threads, so they are still threads. Additionally, not all work is always done on queues, especially when working with legacy APIs.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#115

Post by jemeshsu »

gdubs wrote: post #75

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.

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.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#116

Post by erichocean »

larrik wrote: post #35
vacri wrote: post #28

Earlier quoted context omitted.

How is that even possible? What could be the possible rationale for keeping old passwords stored? Crazy.

Normally it would to be prevent users from reusing their most recent N passwords, for security. I don't believe Apple does that anywhere, though.

I can confirm that they do.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#117

Post by potatolicious »

seivan wrote: post #104
pifflesnort wrote: post #48

Earlier quoted context omitted.

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.

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

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.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#118

Post by phil »

pifflesnort wrote: post #113
phil wrote: post #109

Earlier quoted context omitted.

That's a pretty carefully thought out list of grievances. What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects. Core Data does solve a few tough problems well. Faulting, uniquing, and cross-context change merging are probably the top…

> What do you mean by 1), though? The link shows a list of methods you can't override on NSManagedObject, but they're things like -class and -isEqual:, which seems pretty reasonable for a system that needs to inspect and compare its objects. Well, keep scrolling :~) Especially 'Custom Instance Variables' and 'Custom Accessor Methods' and 'Validation Methods'. I don't think it's controversial that defining derived ins…

I've subclassed NSManagedObject and added instance variables and custom accessors literally every time I've written Core Data code. It's usually not a problem -- yes, you do have to do a couple things to preserve the underlying behavior.

What problems have you had?

Re: Frustrated with iCloud, Apple’s developer community speaks up

#119

Post by deveac »

potatolicious wrote: post #50
kybernetyk wrote: post #41

Earlier quoted context omitted.

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.

> "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 a…

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

I was a little shocked when the switched to the 'card UI.' On a mobile device where there is very little real estate, they completely nerfed the amount of app information on the discover screens. Added so much physical effort and time it takes for the user to peruse a like number of apps compared to the former UI.

Re: Frustrated with iCloud, Apple’s developer community speaks up

#120

Post by saurik »

zalambar wrote: post #99
saurik wrote: post #17

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 expl…

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…

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

Post reply on HN