Hacker News Reader

Comment by probe | Hacker News Reader

You're spot on - iMessage returns a date_delivered so we know if it's successful or not, and send an SMS backup via Twilio.

View on HN

Note that the “delivered” indicator in iMessage just tells you when it was delivered to the network, and not the recipient. It’s entirely possible to still lose the message after it gets delivered to the network.

The only way you could know for sure if the recipient got the message is if they have read receipts turned on, so that you know when they’ve actually read the message.

And plenty of people have had problems where they took their cell phone number with them to a non-iPhone device but can never receive iMessages, but they also can’t receive regular SMS messages to that number.

There still be plenty of dragons here.

> Note that the “delivered” indicator in iMessage just tells you when it was delivered to the network, and not the recipient. It’s entirely possible to still lose the message after it gets delivered to the network

Is there any reason to believe that in the USA for example iMessages would be 'dropped' at a higher rate than SMS? Put another way, is an iMessage 'delivered' less valuable than an SMS 'delivered'? Curious to hear your thoughts.

There is a low limit to the maximum size of an SMS message. Small enough to fit the entire thing plus all meta data easily into a 512 byte UDP packet. Sure, UDP is unreliable, but everyone knows that and you build additional reliability mechanisms on top of that. The SMS protocol is different, but still shares a lot of similarities.

With iMessage, the messages themselves can be much larger, and the larger the message the more likely it may run into packet fragmentation which could easily result in it being silently lost down the road.

With SMS, once the network has accepted the message, I think you have a higher probability that it will actually reach the recipient.

Another factor here is cost — precisely because you pay for SMS messages, the carriers are going to aggressively maximize the delivery probability, because they don’t want to lose a single red nanocent. But iMessage is free, so why should anyone care to optimize that for maximum delivery probability?

Then you also run into the other issues noted above, e.g., where someone previously used a given number with an iPhone and then moved to Android. The number is still detected as being iMessage capable, but you can’t actually send an iMessage to them on Android.

I guess all I’m really saying is TANSTAAFL — There Ain’t No Such Thing As A Free Lunch.

Oh, and be careful what you optimize for. You may optimize yourself out of a job.

Got it. I have another question. Say a new user opts in to receive a text notification over the phone but you don't know whether they're using iMessage, or an iPhone for that matter. Can you try sending them an iMessage via your API as an attempt, and then handle failure (instead of "iMessage turned off", the case is: "not on an iPhone"... perhaps they're on Android, landline, etc). Also if so, does your API differentiate between the two cases? And any commentary about privacy and how you all handle that would be great.

We can tell whether the number is iMessage compatible (similar to how when you type in a new number to text on an iPhone you can tell whether it is iMessage compatible or not). So if it's not iMessage, we can send that number an SMS like normal. If they are iMessage, but for some reason delivery fails, we can also send an SMS as a backup.

Happy to chat more on privacy depending on your use case and how you want to set it up!

Reply on news.ycombinator.com