Archive for April 26, 2015

Sunday, April 26, 2015

iCloud Photo Library: the Missing FAQ

Joe Kissell:

Q: So, um… is there anything I can do about that whole bandwidth issue?

A: Yes. First, you can pause transfers. To do this, go to Photos > Preferences > iCloud and click Pause for One Day, which does exactly what it says. (You can manually resume transfers before the day is up by clicking Resume.) But if you need transfers to pause for a longer period of time, you’ll have to click that button every day. Your second option is to temporarily disable iCloud Photo Library altogether by going to System Preferences > iCloud, clicking the Options button next to Photos, and deselecting iCloud Photo Library. There’s no penalty for doing so; this merely disables syncing, and does not affect any photos on your Mac (except that if iCloud Photo Library has downloaded low-resolution versions of any photos but not the full-resolution copies at the moment you disable syncing, Photos may delete the low-resolution versions, and will warn you that it’s about to do so). If and when you later reselect it, syncing will resume.

But what if you quit Photos? Won’t that also stop syncing? Maybe. My initial experiments showed that transfers did indeed stop when I quit Photos. After Jason Snell pointed out that he had different results, I ran more tests. My revised results suggest that downloads from iCloud Photo Library pause when you quit Photos, but uploads continue even when the app isn’t running. Furthermore, My Photo Stream (if enabled) may transfer photos when Photos isn’t running. All that to say: quitting Photos might help in certain situations, but you can’t count on it.

Bandwidth is an issue, especially when traveling. On my last trip, I had to disable My Photo Stream and import via USB because, even overnight, the photos wouldn’t all finish transferring to my Mac over Wi-Fi. I also found that I needed to set a slow fixed transfer rate for Arq to prevent it from blocking all my other network connections. With the new photos removed from my phone daily, because it was full, and not enough bandwidth to upload them all to a cloud backup, I ended up setting up Time Machine to back up the new Aperture masters to an SD Card.

Update (2015-04-28): Photos doesn’t have a bandwidth limiter, just an off switch. John Siracusa discusses the poor family workflow and how iCloud Photo Library makes the iOS photo picker really slow.

Update (2015-05-04): Matt Henderson:

According to this Apple support document Faces data does not sync. Terribly disappointing.

Fraser Speirs:

The only reliable way I found to determine whether my Mac was completely finished migrating all the data to the cloud was to observe the Networking tab in Activity Monitor. When Photos was migrating, there was a very obvious pattern to the upstream bandwidth usage.

Matt Henderson:

My iPhone saw the Library data quite quickly, but my iPad didn’t, even after a toggling of iCloud Photo Library. Ben Brooks recommended toggling it on all my devices. I would have never considered doing that, but somehow it worked.


But we discovered that the iCloud Photos app on our second generation AppleTV doesn’t provide access to the library, just the “Photo Stream” and shared albums.


Watching videos in Photos on my Mac is very slow (over my Spanish ADSL connection), since the entire video has to download before viewing can begin. I wish there was an option to just stream them.


When cropping photos, I wish there were an option in the Setting to preserve the original aspect ratio. I almost never want a free-form aspect ratio when cropping (which is the default).

The One Line You Should Add to Every Makefile

John Graham-Cumming, who’s just written the GNU Make Book (Amazon):


print-%: ; @echo $*=$($*)

It allows you to quickly get the value of any makefile variable. For example, suppose you want to know the value of a variable called SOURCE_FILES. You’d just type:

make print-SOURCE_FILES

This works with the 2006 version of GNU Make that comes with Xcode.

Reviving an Apple Wireless Keyboard

After about five years of service, my Apple Keyboard started giving me lots of trouble: missing keys that I’d typed, repeating keys that I’d only typed once, showing the character accent pop-over when I hadn’t held down a key, and spontaneously connecting and disconnecting from Bluetooth.

In the past, these types of problems always signaled that the two AA batteries needed changing, even though they were usually shown at 20% or higher capacity. This time, however, changing batteries only helped for a few hours, and then the problems recurred. I tried several sets of batteries, all above 85% capacity. Restarting the Mac sometimes seemed to help, but only for a short time. Other Bluetooth devices worked fine with the Mac.

I was pretty sure that I needed a new keyboard when I came across this post by Kevin C. Tofel about using tin foil to fix a Bluetooth Apple Keyboard that wouldn’t power on. He put a little ball of aluminum foil between the battery and the keyboard’s positive contact to make sure that they were connected. My keyboard always turned on, but perhaps the problems were caused by it intermittently losing power. Sure enough, I dropped a much smaller ball of foil into my keyboard two days ago, and it’s been working perfectly ever since.

This is a great keyboard. The only other problem I’ve had is that the labels are wearing off some of the keys—the E and S are gone, along with half of the D and C, and much of the Down Arrow—though I only use it with clean fingers. The E has even developed a little depression. This never happened with other keyboards that I used, for more years.

Deprecating the Sync and Datastore APIs


We added the Datastore API in the summer of 2013 to support syncing structured (non-file) data with Dropbox. The Sync API and Datastore API are both part of the same mobile SDKs.

Since its launch almost two years ago, the Datastore API hasn’t seen the adoption we had hoped for. While some developers have adopted this API and loved it, the raw numbers show that it wasn’t used by very many apps.

The Datastore API is somewhat unique in that it, unlike the Core API, deals with non-file data, so we’re working directly with individual developers to help them migrate to an alternative. Existing apps built using the Datastore API will continue to work in the meantime.

I’m not aware of a good replacement for the Datastore API.