After I blogged about Ulysses for Mac, a couple people told me that an iPad version was coming soon and that it was great. That new version shipped this week. I put down $20 immediately even before reading the positive MacStories review by David Chartier.
Unfortunately I can’t use it much because it has no native Dropbox support. For a market that has literally many dozens of Dropbox text editors, I didn’t consider that Ulysses would ship without something so integral to my writing workflow.
(The Mac version doesn’t have this problem because of the concept of “External Folders”. I simply add my Dropbox notes folder to Ulysses on my Mac and everything syncs.)
Last month I wrote a post called iCloud is too opaque, in which I made an argument against having important text files and photos synced to a backend that allows no visibility when things go wrong, and no compatibility with other apps. Ulysses for iOS falls into this trap. Its use of iCloud is private to the app, unlike iCloud Drive or Dropbox which are accessible from other apps.
I know I’m not the only one who feels this way. The FAQ for Ulysses spends considerable space trying to explain away their lack of Dropbox support, even attempting to pin the issue on Dropbox instead of Ulysses itself.
The Soulmen, makers of Ulysses, are talented designers and developers, and I’m typing this in Ulysses for Mac because their app has a great mix of features and attention to detail. I respect that they’ve grown the company to 11 people already. But closed syncing solutions aren’t a good choice for exclusivity. Having cross-platform syncing across competing Twitter apps is why I created Tweet Marker, so you can be sure I want the same for my text documents.
Last year I wrote that I would be removing Tweet Library from the App Store at the end of December, and later said on Core Int and in a tweet that there would be one last update before the app is gone. It’s well into January and the old version is still for sale. I’m over a month behind schedule but still plan to release the updated version and stop selling the app.
On the latest Release Notes podcast there was a great discussion about when to give up on an app that isn’t making money, including a mention of my plan with Tweet Library. Joe and Charles talked about why it’s usually such a bad idea to promise features before you ship, and whether there’s an obligation to give customers any updates at all.
I pretty much agree with everything they said, but the upcoming Tweet Library 2.7 “features” are different. My goal with this release is for the app to be functional and stable for as long possible. I think the app needs better syncing of tweet collections to help future-proof it, to make it easier for customers to move between iOS devices when they upgrade their iPhone or iPad a year from now. For an app that is going away, I should do everything I can to make sure that a customer’s data is accessible and that import and export are as robust as possible.
It’s a reasonable question to ask why I would spend so much time working on something that will essentially bring in no additional revenue. But while it won’t directly make any money, it probably helped convince some new customers to buy the app over the last month, and it will very likely reduce the support burden for the app over the following year.
I also view it as a sort of parting “thank you” to my customers. It’s just the right thing to do to wrap up the app. Panic did the same thing when they stopped selling Unison, releasing a major free update at the same time.
If you’re interested in picking up a copy of Tweet Library before it’s too late, you can buy it on the App Store for $4.99. The new version should ship in early February.
Rich Siegel joins the discussion of iCloud syncing problems, adding the most technically comprehensive essay I’ve seen yet:
“Corrupted baselines are another common obstacle. While attempting to deploy iCloud sync on Mac OS X 10.7, we ran into a situation in which the baseline (a reference copy of the synchronization data) would become corrupted in various easily encountered situations. There is no recovery from a corrupted baseline, short of digging in to the innards of your local iCloud storage and scraping everything out, and there is no visible indication that corruption has occurred — syncing simply stops.”
I learned a lot by reading this. Also check out the post from Brent Simmons on why controlling your own web services is so important.
Pretty sure we hit a tipping point in the iCloud just doesn’t work narrative this week. Whether that judgement is fair or not, Apple should drop everything to focus on making iCloud totally robust in time for WWDC. (And I say that even though I use neither Core Data nor iCloud, and probably never will.)
With the success of Tweet Marker, several people suggested I should build a sync server for RSS. This was last year and earlier this year, before Google Reader officially shut down, but after it was clear that we needed something better. I jotted down some notes for a couple ideas but ultimately decided not to do it. I’ve already got my hands full with my current shipping products!
Luckily many great developers are now on this. Feed Wrangler from David Smith, hopes for a possible NetNewsWire Cloud, more interest in Fever, and other established web apps like NewsBlur and Feedly. As Marco Arment said, this could end up being a great thing for innovation in blogs and RSS again.
But just because I’m going to watch on the sidelines for the server sync part of RSS, doesn’t mean I’m going to completely skip building better RSS support into my own products. There’s a lot I’d like to do with client-side RSS support in Watermark.
“Guy English writes about iCloud”:http://kickingbear.com/blog/archives/202 and the magic glue (Push Notifications’ persistent connection) that makes it work:
“Each of these new features tickle the persistent ‘push’ connection and trigger some action on the device. The short-form state may be transmitted immediately and set on any connected device within moments. Document syncing is likely to trigger a negotiation process to compare the state on any one device with The Truth stored on Apple servers and replace the document on the device with the latest revision — this has the advantage of limiting the window between syncing where conflicts are most likely to occur.”
Sync speed matters. The first note sharing server I built for VitalSource years ago assumed a lot of offline time, and despite “my blogging in 2007 that it was”:http://www.manton.org/2007/01/bookshelf_note_sharing.html “magic”, in practice it could take 5-10 minutes before all your computers got their act together to get a set of highlights completely synced. With that kind of lag, note edits might happen on a client in the meantime, so we remembered conflicts everywhere and had a UI for resolving them.
Too complicated. The new system, recently rolled out in Bookshelf for iPhone and iPad, syncs so much more efficiently and quickly that conflicts don’t need the same emphasis. We can throw away a bunch of code and simplify the user interface.
I’ve yet to do anything with iCloud except read the release notes and sit through a couple WWDC sessions, but we’re going to have a fantastic platform if it can deliver the same speed and reliability of Push Notifications. Guy’s post is the first I’ve seen to connect the dots, capturing how well-positioned Apple is to use this plumbing for all sorts of stuff.
So you want to sync the last-read tweet with all your different Twitter apps on iPhone, iPad, and Mac? Yeah, me too. While I hope to build a version of Tweet Library for other platforms, what I’d also love is to be able to switch between clients and know that each one will pick up where I was last reading in the timeline.
That’s why I’m introducing a new service for Twitter developers: Tweet Marker.
I’ve already showed it off to a few developers, and if you’re writing a Twitter app I’d love for you to support it too. It will be baked into the next version of Tweet Library.
There are still some unknowns (especially around whether I will need to ask for help to cover hosting costs), but I wanted to launch it now before WWDC so that other Twitter app developers meeting at the conference can give me feedback on the service. Tweet Marker has actually been running for months, and when an opportunity came along this week for a new logo (thanks Alex!), I knew it was past time to finish documenting the service and get it out.
To be successful it needs at least 2 apps to support it (I’ll supply one of those). I’ve tried to solve all the other basic problems. It’s simple, fast, scalable on Heroku, and protected so that mischief-makers can’t tamper with tweet IDs.
Send me an email or find me in person next week if you have any feedback.
Update: This post has been updated to reflect the service name change from Tweetmarks to Tweet Marker.