Thing is, push notifications USED to work with Gmail on iOS, but then Google changed something (I forget what) and it was no longer possible.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
You Can Unsend an Email 10 Seconds After It's Sent in iOS 16 Mail App
- Thread starter MacRumors
- Start date
- Sort by reaction score
Honestly I’m glad they did. The mail app was not as important to them because businesses were locking employees to Outlook and then GMail. Apple has generally preferred 3rd parties to focus on such things, but I see them changing that now. They are starting to take software initiatives internal as their App Store business model comes under attack. I believe we will see a lot more 1st party software innovations down the road.
In this case the changes are to bring the software to parity with what’s out there by including the most popular requests. This may continue for additional updates, but there may be significant changes that ups the anti.
HobeSoundDarryl
macrumors G5
These 2 posts seem to really tell the key story here. Either the system is delaying the actual "send" for those 10 seconds or perhaps iCloud is being inserted as new "middleman" here: email doesn't send as it does now but gets into a (presumably secure) buffer in iCloud. If you don't unsend it in 10 seconds, iCloud then sends it as if you sent it "as is" now. Can that work? I don't know. It seems that Macs could pass the information to iCloud so that iCloud could actually execute the send for you a few seconds from now.
Why do this? For a reason already shared in this thread: what if you click "send" and immediately sleep your laptop: the email send was the last thing you wanted to do today. If you sleep it before it departed, you would assume a send that didn't actually leave the laptop yet. On the other hand, if iCloud is a new middleman, you still immediately send it out of your laptop and iCloud controls whether it goes in 10 seconds or not based on you clicking unsend or not.
I have no idea if that is how it works but it seems that would be the BETTER way than simply delaying it on the local device. Is that as secure or not? I don't know. Depends on how it works if it works that way. Maybe it really is just delaying the send on the local device.
If we think about this as it will apply to Messages "unsend/delete", in that case Apple IS in full control of the texting servers... so more like how Outlook works, the text you send is stored in iCloud and you could have up to any amount of time to unsend/delete it since Apple fully manages it between you and the recipient.
Unlike email, I actually think the Messages version of this will get more usage. IMO, it is much easier to accidentally send a text to the wrong person than sending an email to the wrong person. Personally, it seems like a year or two since I sent an email to the wrong person (same first name) but I regularly send a text to the wrong person when multiple texting conversations are going.
Last edited:
Google stopped supporting Exchange push for quite a while now.
As far as I know, Apple hasn't supported Push for IMAP for a while.
Former email admin here.
This "unsend" isn't really "unsend" and that's a good thing. It *delays* sending your email for 10 seconds after you click "Send", giving you the time to cancel the send.
That's much better than some "unsend" approaches in proprietary mail platforms (waves at Microsoft), which do allow you to recall/retract/unsend a message after it's been delivered. Those unsend mechanisms require that both ends of the email chain use the same proprietary platform. If you happen to send a msg to somebody not on the same mail system, the unsend doesn't work and they end up getting your initial message (and often times a 2nd message indicating you wanted to recall the 1st message, which can be a very bad look).
I just wish Apple called this "cancel delivery" rather than Unsend. Because really, you can't guarantee that an email can be "unsent" after its been delivered - and you should never rely on the ability to do so.
This "unsend" isn't really "unsend" and that's a good thing. It *delays* sending your email for 10 seconds after you click "Send", giving you the time to cancel the send.
That's much better than some "unsend" approaches in proprietary mail platforms (waves at Microsoft), which do allow you to recall/retract/unsend a message after it's been delivered. Those unsend mechanisms require that both ends of the email chain use the same proprietary platform. If you happen to send a msg to somebody not on the same mail system, the unsend doesn't work and they end up getting your initial message (and often times a 2nd message indicating you wanted to recall the 1st message, which can be a very bad look).
I just wish Apple called this "cancel delivery" rather than Unsend. Because really, you can't guarantee that an email can be "unsent" after its been delivered - and you should never rely on the ability to do so.
Click send, click quit, close laptop lid (or click shutdown), and … what happens to the waiting email?
That is exactly what is happening. Every email just waits 10 seconds to actually send. There is not a federated way to unsend an email.
Don’t shut down within ten seconds of sending. Also avoid holding it incorrectly.
I did wonder how they could accomplish this since you can't just reach out to the other person's email client and delete their mail unless they were running Apple Mail. So now we know that Mail simply holds the mail for 10 seconds before it's sent. I suppose that's a fair compromise, but I doubt it'll have much utility since 10 seconds isn't much time to regret sending and then acting on that regret. Regret would have to be instant. Mail clients don't want to hold mail for too long because sometimes mail delivery is sensitive, such as 2-factor authentication emails.
Well, the Mac or iOS device could send the email when it’s “asleep”. Modern power management is really quite interesting. For instance, instead of running tasks as they come in, the scheduler will generally cluster tasks together, so, instead of turning on the radio or ramping up the processor for tasks for an extended period (like a car idling), it executes them all in one go then turns off the radio and ramps down the processor. I saw a WWDC video on this around the time the Apple Watch was new, so there’s likely been a lot of optimizations in this department even since then.
HobeSoundDarryl
macrumors G5
No way to "recall an email whenever" with the Internet as it is designed UNLESS Apple controls the email servers for both sender and recipient... and thus the email is parked in iCloud. Once the email leaves your computer, it is like somebody's personal photos leaking onto the internet- no amount of effort is likely to delete them.
Messages (texts) will be completely different because Apple is fully hosting them between Apple device sender and Apple device receiver. I presume texts to non-Apple device people (Android, etc) will not remain in Apple's control. But otherwise, Apple to Apple texts should be unsend/delete-able at any time.
Messages (texts) will be completely different because Apple is fully hosting them between Apple device sender and Apple device receiver. I presume texts to non-Apple device people (Android, etc) will not remain in Apple's control. But otherwise, Apple to Apple texts should be unsend/delete-able at any time.
The thing is, you can’t “recall” an email, this isn’t an IM chat on a central server. This is email, when you send that email, you send it to an email server outside of your control. Realistically, all you can do (as has been mentioned multiple times in this thread) is delay sending the email some period of time. Your suggestion boils down to never sending the email. It’s untenable. You might suggest mechanisms by which they might be done, but that would involve the whole email stack adopting these mechanisms. The server you’re using for SMTP would have to support them, the recipients’ email servers would have to support them, the recipients’ email clients would have to support them. The whole email stack, managed by such a variety of vendors, would have to get together, agree that this is a good idea and worth the time and effort*, then agree on an implementation and implement it, and then email service providers would have to accept it before you could do that. It’s a complete non-starter to make a change that would allow for email recall.
*Typically in the form of an IETF RFC, and Wikipedia says in its article on the IETF: “For protocols like SMTP, which is used to transport e-mail for a user community in the many hundreds of millions, there is also considerable resistance to any change that is not fully backward compatible, except for IPv6.”
Edit: Huh, I never knew that iOS copy+paste preserved hyperlinks in rich text, go figure. Anyway, you could implement a solution like Outlook does, but that requires the recipient to be running Outlook. Which is more like the IM chat example I gave above, both end points are controlled by a common vendor. Note, in the case of email, it could only be implemented by Google in Gmail (between Gmail users) or by Apple in iCloud Mail (between iCloud Mail users), even if both parties are running Mail.app. Multiple service providers could agree on an implementation that could be federated, but then you’d just have this vague quasi standard that doesn’t work everywhere.
Last edited:
10 seconds is effectively instantaneous when it comes to email, though. 10 seconds is a shorter time interval than the common internet time out interval (usually around 30 seconds or so). Which means that the network itself is potentially adding more delay than Mail is, it’s already about as close to real time as you can get with email. If you truly need a Real Time high reliability messaging protocol, you’re not using email. (There are actually a bunch of these protocols depending on your field. Finance is a field that has multiple such protocols.)
This is good news but Apple Mail is a joke. Besides its unparalleled integration to the OS (which developers can't have because, well Apple) there's no reason to use it over a more modern mail client that has far better, user friendly features. I just wish they'd give Mail to a team of hungry young Apple devs to reimage and revamp.
In 95% of the cases in Canada an email sent from one icloud address to another icloud address shows up in <5 seconds in my experience in 2022.
And if both parties are in the same room it’s usually <10 seconds from any of the major email providers to any other.
A mandatory 10 second delay is definitely not instantaneous in those cases, and will be quite noticeable to anyone who sends a lot and hold near real time conversations over it.
In fact it’s doubling or tripling the wait time for quite a large chunk of use cases if it’s mandatory.
Apple in iOS 16, iPadOS 16, and macOS Ventura is overhauling the Mail app and introducing a slew of new features that bring it more in line with competing mail services such as Gmail. One of those new features is a long-awaited Undo Send option, designed to let you quickly recall an email if you make a mistake.
Undo Send works for up to 10 seconds after you send an email, so you don't have a lot of time to change your mind if you do want to unsend an email that you've sent out. Google's Gmail service also has an undo send feature for emails, but you can customize the cancelation period to 5, 10, 20, or 30 seconds.
For now, Apple is limiting undo send to 10 seconds, but it's possible the company could add other time options in the future.
There are several other new features coming to the Mail app. You can schedule your emails for the future, or have Mail give you a reminder about an email you opened but forgot to respond to. It will also let you move sent messages to the top of your inbox so you can get a reminder to send a follow-up, and it can notify you if you forget an important part of an email like an attachment or recipient.
Rich links are now supported in email messages so you can see more at a glance, and search is improved. Apple says that you'll see better search suggestions from the moment you begin a search, and it will also correct typos and use synonyms for your search terms to bring up what you're looking for.
These features are available across Apple's platforms for those running the latest software. Apple's updates are limited to developers at this time, but the company plans to release public betas in July.
Article Link: You Can Unsend an Email 10 Seconds After It's Sent in iOS 16 Mail App
I have 30 seconds on my Google hosted work email. Didn't want any more of those, 'damn i forgot the attachment' or 'did i reply all?' moments.
Unsend option is good. More time periods should be added in the future. Scheduling an email is also great.
Push notifications for Mail on the iPad and iPhone use Apple's proprietary push notification service (APNS), which is essentially the same thing used by third-party apps to handle their own push notifications. For Google to support push notifications in Apple's Mail app, it would need to build a custom, Apple-specific solution to handling this, which it obviously isn't willing to do.
Some mail providers have taken this extra step. Fastmail comes to mind, which worked with Apple in 2015 to add push notifications for Apple Mail — and managed to do a better job of it than even Apple does with iCloud. For example, iCloud pushes only new messages, while Fastmail pushes updates for all mailbox changes, meaning that your unread badge count decreases or goes away when you read a message on another device.
Note that Apple Mail on the Mac is a different case. It uses the longstanding open IMAP IDLE extension, which allows it to receive new messages by effectively maintaining a persistent connection to the server. Most IMAP servers support this, including Gmail, which is why you'll get near-instant updates in Apple Mail on your Mac, but not your iPhone or iPad. IMAP IDLE consumes more power and doesn't work nearly as reliably when hopping around cellular and Wi-Fi networks.
That's exactly what Microsoft did, along with Spark and other third-party clients that support push notifications for new mail. Essentially, Outlook, Spark, et al are using a proxy server that maintains an IMAP IDLE connection to Gmail's servers. If you're using one of these apps, you can actually see this by checking what's connected to your Gmail account; you'll see connections from a bunch of IP addresses that are nowhere near your actual location.
In other words, they stay logged into Gmail on your behalf, regularly checking for new messages, and then use push notifications to deliver those updates from their servers to their apps, just like Gmail does for its own iOS app.
There are obvious privacy concerns with this approach, which is why Apple isn't about to go there.
Google used to support push by letting users configure their accounts with Exchange ActiveSync, which was a totally different protocol designed for use with Exchange Servers. Google called this Google Sync and it's still technically available for Google Workspace customers, although Google is trying to encourage organizations to move away from it.
Due to the way Exchange ActiveSync works, Google Sync always had some odd limitations that made it a tradeoff between configuring your account via a standard IMAP connection and losing push notifications. For instance, drafts and starred/flagged messages wouldn't sync over Google Sync. I went back and forth a few times over the years, but ultimately decided the idiosyncracies weren't worth it just to get push email.
It depends on what you call "Push IMAP." Apple supports IMAP IDLE in the Apple Mail on the Mac, but it's never supported this in iOS due to the complexities of battery life and changing networks.
From the very beginning, Apple Mail on the iPhone and iPad has only supported Apple's own push email technology, which is based on the APNS (Apple Push Notification Service) framework used by every iOS app that wants to use push notifications. It still works with iCloud, and I think Yahoo may even still support it. Fastmail also specifically added support for Apple's push email features in 2015, and it still works great. I'd been using Fastmail off and on for years, but that's when I permanently switched over, and I haven't looked back since.