Limpando meus 200 GB do iCloud com algum JavaScript
A Biblioteca de Fotos do iCloud da Apple é acusada de relatar uso inflado de armazenamento, com alguns usuários descobrindo que vídeos são contabilizados no iCloud como muito maiores do que os arquivos que eles conseguem baixar de fato. Os comentaristas propõem explicações técnicas — como originais ocultos, histórico de edições, múltiplas codificações e metadados opacos da biblioteca Photos —, mas argumentam que as ferramentas da Apple dificultam ver ou limpar o que realmente ocupa espaço, empurrando as pessoas para planos de armazenamento mais caros. Outros compartilham alternativas, ferramentas de terceiros e opções de auto-hospedagem, ao mesmo tempo em que apontam preocupações mais amplas com aprisionamento, exportação fraca de dados e escolhas de produto orientadas por assinaturas.
Discrepâncias no armazenamento do iCloud
- Vários comentaristas veem a divergência entre os tamanhos de arquivo reportados e os reais como potencialmente séria, até digna de processo, se for generalizada.
- Outros argumentam que isso é, em grande parte, como o Photos e o iCloud funcionam: os originais são sempre mantidos, as edições são metadados, e dados extras específicos do app (miniaturas, dados de rosto, versões) são armazenados e sincronizados.
- Alguma especulação técnica: múltiplas codificações ou resoluções por vídeo, contêineres HEIC com múltiplos frames, backups/versionamento e overhead interno do armazenamento de objetos.
- Um exemplo do artigo (128 MB reportados vs arquivo de 48 MB, ~170 MB liberados ao apagar) leva pessoas a suspeitar de cópias adicionais ocultas ou formatos extras.
- O consenso: o comportamento pode ser tecnicamente explicável, mas é opaco e parece hostil ao usuário quando conta contra cotas pagas.
Opacidade e ferramentas ruins
- Muitos reclamam que as interfaces da Apple não expõem os tamanhos reais por item nem facilitam a limpeza, especialmente para Photos, iMessage e backups do iCloud.
- iMessage no iCloud é destacado: sem visualização na web, busca quebrada, relatório de tamanho impreciso, exclusão lenta/com bugs e possível corrupção de banco de dados.
- Alguns veem isso como design de padrões obscuros para empurrar usuários para planos de armazenamento mais altos e recorrentes.
Preços e níveis
- Frustração frequente com:
- 5 GB gratuitos sendo, na prática, inúteis para dispositivos modernos.
- Saltos grandes entre 50/200 GB e 2 TB, sem um nível intermediário de 400–500 GB.
- Outros contrapõem que armazenamento em nuvem é barato e vale a pena pagar em vez de autogerenciar backups multi-dispositivo.
Workarounds e ferramentas
- Usuários mencionam:
- Baixar toda a mídia via app do iCloud para Windows, Photos no Mac com “otimizar” desligado, ou o portal de exportação de dados da Apple.
- Ferramentas de terceiros: baixadores de fotos do iCloud, osxphotos (incluindo limpeza RAW+JPEG preservando metadados), PhotoSync, apps de deduplicação e scripts que usam PhotoKit ou AppleScript.
- Um script Tampermonkey/Greasemonkey derivado do snippet JavaScript do artigo para destacar arquivos grandes na interface web do iCloud Photos.
Auto-hospedagem e alternativas
- Alguns preferem soluções de fotos auto-hospedadas (por exemplo, NAS + apps como Immich) por transparência e controle, embora reconheçam a complexidade e a necessidade de backups separados.
- Outros escolhem explicitamente grandes provedores de nuvem (Apple, Google, Microsoft) pela conveniência, apesar desses problemas.
Questões em aberto
- Não está claro quanto da discrepância se deve a bugs versus design intencional.
- Não está claro exatamente o que entra nas cotas do iCloud para álbuns compartilhados, fotos ao vivo e derivados internos em todos os casos.