
Show HN: How we reduced our Twilio costs 80% by switching to iMessage - probe
https://usebalto.com/developers
======
camhenlin
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!

------
probe
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/](https://usebalto.com/)) and
wrote a blog documenting the journey for those interested
([https://usebalto.com/blog/balto-origin-
story%20](https://usebalto.com/blog/balto-origin-story%20)) :)

~~~
mehhh
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?

~~~
probe
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!

------
davidajackson
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)

~~~
probe
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.

~~~
bradknowles
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.

~~~
davidajackson
> 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.

~~~
bradknowles
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.

------
theveloped
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!

