Good article. Thanks for disentangling the jargon around Salesforce. I've always wondered why the idea of "CRM" never extends to more than the "Sales" process. What about more lightweight, easy-to-use system that someone who just opened a flower shop, or a yoga studio, could use to manage not just customers but also their employees and contractors? Why don't people use "Personal CRM" tools to keep track of conversations around the work-place, or interacting with employees? There is a lot of potential for a "contact interaction system", with many many use-cases, but I'm curious if the idea just doesn't have legs, or if it's waiting for something to popularize the concept.
Personal angle: I work on such a 'contact interaction system' with an app I have in the App Store, and though I market it as "CRM", my goal is to build something that's very easy-to-use so that "anyone" can use it, for the people who are looking for a good system to manage their contact and customer interactions. I would love to figure out how to drive more traction around the idea, since it's something that's beyond the regular idea of "CRM app for sales". Any thoughts?
It's orbit is thought to range between 200 and 700 AU, which is well outside the Kuiper belt at 30-50 AU and well inside the Oort cloud at 2,000-200,000 AU. So barring the discovery of more stuff in that area it seems to qualify.
That would be well beyond my knowledge or ability to say.
It certainly seems plausible, it may even explain the existence of the Kuiper belt, being held in the balance between Neptune and this planet much like the inner belt is by Mars and Jupiter.
Probably a planet. The distinction between planet and dwarf planet turns on whether the body has demonstrated gravitational dominance. Planet Nine's existence (if it indeed exists) was inferred from alignments of other bodies' orbits, which makes for a very, very strong case that it's a planet and not a dwarf planet.
- this is one of the most frustrating things about Mac (and iOS) development. There's no good reason why this cannot be brought down to 1-2 days by hiring a ton of people to the App Review staff. App Review is not really a technical skill that should be very hard to scale up, and one that can't be outsourced to locations outside of Cupertino. Apple is the most cash-rich company in the world; they can easily throw some money at this problem if they cared about developer satisfaction. Far easier to resolve than problems like sandboxing and upgrade pricing, where there is a major cost for customer satisfaction to think about.
I have apps in the iOS and Mac App store, so this is a big sticking point form me. But there is one thing missing from the article, which is a discussion on why Apple wouldn't want to add a paid upgrade model to the App Store (iOS or Mac).
Some potential reasons:
- confusing to casual users who aren't used to this model, and might not expect it
- more expensive (users at this point feel entitled to free or very cheap software)
- potential for abuse (random apps will start charging for every minor update)
One way they can prevent abuse is to limit developers, and allow paid upgrades only once a year per app. That sounds like a reasonable compromise to me. I don't want the majority of iOS/Mac users to be scared off from buying apps because they think every app is going to nickel-and-dime them at every bug-fix update or minor features. Once-a-year upgrade (with an option to ignore the update if user wants to and continue using the app as-is) could solve both problems.
About "confusing to casual users who aren't used to this model, and might not expect it":
If we tailor everything to the person with the lowest possible knowledge* , we get two things.
1. Everything around us will be a stupid as we can make it.
2. Eventually a person with even less knowledge will be found.
i killed myself to get my entry in. it was another version of healthcare.love. i wish i knew what they were doing so we could team up. i checked my analytics this morning. i was the only one who viewed the official video. i was the only one who launched the app. i'd love to collect the stats from everyone to see how many apps even got played.
It's quite a farce. One can excuse not launching the app (it would require some setup for each individual app), but not looking even briefly at the video is inexcusable. But I'm guessing they already picked the 5 finalists for PR-value well before the entries were submitted, so they didn't want to spend their party-time at Dreamforce doing something so boring as looking at hackathon entries.
i would excuse it if they didn't make such a big deal that you had to show source and that you should start a month early. when you do that, you OWE people a run. the way they did it, you didn't even get a little screen time to shine for your sweat. this thing needs to get rejudged in the open.
So true. I've been working on my iOS app for about 4 years now, and recently started work on porting it to the Mac. But it's so much more tedious than I expected, for exactly the reasons you mention: lack of documentation and support, lots of subsystems to work on, legacy controls that aren't customizable. Attending WWDC and talking to people on both AppKit and UIKit teams, it's striking how little they seem to collaborate; it's like they live in their own organizational bubbles, and there is very little push from on top to make them more streamlined. They have made some progress on some frameworks to consolidate them across Mac OS and iOS (MapKit comes to mind), but it feels like they still operate as two independent entities within Apple; one being the young hot-shot with all the resources, and the other being the envious legacy-system that knows it's past it's best.
Just to add to the "anecdotal" evidence: I watch App Store rankings for my app like a hawk, and aside from the comment about rankings not changing as often, maybe once in 2-3 hours, I haven't noticed any other changes. My app is rated very highly (4.5 for most recent version), and it's ranking inside Business category is consistent with revenue as before. Haven't noticed anything different.
Thanks! The ID number is only referenced in this file: ~/Library/Mobile Documents/BJ97GLR9R3~com~cjournal~icloud/Configuration.plist
It's just a reference to check if your current device is participating correctly with the rest of the iCloud container, so that you can tell if someone deleted the iCloud container behind you while the app wasn't active, the app would be able to handle that situation. It's only exposed to the user in case something is wrong and the user can quickly check this value from that plist file. In practice, it hasn't proven too useful to expose this to users, but something to build on for a future update.
Thanks for that feedback! I thought I had conveyed my own displeasure with CDIS at the end, and mentioned a few times that "only if it worked well". Maybe I should've highlighted this more to reflect my own frustrations that I've experienced so far. I just felt that the tone had gone to an extreme in the other direction (that it's completely unworkable; and even if it did, you shouldn't support it).
My point was mostly to discourage people from completely writing off the idea around CDIS, that you shouldn't work with it "even if it worked", and countering some of the incorrect assumptions that some people were making. I think there's great reasons to adopt it (theoretically), and (this might be personal opinion) I don't believe that they're too far from cracking it. I guess time will tell. I've figured out a few hacks to backup data, to recover from failed syncs, walk through users with cleaning up their iCloud containers and get devices to setup sync again. They're mostly hacks that shouldn't be required, but have gotten to the point where users mostly have a great experience with the app, and even if sync fails or they start seeing weird errors, I can recover their data and walk them through restoring their state. I've only seen 3-4 people who have lost access to their data completely, and that really sucked. But that's a risk anyone takes with any technology, home-made or provided by some other platform.
I am open to the idea that I'm maybe too optimistic about all this. But having spent a lot of time and energy on CDIS, and having my app in production supporting CDIS for a few months, I think it was valuable information to share. A lot of issues that devs might run into while testing don't actually pan out in real-world usage. People don't have their devices sitting open side-by-side, trying to edit data simulatenously. But in any case, my plan is to compile a list of all the issues I've experienced next, and maybe some of the hacks that I'm using to work around them, and do another write-up in the near future.
> "that you shouldn't work with it "even if it worked""
I simply have not seen this attitude at all on the internet. Everybody wants the promise of CDIS. All of the anger, frustration, and vitriol is around the broken promise of it, not the concept.
> "and (this might be personal opinion) but I don't believe that they're too far from cracking it."
That remains to be seen. There is a growing sentiment in the Apple dev community that Apple's QA quality is slipping, and slipping hard, and this has a large detrimental impact on developers.
I was recently at a conference where this "joke" was made multiple times. Whenever someone commented that "X might be fixed in iOS7" someone would pipe up "Great, then we can use it when iOS8 comes out."
The upgrade rate on iOS devices far outstrips Android, but even now, on the eve of iOS7, a good 15-25% of devices are still on iOS5. There is effectively a one-year gap between Apple coming out with new API, and being able to require the use of the API in your app (unless you feel like leaving up to a quarter of your userbase out).
With things like CDIS this one-year gap is effectively lengthened to TWO years. Apple comes out with something new that's broken enough to be unusable in production. We wait another full year for them to finish baking it. And then we wait another year for the install base to be wide enough to ship an app with it.
With CDIS this is coming up to be a FOUR YEAR GAP, assuming they make it production-stable in iOS7.
There is plenty of reasonable skepticism when it comes to doubting whether CDIS will be fixed at all, or be quietly swept under the carpet as a failed technology.
> "I've only seen 3-4 people who have lost access to their data completely"
In my experience data loss has never been an issue - loss of iCloud connectivity is. Which is to say, once a conflict resolution failure occurs, that device is now an island - no changes made there will be communicated to any other device, and no changes made elsewhere makes it to that device either. And there is no way to restore this connection that anyone is aware of it.
Data loss hasn't ever been a major problem here - when a breaking conflict resolution occurs Core Data's default behavior is to go all-local rather than delete data.
The inability to repair a broken iCloud link is 100x more aggravating than simply breaking, since it means having to tell a user that they are SOL. By far the greatest frustration I've encountered re: CDIS is exactly this - that once it breaks, it's permanently broken.
> "But in any case, my plan is to compile a list of all the issues I've experienced next, and maybe some of the hacks that I'm using to work around them, and do another write-up in the near future."
I'm looking forward to it, though I remain extremely skeptical that Core Data is production-ready.
I've now, collectively, been in rooms with literally thousands of angry CDIS developers. Very smart developers who have yet to be able to ship a single CDIS-enabled app because its stability is simply atrocious. I'm wondering how it is that your experience is so different from everyone else's - where you reportedly have CDIS working in a production app with few/no issues, while others can't even get their Core Data stores to stand up straight. That's a pretty huge gap in progress.
> I simply have not seen this attitude at all on the internet. Everybody wants the promise of CDIS. All of the anger, frustration, and vitriol is around the broken promise of it, not the concept.
- I referenced the Brent Simmons article and the Marco / Siracusa podcast early on in my post. They're all highly-visible and prominent members of the Apple dev community, and this was clearly their stance that I was challenging.
- Regarding upgrading, you can mark out certain features to be available on the latest version of iOS while maintaining general backward compatibility with the previous iOS version. My app is compatible with iOS5, but I don't expose the iCloud sync option to iOS5 users because I don't want them to use it. I've had 0 complaints about this policy.
> The inability to repair a broken iCloud link is 100x more aggravating than simply breaking, since it means having to tell a user that they are SOL. By far the greatest frustration I've encountered re: CDIS is exactly this - that once it breaks, it's permanently broken.
This isn't true. I encounter this problem fairly regularly with users, and the process I outline for them is this:
- turn off iCloud sync option from my app from all devices. This will make an object-by-object copy of 'ubiquity' sqlite db into their local sandbox
- nuke their container from Settings -> iCloud -> Storage and Backup -> Manage Storage -> Documents and Data -> Show All -> <my app> -> Edit -> Delete All. This cleans out their iCloud database and all metadata associated with it
- wait a few minutes for the delete to sync over to all devices
- choose one of the devices as the most recent 'truth' version, and use that to be the first device to sync up to iCloud
- connect second device to iCloud again, and this will fetch data from iCloud instead of uploading. Once done,from then on, sync will work again seamlessly across both devices.
The instructions have some nuance in them, but that's the gist of it. Resetting the iCloud container fixes almost all the problems that you would encounter with CDIS, and the hacks are around making backups and restoration of data as painless as possible, and trying to minimize data loss. Again, this adds customer service add-on, but it's far far from impossible.
This is the part that's news to me - I've observed myself and corroborated with many other devs that nuking a container prevents the container from being recreated by that app ID ever again.
This really is the one big sticking point - if nuking containers actually worked properly the scope of the problem is greatly reduced. Sure, potential data loss, but at least your devices start talking again.
I'd be interested in seeing code, but this is definitely something outside of your app. Very curious. I was very recently in a room full of CDIS devs who complain that the above is still broken in iOS 6.1.3, and I'm at a loss as to how you've been able to achieve successful recreation of an iCloud container that has been deleted via Settings.
Nuking a store works great; always has, even with iOS5 actually. And 'nuking' I mean specifically going into settings and doing a Delete All. If you delete the root ubiquity folder in Mobile Documents using Finder, then yes, you're never going to be able to use that ubiquity container again.
After nuking a store and waiting a few minutes (ideally restarting your device as well), the container is just as good as new. You can try it out with a basic CDIS app yourself and see.
That's the news part - I'm not talking about deleting the ubiquity container. Ever since iOS5, and even in iOS6, my experience - and the experience of every developer I've ever run into using CDIS - is that deleting a container via Settings -> iCloud -> Manage -> {appname} -> Delete All results in a permanent breakage.
I'm not calling you a liar - I'm quite confident it works fine for you, but I'm wondering how our experiences can be so different. This isn't just me, this is literally confirmed by entire room fulls of people who've been wrestling CDIS for months.
Just to chime in: I use this all the time in testing, and it's never failed on me. You have to do the right thing in your app to watch for these changes and gracefully reset and all, but I've nuked the container (from Settings->iCloud, on Mac and iOS) dozens of times now and never had permanent breakage of any kind.
Occasionally, after doing this, it'll appear to take much longer to provision a new ubiquity store (sometimes minutes, which is unacceptable), but never actually broken.
It's not just me. You can go through a lot of the threads on devforums.apple.com, in the iCloud section, and you'll hear the same thing. The solution to almost all problems is using the Delete All hammer. It's just an unpleasant solution, but definitely fixes the problem and lets you start fresh.
- using Apple-sanctioned technologies might improve your chances of getting featured by Apple. Of course, well-known popular apps get featured regularly by Apple, but this is one of the factors that goes into their calculations of who to feature. This is not a reason per se for using iCloud, but an added incentive (as I mention, it really didn't pan out for me!)
- Exporting data out of iCloud shouldn't be any more complicated than importing data into iCloud is. You can easily walk through the Core Data object graph and do whatever you want with the data. And with NSIncrementalStore, you can easily keep the core of your application the same and utilize some other web service to power the data for your app.
Personal angle: I work on such a 'contact interaction system' with an app I have in the App Store, and though I market it as "CRM", my goal is to build something that's very easy-to-use so that "anyone" can use it, for the people who are looking for a good system to manage their contact and customer interactions. I would love to figure out how to drive more traction around the idea, since it's something that's beyond the regular idea of "CRM app for sales". Any thoughts?