Tag Archives: icloud

Paying for iCloud storage

Dan Moren had an article at Macworld last week about the price for iCloud storage. Most iPhone users quickly run out of space for a backup, but they don’t use iTunes either because iCloud is just much simpler:

Apple’s philosophy is about making its products seamless and easy to use. Encouraging people to use iCloud backup is, in most cases, smoother and simpler than having to back-up to a computer.

It was 5 years ago that Steve Jobs introduced iCloud and talked about demoting the computer from the central hub:

Keeping these devices in sync is driving us crazy. So, we’ve got a great solution for this problem. And we think this solution is our next big insight, which is we’re going to demote the PC and the Mac to just be a device. Just like an iPhone, an iPad, or an iPod Touch. And we’re going to move the digital hub — the center of your digital life — into the cloud.

I use iCloud backup exclusively, with only the occasional manual iTunes backup when I know I’m going to immediately restore from it, such as when upgrading to a new iPhone. I expect most new iPhone users rarely sync with iTunes, relegating iTunes to a playback app for their iTunes rentals and Apple Music subscription, but not much else.

That’s certainly the case for my family, at least. After some lost photos recently, I told the kids I would bump their allowance by $1 to cover everyone having at least 50 GB of iCloud storage. No more excuses.

Maybe it should be free, as Dan Moren argues above. Or maybe Apple could encourage upgrades by bundling extra iCloud storage with Apple Music and other popular services. But even today, at 99 cents, it’s a small price to pay for cloud backup that you never have to think about.

Ulysses iOS missing Dropbox support

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.

iCloud is too opaque

Last night, Federico Viticci tweeted that he lost a draft blog post he was working on because of an iCloud problem:

“Just lost 1.5k words I had prepared for tomorrow because I wanted to try iCloud sync instead of Dropbox this week.”

The story has a happy ending because he was able to manually recover the document from the app’s database, but that is well beyond the complexity that most users could handle. iCloud is usually so opaque that we just can’t see what is going on behind the scenes with our data.

Everything I write on this blog (and notes for all my projects) goes into simple text files on Dropbox. I can edit from multiple apps on different platforms, the files are synced everywhere, and Dropbox tracks the revisions of each file so that I can restore a previous version at any time. I could take the text file I’m currently typing in, drag it to the Finder’s trash and empty it, and restore from the web in 30 seconds even without any kind of traditional backup solution.

That’s why all my photos are on Dropbox too. Instead of being opaque like iCloud, with no easy way to troubleshoot or recover files when things go wrong, with Dropbox it’s all there in the local file system or over the web.

Dropbox has had a few side projects and distractions, but their foundation is obvious and accessible, so they can keep coming back to that. Here’s Stephen Hackett writing in December about documents and photos after Dropbox shut down Mailbox and Carousel:

“As much as these apps were loved by their users, it’s clear that the company is moving in another direction. While things like Paper don’t make much of a difference to me, knowing that Dropbox will reliably sync my files, be easy to use on iOS and continue to be around is important to me. If Mailbox and Carousel had to go to make that possible, then so be it.”

I really like the clean UI in Dropbox’s Paper, but because it doesn’t yet sync with regular files like the rest of Dropbox, Paper isn’t building on Dropbox’s core strengths. Daniel and I use it for planning Core Intuition, but I wouldn’t use it for critical writing any more than I would use the new Apple Notes.

I hear that people love iCloud Photo Library and Notes, and that the quality of these apps and companion services has significantly improved. That’s great. (I also think that CloudKit is clearly the best thing Apple has built for syncing yet.)

But to me, it doesn’t matter if it’s reliable or fast, or even if it “always” works. It only matters if I trust it when something goes wrong. Conceptually I’m not sure iCloud will ever get there for me.

Core Intuition 152

We posted episode 152 of Core Intuition today, with discussion of iCloud Drive, iOS 8, and Yosemite, plus mini-rants about distributed version control, why Daniel uses Mercurial, and how I just switched everything to GitHub. I like how this episode turned out. As usual, it’s under 40 minutes, and not a bad place to start if you’re just subscribing for the first time.

The Core Intuition jobs site is still half off for a few more days. $100 to get your job in front of a bunch of great iOS and Mac developers.

(After a decade on Movable Type, I’m migrating this blog to a new system, so I fell into the trap of not posting much until that process is complete. I’ll have much more to write about this soon.)

iCloud sync narrative

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

iCloud vs. the web

“This MacStories article”:http://www.macstories.net/stories/iclouds-first-six-months-the-developers-weigh-in/ covers the progress that developers have made adopting iCloud over the last 6 months. Over the next 6 months, we should have an even better appreciation for what iCloud is and isn’t good for.

For iOS backups and iTunes Match, iCloud is fantastic. For private, app-specific data that doesn’t make any sense away from a single developer’s native Mac and iOS apps, it’s also excellent. There’s no question that using Macs, iPhones, and iPads today is a significantly better experience thanks to iCloud.

But there are two fundamental limitations in iCloud that make it inappropriate for a bunch of syncing uses:

  • No way to access it from other platforms or web apps.

  • No way to share data between apps from different developers.

I don’t expect Apple to change this. Again, for what iCloud was made for, these limitations are fine. It simply means that iCloud cannot replace web APIs that do solve these two problems.

“Here’s what I wrote”:http://www.manton.org/2011/06/faq_for_tweet_marker.html not long after announcing the Tweet Marker API:

“The primary goal with Tweet Marker is to enable different Twitter apps to work together. iCloud is designed for storage and syncing only between apps from the same developer, so it’s not appropriate as a replacement architecture for Tweet Marker.”

Think back to the so-called Web 2.0, which gave us web services to access previously closed-off data. This eventually led to truly dominant syncing APIs like Dropbox, Simplenote, and Instapaper. At the same time, we all have more devices than ever before. Syncing exploded on iOS in text editors and note taking apps. Without a proper shared file system between apps, or even an event or scripting system, these iOS apps looked to web APIs as the only way to communicate.

That has turned out wonderfully. With web APIs as the only solution, we see more compatibility between apps and more web services popping up all the time. If you create a new web app, it’s dead without an API. Every success of the modern web, from Flickr to Twitter, has an API that is available from any platform.

So then what about iCloud? If Web 2.0 made data more accessible, iCloud takes that same data and… keeps it closed. It’s a step forward on user convenience and a step back on interoperability.

If you’re a developer considering iCloud support, just make sure your data fits there. Ask yourself if your data is all about your app, or if it’s bigger than your app. Developers who are willing to take a risk on building an open API instead of iCloud could see new opportunities: web-based views of their data, compatibility with other apps, and syncing on the Mac outside of the App Store.

A couple years ago, “Shawn Blanc said about cloud syncing”:http://shawnblanc.net/2010/08/sans-cloud/:

“And my next wish? A cloud-based service like Instapaper, but for to-do items. I want it to be available in apps like Tweetie, Reeder, and more, so when I click on ‘Do Later’ it sends the link or item of note into a running to-do list (that syncs with Things, of course).”

Imagine if Things or OmniFocus or another tasks app opened up a slice of their private syncing API to make the Instapaper of to-do inboxes. Now take other APIs for all of the useful apps we use. Not just to-do apps as Shawn mentions, but RSS, photos, blog drafts, sketches, and more.

What I wrote above about Tweet Marker is still very much true. Since then, Tweet Marker has become the standard for last-read syncing between Twitter apps, with support for 15 apps and many more in development. I want to see more syncing platforms like this. Let’s think big and make apps work together.

Sandboxing and Clipstart

I wrote a draft of this post a few weeks ago, before Mac OS X Mountain Lion was announced. It was pretty critical of Apple’s aggressive approach to sandboxing, and I’ve kept most of that, but the new Gatekeeper feature for Mountain Lion at least gives me a way out. I don’t think Apple would have created Gatekeeper if they planned to abandon apps sold outside of the Mac App Store.

For the next release of my app Clipstart, I will be removing it from the Mac App Store and only selling directly from my web site. With Gatekeeper I hope to have some confidence that my customers will still be able to run the app on future versions of the OS.

But let’s take a step back, to a good blog post from Craig Hockenberry on moving xScope to use sandboxing. One of the most important things to keep in mind is that what works for one app may be unsuitable for another. Craig touches on this with an example from Panic’s Transmit:

“Of course there are some applications that have a harder time than others: primarily if those apps require access to all or part of the filesystem (think about syncing data with Transmit, for example.)”

Clipstart also falls into the same “needs to access the whole file system” category as Transmit. It’s not just one feature; the whole app is based on the fact that it can point to video files anywhere on the system, or manage your video library in a central location on any hard drive. These are things that are difficult to do in the sandbox, but even worse, I don’t see a clear path forward for existing customers to move into such a restrictive environment.

Maybe I could file bugs with Apple for exemptions, and reduce the functionality of my app to fit within the limits of the sandbox, but I’ve made the decision that it is just not worth it. I would much rather spend 100% of the time I have for Clipstart on new features only, not playing catch-up with Apple.

Atlassian has made a similar decision for their app SourceTree. On the sandboxing restrictions:

“The trouble is, the sandboxing implementation currently in place on Mac OS X Lion doesn’t allow for all the behaviours that real Mac applications do _right now_, behaviours which are not at all contentious, are approved in the Mac App Store already, and indeed are very much appreciated by users.”

Daniel Jalkut continues this argument, saying that sandboxing could be good for developers, if only the current entitlements weren’t so very incomplete. That’s true. But we can only make decisions based on what entitlements and APIs are there today, and today it’s not enough.

I will try to make this casualty of sandboxing as painless as possible for Clipstart customers. I will honor Mac App Store receipt files so that everyone can migrate to new versions of the app. And I’ll provide extra serial numbers to anyone who asks, for fresh installs on machines that never had the Mac App Store version.

Clipstart has turned out to not be a very good fit for the Mac App Store anyway. It’s the kind of app that you need to download and try out before committing your whole video library to it. Sandboxing is just the latest and most significant in a series of frustrations with the MAS.

For my customers, sandboxing isn’t actually a feature; it’s a bottleneck to getting work done. I can’t justify spending any time on it. I already have a product and platform (Tweet Library for iOS) where I can play the app review game. I want my Mac app to be a break from that, with a total focus on making the app better and a release schedule and feature set that I control.

So it was a relief to hear about Gatekeeper. I don’t want pulling Clipstart from the MAS to automatically doom the product, and now I don’t think it will. Instead of shying away from features that won’t work in the sandbox, I can even embrace them as a competitive advantage. I’m more excited than ever to get back to Mac development without this decision and chilling effect hanging over my head.

Push-based sync

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