Should we criticize something without acknowledging the others? The kind of article will sound a bit slant toward anti-Apple. The more appropriate approach is to show clearly how many apps using CoreData syncing (problem) compared to how many using document syncing (no problem).
I guess Apple knew about the weakness of CoreData syncing very well. After all, Margo Arment just criticized it not too long ago (before even this article).
Margo Arment? Is that Marco's wife?
But you're right, this is not a new issue. We as developers have been struggling with this for a long time. But there are two problems - (a) Apple is virtually non-communicative on this. (b) We have learned from the past that there are consequences when we are too vocal with our complaints.
Maybe that's why the developer is having problems - adding spaces where they shouldn't be. /s
Oh, and btw, when the original source is The Verge, it's probably best to take it with a massive grain of salt.
No. The original source is not the Verge. This issue has been discussed publicly (and privately) for quite some time. You really need to ask yourself - how is it that you feel qualified to defend Apple so vociferously when you clearly don't understand the issue at all? Don't you care about your credibility? 'Nuff said.
No. The original source is not the Verge. This issue has been discussed publicly (and privately) for quite some time. You really need to ask yourself - how is it that you feel qualified to defend Apple so vociferously when you clearly don't understand the issue at all? Don't you care about your credibility? 'Nuff said.
I like articles with facts in them. I don't like fact-free hit pieces.
Why is it that Apple just plain sucks are doing cloud stuff? They always have and apparently always will.
Well, iCloud is a more pervasive, thorough, and ambitious cloud and syncing solution than anyone has ever done or is doing, including Google. So no, Apple doesn't just "plain suck" at cloud, they're just pushing the envelope more than anyone, and running into extremely complex technical problems to resolve that noone has ever encountered, and not simple to just "solve".
Apple DOES suck at cloud services. And that has less to do with technical ability than with corporate policy.
For one, the vast majority of iCloud services working well are rebranded mobileMe nee dotMac services. Even iTunes is mostly just a webObjects web app coupled with a special purpose web browser called iTunes.
The problem with Apple's cloud services are several:
a) oversimplification
b) no international focus
c) taking control away from the user and giving it to buggy software
d) replacing services instead of complimenting them (nothing that one can rely on)
e) discarding older paradigms that are finally working with new paradigms that are full of bugs
f) Apple's cloud and app strategy is app centric instead of data/project centric
To give a few examples to each of these categories:
a) oversimplification.
The most fundamental part of the Apple cloud services is the AppleID. AppleID was totally screwed up, when in the pathological drive to simplify things past their true nature, Apple decided to replace a HAS-A relationship with an IS-A relationship. A user HAS An e-mail address, but a users IS not An e-mail address.
Thus when Apple switched from an AppleID being an arbitrary string which is associated with one or more e-mail addresses, it caused a bunch of issues that are not resolved to this day. dotMac/mobileMe e-mail addresses with one swoop became AppleIDs with no way of merging them. iCloud made matters worse, because while actively managed AppleIDs e.g. [email protected] acquired over time automatically the various @me.com and @icloud.com aliases, other AppleIDs, such as the ones Apple created from iChat accounts did not. Also the software was buggy, so I now have more than half a dozen AppleIDs (not counting the international AppleIDs of mine, see my next point), and worse, some of them have the same user identifier. e.g. I have an AppleID [email protected] with an associated alias [email protected], but a totally separate AppleID called [email protected]. This is a situation that was not supposed to be possible and that would only be possible to fix if a database admin would go in and manually merge these accounts somehow, but of course Apple won't do that, and they have no other means of merging accounts. As a result all sorts of malfunctions in cloud services happen. There are other issues, like iMessage never working on either my iPhone or iPad, even though it works on my computers. With another AppleID I can't add an e-mail address, because that e-mail address the system claims to be added already to another AppleID, but there it's in limbo state, meaning it's added but not verified, and it doesn't show up in the account management page. Resending the verification e-mail doesn't work either, due to some bug, and so that e-mail address can neither be removed nor confirmed on one AppleID, nor be added to another AppleID. All of this is due to oversimplification, due to not taking into account "non-average" usage scenarios, buggy back-end software, and insufficient support which could manually fix/merge/delete things. It's a mess, and I don't see it better, because even if Apple fixes things for new accounts, I see no effort from Apple working on tools to clean up the mess pass failures have created.
Similarly, when Apple had "family" accounts, many used to have these to essentially create e-mail aliases. When Apple introduced e-mail aliases and discontinued family accounts, there was no way to merge in these e-mail addresses as aliases, they now live on in perpetuity as separate AppleIDs and separate accounts.
b) Content provider have an interest in making sure that content is only licensed to people with a legitimate connection to a certain geographical area. This is annoying for users, but it's a fact of the current business climate. However all that would mean is that Apple verifies a billing/shipping method in a particular country before allowing an AppleID to be able to purchase/license/rent content designed for that geographical area. While Amazon and eBay allow a single user to be active world wide, an AppleID can only be associated with ONE country. I live in the US, have family in several European countries, and I travel a lot. You want an app that lists store opening hours in Austria? Oh, well, you need an AppleID associated with Austria. Frequent buyer app for some German retailer? Get a German AppleID. etc. Now I have several AppleIDs for purchasing content in a variety of national iTunes/AppStores. It's a pain in the butt, since even to download upgrades, I have to constantly switch identities in iTunes, etc. Further, content syncing between various Macs is not working properly, because switching the AppleID for autodownloads can only be done once every 6 months. Userfriendly? I think not.
c) Many times have I entered a new contact on my computer. Some network or server glitch happens, and all of a sudden my complete address entry is replaced by push with an incomplete version from Apple's servers. iCloud assumes it's the master, even though nobody ever enters data on iCloud. I want to be able to designate who's the master (and that should always be my computer) and I want to be alerted if there are sync conflicts such that I can take appropriate action. mobileMe was half there: it alerted, but it didn't have good tools for manual conflict resolution. iCloud is so dumbed down that "there are no conflicts, the cloud is always right, damn if the user loses data." The user just lost control, and is even more pushed towards becoming a brainless consumer who's clueless about what, how, and where things go on with his data.
d) Apple replaces services, instead of adding services. Case in point Photostream. Photostream is great for some moronic FB users, who think they have to post a photo about every crap they take, chronologically ordered, as if they were actually writing history.
It's useless for anyone who wants to tell a real story, share artwork, etc. A photostream is a crude, time-line-chain of individual pictures, a gallery/album is a curated, manually arranged sequence of images that tell a story, e.g. juxtaposing DIRECTLY a picture from today with one from a few years ago. It can be done in a gallery, not in a photostream (unless the stream only contains these two pictures).
So while the photostream may have some use for low-grade documentary purposes, it's not a suitable substitute for a curated album/gallery, but that's what Apple is pretending it to be. Nevermind that the presentation quality of the photostream is leaps and bounds worse than mobileMe galleries, and that the granularity of access privileges to photostreams is abysmal. Photostream is a downgrade from something that worked flawlessly to something some hipster who doesn't know what photography is all about thought up in a desperate attempt to emulate the ridiculous "social media" fad.
Similar examples would be the axing of keychain syncing, which makes millions of macs less secure, because without keychain syncing people will increasingly use again simple passwords they can easily remember as they move from one machine to another, instead of knowing that their passwords travel with them by virtue of keychain sync. Of mail account syncing or....
This replace one thing with something completely different that only has a small overlap with what was there before means that while the Apple eco-system sucks you into their cloud services, you have no solution you can rely on, plan on being there, or that will reliably work for more than the life cycle of a particular OS release. Many things here still rely on OS X 10.6.x but none of that works with iCloud, and mobileMe is gone. Galleries were a great way of adding restricted access photo albums to small business web sites (some hosted by mobileMe). Hosting and the galleries disappeared, causing a lot of transition costs and head aches for users. But Apple cares about what demos well at the next product introduction, not about long term usability and infrastructure concerns of their users.
e) Apple replaces services that are finally reasonably well debugged by new paradigms full of bugs. Apple is in constant beta, not because they never fix bugs, but because when they finally finish a building, they tear it down for new construction. mobileMe was a huge mess when it first was rolled out. It got a bad reputation, but towards the end, it actually worked quite flawlessly; much more so than iCloud does now. While iCloud may be better in some indefinite point in the future, we'd have had a functioning system until that point arrived. Instead Apple pulled the rug away from under user's feet, even creating a situation for several months where iCloud was not yet available and mobileMe was no longer available for new sign ups, creating a limbo state for new Mac and iOS users; and now we have to deal with the immaturities in the iCloud infrastructure for several years while hardware that's perfectly functional is relegated to the scrap heap, because it can't be updated with newer versions of iOS that (properly) work with iCloud.
f) everything becomes captive to an app. Apple's data processing becomes app centric again, which reminds me of how computing was back in the MS-DOS days: each app had it's files, and the data stayed there. Maybe you could use a screen switcher to switch back and forth between various apps (welcome full screen mode!), but that was it.
There was a time when things were supposed to be data centric: open data formats, that would be process with a myriad of competing or complimenting apps, even live data containers embedded in documents, etc.
Without a clear, open object model, and some object interchange between various apps, and the use of open document formats, the computing platforms are taking a massive step backwards in interoperability. People's data is on the one hand held hostage, yet on the other, there is no commitment to availability of apps and related services over time.
In terms of computing paradigms, we're in a worse spot now than in the late 90s, and the closed nature of iOS and the cloud strategies of various computing powerhouses are not painting a rosy picture for the future.
The subscription model that's underhandedly advanced on all fronts, along with planned obsolescence of hardware/OS combination is not good for users. Apple (so far) is less aggressive than companies like M$ or Adobe or Google, but for how long? iCloud certainly isn't just going to remain this wonderful free for all service that Apple provides out of the goodness of its heart to everyone at no cost forever. Time to look a "gift horse" in the mouth. mobileMe cost money, but it also was largely a bundling of services that were based on established protocols or web products that were easy to replace. iCloud aims to be insidious and suck you into a dependency from which one can hardly extricate oneself.
So, compared to the mixture of online services I'd have to use would I use Win/Android, this is still the better scenario, but choosing between bad and worse doesn't make me blind to the fact that this whole situation could be a hell of a lot better.
So yes, Apple's cloud services do suck, and that comes from someone who has with this platform since it was called NeXTSTEP 0.8
It's time Apple wakes up and starts thinking "products" again, instead of just thinking "marketing". Design is key, simplicity is important; but when design trumps function and when things are made simpler than they really are, then you start having serious problems.
Computers were supposed to be wheels for the mind, but they have become wheelchairs for feebleminded.
I know what you mean, there are a lot of silly Apple beat up articles on the web, but unfortunately this is not one of them. I have experienced it myself, wasted weeks of work. And here is a reputable, non-Apple hating developer, made up of ex Apple employees, Black Pixel, saying the same thing, the new upcoming version of NetNewsWire will not use iCloud: http://blackpixel.com/blog/2013/03/the-return-of-netnewswire.html
That's nice, but it still doesn't address the question of how serious a problem it is.
A reasonably researched article would say something like:
"Apple says that 20,000 apps use CoreData. During the past 6 months, about 10% of the app developers have had problems, based on a survey conducted by billybobssurveys. The most frequently reported problems are......." and so one. There needs to be some effort to quantify the extent of the problem.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
This is perhaps the worst post ever on Apple Insider.
1. What does "oversimplification" mean in this context? Many consumers prefer simplification. Is the plain doughnut "oversimplified?" There are a multitude of repetitive statements in the post without any supporting evidence.
2. Interesting statement but doesn't seem true. Additionally, no competitor offers the internationalization and localization that Apple offers. Apple products and services are in many more countries than competing products.
The rest of the comments are even worth commenting about.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
No. Not even the FDA expects arguably the most critical data, medical records, to be 100% accessible and confidential with integrity.
This is perhaps the worst post ever on Apple Insider.
1. What does "oversimplification" mean in this context? Many consumers prefer simplification. Is the plain doughnut "oversimplified?" There are a multitude of repetitive statements in the post without any supporting evidence.
2. Interesting statement but doesn't seem true. Additionally, no competitor offers the internationalization and localization that Apple offers. Apple products and services are in many more countries than competing products.
The rest of the comments are even worth commenting about.
Another blocked poster.
While you're free to your opinion, the way you state it shows that you neither read, nor comprehended what I wrote.
To the "points" you made:
ad 1) I made several clear examples of what oversimplification means: it's making something simpler than it is, such as, in terms of data base modeling, replacing a has-a relationship with an is-a relationship when that's plainly not reflected in reality.
If you do not understand what that means, then frankly, you're not qualified to engage in this discussion.
ad 2) Yes, competitors do offer it, clearly eBay and Amazon.com allow me to access all their regional/national stores with a single user id. I can log in to amazon.com and amazon.de, amazon.co.uk, amazon.fr and my user data is the same everywhere. The account has US and European means of payment associated with it and it has European and US delivery addresses associated with it. I can download wherever I am from whichever store I choose. I can even have items physically delivered to any of my addresses without significant problems. Similar things hold true for eBay, and even google lets me log-in with a single Google account in it's various national incarnations of their services. Apple sticks out like a sore thumb by going out of its way to make it difficult to use AppStore and iTunes in any other country than the one they would like you to have to pegged to.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
Sorry, but you're living in a dream world and your opinion is useless if you ever expect anything that is used by hundreds of millions of people to NEVER have a failure.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
No. Not even the FDA expects arguably the most critical data, medical records, to be 100% accessible and confidential with integrity.
There's a huge difference between "availablity" and "data loss". When iCloud has here and there an outage, that can be quite a nuisance, but if it's not too often and too long, and sync properly works and one has thus a local cache of the data, it's tolerable.
But if randomly data disappears, or good data gets overwritten with bad data without the user being warned that a potential conflict exists and the user being given a choice which version of the data to pick, then you have a serious problem.
It's not like there's a backup you can roll back to when iCloud syncing screws up, the cloud is supposed to be that back up and it's supposed to be reliable.
We're not talking about something like a home-spun sync solution here, we're talking about something that Apple wants you to trust your crown jewels to, and give up local storage and local backup for. The level of reliability isn't acceptable for anything more critical than school homework. The dog, nee, the iCloud ate it...
There's a huge difference between "availablity" and "data loss". When iCloud has here and there an outage, that can be quite a nuisance, but if it's not too often and too long, and sync properly works and one has thus a local cache of the data, it's tolerable.
But if randomly data disappears, or good data gets overwritten with bad data without the user being warned that a potential conflict exists and the user being given a choice which version of the data to pick, then you have a serious problem.
It's not like there's a backup you can roll back to when iCloud syncing screws up, the cloud is supposed to be that back up and it's supposed to be reliable.
We're not talking about something like a home-spun sync solution here, we're talking about something that Apple wants you to trust your crown jewels to, and give up local storage and local backup for. The level of reliability isn't acceptable for anything more critical than school homework. The dog, nee, the iCloud ate it...
This demonstrates that you have no idea of what you speak. "Integrity" which is clearly listed in my post refers to potential "data loss" and more.
There's a huge difference between "availablity" and "data loss". When iCloud has here and there an outage, that can be quite a nuisance, but if it's not too often and too long, and sync properly works and one has thus a local cache of the data, it's tolerable.
But if randomly data disappears, or good data gets overwritten with bad data without the user being warned that a potential conflict exists and the user being given a choice which version of the data to pick, then you have a serious problem.
It's not like there's a backup you can roll back to when iCloud syncing screws up, the cloud is supposed to be that back up and it's supposed to be reliable.
We're not talking about something like a home-spun sync solution here, we're talking about something that Apple wants you to trust your crown jewels to, and give up local storage and local backup for. The level of reliability isn't acceptable for anything more critical than school homework. The dog, nee, the iCloud ate it...
This demonstrates that you have no idea of what you speak. "Integrity" which is clearly listed in my post refers to potential "data loss."
Data integrity is about bit flipping, data degradation, not about total loss.
A loss of data integrity happens e.g. when your disk fails, and you restore from backup tape, and a small section can't be read properly and now some numbers are altered, a single address record is corrupted, a photo has a few scan-lines of bad pixels. That's loss of data integrity. The data is there, but damaged.
Data loss is like your disk fails, and you have no backup.
And that's exactly what is happening with iCloud sync failures. Stuff just goes away, never shows up, shows up incompletely, no backup, no user choice.
The data structures in ~/Library/MobileDocuments/ are opaque and undocumented, so it's not like even local backups of that location would be in any significant way helpful without massive amounts of reverse engineering.
So yes, there is a massive qualitative difference: one lack of 100% reliability is about 99.999999% reliability with random data corruption due to clerical errors and or hardware failure. The other is something that affects a large number of people on a regular basis and that is indicative of fundamental design flaws or serious software bugs (read: premature deployment).
Obviously nothing is 100% reliable, even the Great Pyramids crumble. But there are things that are conceptually 100% reliable and require catastrophic events for failure (e.g. buggy firmware on a batch of data center disk drives, earth quakes, massive fires, etc) that are outside the design specifications or software abstractions involved, and then there's failure "by design" (or lack thereof) where the fundamental design of the software cannot cope with the daily reality with the systems they work with (e.g. software assuming 100% reliable network connectivity in the context of roaming mobile devices, e.g. assuming all devices always have the latest, same OS version installed, etc.) Who knows what Apple's (lack of) assumptions are, but it's clear that we're not talking about issues here that are the result of catastrophic events, but that are the result of a software-infrastructure missmatch at best, and lousy/buggy code at worst.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
No. Not even the FDA expects arguably the most critical data, medical records, to be 100% accessible and confidential with integrity.
One doesn't need to be an Apple apologist to see that this article is rather meaningless.
How many developers have complained? Out of how many total developers? How frequently do they experience problems? Do their users experience problems or is it simply making things a bit more difficult for the developer?
This is one of an endless stream of articles about "someone is complaining about something that Apple did". It's absolutely impossible to tell if this is a problem that affects an insignificant number of people and which has a simple workaround or if it's a serious problem that affects a large number of users.
Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
And just like that, you've proven you know nothing whatsoever about server back end infrastructure.
You're confusing uptime with lack of data corruption/loss.
Typical enterprise-class SLAs for cloud services range from 99.9% to 99.999% uptime. So reliability as far as uptime goes, is in the 99.9%+ range. That means out of a full year the services may be down for no more than from anywhere between 8h to about 5m per year. Usually these SLA have additional clauses that limit the length of such downtime to a certain max. duration per incident.
The point of cloud service reliability isn't that any given server, disk drive, etc. is that reliable, the point is, that fail-over, mirroring, etc. makes failure to the user of the service transparent.
Further, when cloud service providers talk about reliability in percentages, it's about uptime, not data loss.
You really think it would be acceptable if one out of ever thousand or one out of every tenthousand users per year would lose all their data? In the case of Apple that would mean tens of thousands of users would lose their data each year, which would mean over the course of a few years a significant percentage would have lost their data.
Neither is that acceptable, nor is that the rule or the understanding when anyone talks about cloud service reliability. So while a server may crash and a data may be lost from the point of view of that server, cloud services must hide that fact by proper replication (redundancy), backup, failover, and other strategies employed at many levels (ECC RAM, RAID-6 disk arrays, geographically distributed fail-over servers, off-site data backup, etc. etc.) So data loss at any point may lead to down-time to restore or fail-over to another server, but it should not lead to data loss. When data loss happens due to anything but end-user error, it's a scandal. Notice the outrage when Microsoft wiped the sidekick users' data during a migration, etc.
In that context it doesn't matter if some mistake affects many accounts in one incident, or if bad design affects a small, random group of users on a consistent basis. Both are equally wrong and intolerable, because both mean something's fundamentally wrong with the processes being in place.
The "fan community" here has a problem: it tries to rationalize when Apple fails, instead of holding their feet to the fire, yet at the same time, they get bent out of shape when some stupid pundits write crap about Apple. This isn't helpful, this is living in a make-belief world, it's stupid blind allegiance without meaning, just like being fan of a random sports team, or being nationalist for a random country.
A company deserves our support when their products are superior, and it deserves to be punished when they are not where they should be. Jobs knew that, but Apple fans seem to want to ignore that. Concentrate on the real flaws of Apple's products and strategies, and you're doing yourselves as users and Apple as a company a favor. Be complacent and apologetic, and you'll let Apple get away with things that will hurt the company in the future and will make you suffer through inferior products.
The whole apology tour some people have here about iCloud sync reliability reminds me of the infamous exchange between Alan R. Mulally and some manager about how difficult it is to manage a product as complex as a car, to which he answered: "An automobile has about 10,000 moving parts, right? An airplane has two million, and it has to stay up in the air." Not good enough if the plane doesn't crash 99.99% of the time, because that means we'd have a few plane crashes each day. Interesting reading for people who are interested on how to really solve problems: http://www.businessweek.com/stories/2007-06-03/the-new-heat-on-ford
I'm an iOS developer with quite a lot of experience dealing with Core Data over iCloud sync.
Interestingly, Apple has made a good deal of improvements to the API in iOS 6 but hasn't actually dealt with the biggest real problem.
The first obstacle with integrating iCloud in your Core Data applications is that Apple's documentation and even tech videos make it look a lot simpler than it really is. There are a great deal of important things to handle for a reliable implementation that either aren't covered, or aren't covered in sufficient detail.
The second obstacle is that even if you do everything just right, there are a few bugs in the way transaction logs are handled which can cause everything to just "randomly" break.
I've actually spent a *lot* of work trying to figure out exactly what's going on and how to deal with it. The conclusion is that there isn't currently any way to make a 100% reliable implementation that won't sometimes just break. But there are good ways of dealing with the breakage when it does happen and recover from it.
For those developers that are interested, UbiquityStoreManager is a library that simplifies the process tremendously by taking care of all the iCloud stuff for you. It even deals with broken cloud content and has hooks to allow you to plug in your own handling code if you prefer. And if Apple does get their stuff together and fixes these critical bugs in iOS 7, USM will be ready to be your reliable and convenient API to ubiquitous store management: http://lhunath.github.com/UbiquityStoreManager/
One doesn't need to be an Apple apologist to see that this article is rather meaningless.
How many developers have complained? Out of how many total developers? How frequently do they experience problems? Do their users experience problems or is it simply making things a bit more difficult for the developer?
This is one of an endless stream of articles about "someone is complaining about something that Apple did". It's absolutely impossible to tell if this is a problem that affects an insignificant number of people and which has a simple workaround or if it's a serious problem that affects a large number of users.
At the dawning of realisation of a new problem hard facts and figures on a grand scale often aren't available. That doesn't mean there isn't a problem, and it doesn't mean the worry is FUD.
Apologism, it cuts both ways, and a bit of perspective makes all the difference. There are complaints out there, and that they exist is a fact.
I'm an iOS developer with quite a lot of experience dealing with Core Data over iCloud sync.
Interestingly, Apple has made a good deal of improvements to the API in iOS 6 but hasn't actually dealt with the biggest real problem.
The first obstacle with integrating iCloud in your Core Data applications is that Apple's documentation and even tech videos make it look a lot simpler than it really is. There are a great deal of important things to handle for a reliable implementation that either aren't covered, or aren't covered in sufficient detail.
The second obstacle is that even if you do everything just right, there are a few bugs in the way transaction logs are handled which can cause everything to just "randomly" break.
I've actually spent a *lot* of work trying to figure out exactly what's going on and how to deal with it. The conclusion is that there isn't currently any way to make a 100% reliable implementation that won't sometimes just break. But there are good ways of dealing with the breakage when it does happen and recover from it.
For those developers that are interested, UbiquityStoreManager is a library that simplifies the process tremendously by taking care of all the iCloud stuff for you. It even deals with broken cloud content and has hooks to allow you to plug in your own handling code if you prefer. And if Apple does get their stuff together and fixes these critical bugs in iOS 7, USM will be ready to be your reliable and convenient API to ubiquitous store management:
At the dawning of realisation of a new problem hard facts and figures on a grand scale often aren't available. That doesn't mean there isn't a problem, and it doesn't mean the worry is FUD.
Apologism, it cuts both ways, and a bit of perspective makes all the difference. There are complaints out there, and that they exist is a fact.
I never said that there were no complaints, nor that their existence is a fact.
What I said was that there's no evidence that it's a widespread problem. With hundreds of millions of iDevices, there WILL be problems, no matter how good a job Apple did. So simply saying "there were some problems" is useless. Where's the evidence that it's a significant problem?
Comments
Quote:
Originally Posted by matrix07
Should we criticize something without acknowledging the others? The kind of article will sound a bit slant toward anti-Apple. The more appropriate approach is to show clearly how many apps using CoreData syncing (problem) compared to how many using document syncing (no problem).
I guess Apple knew about the weakness of CoreData syncing very well. After all, Margo Arment just criticized it not too long ago (before even this article).
Margo Arment? Is that Marco's wife?
But you're right, this is not a new issue. We as developers have been struggling with this for a long time. But there are two problems - (a) Apple is virtually non-communicative on this. (b) We have learned from the past that there are consequences when we are too vocal with our complaints.
Quote:
Originally Posted by jragosta
In their technical documentation, they tend to use it without the space - to be consistent with their API naming conventions.
http://www.apple.com/ipad/business/docs/iOS_Security_Oct12.pdf
"Data Protection is available for file and database APIs, including NSFileManager, CoreData, NSData, and SQLite."
or
https://developer.apple.com/library/ios/#samplecode/CoreDataBooks/Introduction/Intro.html
Maybe that's why the developer is having problems - adding spaces where they shouldn't be. /s
Oh, and btw, when the original source is The Verge, it's probably best to take it with a massive grain of salt.
No. The original source is not the Verge. This issue has been discussed publicly (and privately) for quite some time. You really need to ask yourself - how is it that you feel qualified to defend Apple so vociferously when you clearly don't understand the issue at all? Don't you care about your credibility? 'Nuff said.
I like articles with facts in them. I don't like fact-free hit pieces.
If that offends you, too bad.
Quote:
Originally Posted by Slurpy
Quote:
Originally Posted by macxpress
Why is it that Apple just plain sucks are doing cloud stuff? They always have and apparently always will.
Well, iCloud is a more pervasive, thorough, and ambitious cloud and syncing solution than anyone has ever done or is doing, including Google. So no, Apple doesn't just "plain suck" at cloud, they're just pushing the envelope more than anyone, and running into extremely complex technical problems to resolve that noone has ever encountered, and not simple to just "solve".
Apple DOES suck at cloud services. And that has less to do with technical ability than with corporate policy.
For one, the vast majority of iCloud services working well are rebranded mobileMe nee dotMac services. Even iTunes is mostly just a webObjects web app coupled with a special purpose web browser called iTunes.
The problem with Apple's cloud services are several:
a) oversimplification
b) no international focus
c) taking control away from the user and giving it to buggy software
d) replacing services instead of complimenting them (nothing that one can rely on)
e) discarding older paradigms that are finally working with new paradigms that are full of bugs
f) Apple's cloud and app strategy is app centric instead of data/project centric
To give a few examples to each of these categories:
a) oversimplification.
The most fundamental part of the Apple cloud services is the AppleID. AppleID was totally screwed up, when in the pathological drive to simplify things past their true nature, Apple decided to replace a HAS-A relationship with an IS-A relationship. A user HAS An e-mail address, but a users IS not An e-mail address.
Thus when Apple switched from an AppleID being an arbitrary string which is associated with one or more e-mail addresses, it caused a bunch of issues that are not resolved to this day. dotMac/mobileMe e-mail addresses with one swoop became AppleIDs with no way of merging them. iCloud made matters worse, because while actively managed AppleIDs e.g. [email protected] acquired over time automatically the various @me.com and @icloud.com aliases, other AppleIDs, such as the ones Apple created from iChat accounts did not. Also the software was buggy, so I now have more than half a dozen AppleIDs (not counting the international AppleIDs of mine, see my next point), and worse, some of them have the same user identifier. e.g. I have an AppleID [email protected] with an associated alias [email protected], but a totally separate AppleID called [email protected]. This is a situation that was not supposed to be possible and that would only be possible to fix if a database admin would go in and manually merge these accounts somehow, but of course Apple won't do that, and they have no other means of merging accounts. As a result all sorts of malfunctions in cloud services happen. There are other issues, like iMessage never working on either my iPhone or iPad, even though it works on my computers. With another AppleID I can't add an e-mail address, because that e-mail address the system claims to be added already to another AppleID, but there it's in limbo state, meaning it's added but not verified, and it doesn't show up in the account management page. Resending the verification e-mail doesn't work either, due to some bug, and so that e-mail address can neither be removed nor confirmed on one AppleID, nor be added to another AppleID. All of this is due to oversimplification, due to not taking into account "non-average" usage scenarios, buggy back-end software, and insufficient support which could manually fix/merge/delete things. It's a mess, and I don't see it better, because even if Apple fixes things for new accounts, I see no effort from Apple working on tools to clean up the mess pass failures have created.
Similarly, when Apple had "family" accounts, many used to have these to essentially create e-mail aliases. When Apple introduced e-mail aliases and discontinued family accounts, there was no way to merge in these e-mail addresses as aliases, they now live on in perpetuity as separate AppleIDs and separate accounts.
b) Content provider have an interest in making sure that content is only licensed to people with a legitimate connection to a certain geographical area. This is annoying for users, but it's a fact of the current business climate. However all that would mean is that Apple verifies a billing/shipping method in a particular country before allowing an AppleID to be able to purchase/license/rent content designed for that geographical area. While Amazon and eBay allow a single user to be active world wide, an AppleID can only be associated with ONE country. I live in the US, have family in several European countries, and I travel a lot. You want an app that lists store opening hours in Austria? Oh, well, you need an AppleID associated with Austria. Frequent buyer app for some German retailer? Get a German AppleID. etc. Now I have several AppleIDs for purchasing content in a variety of national iTunes/AppStores. It's a pain in the butt, since even to download upgrades, I have to constantly switch identities in iTunes, etc. Further, content syncing between various Macs is not working properly, because switching the AppleID for autodownloads can only be done once every 6 months. Userfriendly? I think not.
c) Many times have I entered a new contact on my computer. Some network or server glitch happens, and all of a sudden my complete address entry is replaced by push with an incomplete version from Apple's servers. iCloud assumes it's the master, even though nobody ever enters data on iCloud. I want to be able to designate who's the master (and that should always be my computer) and I want to be alerted if there are sync conflicts such that I can take appropriate action. mobileMe was half there: it alerted, but it didn't have good tools for manual conflict resolution. iCloud is so dumbed down that "there are no conflicts, the cloud is always right, damn if the user loses data." The user just lost control, and is even more pushed towards becoming a brainless consumer who's clueless about what, how, and where things go on with his data.
d) Apple replaces services, instead of adding services. Case in point Photostream. Photostream is great for some moronic FB users, who think they have to post a photo about every crap they take, chronologically ordered, as if they were actually writing history.
It's useless for anyone who wants to tell a real story, share artwork, etc. A photostream is a crude, time-line-chain of individual pictures, a gallery/album is a curated, manually arranged sequence of images that tell a story, e.g. juxtaposing DIRECTLY a picture from today with one from a few years ago. It can be done in a gallery, not in a photostream (unless the stream only contains these two pictures).
So while the photostream may have some use for low-grade documentary purposes, it's not a suitable substitute for a curated album/gallery, but that's what Apple is pretending it to be. Nevermind that the presentation quality of the photostream is leaps and bounds worse than mobileMe galleries, and that the granularity of access privileges to photostreams is abysmal. Photostream is a downgrade from something that worked flawlessly to something some hipster who doesn't know what photography is all about thought up in a desperate attempt to emulate the ridiculous "social media" fad.
Similar examples would be the axing of keychain syncing, which makes millions of macs less secure, because without keychain syncing people will increasingly use again simple passwords they can easily remember as they move from one machine to another, instead of knowing that their passwords travel with them by virtue of keychain sync. Of mail account syncing or....
This replace one thing with something completely different that only has a small overlap with what was there before means that while the Apple eco-system sucks you into their cloud services, you have no solution you can rely on, plan on being there, or that will reliably work for more than the life cycle of a particular OS release. Many things here still rely on OS X 10.6.x but none of that works with iCloud, and mobileMe is gone. Galleries were a great way of adding restricted access photo albums to small business web sites (some hosted by mobileMe). Hosting and the galleries disappeared, causing a lot of transition costs and head aches for users. But Apple cares about what demos well at the next product introduction, not about long term usability and infrastructure concerns of their users.
e) Apple replaces services that are finally reasonably well debugged by new paradigms full of bugs. Apple is in constant beta, not because they never fix bugs, but because when they finally finish a building, they tear it down for new construction. mobileMe was a huge mess when it first was rolled out. It got a bad reputation, but towards the end, it actually worked quite flawlessly; much more so than iCloud does now. While iCloud may be better in some indefinite point in the future, we'd have had a functioning system until that point arrived. Instead Apple pulled the rug away from under user's feet, even creating a situation for several months where iCloud was not yet available and mobileMe was no longer available for new sign ups, creating a limbo state for new Mac and iOS users; and now we have to deal with the immaturities in the iCloud infrastructure for several years while hardware that's perfectly functional is relegated to the scrap heap, because it can't be updated with newer versions of iOS that (properly) work with iCloud.
f) everything becomes captive to an app. Apple's data processing becomes app centric again, which reminds me of how computing was back in the MS-DOS days: each app had it's files, and the data stayed there. Maybe you could use a screen switcher to switch back and forth between various apps (welcome full screen mode!), but that was it.
There was a time when things were supposed to be data centric: open data formats, that would be process with a myriad of competing or complimenting apps, even live data containers embedded in documents, etc.
Without a clear, open object model, and some object interchange between various apps, and the use of open document formats, the computing platforms are taking a massive step backwards in interoperability. People's data is on the one hand held hostage, yet on the other, there is no commitment to availability of apps and related services over time.
In terms of computing paradigms, we're in a worse spot now than in the late 90s, and the closed nature of iOS and the cloud strategies of various computing powerhouses are not painting a rosy picture for the future.
The subscription model that's underhandedly advanced on all fronts, along with planned obsolescence of hardware/OS combination is not good for users. Apple (so far) is less aggressive than companies like M$ or Adobe or Google, but for how long? iCloud certainly isn't just going to remain this wonderful free for all service that Apple provides out of the goodness of its heart to everyone at no cost forever. Time to look a "gift horse" in the mouth. mobileMe cost money, but it also was largely a bundling of services that were based on established protocols or web products that were easy to replace. iCloud aims to be insidious and suck you into a dependency from which one can hardly extricate oneself.
So, compared to the mixture of online services I'd have to use would I use Win/Android, this is still the better scenario, but choosing between bad and worse doesn't make me blind to the fact that this whole situation could be a hell of a lot better.
So yes, Apple's cloud services do suck, and that comes from someone who has with this platform since it was called NeXTSTEP 0.8
It's time Apple wakes up and starts thinking "products" again, instead of just thinking "marketing". Design is key, simplicity is important; but when design trumps function and when things are made simpler than they really are, then you start having serious problems.
Computers were supposed to be wheels for the mind, but they have become wheelchairs for feebleminded.
Quote:
Originally Posted by jragosta
Quote:
Originally Posted by ascii
I know what you mean, there are a lot of silly Apple beat up articles on the web, but unfortunately this is not one of them. I have experienced it myself, wasted weeks of work. And here is a reputable, non-Apple hating developer, made up of ex Apple employees, Black Pixel, saying the same thing, the new upcoming version of NetNewsWire will not use iCloud: http://blackpixel.com/blog/2013/03/the-return-of-netnewswire.html
That's nice, but it still doesn't address the question of how serious a problem it is.
A reasonably researched article would say something like:
"Apple says that 20,000 apps use CoreData. During the past 6 months, about 10% of the app developers have had problems, based on a survey conducted by billybobssurveys. The most frequently reported problems are......." and so one. There needs to be some effort to quantify the extent of the problem.
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
Originally Posted by rcfa
[post]
This is perhaps the worst post ever on Apple Insider.
1. What does "oversimplification" mean in this context? Many consumers prefer simplification. Is the plain doughnut "oversimplified?" There are a multitude of repetitive statements in the post without any supporting evidence.
2. Interesting statement but doesn't seem true. Additionally, no competitor offers the internationalization and localization that Apple offers. Apple products and services are in many more countries than competing products.
The rest of the comments are even worth commenting about.
Another blocked poster.
No. Not even the FDA expects arguably the most critical data, medical records, to be 100% accessible and confidential with integrity.
Quote:
Originally Posted by MacBook Pro
Originally Posted by rcfa
[post]
This is perhaps the worst post ever on Apple Insider.
1. What does "oversimplification" mean in this context? Many consumers prefer simplification. Is the plain doughnut "oversimplified?" There are a multitude of repetitive statements in the post without any supporting evidence.
2. Interesting statement but doesn't seem true. Additionally, no competitor offers the internationalization and localization that Apple offers. Apple products and services are in many more countries than competing products.
The rest of the comments are even worth commenting about.
Another blocked poster.
While you're free to your opinion, the way you state it shows that you neither read, nor comprehended what I wrote.
To the "points" you made:
ad 1) I made several clear examples of what oversimplification means: it's making something simpler than it is, such as, in terms of data base modeling, replacing a has-a relationship with an is-a relationship when that's plainly not reflected in reality.
If you do not understand what that means, then frankly, you're not qualified to engage in this discussion.
ad 2) Yes, competitors do offer it, clearly eBay and Amazon.com allow me to access all their regional/national stores with a single user id. I can log in to amazon.com and amazon.de, amazon.co.uk, amazon.fr and my user data is the same everywhere. The account has US and European means of payment associated with it and it has European and US delivery addresses associated with it. I can download wherever I am from whichever store I choose. I can even have items physically delivered to any of my addresses without significant problems. Similar things hold true for eBay, and even google lets me log-in with a single Google account in it's various national incarnations of their services. Apple sticks out like a sore thumb by going out of its way to make it difficult to use AppStore and iTunes in any other country than the one they would like you to have to pegged to.
Sorry, but you're living in a dream world and your opinion is useless if you ever expect anything that is used by hundreds of millions of people to NEVER have a failure.
Quote:
Originally Posted by MacBook Pro
Quote:
Originally Posted by rcfa
ANY problem is too much. What if on average one out of 1000 users loses all their data each year. Would you want to gamble your data on that? Would you as a developer want to deal with these users who just lost all their data?
Data is holy, nothing can touch, destroy, obliterate data, or it's 100% useless. This isn't about losing your high-score on some stupid computer game, people use iOS for real work.
Oops, medical records gone, Oops, insurance claim gone, Oops shipment gone, Oops flight plan lost...
...you get the idea. Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
No. Not even the FDA expects arguably the most critical data, medical records, to be 100% accessible and confidential with integrity.
There's a huge difference between "availablity" and "data loss". When iCloud has here and there an outage, that can be quite a nuisance, but if it's not too often and too long, and sync properly works and one has thus a local cache of the data, it's tolerable.
But if randomly data disappears, or good data gets overwritten with bad data without the user being warned that a potential conflict exists and the user being given a choice which version of the data to pick, then you have a serious problem.
It's not like there's a backup you can roll back to when iCloud syncing screws up, the cloud is supposed to be that back up and it's supposed to be reliable.
We're not talking about something like a home-spun sync solution here, we're talking about something that Apple wants you to trust your crown jewels to, and give up local storage and local backup for. The level of reliability isn't acceptable for anything more critical than school homework. The dog, nee, the iCloud ate it...
This demonstrates that you have no idea of what you speak. "Integrity" which is clearly listed in my post refers to potential "data loss" and more.
Originally Posted by rcfa
Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
And just like that, you've proven you know nothing whatsoever about server back end infrastructure.
Quote:
Originally Posted by MacBook Pro
Quote:
Originally Posted by rcfa
There's a huge difference between "availablity" and "data loss". When iCloud has here and there an outage, that can be quite a nuisance, but if it's not too often and too long, and sync properly works and one has thus a local cache of the data, it's tolerable.
But if randomly data disappears, or good data gets overwritten with bad data without the user being warned that a potential conflict exists and the user being given a choice which version of the data to pick, then you have a serious problem.
It's not like there's a backup you can roll back to when iCloud syncing screws up, the cloud is supposed to be that back up and it's supposed to be reliable.
We're not talking about something like a home-spun sync solution here, we're talking about something that Apple wants you to trust your crown jewels to, and give up local storage and local backup for. The level of reliability isn't acceptable for anything more critical than school homework. The dog, nee, the iCloud ate it...
This demonstrates that you have no idea of what you speak. "Integrity" which is clearly listed in my post refers to potential "data loss."
Data integrity is about bit flipping, data degradation, not about total loss.
A loss of data integrity happens e.g. when your disk fails, and you restore from backup tape, and a small section can't be read properly and now some numbers are altered, a single address record is corrupted, a photo has a few scan-lines of bad pixels. That's loss of data integrity. The data is there, but damaged.
Data loss is like your disk fails, and you have no backup.
And that's exactly what is happening with iCloud sync failures. Stuff just goes away, never shows up, shows up incompletely, no backup, no user choice.
The data structures in ~/Library/MobileDocuments/ are opaque and undocumented, so it's not like even local backups of that location would be in any significant way helpful without massive amounts of reverse engineering.
So yes, there is a massive qualitative difference: one lack of 100% reliability is about 99.999999% reliability with random data corruption due to clerical errors and or hardware failure. The other is something that affects a large number of people on a regular basis and that is indicative of fundamental design flaws or serious software bugs (read: premature deployment).
Obviously nothing is 100% reliable, even the Great Pyramids crumble. But there are things that are conceptually 100% reliable and require catastrophic events for failure (e.g. buggy firmware on a batch of data center disk drives, earth quakes, massive fires, etc) that are outside the design specifications or software abstractions involved, and then there's failure "by design" (or lack thereof) where the fundamental design of the software cannot cope with the daily reality with the systems they work with (e.g. software assuming 100% reliable network connectivity in the context of roaming mobile devices, e.g. assuming all devices always have the latest, same OS version installed, etc.) Who knows what Apple's (lack of) assumptions are, but it's clear that we're not talking about issues here that are the result of catastrophic events, but that are the result of a software-infrastructure missmatch at best, and lousy/buggy code at worst.
What does it expect?
Quote:
Originally Posted by jragosta
One doesn't need to be an Apple apologist to see that this article is rather meaningless.
How many developers have complained? Out of how many total developers? How frequently do they experience problems? Do their users experience problems or is it simply making things a bit more difficult for the developer?
This is one of an endless stream of articles about "someone is complaining about something that Apple did". It's absolutely impossible to tell if this is a problem that affects an insignificant number of people and which has a simple workaround or if it's a serious problem that affects a large number of users.
obviously no one knows.
staying anonymous is the safer norm.
Quote:
Originally Posted by Tallest Skil
Originally Posted by rcfa
Core infrastructure has to be 100.00% reliable. 99.8% or even 99.9% just doesn't cut it.
And just like that, you've proven you know nothing whatsoever about server back end infrastructure.
You're confusing uptime with lack of data corruption/loss.
Typical enterprise-class SLAs for cloud services range from 99.9% to 99.999% uptime. So reliability as far as uptime goes, is in the 99.9%+ range. That means out of a full year the services may be down for no more than from anywhere between 8h to about 5m per year. Usually these SLA have additional clauses that limit the length of such downtime to a certain max. duration per incident.
The point of cloud service reliability isn't that any given server, disk drive, etc. is that reliable, the point is, that fail-over, mirroring, etc. makes failure to the user of the service transparent.
Further, when cloud service providers talk about reliability in percentages, it's about uptime, not data loss.
You really think it would be acceptable if one out of ever thousand or one out of every tenthousand users per year would lose all their data? In the case of Apple that would mean tens of thousands of users would lose their data each year, which would mean over the course of a few years a significant percentage would have lost their data.
Neither is that acceptable, nor is that the rule or the understanding when anyone talks about cloud service reliability. So while a server may crash and a data may be lost from the point of view of that server, cloud services must hide that fact by proper replication (redundancy), backup, failover, and other strategies employed at many levels (ECC RAM, RAID-6 disk arrays, geographically distributed fail-over servers, off-site data backup, etc. etc.) So data loss at any point may lead to down-time to restore or fail-over to another server, but it should not lead to data loss. When data loss happens due to anything but end-user error, it's a scandal. Notice the outrage when Microsoft wiped the sidekick users' data during a migration, etc.
In that context it doesn't matter if some mistake affects many accounts in one incident, or if bad design affects a small, random group of users on a consistent basis. Both are equally wrong and intolerable, because both mean something's fundamentally wrong with the processes being in place.
The "fan community" here has a problem: it tries to rationalize when Apple fails, instead of holding their feet to the fire, yet at the same time, they get bent out of shape when some stupid pundits write crap about Apple. This isn't helpful, this is living in a make-belief world, it's stupid blind allegiance without meaning, just like being fan of a random sports team, or being nationalist for a random country.
A company deserves our support when their products are superior, and it deserves to be punished when they are not where they should be. Jobs knew that, but Apple fans seem to want to ignore that. Concentrate on the real flaws of Apple's products and strategies, and you're doing yourselves as users and Apple as a company a favor. Be complacent and apologetic, and you'll let Apple get away with things that will hurt the company in the future and will make you suffer through inferior products.
The whole apology tour some people have here about iCloud sync reliability reminds me of the infamous exchange between Alan R. Mulally and some manager about how difficult it is to manage a product as complex as a car, to which he answered: "An automobile has about 10,000 moving parts, right? An airplane has two million, and it has to stay up in the air." Not good enough if the plane doesn't crash 99.99% of the time, because that means we'd have a few plane crashes each day. Interesting reading for people who are interested on how to really solve problems: http://www.businessweek.com/stories/2007-06-03/the-new-heat-on-ford
Interestingly, Apple has made a good deal of improvements to the API in iOS 6 but hasn't actually dealt with the biggest real problem.
The first obstacle with integrating iCloud in your Core Data applications is that Apple's documentation and even tech videos make it look a lot simpler than it really is. There are a great deal of important things to handle for a reliable implementation that either aren't covered, or aren't covered in sufficient detail.
The second obstacle is that even if you do everything just right, there are a few bugs in the way transaction logs are handled which can cause everything to just "randomly" break.
I've actually spent a *lot* of work trying to figure out exactly what's going on and how to deal with it. The conclusion is that there isn't currently any way to make a 100% reliable implementation that won't sometimes just break. But there are good ways of dealing with the breakage when it does happen and recover from it.
For those developers that are interested, UbiquityStoreManager is a library that simplifies the process tremendously by taking care of all the iCloud stuff for you. It even deals with broken cloud content and has hooks to allow you to plug in your own handling code if you prefer. And if Apple does get their stuff together and fixes these critical bugs in iOS 7, USM will be ready to be your reliable and convenient API to ubiquitous store management:
http://lhunath.github.com/UbiquityStoreManager/
Quote:
Originally Posted by jragosta
One doesn't need to be an Apple apologist to see that this article is rather meaningless.
How many developers have complained? Out of how many total developers? How frequently do they experience problems? Do their users experience problems or is it simply making things a bit more difficult for the developer?
This is one of an endless stream of articles about "someone is complaining about something that Apple did". It's absolutely impossible to tell if this is a problem that affects an insignificant number of people and which has a simple workaround or if it's a serious problem that affects a large number of users.
At the dawning of realisation of a new problem hard facts and figures on a grand scale often aren't available. That doesn't mean there isn't a problem, and it doesn't mean the worry is FUD.
Apologism, it cuts both ways, and a bit of perspective makes all the difference. There are complaints out there, and that they exist is a fact.
Quote:
Originally Posted by lhunath
I'm an iOS developer with quite a lot of experience dealing with Core Data over iCloud sync.
Interestingly, Apple has made a good deal of improvements to the API in iOS 6 but hasn't actually dealt with the biggest real problem.
The first obstacle with integrating iCloud in your Core Data applications is that Apple's documentation and even tech videos make it look a lot simpler than it really is. There are a great deal of important things to handle for a reliable implementation that either aren't covered, or aren't covered in sufficient detail.
The second obstacle is that even if you do everything just right, there are a few bugs in the way transaction logs are handled which can cause everything to just "randomly" break.
I've actually spent a *lot* of work trying to figure out exactly what's going on and how to deal with it. The conclusion is that there isn't currently any way to make a 100% reliable implementation that won't sometimes just break. But there are good ways of dealing with the breakage when it does happen and recover from it.
For those developers that are interested, UbiquityStoreManager is a library that simplifies the process tremendously by taking care of all the iCloud stuff for you. It even deals with broken cloud content and has hooks to allow you to plug in your own handling code if you prefer. And if Apple does get their stuff together and fixes these critical bugs in iOS 7, USM will be ready to be your reliable and convenient API to ubiquitous store management:
http://lhunath.github.com/UbiquityStoreManager/
Nice work. Are you responsible for iCloudStoreManager too?
I never said that there were no complaints, nor that their existence is a fact.
What I said was that there's no evidence that it's a widespread problem. With hundreds of millions of iDevices, there WILL be problems, no matter how good a job Apple did. So simply saying "there were some problems" is useless. Where's the evidence that it's a significant problem?