I had already uploaded my entire photo and video library to Google some time ago. In fact I was a big promoter of Google+ photos. (I don’t do the Google Drive system anymore, but that method could still make sense for some people.) But when I installed Google Photos on my phone it had to re-upload every photo in my library from the phone. No duplicates ended up in my library that I know of as a result of this process, so there must be some server-side detection.
But, since my photo library is largely not really on my phone, but in iCloud Photo Library, Google Photos actually caused (1) each of my photos to download locally to the phone before (2) being uploaded to Google and then (3) discarded as a duplicate. This happened for more than 11,000 photos and 250 videos. My iCloud Photo Library went from taking up around 7 GB of space on my phone to taking up 35 GB. As of this writing it’s back to around 15 GB as my phone discards local caches of cloud photos.
My understanding is that my iPhone will only ever download “device-optimized” versions of photos. I would hope that in the event of a duplicate photo Google knows to keep the definitely-full-resolution version added from my desktop and not the possibly-downrezed version from my phone.
Today, Google Photos decided to re-upload about 60 pictures from my phone. My best guess is that it is seeing the local photo (or thumbnail, or downrezed photo) as different than the photo that had been uploaded before, perhaps because of the behind-the-scenes operations of iCloud Photo Library. This is annoying, and again gives me anxiety that my Google Photo copy of a photo is being replaced by some low-rez version, or that I am going to end up with duplicates.
Google Photos is only “free” if you allow it to saved compressed versions of your photos–any photos over 16 MP will be reduced in quality. I don’t want that, so I have set it to only upload original files, which counts against your Google storage. (I currently pay $2 per month for 100 GB.) However, if you choose this option, even photos that are already under 16 MP will count against your storage. You can choose the “always free” or the “always pay” option, but there’s no “only pay for photos above a certain size” option.
Edits and deletions you make to your Google Photos library will sync back to iCloud Photo Library, through your iOS device. If you delete a photo on Google that is also saved on your iPhone, the Assistant will ask you whether you want to “sync deletes.” (This is true whether you delete the photo in the Google Photos app or on the website.) If you agree, the photos will also be deleted from your camera roll/iCloud Photo Library. Similarly, if you edit a picture in Google Photos, you should get a “sync edits” notification. (This only worked for me making edits in the app, not making edits in the website, which seems inconsistent.) Each time you must agree in the Assistant card as well as in the iOS pop-up–which is as it should be. However, if you make an edit to a photo in your camera roll/iCloud Photo Library, Google Photos will see that as a new photo, and upload it. So you will have your original photo and the edited version both up in Google Photos. Also, photos added to your Google Photo Library from another device or the web are not then synced to your local camera roll/iCloud Photo Library.
Overall, the smartest way to use Google Photos on an iOS device is probably not to also use iCloud Photo Library. Just have your local camera roll, and periodically delete it once Google has uploaded everything. If, like me, you want to use Google Photos as an extra layer of photo backups and to occasionally look at cool AI stuff, while keeping iCloud Photo Library as your primary photo system, you’re going to run into some strange little odds and ends, such as your entire photo library being downloaded and then uploaded again for no good reason.
For the record, my entire photo backup system is currently this: All my photos are in both iCloud and Google Photos. I have a Mac that runs Photos.app, too, which saves all my photos locally to an external hard drive in full resolution. That photo library is backed up continually via Time Machine, and I make a weekly clone of that external hard drive to another external hard drive with Super Duper. Finally, the whole thing is also backed up via Backblaze. So, my whole photo library, which you may have guessed is very important to me, is currently backed up to three local drives and three separate cloud services.
This is not because of its looks, its excellent features like Voice Boost or Smart Speed, or its no-nonsense playlist features. Rather, it’s the best designed because of its conceptual simplicity, and the features it does not have. Most other podcast clients, including Apple’s own, allow every podcast episode to be marked as played or unplayed, and then to be downloaded or not downloaded. Additionally, most of them allow you to stream a podcast episode, as well as download it before playing it.
Overcast dispenses with that: a podcast is either downloaded, or not downloaded. That’s it. A podcast that is downloaded is either unplayed, or in progress. The section in a podcast’s settings where downloaded podcasts are listed is just called “Unplayed.” (There is now the ability to tell the app not to delete episodes after they have been played–but there is still no explicit played/unplayed feature in the app.)
This makes managing podcasts very easy. You never run into a situation where a podcast you want to listen to is new and unplayed but not yet downloaded–as soon as the podcast is available, it automatically downloads. And if you’re done with a podcast, you simply swipe to delete it. You don’t have to worry about some distinction between marking a podcast played (but not deleting it), deleting it (but not marking it as played), or both deleting a podcast and marking it as played. (When I’m done with a podcast episode in Apple’s podcast app before it’s over, I always both mark it played and delete it.)
Overcast, left. Unplayed=Downloaded. Simple. Apple’s Podcast app, right, complete with downloaded and undownloaded unplayed episodes, downloaded and undownloaded played episodes. Not simple.
Marco has said before that he is working on adding streaming. I hope he can do that without losing the app’s simplicity. For example, just allow people to stream episodes from the “All” area, without adding a played/unplayed feature. And rename the current “Unplayed” area to “Downloaded.”
Overcast’s design simplicity comes with tradeoffs: it’s not a suitable app for particular use cases. I will list two. There are some podcasts that I subscribe to where I want to listen to every single episode. Perhaps sequentially. There are many history podcasts of this sort–for example, Mike Duncan’s “The History of Rome” podcast, which ran from July 2007 through September 2013, is 179 episodes, and you really have to listen to them from the beginning. It would be unwieldy to download all of these, and they might fill up your phone. There are many “history of” podcasts of this sort. Another podcast I listen to is the USCCB’s “Daily Readings” podcast–the Catholic lectionary. This podcast updates once a month, with one episode per day of the month. But I might not want to download thirty-one episodes all at once. For podcasts like this, there are two options. One, don’t listen to those podcasts with Overcast. Use Apple’s built-in Podcast.app, instead, for instance. Or, use Overcast for those podcasts, but keep track of which ones you have listened to some other way and just manually download each episode before you want to listen to it. I just use Podcast.app. It’s not written in the sky with letters of fire that you can only use one podcast app at a time.
The fact that Overcast has a simplified approach to podcasts comes with tradeoffs is no reason to reject its simplified approach.1 A complicated approach comes with tradeoffs, too, though they can be less visible–the amount of time users spend fiddling with settings, mental overhead, and so on. I wish more apps would ditch “essential” features the way Overcast has.
I note the one area where I disagree with Marco’s approach: his lack of support for chapters. It’s not that I disagree with his conclusion that it’s not worth the development time to add a feature requested by a minority of users–though I am one of those users (chapters are useful for navigating the weekly 9 hour, full-text podcast of The Economist). But rather, I don’t think that adding chapter support would necessarily add UI complexity: I would add the list of chapters to where podcast show notes are currently displayed, and, if a podcast has both notes and chapters, display the notes under them. Navigating through chapters would be solely through this interface. I wouldn’t bother with “skip chapter” buttons or automatically scrolling in the list to the currently-playing chapter. Users who don’t care about chapters would never see any of this. However, this might not be enough for some chapter-loving users, so screw them (me). ↩