Show HN: How we reduced our Twilio costs 80% by switching to iMessage | Hacker News Reader

Show HN: How we reduced our Twilio costs 80% by switching to iMessage

usebalto.com

18 pointsprobe12 comments

Hi, I've actually tried to run a similar (and now completely shut down) service a few years ago. If you look at my github I have several public iMessage-related projects. The biggest thing I ran into was getting my services rate limited or even blacklisted from iCloud for large periods of time when attempting to scale up. At low scale things worked fine and I am still running some iMessage bots (similar to classic IRC bots) for group chats with some friends without issue.

The only way I was able to mitigate rate limiting and black listing was to use actual physical Macs, only host a low number of users on each Mac, and put each Mac on its own physical internet connection. I also had to rate limit users and prevent them from sending the same message to many recipients as that would cause the machine to get blacklisted. Because of this I determined it would be nearly impossible to scale up without charging exorbitant amounts of money, which you seem to have avoided with your $20/mo rate which seems very reasonable.

Can you share answers to any of these. Totally understand if some of these are secret sauce and you can't answer:

- how you are preventing or mitigating blacklisting and rate limiting?

- what are you doing to detect when you are blacklisted?

- what is your remediation once you've detected that you are blacklisted?

- how are you handling scaling up your numbers of users?

- how are you sending/receiving the messages? (I'm curious: did you write your own solution that talks to iCloud services or are you abusing Messages.app and its corresponding SQLite database?)

- has anyone from Apple contacted you? are they okay with it?

Anyways, cool service, good luck!

Hi all! Like many people here we wanted to reduce our monthly expenses given the time, and found Twilio to be one of the highest line items. When we dug into the data, we found that 80% of our users were iPhone users and thus could receive iMessages.

Thus we built Balto - an API to send iMessages, and were able to transition our entire customer list successfully (as well as take advantage of iMessage features like unlimited messaging, read receipts, apple pay, etc.)

Would love HN thoughts/feedback! We also have a customer facing version if you’re not a developer (https://usebalto.com/) and wrote a blog documenting the journey for those interested (https://usebalto.com/blog/balto-origin-story%20) :)

Have you run into any rate limiting on iMessage? We usually see bulk messaging (eg: appointment reminders) getting silently dropped by carriers if over 100 messages are sent from that number in a day.

Additionally, what stops Apple from breaking your service, like so many other unofficial chat APIs?

Yup great callout, something we think a lot about. We haven’t run into any rate-limiting yet, though are aware that it’s a possibility. iMessage returns the date_delivered which has been valid and we send an SMS in those cases.

As for Apple shutting us down, it is a valid concern, although right now the service looks no different than if one were to type out a message on their own device.

Happy to share more details and go through any concerns you might have - maybe there's ways we can help with appointment reminders!

What happens if user has disabled iMessage, does your API notify your enterprise customers with an error?

I can see this useful if the following is possible:

send iMessage, if fail then send text via twilio

But otherwise couldn't see the use case (at least for reliable delivery rate)

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.

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!

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.

Amazing work! I have been selling a product using a WhatsApp chatbot for some time now. iMessage would be a great addition to this so I will definitely get back to you once I find some more time to work on the project. Great work in getting this setup!

Reply on news.ycombinator.com