Cory Solovewicz receives more unwanted emails than you. Seriously—it’s a lot more. Since December 2024, one of the domains at which the security researcher receives email has registered 401,796 messages—by his calculations that’s an average of 699.99 pings per day.
This deluge isn’t the regular flood of spam, newsletters, and unwanted deals that fill many people’s inboxes. Instead, companies and other organizations are inadvertently sending Solovewicz other people’s private information and company secrets. Over the last few years, he’s received injury reports from a city government, confirmation of people’s pizza orders, and account setup emails from a school platform. “I get service orders for people that need repairs. I get lots of test platform credentials,” says Solovewicz, a security researcher and consultant.
Solovewicz is receiving the avalanche of messages as he’s the owner of the domains noreply.us and noreply.net, which he purchased in 2020 and 2024, respectively. After originally planning to use the noreply.us domain as a catch-all email—which receives mail sent to any @ address on that domain—to filter messages and enhance his privacy, the researcher quickly noticed that other systems were sending mail to @noreply.us addresses. “I created an accidental honeypot,” Solovewicz tells WIRED. “I had no idea it was going to turn into this.”
This idea is so powerful—and so longed for—that it’s escaped containment among the Apple crowd. I’ve seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped.
People conflate a bunch of different ideas when talking about Snow Leopard:
Were there really zero no features? No, but there were fewer user-facing ones.
Was the initial release especially low in bugs? No, but it was better than Leopard’s.
Did it feel faster? Yes.
Was the final release especially low in bugs? Yes, it was fantastic.
Was it just because of the longer release cycle before Lion? No, they really did focus on quality for the initial release. And they didn’t add as much stuff mid-cycle as they did with Tiger and Leopard.
Snow Leopard’s stated goal internally was reducing bugs and increasing quality. That is a fact, not marketing. I am not sure why people on the internet don’t believe that, but I was there. If you wanted to ship a feature you had to get explicit approval from leadership and the bar was high. In normal feature releases it operated bottom up “here is what we are planning to ship” and in Snow Leopard it was top down “can we ship this?”.
AFAIK Snow Leopard was the first release of this kind (the first release I worked on was Jaguar or Puma), and was a direct response to taking 8 software updates to stabilize 10.5 and the severity of the bugs found during that cycle and the resulting bad press. Leopard was a HUGE feature release and with it came tons of (bad) bugs.
[…]
Testing was basically engineers, internal QA, some strategic partners like Adobe and MS, and the Apple Seed program (which was tiny). There was very little automated testing. Apple employees are not representative of the population and QA coverage is never very complete. And we sometimes held back features from seed releases when we were worried about leaks, so it wasn’t even the complete OS that was being tested.
Software updates are always needed, though the issues they fix became less severe over time due to larger seeds (aka betas), recovery partitions, and better / more modern development practices. But I can tell you FOR A FACT that Snow Leopard had fewer major bugs over its lifetime, coalesced very quickly, and was extremely solid when Lion was released.
I agree with you that Snow Leopard was billed as no USER VISIBLE features. But people did NOT just fix niggling bugs, it was an architecturally huge release. E.g., it introduced GCD. And unless I’m confusing the year, it rewrote the Mail backend to use it and mail hasn’t had reliable search since.
My memory is that quality was so low that we pushed back the release. With the extra time we did manage to fix enough bugs that it was well received. But internally it was more destabilizing than most releases due to the amount of architectural churn.
Yeah as someone else that worked on Snow Leopard I found this article and ones like it a bit silly. They’re a lot like the old “debug code” posts on Mac forums back in the day trying to explain why Puma was slow (no, you’ve got a G3 and an unaccelerated video card).
Tiger and Leopard were sprawling releases. Tiger covered 32-bit and 64-bit PowerPC, then 32-bit x86, then 64-bit x86 Macs. Tiger was also what I guess I’d say is the first “modern” OSX release, with subsystems like launchd and a more mature OpenDirectory replacing older NeXT subsystems.
Leopard in my experience was a train wreck. It shipped a lot of new features, both user facing and back end frameworks, but the development was seriously impacted from teams losing engineers to iOS. Leopard had features planned assuming 100% availability of SWE’s resources but ended up with 40-50% of SWE’s resources (made up numbers based on my feels at the time). Many new frameworks in Leopard did not land or get stable until very late in the development cycle which meant everything downstream had to scramble right before GM. It was 100% the case that Leopard was not really stable until 10.5.8 and still sucked IMHO.
There was a lot of clean-up needed in MacOS and that was Snow Leopard. It was not a perfect release but 10.6.3 (the second disc pressing IIRC) and onward were very stable. Dropping PowerPC support really helped focus QA since they didn’t need the massive array of test hardware Tiger and Leopard required. You also didn’t need to wrangle builds for four architectures, including multiple compilers as a few libraries (if not whole frameworks) were compiled with ICC on x86 for performance reasons.
The “Snow Leopard wasn’t that great” meme is weird. I’m sure it had its problems like every OSX release did. Unfortunately most OSX releases broke someone’s workflow. Snow Leopard ware no different. But it was always billed internally as a “no new features” release and those features that it did ship faced a very high bar to get in the release. I definitely look back on Snow Leopard as a high water mark for macOS quality in terms of a release.
If you weren’t there then you don’t know why I considered getting a “10.6.8” tattoo at one point. Boot Camp was no longer siloed, zero-drama Exchange support was baked in, Quicktime X hauled ass, and It was the definitive answer to the smoldering wreckage of Vista.
Snow Leopard has always remained the best Apple OS in my memory. For me Mail search was perfect all the time, once spotlight finished indexing it was incredible, iTunes, finder, everything just worked. The consistency was felt everywhere…
Nonetheless, when I send an email in Mail app, from a non-iCloud account to an non-iCloud account, Mail immediately triggers an iCloud connection, as revealed by Little Snitch.
[…]
What could Mail be querying and saving in CloudKit when I’ve disabled Mail in iCloud?
[…]
As you can see in my screenshot at the beginning of this blog post, I have Contacts turned off in iCloud settings, so my Previous Recipients list should not be synced to iCloud. Nonetheless, I followed the commenter’s suggestion of logging in Terminal. I saw log messages that referred to com.apple.mail.recents, which might indicate Previous Recipients and would certainly explain why this happens when I send an email.
[…]
I do object to notifying Apple that I’ve just sent an email. That in itself seems like a violation of my privacy.
The settings are confusing, even more so than with System Preferences. If you go to System Settings ‣ Apple Account, it shows a round rect that says Mail and shows the Mail icon. If you click this, it lets you uncheck Sync this Mac for iCloud Mail. This mirrors the iCloud Mail checkbox that you get when you click See All to see the full list of apps. I don’t like how the top-level name and icon suggest that you’re going to a settings sheet for the Mail app, but then it actually gives you iCloud settings.
Importantly, there’s also anotherMail checkbox in that list. It’s easy to miss because, first, why would you expect to see twoMail checkboxes?
And, second, it’s not obvious that there are actually three lists: a bunch of “favorite” system apps, in non-alphabetical order, for some reason including lesser ones like Freeform and Image Playground; followed by a second list of system apps in alphabetical order; and then a third list of alphabetical third-party apps.
Mail is in the second list, along with (to me) other top-tier apps like Books and Maps. Anyway, this second Mail checkbox controls the syncing of non-mail Mail data such as rules and smart mailboxes. But not, apparently, according to Apple, the previous recipients.
Na carta aberta, intitulada “Apple is getting this wrong” (“A Apple está entendendo isso errado”, em tradução direta), a empresa de Sam Altman tenta demonstrar inconsistências na narrativa apresentada pela Apple aos tribunais, classificada por ela como “descuidada, agressiva e estranhamente pessoal”. A OpenAI também diz que a prática não faz jus à grandeza histórica da Maçã.
Quanto às questões endereçadas na carta, a acusação principal — de que Tang Tan, líder de hardware da OpenAI e ex-designer da Apple, utilizou seu conhecimento sobre os procedimentos internos da Apple para repassar informações confidenciais sobre os seus produtos — foi contestada, com a versão oficial da OpenAI alegando que Tang sempre foi enfático quanto à falta de intenção em fazer uso de segredos industriais de outras empresas. A confusão sobre a revogação de acesso já havia sido mencionada em uma reportagem do The Information.
Sobre Chang Liu, cuja acusação envolvia a retenção de dispositivos e acessos para baixar arquivos internos, a réplica à Maçã, caso verdadeira, é um tanto reveladora: na carta, foi mencionado que funcionários da Apple entraram em contato com Liu mesmo após a sua saída para localizar os arquivos de projetos internos, revelando uma fragilidade no processo de revogação do acesso a arquivos internos. As mensagens trocadas entre Chang e um funcionário da Maçã via iMessage foram divulgadas junto da carta.
Já tratando sobre a alegada ciência da OpenAI quanto aos temas do processo, a dona do ChatGPT expôs emails de advogados externos que representavam a Maçã admitindo um erro no envio das mensagens, ocasionado por uma confusão entre os sobrenomes de Che Chang (conselheiro geral da OpenAI) e de um funcionário de sobrenome Wang — a quem, alegadamente, se referia a mencionada conversa por telefone, que nunca aconteceu, de acordo com a carta e com uma confissão feita em um dos emails divulgados.
A carta não cobriu, no entanto, as acusações de que a OpenAI vinha incentivando funcionários da Apple a realizar entrevistas para os seus cargos e fornecer detalhes sobre dispositivos ainda não lançados, e nem o suposto contato feito por parte da OpenAI com fornecedores da Apple sob o apoio de dados internos importantes.
Solicitação de liminar
Ontem, a Apple solicitou, de maneira preliminar, uma liminar para impedir que Liu e Tan possam acessar, obter, utilizar ou divulgar informações confidenciais. O pedido foi rebatido na carta:
O pedido da Apple por uma liminar preliminar é baseado em informações falsas e é completamente desnecessário, porque não temos, nem queremos ter, nenhum de seus segredos comerciais. Estamos muito mais interessados em construir produtos e tecnologias inovadores que ampliem as fronteiras do que é possível.
Até o momento, a Maçã não se pronunciou sobre a resposta da OpenAI.
A nova versão foi compartilhada pelo usuário mactracker na versão beta do macOS 27 e, como apontado por ele, permite exibir sugestões contextuais de respostas inteligentes geradas pela Siri sem a necessidade de inserir automaticamente no rascunho, semelhante ao funcionamento de outras inteligências artificiais (IA) em apps de email.
As opções da nova barra incluem alternativas de edição, reescrita, correções gramaticais e/ou de escrita e uma opção intitulada “How does this sound?”, além das ferramentas tradicionais de formatação, escanteadas na lateral direita do novo layout.
Na versão atual, essas opções de formatação de texto também estão recolhidas na lateral direita da janela do aplicativo, desaparecendo por completo assim que se seleciona a opção de escrever com a Siri.
O novo layout está oculto por trás de uma feature flag interna, de forma que a maioria dos usuários da versão beta não consegue habilitá-lo. A beta 4 apresenta ainda algumas inconsistências no funcionamento do recurso, como a ausência da barra na escrita de novas mensagens, restringindo o seu funcionamento às réplicas de email.
Não se sabe ao certo se o recurso chegará à versão final do macOS 27 (prevista para aterrissar em setembro), mas ele parece acompanhar as reformulações propostas sobre a integração das ferramentas de IA no cotidiano do ecossistema da Apple nos sistemas 27.
A Anthropicanunciou uma atualização para o modo de voz do Claude, que agora passa a ser compatível com os modelos Opus e Sonnet, ampliando as suas capacidades de funcionamento.
Até então, o modo era compatível somente com o modelo Haiku, voltado a respostas rápidas e com menor tempo de raciocínio. Agora, aqueles que possuem acesso aos outros modelos de inteligência artificial (IA) da Anthropic poderão utilizá-los durante conversas por voz, aproximando a experiência da entrega feita durante as interações por texto.
Segundo a empresa, a novidade permite o uso para fornecer feedbacks sobre a comunicação do usuário, simular apresentações ou até mesmo auxiliar em sessões de pesquisa mercadológica e brainstorming. O modo de voz do Claude também se tornou compatível com a integração de aplicativos como Gmail, Google Agenda, Slack, Canva e Notion, permitindo que a IA altere os horários de reuniões, redija emails ou crie documentos diretamente por comandos de voz.
O recurso também passa a dar continuidade a partir de uma conversa iniciada em texto, utilizando automaticamente o modelo previamente solicitado para manter a fluidez das interações, sem a necessidade de recomeçar uma conversa para iniciar o modo de voz. A cota de uso é a mesma em ambas as formas de uso.
Quanto aos idiomas compatíveis, além do português (do Brasil) e do inglês, temos francês, alemão, hindi, indonésio, italiano, japonês, coreano e espanhol (da Espanha e América Latina). A Anthropic pontua que o idioma deverá ser selecionado manualmente, já que o Claude não é capaz de reconhecer essa informação automaticamente.
No momento, a repaginada do recurso está em versão beta tanto para os usuários do Claude no app mobile quanto nas versões web e desktop — a Anthropic, porém, recomenda o uso principalmente no celular. Até agora, apenas os planos pagos possuem acesso aos modelos Sonnet e Opus, enquanto usuários da versão gratuita permanecem com o Claude Haiku.
A vulnerability in Apple’s “Hide My Email” tool lets almost anyone discover a person’s real email address that is supposed to be hidden by the feature, and Apple has failed to fix it for more than a year, according to a security researcher and 404 Media’s own tests.
[…]
“Apple Hide My Email is leaking email addresses that are supposed to be hidden. We reported the issue and replication instructions to Apple over a year ago. We don’t know why it hasn’t been fixed, but we don’t feel comfortable waiting any longer. Hide My Email users deserve to know that it may be possible for attackers to discover their hidden email addresses,” Tyler Murphy, the co-founder of EasyOptOuts, which discovered and reported the issue to Apple, told 404 Media.
“Free, publicly accessible people-search sites make it easy to link an email address to other personal details, so people relying on Hide My Email for safety may be at risk,” Murphy added.
[…]
To test the issue I generated a new Hide My Email address and provided it to Murphy. Around five minutes later, he replied with my real email address linked to my Apple account which was supposed to be hidden.
Murphy said that he reported the issue to Apple in June of last year, and the company told him it was looking into it. Apple said it had been fixed in March of this year, but Murphy found that wasn’t the case. He again contacted Apple, with the company saying that it would appreciate him not revealing the existence of the flaw until it had been resolved.
Apple then said it planned to address the issue in June, but since it still hasn’t been fixed[…]
March 19, 2026: Using the reproduction instructions from our initial report, we determined that the vulnerabilities hadn’t been fixed.
May 22, 2026: We realized that the vulnerabilities may have greater severity and scope than we thought initially and reported this to Apple. Apple never acknowledged the report of increased severity.
June 30, 2026: Apple again reported that the vulnerabilities were fixed and asked us to verify. We determined that the vulnerabilities hadn’t been fixed.
Very few details are available right now. I have seen speculation that the original email address is revealed when someone replies using their hidden email address, but the impression I get from Cox’s reporting is that no user interaction is necessary[…]
[…]
I am also unclear about how, as of May, the EasyOptOuts guys found the “vulnerability may have greater severity and scope” than initially reported. Ominous, though.
I don’t know whether I’ve accidentally stumbled upon that vulnerability, or perhaps in this case the Hide My Email user just messed up in some way, but I’ve definitely discovered a bizarre and troubling Hide My Email bug in Mail app (on macOS Sequoia 15.7.7).
[…]
Bizarrely, however, Mail app displayed an alert that I’ve never seen before, “This message was forwarded to you by Hide My Email,” despite the fact that I have previously received many emails from people using Hide My Email.
[…]
Why I am seeing two different @icloud.com email addresses, one of which appears to be the sender’s unhidden address?
Why are the To: and From: fields in my reply disabled?
Why is my reply not from my @underpassapp.com email address but rather displayed falsely as from the sender’s @icloud.com address and really from my unrelated Apple Account address?
Apple this week was sued over a reported “Hide My Email” flaw that could expose a user’s real email address. The proposed class action lawsuit alleges that Apple violated California’s false advertising law and other consumer protection statutes by knowingly offering a feature that does not work as advertised.
This is interesting in that the June 2025 bug report is the evidence that Apple “knew” the feature didn’t work, while “Apple continued to represent to consumers that Hide My Email
would actually hide users’ email.” How long are they supposed to get to fix a bug?
The misleading user interface elements in Mail app are a bug, but by themselves they’re not a vulnerability. The vulnerability is that when I send a reply to my maliciously crafted email, my Apple account email address is disclosed in the “From” field of the sent reply! In other words, the Mail app interface lies, fails to show the true sent value of the “From” field.
There are a couple of crazy aspects to this information disclosure vulnerability:
It does not require that the victim actually use Hide My Email! I never use it. As I mentioned in my previous blog post, I don’t even have an icloud.com email account.
It does not matter which of the victim’s email accounts receives the email from the attacker. If your Apple account email address is a@foo.com, but you receive a maliciously crafted email addressed to b@bar.com, Mail app will still send your reply from a@foo.com, thereby disclosing your Apple account address.
Apple addressed a vulnerability in Hide My Email that exposed a user's real email address, reports 404 Media. Apple told the site the issue was fully fixed in a patch released on July 3.
[…]
While the bug has now been addressed, email logs that pre-date the fix could still expose user email addresses.
Later this summer, Apple will unify the email domains used by Sign in with Apple and iCloud+ Hide My Email under a single, shared domain: private.icloud.com.
New addresses generated for both features will be issued on the new domain.
[…]
Existing addresses on the legacy domains will continue to work and forward mail to users without interruption.
It’s unclear to me what the benefit of this is. Is there a reason to migrate legacy addresses?
This makes it much easier to ban all aliases without affecting non-relay mailboxes on iCloud mail.
This is certainly a big hit for iCloud privacy, since some plausible deniability together with Apple’s backing made banning iCloud aliases costly. But now a lot of services will just refuse to accept these emails, just like what happens with free temporary mailboxes.
But my retort is that a service that won’t accept these email addresses is one that I probably don’t want to have anything to do with. The only reason not to accept private.icloud.com email addresses is if you want to do something invasive with users’ actual email addresses.
The main problem I have with Hide My Email is that some customers use it and then have no way to look up their purchase info via e-mail because they don’t know which address they used. Of course, I wouldn’t reject such addresses, but I wonder if services will start using the new domain to recognize that Hide My Email is being used and nudge the user to provide a different address.
[… Apple] decides to do a big feature. The circus comes to town, they build the feature, they launch it, they leave town, and that feature sits there.
And the problem is, there’s bugs, things are broken, and in Year Two, you’re like, “You’re going to fix all the things that were broken in the thing you shipped last year, right?” And in the last decade, I would say, a lot of times what happens is they just don’t. And if you’re lucky, they’ll fix it Year Three or Year Four, […] give it a polish.
The thing that troubles me most about Apple software quality in general is the feeling like they don’t have the people to own the thing that they launch. They build the thing that they launch, and then those people go off and do something else, and nobody is maintaining and improving the thing that’s there.
I think this is spot on, and said really well. Are you honest with yourself about resourcing and focus for right after the launch and then later on? Have you really thought about worst case and best case scenarios vis-à-vis bug reports, latency, user feedback, and craft/quality however you define it? Have you actually started to make room for those outcomes ahead of time?
For me, an ongoing tension with Apple is Finder, so central to my (and I imagine many people’s?) use of a Mac, but rewritten at some point eons ago in a new framework that caused all sorts of problems, and then pretty much abandoned like a proverbial American city’s downtown.
Revealing files in the Finder and Mail’s table view sort indicators have been broken for me since Big Sur. Disk Utility still doesn’t work as well as before its El Capitan rewrite. But these aren’t even big new features.
The issue really, that Jason pins down, is that it’s so easy to use incremental development, agile development, sprints, whatever, as a method to do the wrong thing. If you have a year-long schedule, it is easier to say “I will take care of the Finder”, and within the scope of that is a number of features that need be built, but there’s also room for ongoing maintenance. Within the confines of sprint planning, within a culture that sheepishly focuses on the wrong thing, or is obsessed by following the wrong number, or worries about the internal politics of appearing to not have it together, all of a sudden the same work, scheduled into 3 week long sprints, looks like poison.
I know of plenty of organizations that make this work. That have the maturity and discipline and culture to see bugs and defects for what they are, to allocate plenty of time to them and to focus extra time on them with regular intervals.
Agora, o mesmo veículo informou que a Apple corrigiu a vulnerabilidade em questão em uma atualização (muito provavelmente remota) lançada em 3 de julho — mais de um ano após ter sido alertada sobre a falha.
Tyler Murphy, cofundador da EasyOptOuts e responsável por relatar a falha à Apple inicialmente, disse ter sido informado de que o caso estava sob investigação. A Apple afirmou a ele que a vulnerabilidade havia sido corrigida em março de 2026, o que não aconteceu. Nos meses seguintes, a Apple disse estar analisando o problema novamente […] por isso, Murphy contatou o 404 Media para tornar o caso público.
Como já informamos, o envio de um email para um usuário que possuía o recurso de privacidade ativado — email esse que acabava sendo rejeitado como spam — fazia com que o endereço real da pessoa aparecesse nos registros do remetente.
O 404 Media confirmou que a vulnerabilidade foi corrigida, mas ainda aponta que os usuários devem ser cautelosos.
A falha que fazia com que o recurso Ocultar Meu E-mail da Apple vazasse endereços ocultos para os remetentes foi corrigida. No entanto, não acreditamos que o risco para os usuários do recurso tenha sido eliminado. Como emails legítimos podiam ser rejeitados (gerando uma devolução ou bounce), revelando seu endereço oculto, e como os registros de transferência de email são frequentemente armazenados, presumimos que qualquer endereço oculto vinculado a um endereço do Ocultar Meu E-mail criado antes de 7 de julho de 2026 pode ter sido exposto e ainda pode constar em registros de terceiros.
A Apple, vale lembrar, já foi alvo até mesmo de uma ação judicial devido à falha, com os autores da ação buscando o reconhecimento de uma ação coletiva. Eles alegam que a Apple violou uma lei da Califórnia sobre publicidade enganosa e outras normas de proteção ao consumidor, pois a empresa sabia que o recurso não funcionava conforme anunciado.
Tired of clunky email triage on your iPhone? Avec’s swipe-based interface lets you quickly sort important messages from noise, using AI to prioritize what matters. It’s Gmail-only and iPhone-only for now, but IMAP support is promised and a desktop version is coming.
Apple’s Hide My Email feature has a vulnerability that does exactly what the name says it shouldn’t: reveal your real email address. Worse, Apple has ignored reports of the flaw for over a year.
“O armazenamento do iCloud está quase cheio”. Se você usa iPhone, aposto que leu essa frase nesta semana. Talvez hoje. Ela aparece nos Ajustes, aparece por notificação, aparece quando o backup falha de madrugada… e não desiste nunca. Não é um bug. É, possivelmente, o vendedor mais eficiente que a Apple já contratou.
Nas últimas semanas, escrevi aqui duas matérias medindo produtos da Apple numa moeda que todo mundo entende na pele: horas de trabalho. Vimos quanto custa um Mac depois dos aumentos e quanto custou cada geração de iPhone desde 2007. Mas hardware você paga uma vez e o assunto morre; assinatura, não. Assinatura é um pedágio silencioso: poucos reais por mês, para sempre. E ninguém de fato se dá ao trabalho de fazer essa conta — então eu resolvi fazer.
Os mesmos 5GB desde 2011
Antes dos números, um pouco de contexto. Quando o iCloud nasceu, em outubro de 2011, a Apple deu 5GB gratuitos para cada conta. Era a época do iPhone 4s, de câmera de 8 megapixels e fotos de uns 2,5MB cada. Dava para viver um bom tempo dentro daquele limite.
Quase 15 anos depois, os 5GB continuam exatamente os mesmos. Só que o mundo ao redor deles mudou de tamanho: o iPhone 17 tira fotos de 48MP, grava 4K a 60 quadros — cerca de 400MB por minuto — e sai de fábrica com 256GB. Ou seja, a Apple vende um aparelho com 256GB e dá uma nuvem que corresponde a 2% disso. Um backup básico, sozinho, já não cabe. A caixa ficou pequena de propósito ou só ficou pequena? Guarde essa pergunta.
Quem não aguenta o aviso assina o iCloud+. No Brasil, depois do reajuste de até 33% em 2025, as mensalidades saem por R$5,90 (50GB), R$19,90 (200GB), R$66,90 (2TB) e vão até R$399,90 (12TB).
A conta em horas, plano a plano
A régua é a mesma das matérias anteriores: salário mínimo por hora no Brasil (R$8,50), nos Estados Unidos (piso federal de US$7,25), no Canadá (C$17,60, em Ontário) e em Portugal (5,31€). Cada célula mostra quanto tempo de trabalho um mês de assinatura consome.
Plano
Brasil
EUA
Canadá
Portugal
iCloud+ de 50GB
42min
8min
4min
11min
iCloud+ de 200GB
2h20min
25min
14min
34min
iCloud+ de 2TB
7h52min
1h23min
44min
1h53min
iCloud+ de 12TB
47h
8h16min
4h33min
11h18min
Preços oficiais da Apple em julho de 2026, sempre no plano mensal.
À primeira vista, parece barato — e é justamente assim que uma assinatura funciona. O plano de 50GB custa 42 minutos de trabalho por mês. Quem reclamaria? Mas suba na tabela: o plano de 2TB, o mais comum para quem tem família ou anos de fotos acumuladas, consome quase um dia inteiro de trabalho por mês de um brasileiro de salário mínimo. O mesmo plano custa 44 minutos para um canadense. E o de 12TB beira o surreal: 47 horas mensais — mais de uma semana de expediente, todo mês, só para guardar arquivos.
Vale a comparação com o hardware: nas matérias anteriores, o brasileiro trabalhava de 8 a 12 vezes mais que o americano pelo mesmo iPhone ou iPad. Nos serviços, a distância é menor — cerca de 6 vezes no plano de 2TB —, mas segue aí, firme e forte. Contra o Canadá, a proporção volta às mesmas 10 vezes de sempre. E Portugal repete o papel de meio-termo que já apareceu na conta do hardware: 1h53min pelos mesmos 2TB, 4x menos esforço que o brasileiro — confortável perto de nós, longe do sossego canadense.
O pedágio que nunca acaba
Agora, o detalhe que muda tudo: essa conta não fecha nunca. O iPad de 706 horas dói uma vez; o iCloud cobra todo mês, até o fim dos tempos — ou das suas fotos, o que vier primeiro.
Um ano de iCloud+ de 2TB custa R$802,80 — 94 horas de trabalho, meio mês de expediente por ano. Em 10 anos, são mais de 900 horas: território de iPhone 17, que calculei em 1.006 horas na matéria anterior. Ou seja, guardar as fotos por uma década custa quase o mesmo esforço que comprar o telefone que as tirou.
E tem o degrau seguinte, claro. O Apple One Individual (R$42,90) leva 5 horas mensais de trabalho; o Premium (R$99,90), quase 12 horas — cerca de 140 horas por ano, ¾ de um mês de trabalho anual em assinatura. No fim das contas, o brasileiro de salário mínimo que assina o pacote completo da Apple dedica praticamente um mês do ano só para manter os serviços da Maçã rodando.
Por que a caixa não cresce
Aqui entra o olhar de produto, área em que trabalho há mais de 20 anos. Aquele aviso de armazenamento não é um acidente de percurso: é um funil de conversão dos bons! Ele aparece no momento de maior dor (backup falhou, foto não salvou), oferece a solução a um toque de distância e custa “só” R$5,90. Nenhum vendedor de loja chega perto dessa taxa de conversão.
E o incentivo para manter os 5GB congelados é gigante. Os serviços renderam à Apple US$109,2 bilhões no ano fiscal de 2025, com margem bruta de 75% — o dobro da margem do hardware. Cada pessoa que cede ao aviso vira receita recorrente, previsível e baratíssima de servir. Se os 5GB gratuitos virassem 50GB amanhã, quantos milhões de assinaturas de entrada evaporariam? A Apple sabe a resposta melhor do que ninguém. Tanto que Google (15GB) e Microsoft (5GB, mas com Office no pacote) jogam jogos parecidos — a Apple só joga com a caixa mais apertada do mercado.
Sejamos justos num ponto: nuvem custa dinheiro de verdade (data center, energia, redundância) e o iCloud+ entrega junto recursos como o Retransmissão Privada (Private Relay) e o Ocultar Meu E-mail (Hide My Email). Não é um produto ruim; eu mesmo assino e não pretendo cancelar. O problema não é o plano pago existir, é a versão gratuita ter sido desenhada para não ser suficiente — em 2011, ela era.
No fim, é uma escolha de modelo de negócio — e das mais bem executadas. Só acho saudável que a gente a chame pelo nome. Quando o aviso aparecer de novo aí no seu iPhone — e ele vai aparecer —, lembre que aqueles 42 minutos de trabalho por mês não foram um acaso: foram desenhados, testados e otimizados para esse exato momento. A Apple não vende mais só o telefone. Vende o lugar onde a sua vida digital mora — e cobra o aluguel em dia.
Login
