zulfishah

It's available for iOS and Mac. Search for Contacts Journal in the App Store. Would love your feedback.

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?

Were it to be confirmed, would "Planet 9" actually be classified as a Dwarf Planet?

>App Review continues to take at least a week

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

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.

The winning team presented their project at a Meetup well before the Hackathon was even announced: http://www.meetup.com/Salesforce-com-Integration-Analytics/e...

Which is totally against the official rules for the Hacktahon, which stated "The application you or your team submits must: have been developed solely as part of this Hackathon" http://res.cloudinary.com/hy4kyit2a/image/upload/Final%201M%...

So there you go.

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.

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.

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.

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

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.

Good points, though I'll just say this:

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

Couldn't agree more than it's just badly implemented right now. It's at a "barely viable" stage right now. Article was meant to question the very assumption that it's a just a fundamentally bad idea to begin with, and all the negativity that's recently coming out in the press. Yes, it's not for every app or every situation, but it could be a great solution for a lot of apps (if only it worked a bit better!).

Every engineer's worst nightmare. I've worked at a one of the biggest software companies in the world, and I'm working on my own self-funded one-person startup: the panic before doing anything remotely involving production user data is still always nerve-wracking to me. But agree with everyone's assessments here of the failure of the whole company to prevent this. A hardware failure could have just as likely have wiped out all their data. If you're going to cut corners with backing up user data, then you should be prepared to suffer the consequences.

Thanks for sharing this. Took real guts to put it out there.

Try my app, "Contacts Journal" (http://itunes.com/apps/contactsjournal). It's iOS only, so no web interface, but it might be exactly what you need. Users love it (check out all the great reviews).

Disgusting.

For next year, you probably want to talk to an accountant about paying estimated taxes. If you drop 20k in taxes to the IRS at the end of the year, they're not going to be happy. In fact, you can get fines for doing that.