I understand why Apple is hesitant to add the feature.
But this is a fantastic shortcut to get around the limitation.
But this is a fantastic shortcut to get around the limitation.
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.
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!
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.
Should they (I asked to send) or not (‘sending’ device offline)?
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.
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?
What if the ‘wrong one’ comes back first?
Does it work with SMS?
Lots of weird complications to think about.
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.
- 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.
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.