Why would they be hesitant? Complex user experience?
I'll admit I've never scheduled a message for later, other than on Twitter since I've lived in some awkward time zones relative to the bulk of my mutuals. But I can't come up with a reason why Apple wouldn't want to add it.
I can imagine a number of complications here. How should delayed send work with respect to both end-to-end encryption and with network connectivity loss? Ie I can see a possible way to build this where the sending user’s device queues and sends it later, but what if that device is out of network coverage area, or battery-dead, at the requested send time? …so then we could think about doing it at the server level, but then to maintain end-to-end encryption, the message would have to be pre-encrypted; how would we handle rekeying a user? Ie if the delay send is for 24 hours from now, but one of the recipient’s keys get rotated (which afaik can happen in a couple of reasonable conditions; but others here will know more)… well, we end up with a solution that also can’t reliably deliver the message.
One thing I really appreciate about Apple Messages is just how well it works, and how little spam ever makes it in. I think the reliability of Messages is almost taken for granted… I wouldn’t want to give that reliability promise up for this sort of feature!
Maybe I am missing something obvious/important. Google Messages delay send will not send the message if the phone is off/disconnected. What's wrong with Apple Messages setting up delayed messages just like that? You said reliability. But Google Messages delay has worked 100% of the time for me and I've never had a situation where the phone was off when it needed so maybe I am the wrong person to ask.
Is there a way to have the timestamp part be unencrypted and the message be encrypted or does that violate end to end policy?
Though I like being able to cancel/edit until the send deadline so from my perspective it's best to keep on the sender device as long as possible and send only at the last possible second.
But iMessage is synced between devices. So if I delay a send on my iPhone and lose network, my other Apple devices know enough they could still send it.
Should they (I asked to send) or not (‘sending’ device offline)?
If it's E2EE, why not send the message with a timestamp at which the server should approximately process the message? If it's well encapsulated/encrypted, it shouldn't matter that the message is on the server for a while.
Who said the queue has to be on the sender’s device or the server?
Sender sends it encrypted with a flag to not display until X time, phone receives it whenever, and then displays it at X time because it’s just been sitting there.
Well I think one benefit of a scheduled send is the ability to cancel or edit after hitting the send button. So I'm not sure if I'd appreciate setting it up like you say here.
What does the receiving user see? Do they know it was scheduled?
If not they may expect me to start responding when I may be unavailable.
What happens to read status (when on)? I haven’t read your last X messages but I did send one to you? That’s off.
Can it be canceled?
How does this interact with the new function in iOS 16 letting you edit and delete after send?
Can I schedule send on my iPhone but edit before send on my iPad?
What if I schedule send and lose network. Then I edit on both my iPhone and iPad to show different things but they’re both off network. Not they both come back. What gets sent?
- In the notification: yes. In the chat view: no. I don't know why it matters, though. If you expect an immediate response, you should probably use a more asynchronous communication method (many email platforms can hold messages for you). That doesn't seem like a reason to not make the feature available, though.
- That's a possible state regardless, unless the client must always have a full database of all received messages before new messages come in; most messaging apps seem to support a "fragmented" read state and I doubt iOS's messenger doesn't.
- Yes
- I don't see the problem here. Replace the message in the queue using an account+message identifier/cryptographic signature/magical pixie dust.
- Yes
- If the message is sent by the server at the scheduled time, this isn't a problem. If you rely on individual devices (Google's implementation), you may end up sending a duplicate. I doubt this'll happen that often in practice.
- Depends on the implementation; the server will probably keep the "correct" version to send.
- Probably not? There are tons of features that don't work with SMS though. I haven't used SMS for years, but Google's Messages app has delayed messages and a web client, so this seems like a solved enough problem for those still using SMS.
Several chat apps, including SMS apps, have this feature already. E2EE adds a layer of complexity but even that can be fixed with existing technology.
Personally, I would solve all of these by pushing the message up, like sending it, but with colors that make it clear that it's suspended, and a clock icon, which shows when it will send.
Long press the message to get a context menu: edit, delete, reschedule, send now.
As for sync and all that, whatever algorithm they use for Notes is fine with me. I would expect the message itself to be living in iCloud until it's sent, so most of the questions about losing network connectivity or not having battery life wouldn't apply. So no, no SMS: support for SMS in Messages is an afterthought and I would in fact prefer two different apps, although I might be the only one who feels that way.
Telegram's implementation shows a little calendar icon next to the text input when you've planned a message, which takes you to a list of planned messages you can interact with like any other message. This solves the problem of your message appearing right in the middle of already sent messages or your message constantly bubbling down as a real-time conversation takes place. I think it works quite well.
I'll take a crack here: they believe the need should be solved elsehow. They see the "I want to send a message later because I don't want to bug anybody" need as better solved from the other end: "I don't want to be bugged because I'm asleep/busy/whatever".
This one I'm not seeing. Spam is about volume, how does this help a spammer spam more if it takes longer than just sending a message, which presumably it would?
Me neither, can't see "the obvious" reason for them not implementing this.
Apple usually trots out "privacy" or "security" when people find their software lacking in terms of usability or convenience but I can't understand why this would be an issue for them.
But this is a fantastic shortcut to get around the limitation.