[ethbr1]

Exactly. It's amazing how often the nuance between may and must is missed by Apple fans.

Apple should be able to lock down their ecosystem as a default -- plenty of people will be happy to use that default experience.

But Apple should absolutely be prohibited from not allowing users the choice of unlocking their own device, for additional functionality, if they choose.

It's also glaringly obvious that many of the "freedoms" Apple affords its users (freedom from iMessage spam!) help drive its revenue...

[thebigman433]

> It's also glaringly obvious that many of the "freedoms" Apple affords its users (freedom from iMessage spam!) help drive its revenue...

Yea I mean this isnt really hard to understand. 99.9% of users would rather have no iMessage spam and also not be able to publish messages from their 3rd party watch. This works in Apple's favor revenue wise because people value having clean and familiar experiences, and dont feel like they are leaving anything behind

[fastball]

Not sure you understand the argument. If you allow people the ability to access iMessage however they want, how do you prevent iMessage spam? You may not care about this, but a lot of people do.

[TheBicPen]

How does connecting to a smartwatch enable spam? None of the comments here explain in detail how that would happen. The messages still get sent through an iPhone and through Apple servers. It's not like Apple is giving up any control over those.

[moron4hire]

How do you prevent iMessage spam, indeed? Because it's not being prevented right now.

[protimewaster]

Can't you already send iMessage spam using Apple Script on Mac? Would it be that much worse if it was also possible from iPhone?

Also, I'm pretty sure you can just set up a click farm to spam from iPhone right now, so there's also that.

[VogonPoetry]

It isn't easy to do with just AppleScript on a Mac. I run a sports team and I wanted to send out a message to people for special situations. Some of the challenges are that you cannot script sending a new message if there isn't already a thread -and- it seems like you must use the same contact info (email or phone number). There isn't much feedback when it goes wrong. Some of these do make sense for preventing spam. I suspect I could have used the accessibility APIs to drive the UI. I eventually gave up.

[saagarjha]

Do you think using a watch bridge would be easier?

[VogonPoetry]

Not really, but that really wasn't what I was trying to say. I was trying to counter what I thought was a faulty equivalence argument; AppleScript allows unrestricted use of iMessage today, so giving watches an API won't make it worse.

I do think that the state of AppleScript automation is the result of trying to break the mechanisms that were being used to generate SPAM. Could you agree that automation capable interfaces do increase the chances of bad actors taking advantage? Right now, with a lack of information, I don't know how I could make an iMessage automation interface "safe by design".

I do see a direct path from the mandated AT&I breakup and interoperability rules to SIP / VOIP services and the resulting levels of Phone spam and caller-id fraud. This has cost a lot of people, life changing amounts of money and much wasted effort and time.

Un-nuanced tech laws or mandates have a terrible track record for having bad side effects. Those effects often never get addressed, which makes me wonder a bit about the original motivation of why the laws came to be in the first place.

I also see a narrative that company X will automatically refuse to work with company Y or community Z and are de-facto always acting in bad faith. Even if company X was never approached or asked - yeah, companies do tend to isolate themselves making direct communication very, very difficult. I cannot deny that there are some company X's that do seem to behave very poorly. A counter example, in my opinion, is the recent Bambu labs API issue. As a tinkerer, a few minutes of looking at how people had built interactions with their printers strongly suggested to me that Bambu introducing an actual API endpoint was a really, really sane thing for them to do. (I did comment this way). Only time will tell if Bambu was actually trying to improve things or was acting in bad faith.