Spark Stores Email Account Credentials On Their Servers?

This seems like a major privacy concern, doesn’t it?

There’s a post on Reddit that addresses this. The salient point seems to be:

Tldr: there is a security risk to third party apps, but they all have it, not just spark. And also that the risk is higher if oauth isn’t used. But outlook, airmail et al also store credentials on servers. This is a requirement if an app does push notifications on ios. So there’s nothing unique about Spark’s practices, and they’ve been unfairly singled out.


The semi-unique thing about Spark is that you cannot disable push notifications to not allow server components, which is allowed in some apps like Airmail or Canary.

I did a small review on this issue on my blog last year for those who are interested. Basically Spark was marketed for privacy and local AI filtering at the very beginning, with promises to disable server components. The server was made mandatory when they introduced the team features, even for those who don’t use these features.

1 Like

This discussion has been going on for literally years at this point. :slightly_smiling_face: If you want Spark’s power features such as Snooze and Send Later, an external server is required. This can’t be done asynchronously.

I would point out that Sanebox does exactly the same thing. Of all the email apps doing this, I would trust Readdle and Sanebox way more than buggy Airmail.


May I ask where does the trust come from? I’m a bit curious.

Because in my experience with Readdle, they have never shown any trustworthy behaviours. They never fix bugs after years of feedback. They never deliver the features by popular request, like OCR, even with vague promises when switching to subscription in the case of PDF Expert. They never deliver the privacy focused options for Spark, which is possible if users opt out of some features.

They do make functional and well-designed apps. But that lone doesn’t earn my trust.

1 Like

I honestly don’t have a good answer for this. Let’s say that, among the players in that game, they’re the ones I distrust the least. In my experience, Readdle has always been very reactive and support available, and their apps work as advertised. I contrast that to Google’s data harvesting and the six months of close contact with the Airmail devs on their beta Slack that made me throw my hands in the air out of disgust and give up on them, as some features still don’t work (worse, they fail silently) despite months of reports, bad reviews and bad rap from the podcast scene.

If I want the features I want, I need an external server OR a Mac running 24/7. I don’t have the latter so I have to choose a player from the former. And Readdle seems like the safest best if you don’t want Google.


Thanks! That makes sense. I guess the better option is to just choose the lesser evil here.


But thanks for the question because it got me thinking. I have tried very hard and succeeded to be Google-free but email power features are all in Gmail and paying for Workspace would actually give me privacy (I already pay for Fastmail anyway). I know Google’s security is iron clad (and I know they scrape my data anyway) while I truly don’t know much about Readdle’s, so maybe - just maybe - that could be a case for Gmail.


Like Gmail? :thinking:

Gmail has Google’s servers running 24/7.

1 Like

That makes sense to me if it allows people to send emails 24/7. Doesn’t Spark do the same thing?

Yes? But that’s not what we are talking about, I think?

There are two things at play here. a) Sending regular emails, through your usual SMTP server. Any app does that. b) Doing advanced stuff such as send later and snooze. For this, you need an offsite server because email protocols are not devised for asynchronous communication. So you basically need a machine that acts as an intermediary to do the stuff you have scheduled and plug it back into regular email protocols. Which is why Spark has that intermediary server, Airmail does too, and since Sanebox and Gmail run in the cloud, it’s pretty much a given that they do this.


I have no clue anymore. I’m confused. :sweat_smile:

You’re saying that Spark runs in the cloud?

Yes, partly (Snooze and Send Later), it has to. Which is why they have access to your credentials.


Does that not excuse the privacy concerns though?

As said previously, Sanebox, Airmail and Google do the same. If you want cloud-based functionality, you always run the risk of seeing your privacy exposed. Spark is no different.

You can otherwise run Apple Mail, Airmail Business and all apps which do not provide such features.


Apple Mail / iCloud Mail isn’t cloud-based?

You are confusing two different things.

  • Your email provider by definition is cloud-based since we all use IMAP. It’s a server using standard protocols defined decades ago. But Apple Mail / iOS mail does work locally and only communicates with your server when it’s needed. It works offline.
  • Server-side processing brings an additional layer which needs to be cloud-based. iCloud rules, Gmail, Spark and Airmail servers for snooze and send later, Sanebox.

Both can be integrated in the same system, like with Gmail.


Oh, I see now… :sweat_smile:

1 Like

Apple Mail is a first-party app, so Apple can do things that other apps can’t. The claim is that, as a third-party app, in order to send push notifications - which are kind of important for a mail app - the vendor of the app needs to be running a server to send those notifications. And that server needs to be able to get your email, otherwise how would it know that you had email to notify you about? So it needs your username / password, or an app token (if supported by your mail provider), etc.

Gmail can do it because it either already has your username/password, or it can just access your mail without the username/password. One or the other, depending on implementation. :slight_smile:

As a side note, it sounds like the same issue as “well why the **** can’t DEVONthink just sync my data automatically? Why does David have to have a Shortcut to wake the iPad up at 2 am to let it sync?”

The answer is “because DEVONthink can’t just say ‘hey, iPad, I’m going to be doing some Really Important Stuff here - let me run in the background until I’m done.’” The iPad just (basically) shuts DEVONthink down as soon as it loses focus. Or as soon as the screen auto-locks.

That’s not the behavior you expect from a mail app, presumably. So the external server is needed.

Incidentally, this is why it would be catastrophic to many peoples’ existing workflows if Apple implemented the power saving / security model of iOS on macOS. Imagine no background syncs. No user-defined launchd / cron processes. All apps just shutting down and reloading after they lose focus. Which is why I’m pretty certain they’ll never do it. :slight_smile: