5 ms·

As an iPhone user, I find it super annoying too. I love my iPhone and Apple products in general but it's not fair to expect all my friends to be the same. One o

As an iPhone user, I find it super annoying too. I love my iPhone and Apple products in general but it's not fair to expect all my friends to be the same. One of my friends has an iPhone but turned off iMessage out of an abundance of caution. As a consumer, I would really like it if non-iMessage user can get the same experience as all the iMessage users. We know there is a way. The standard wasn't great when it was new but it has matured a lot. I would really like it if Apple supported it. Its behavior seems needlessly antagonistic.

pmarreck 3y ago
> One of my friends has an iPhone but turned off iMessage out of an abundance of caution In my experience, iMessages have far greater delivery reliability than SMS text messages. I've actually gotten into inadvertent fights with people over undelivered SMS text messages.
- AnthonyMouse 3y ago
  The issue isn't that Apple should be using SMS in particular -- SMS sucks. But they should either use some standardized protocol, or publish a protocol standard for iMessage. Someone willing to do the work should be capable of producing an interoperable implementation.
  - Jtsummers 3y ago
    You'll get your wish later this year with iOS support for RCS.
    - AnthonyMouse 3y ago
      Not exactly. It's a step in the right direction but it's the same problem as iMessage supporting SMS in addition to its own protocol. If the proprietary protocol supports something the open protocol doesn't, or that Apple doesn't implement for the open protocol, a competing implementation can't do it. And if it doesn't do that then why does the proprietary protocol exist? If you're going to make your own protocol, publish a spec.
      - junofan 3y ago
        Isn’t iMessage a service, not a protocol? Should I be able to operate a business that sends bulk advertisements to iMessage users?
        AnthonyMouse 3y ago
        > Isn’t iMessage a service, not a protocol? It's a service and a protocol and a client application. But it should be possible for a third party to make an interoperating client application using the same protocol, and then it could connect to any service implementing that protocol. Obviously if you want to be selective in who can use your service then you should create a protocol that supports some kind of federation so that each user's service can forward messages to another service if the two endpoints don't use the same one. Email works like this, for example. > Should I be able to operate a business that sends bulk advertisements to iMessage users? Can you do this now by using a Mac with iMessage?
  - naravara 3y ago
    The touchy part is the end-to-end encryption. The whole point is that Apple is the trusted party there. As an iMessage user I don’t want my messages passing through who knows which other parties’ servers when I send messages to others. The point of the blue bubble is to ensure the encryption is there.
    - AnthonyMouse 3y ago
      End-to-end encryption is where the client device encrypts the message and then the other end's client device decrypts the message. It doesn't matter how many servers it goes through, none of them can read it, that's the entire point of end-to-end encryption. The hard part is associating some identity with the user's keys, but when the ID is your phone number or email address, the entity doing that is inherently your phone company or email provider. You can standardize a way to do that, i.e. to sign up you get an SMS or email with a code and have to enter the code. The client can automate that if it has access to read your SMS or email, or otherwise you enter it manually.
      - naravara 3y ago
        If the person on the other end is using a non-Apple client you cannot verify independently that their client isn’t peeping. It’s the client, not the servers. But also when it comes to managing the keys and syncing across devices it’s also the servers.
    - Sabinus 3y ago
      If you're an iMessage user, don't you want your messages to non apple users to be encrypted? Kicking them out of the system makes your messages less secure, not more secure.
      - naravara 3y ago
        Who verifies that the client on the other end of your line isn’t intercepting the messages after they’re decrypted?
- crazygringo 3y ago
  > I've actually gotten into inadvertent fights with people over undelivered SMS text messages. Oh, man. Thankfully I haven't had an undelivered text in over a decade. But back in the early-to-mid 2000s, it was maybe a 5% failure rate in the country I was living in then? With no indication. And yes it really did cause arguments with romantic partners. There were times I had to pull out my phone and prove I'd asked/invited/told them whatever. But it's not like that ever really fixes the situation either. But if you asked anyone to confirm they'd gotten your message you seemed paranoid or needy. You just couldn't win. So much friction.
jorvi 3y ago
> Its behavior seems needlessly antagonistic. It is just standard fare across the modern bigtech world. Prior to the iPhone / iOS, Apple would have happily built in support for something like Google Cast, because they operated from the idea that their products should be the most useful for their customer. These days it’s all about forcing people into your ecosystem for increased lock-in. Thus, no baked in support for Cast (except in the Apple Music app on Android). As far as Apple is concerned, if you are visiting a friend and want to play some music on his Chromecast, the solution is to buy your friend an Apple TV for AirPlay.
- pmarreck 3y ago
  > Prior to the iPhone / iOS, Apple would have happily built in support for something like Google Cast I really don't think you can assume this. For example, a long time ago in computer years, Apple rolled out "Yellow Box for Windows" which was a way to get NeXTStep apps running on Windows http://www.shawcomputing.net/resources/apple/os_pictures/ybnt4/ http://www.shawcomputing.net/resources/apple/os_pictures/ybn... as part of Rhapsody Developer Release 2 (this was a prerelease OS X)... and then promptly ditched it. Being able to develop once and then deploy to both OS X and Windows sounds great to developers, but think about this: If you had access to Mac apps from a Windows machine, then why would you buy a Mac, when Apple is competing on quality and not price? It'd be a win for app developers but a big "lose" for Apple. So why would Apple have ever built a way to cast to Google Cast if they already had an AppleTV product that wasn't competing on price with Google Cast? (AppleTV's are great, btw)
  - bloppe 3y ago
    Google can and has done the same thing. They stopped supporting YouTube on FireTV because Amazon refused to sell ChromeCast devices on their website. All these competitors have options to force you to buy their hardware just to use their services and vice versa. Google could start slowly degrading all their services for users without Chromebooks. Microsoft could force you to buy a Windows phone just to use ChatGPT. Clearly, all of this is bad for users across the board. Apple is by far the most aggressive when it comes to this kind of anticompetitive bundling. You can't just say "of course they want to be anticompetitive, that's just business!". You're supposed to not let them pull this shit.

pmarreck 3y ago

> One of my friends has an iPhone but turned off iMessage out of an abundance of caution In my experience, iMessages have far greater delivery reliability than SMS text messages. I've actually gotten into inadvertent fights with people over undelivered SMS text messages.

AnthonyMouse 3y ago
The issue isn't that Apple should be using SMS in particular -- SMS sucks. But they should either use some standardized protocol, or publish a protocol standard for iMessage. Someone willing to do the work should be capable of producing an interoperable implementation.
- Jtsummers 3y ago
  You'll get your wish later this year with iOS support for RCS.
  - AnthonyMouse 3y ago
    Not exactly. It's a step in the right direction but it's the same problem as iMessage supporting SMS in addition to its own protocol. If the proprietary protocol supports something the open protocol doesn't, or that Apple doesn't implement for the open protocol, a competing implementation can't do it. And if it doesn't do that then why does the proprietary protocol exist? If you're going to make your own protocol, publish a spec.
    - junofan 3y ago
      Isn’t iMessage a service, not a protocol? Should I be able to operate a business that sends bulk advertisements to iMessage users?
      - AnthonyMouse 3y ago
        > Isn’t iMessage a service, not a protocol? It's a service and a protocol and a client application. But it should be possible for a third party to make an interoperating client application using the same protocol, and then it could connect to any service implementing that protocol. Obviously if you want to be selective in who can use your service then you should create a protocol that supports some kind of federation so that each user's service can forward messages to another service if the two endpoints don't use the same one. Email works like this, for example. > Should I be able to operate a business that sends bulk advertisements to iMessage users? Can you do this now by using a Mac with iMessage?
- naravara 3y ago
  The touchy part is the end-to-end encryption. The whole point is that Apple is the trusted party there. As an iMessage user I don’t want my messages passing through who knows which other parties’ servers when I send messages to others. The point of the blue bubble is to ensure the encryption is there.
  - AnthonyMouse 3y ago
    End-to-end encryption is where the client device encrypts the message and then the other end's client device decrypts the message. It doesn't matter how many servers it goes through, none of them can read it, that's the entire point of end-to-end encryption. The hard part is associating some identity with the user's keys, but when the ID is your phone number or email address, the entity doing that is inherently your phone company or email provider. You can standardize a way to do that, i.e. to sign up you get an SMS or email with a code and have to enter the code. The client can automate that if it has access to read your SMS or email, or otherwise you enter it manually.
    - naravara 3y ago
      If the person on the other end is using a non-Apple client you cannot verify independently that their client isn’t peeping. It’s the client, not the servers. But also when it comes to managing the keys and syncing across devices it’s also the servers.
  - Sabinus 3y ago
    If you're an iMessage user, don't you want your messages to non apple users to be encrypted? Kicking them out of the system makes your messages less secure, not more secure.
    - naravara 3y ago
      Who verifies that the client on the other end of your line isn’t intercepting the messages after they’re decrypted?
crazygringo 3y ago
> I've actually gotten into inadvertent fights with people over undelivered SMS text messages. Oh, man. Thankfully I haven't had an undelivered text in over a decade. But back in the early-to-mid 2000s, it was maybe a 5% failure rate in the country I was living in then? With no indication. And yes it really did cause arguments with romantic partners. There were times I had to pull out my phone and prove I'd asked/invited/told them whatever. But it's not like that ever really fixes the situation either. But if you asked anyone to confirm they'd gotten your message you seemed paranoid or needy. You just couldn't win. So much friction.

jorvi 3y ago

> Its behavior seems needlessly antagonistic. It is just standard fare across the modern bigtech world. Prior to the iPhone / iOS, Apple would have happily built in support for something like Google Cast, because they operated from the idea that their products should be the most useful for their customer. These days it’s all about forcing people into your ecosystem for increased lock-in. Thus, no baked in support for Cast (except in the Apple Music app on Android). As far as Apple is concerned, if you are visiting a friend and want to play some music on his Chromecast, the solution is to buy your friend an Apple TV for AirPlay.

pmarreck 3y ago
> Prior to the iPhone / iOS, Apple would have happily built in support for something like Google Cast I really don't think you can assume this. For example, a long time ago in computer years, Apple rolled out "Yellow Box for Windows" which was a way to get NeXTStep apps running on Windows http://www.shawcomputing.net/resources/apple/os_pictures/ybnt4/ http://www.shawcomputing.net/resources/apple/os_pictures/ybn... as part of Rhapsody Developer Release 2 (this was a prerelease OS X)... and then promptly ditched it. Being able to develop once and then deploy to both OS X and Windows sounds great to developers, but think about this: If you had access to Mac apps from a Windows machine, then why would you buy a Mac, when Apple is competing on quality and not price? It'd be a win for app developers but a big "lose" for Apple. So why would Apple have ever built a way to cast to Google Cast if they already had an AppleTV product that wasn't competing on price with Google Cast? (AppleTV's are great, btw)
- bloppe 3y ago
  Google can and has done the same thing. They stopped supporting YouTube on FireTV because Amazon refused to sell ChromeCast devices on their website. All these competitors have options to force you to buy their hardware just to use their services and vice versa. Google could start slowly degrading all their services for users without Chromebooks. Microsoft could force you to buy a Windows phone just to use ChatGPT. Clearly, all of this is bad for users across the board. Apple is by far the most aggressive when it comes to this kind of anticompetitive bundling. You can't just say "of course they want to be anticompetitive, that's just business!". You're supposed to not let them pull this shit.