Research

I Analysed 708 Negative App Store Reviews of Email Apps — Here’s What People Actually Want

Isaac Hinman·Co-founder, Marco

Why I did this

Before building Marco, I wanted to understand what email users actually complain about, not what product reviewers write or what competitors claim, but what real people, frustrated enough to leave a 1-star or 2-star review, actually say when an email app lets them down.

I read 708 negative reviews across the iOS App Store and Mac App Store for seven email clients: Gmail, Outlook, Spark, Superhuman, Apple Mail, Canary Mail, and Hey. I categorised each complaint by its primary issue. Some reviews mentioned multiple problems. I used the most prominent one.

This is not a scientific study. It is a solo founder reading reviews and counting patterns. The sample is biased toward users who felt strongly enough to write something. But those are exactly the users I wanted to understand: people who hit a wall and wanted everyone to know about it.

The breakdown

Bugs and crashes

Count156
% of Total22%
Most Cited AppsOutlook, Apple Mail, Spark

Search not working

Count112
% of Total16%
Most Cited AppsApple Mail, Gmail, Outlook

Sync issues / missing mail

Count98
% of Total14%
Most Cited AppsSpark, Apple Mail, Canary

Notifications broken

Count79
% of Total11%
Most Cited AppsGmail, Outlook, Spark

Privacy / data concerns

Count68
% of Total10%
Most Cited AppsSpark, Gmail, Edison (mentioned in reviews)

Cost / paywall frustration

Count62
% of Total9%
Most Cited AppsSuperhuman, Hey, Canary

Multi-account problems

Count54
% of Total8%
Most Cited AppsGmail, Apple Mail, Outlook

UI complexity / bloat

Count48
% of Total7%
Most Cited AppsOutlook, Spark, Gmail

Offline limitations

Count31
% of Total4%
Most Cited AppsGmail, Superhuman, Spark

Bugs and crashes: 22%

The single largest category. More than one in five negative reviews was about the app crashing, freezing, or exhibiting broken behavior, not missing features, not design complaints, just basic reliability.

"App crashes every time I try to open an attachment. Been like this for three updates. How is this acceptable for a mail app?"

"Freezes for 10 seconds every time I switch between accounts. I have given up and gone back to using the browser."

This is the most basic expectation users have, and the one that email clients fail at most frequently. The apps with the most crash complaints were the ones with the most complex feature sets. Complexity creates surface area for bugs.

Search not working: 16%

The second largest complaint. Users searching for emails they know exist and getting no results, wrong results, or results that change depending on when they search.

"I searched for an email from my bank. Nothing. Searched again with different keywords. Still nothing. Went to Gmail in the browser, found it in two seconds."

This is the problem I wrote about in Why Apple Mail Search Feels Bad. The root cause is almost always clients relying on server-side IMAP SEARCH instead of maintaining a local index. When you depend on a 1990s protocol for 2026 search expectations, users notice.

Sync issues and missing mail: 14%

Emails not appearing, appearing late, or disappearing after they were visible. This is the scariest failure mode for an email client because it erodes trust. Once you suspect your client is hiding mail from you, you can never fully relax.

"An important client email arrived two hours late. I only found out because they called to follow up. Uninstalled immediately."

Sync reliability is an infrastructure problem. It requires careful handling of IMAP connection state, provider-specific edge cases, and conflict resolution. For a technical deep-dive, read What Most Email Clients Get Wrong About IMAP.

Notifications broken: 11%

Push notifications not arriving, arriving late, or arriving for the wrong account. For users who depend on timely notification of important emails, a broken notification system is a dealbreaker.

This one is technically challenging. Push notifications for email require either Apple Push Notification Service (APNs) integration, a background fetch mechanism, or IMAP IDLE support. Each provider handles this differently, and the iOS background execution model adds further constraints. But users do not care about the technical difficulty. They care that they missed an email.

Privacy and data concerns: 10%

One in ten negative reviews mentioned privacy, data collection, or trust issues. This was highest for apps that process email server-side and for apps with free tiers that users suspected of monetising their data.

"Found out this app reads my emails to show me ads. Deleted."

"Why does a mail app need access to my contacts, calendar, and location? No thanks."

The privacy concern is not hypothetical for users who write these reviews. They have either read the privacy policy, seen a news article about data practices, or noticed permission requests that felt invasive. For more on this, read The Real Cost of Free Email Apps.

What people say they want vs what they actually switch for

The reviews tell you what broke. They do not tell you what people switch to. From our own migration conversations, the pattern is slightly different:

  • People complain about bugs, but they tolerate bugs for a long time before switching.
  • People complain about search, and search is the trigger that actually makes them switch.
  • People complain about privacy, but most only switch when a news story makes it feel urgent.
  • People rarely complain about offline in reviews, but users who need offline and discover it is missing switch fast.
  • Cost complaints are loud but the actual switching rate from cost alone is low. People switch when cost combines with another frustration.

What this means for Marco

When I started building Marco, I did not set out to build every feature. I set out to not fail at the things that make people leave. The top complaints (reliability, search, sync, privacy) are all infrastructure problems. They are not solved by adding features. They are solved by getting the architecture right.

  • Bugs and crashes: Marco's codebase is intentionally small. Fewer features, less surface area for bugs.
  • Search: local full-text index across all accounts. No IMAP SEARCH dependency.
  • Sync: IMAP-first with per-provider compatibility handling. See our IMAP approach.
  • Privacy: no ad targeting, no AI scanning, no data monetisation. Our servers handle sync and indexing, nothing more.
  • Offline: offline-first architecture. See why this matters.

I did not read 708 reviews to confirm what I already believed. I read them to find out what I might be wrong about. The biggest surprise was how dominant basic reliability complaints are. Users do not want revolutionary email. They want email that works, every time, without thinking about it.

For the story of why I built Marco in the first place, read Why I Built an Email Client as a Solo Dev. For the broader case that email is fine and clients are the problem, read Email Is Not Broken.

Author

Isaac Hinman, Co-founder, Marco

Isaac Hinman co-founded Marco and works directly on sync architecture, IMAP integrations, and offline reliability across providers.