From a hardware standpoint third party fitness trackers with full integration into iHealth and third party ear buds with the same (or better) features than airpods.

Part of the IBM settlement required them to document interoperability. That was used by the DoJ to force Microsoft to document their CIFS (distributed storage) and Active Directory (naming/policy) protocols.

The latter might be particularly instructive as my experience with CIFS when I worked at NetApp was the different ways that Microsoft worked to be "precisely" within the lines but to work against the intent. Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?

> From a hardware standpoint third party fitness trackers with full integration into iHealth and third party ear buds with the same (or better) features than airpods.

As someone who makes apps in the health space, I couldn’t care less if other tracker data was integrated into HealthKit. HealthKit honestly sucks - it's some bastard of objc naming schemes and methods jammed into Swift. The async is horrible to debug, too. No one has a good time in HK.

The issue with other trackers is that they are more locked down than Apple. You can't just get HR from Oura for instance - and that's not a health kit issue either.

The reason you can't get heart rate data from Oura is that they don't want people looking at it except in aggregate, because then they would notice the accuracy problems and data gaps.

I'm not a developer in this space myself, but my impression is that HealthKit is one area where 3rd party apps have access to the same data as 1st party apps.

I had a similar experience with MSFT docs when working at Sun. The docs were not very good, and though they seemed somewhat redacted, it felt like in fact their internal docs probably weren't much better.

Don't tall into that trap of thinking.

Many years ago I knew an ex-microsoft engineer. Microsoft had poor interoperability with something, and I speculated that engineers in microsoft didn't know what 3rd parties were doing and accidentally broke things.

He told me, "don't be naive - microsoft would have meetings saying 'how can we own this?'"

Not to cast doubt on your friend's story, I worked on both the SQL Server team and later on the Windows kernel team in the early 2000s (the bad years). I came from "outside" meaning I had already had a career at non-Microsoft-related companies (mostly startups using linux on the server). I was continually shocked at how _little_ the MSFT employees seemed to know about the industry, or how their customers used their own products.

As an example, this was the era of the J2EE App Server. Almost none of the people I worked with knew what an App Server was, despite the #1 database in use by App Server customers being MSFT SQL Server.

This was before that, early to mid 90's era

I still don't know what an app server is. Isn't that one of those things from the enterprise programming era where they'd get "architects" to design an "enterprise system" and it would come with twenty different things with names like "message bus" and "dependency injection" that no program in history has ever actually needed?

In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now. The two most common in my career were JBoss and Tomcat. Since Java packaged applications into Jars which could be run anywhere (up to environmental assumptions made by developers), you could simply scale up by sending these jars to the app servers to run. Actually, the Alibaba group was quite annoyed in the JCP that western members had given up on these aspects of the Java platform and were moving to support containerization. Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such. App servers standardize what it means to start an application which makes operating many applications much easier.

Message buses were generally in memory or in process streaming brokers. Most of these have moved externally today via Kafka, RabbitMQ or cloud proprietary versions like SQS. Some people may lean on ZeroMQ to build similar behaviors when doing multiprocessing and some people may even do it in process if they like the api. Definitely very much part of large scale application development today although the terms of art have changed.

Dependency injection is just a fancy name for polymorphism via fields in your struct, although if you have too much exposure to spring you will associate it with that plus an inversion of control on the actual injection part: that is, you will associate it with heavy use of annotations. If you have polymorphism with a switch (or chained ifs) on a parameter, you don't have dependency injection but if you have polymorphism by having different inplementations of a field of your struct then you are doing dependency injection. Very much part of good software design today, the annotation driven wiring possibly not so common outside of Java + Spring.

I think of dependency injection as a generalization of LD_PRELOAD, the point being that the "injection" is done via configuration that is external to the application's code.

That's a good take, I hadn't really thought of that one before and I had certainly used LD_PRELOAD or some incarnation thereof (forgive my memory is was more than a decade ago) to swap out different implementations of the same API.

> In case you are honestly interested--although your hyperbole suggests otherwise--an app server then was what the docker daemon (or podman or other container launcher) would be now.

Sure. I have worked on JVMs before, but not server side, and I never had to touch anything sold by IBM.

> Arguably, CGI servers for php/python etc. were also a type of app server, although I rarely heard them referred to as such.

No, I think there's a difference. The deployment story for PHP was that you copied it to the web server and that was that. The mandatory part was a webserver you had anyway. There is FastCGI, but in PHP's case it can be thought of as purely a cache and is not necessary.

> App servers standardize what it means to start an application which makes operating many applications much easier.

A PHP web app does have some moving parts like needing to start nginx/fastcgi/mysql, so in that sense it still needs a container.

But the difference between the PHP source itself and Java is that PHP is 1. stateless and 2. doesn't take nearly as long to start up.

The first one is the big one and means you don't need to restart anything to update the app. This part of PHP is so well designed it practically makes up for how bad the rest of it is.

The second one was more of a Java flaw; the runtime is undercooked (which is why it had all that other super complex stuff on top of it) and everything has to go on the heap, instead of having more of a concept of constant data that could just be mapped in from the binary/jar file. That's what they got for not adding value types I guess.

The Kubernetes of the 90s and early aughts

During the Ballmer era MSFT was famous for the lack of cooperation between and within teams. That's what you get when you use stack ranking to decide compensation.

Microsoft's documentation for Microsoft's own technologies (as in, the C# libraries they provide) is terrible. What's the competitive advantage there?

That is not true in my experience, Windows API is superbly documented and C# docs are of far higher quality than Java's

The C# documentation was, at least in its initial years, very good. It even had working examples that demonstrated functions. Compare that to typical javadoc of its time.

MS documentation used to be amazing back when I programmed for Windows. It was one of the hardest parts of moving to Java for me.

Reminds me of Bob Colwell's talk, although it's not from the same angle: https://youtu.be/jwzpk__O7uI?si=NZmfU6av_2D-uPgk (around 1:04:10)

>Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?

Maybe it was a deprecated part of the protocol, and setting it would cause an error or do nothing.

Maybe it's there to prevent desyncing errors that occur for long strings of zeroes. Information theory isn't the only possible consideration.

Or it could be a placeholder for future expansion and while it would do nothing now, in the future it might break things if you've ignored the documentation.

If you design a protocol without at least one field reserved for future expansion you are a bad engineer. Generally I would call this the protocol version number field, but there are other options. The important thing is there is some field that currently has a defined range, but can get an a larger range in the future and you check that field and abort if it is out of range.

I also recommend a second field called protocol ID which is set to a known random value (your wife's birthday) so that if someone gets an unknown message if they see that value they can guess what the protocol is.

Super apps are a dud. China has them because the regulators want them, not because they're a good business.

My understanding is the reason they are dead in the US is even though the banks might let you build payments into it they will not let you negotiate any discount in fees so you will have to add your own fees on top of their own fees. It begs the question of why a bank or consortium of banks hasn’t developed a super app.

When I gave this talk in late 2016

https://www.slideshare.net/paulahoule/chatbots-in-2017-ithac...

there was huge interest in messaging-centric apps as this runs around the boondoggle of having even the tiniest patch to your app get reviewed.

Why do they show up in other asian markets, like Grab and such?

A lot of people are used to WeChat, so it can feel natural to make another one. LINE is also basically WeChat.

I don't think that's enough to make them competitive though. For instance, a scandal in one feature of the app (or Facebook being considered lame by kids) will hurt the rest of it.

Exactly. Most people would rather use the best app for the niche thing they want to do rather than the shittier version from some mega-app they happen to have for some other reason.

Yes, but don't underestimate the power of convenience. That factor seems to inordinately raise the shittiness toleration threshold these days.

Cloud game streaming has been recently allowed worldwide under a few conditions ( https://developer.apple.com/news/?id=f1v8pyay ).

Forcing Apple to allow third party payments without Apple's cut would improve market opportunities for many businesses. Facebook could have its marketplace conduct peer to peer transactions. Amazon could allow the purchase of digital goods (books, movies, etc.) and put it on more equal footing with Apple itself. While big businesses are best positioned to take advantage today, the effects directly trickle down to small startup businesses.

While I personally don't care for it, cryptocurrency use would have more potential. Apple blocked apps for NFT features in the past because they couldn't get their 30%.

Having third party marketplaces might make it so that there is some actual curation at the App Store.

I wonder if this will have a trickle down effect on other app stores, specifically gaming consoles. Would XBox Live or Playstation Store, for example, be on the hot seat if they rejected an application or "game" that was basically a storefront for streaming other games?

I don't think so, at least not as a consequence from this case if Apple loses. Antitrust cases are usually very limited in scope. Microsoft's loss required many actions (documenting Active Directory and other protocols/formats, browser choice screens, etc.), but no one else in tech were required to do so.

John Sircacusa (from ATP.fm) pointed out years ago that the heart of Apple's biggest issues is business relationship management. This was when Apple only had a handful of issues with a few companies and made some poorly received statements about developers. Their ability to build mutually agreeable relations has only gotten worse in recent years.

Sony and Microsoft have kept their relations with third parties tough but ultimately agreeable. They promote practically all of their third parties (unlike the App Store which has so many apps that its like winning the lottery to be promoted). Consoles have stores which are probably more curated but which third party publishers/developers actually like.

IMO, DoJ, EU, etc. are acting primarily because they have received so many complaints from Spotify, Microsoft, Epic Games, Google, Meta, Tile, etc. Governments don't take action for the "public" interest on its own.

> Forcing Apple to allow third party payments without Apple's cut would improve market opportunities for many businesses.

It would, but that is how Apple collects their commission. Where regulations where Apple has been forced to provide this separation (such as the US), they have split 3% to cover payment fees out of the commission, and put additional considerations for when leaving the app to make a payment would result in a commission and that Apple may audit that you are properly reporting commissions.

The DMA mandated that Apple decouple their commission structure from a single App Store in favor of multiple marketplaces, and they put in a 50 Eurocent core technology fee per user per year (after a margin of free installs).

> Amazon could allow the purchase of digital goods (books, movies, etc.) and put it on more equal footing with Apple itself.

Amazon does have digital purchasing of Video. Amazon added the ability to subscribe to a limited video version of Prime using in-app purchasing, and that kind of account will bill purchases using in-app purchasing.

They likely have razor thin margins for anyone who chooses to do this, but expect customers to either have existing Prime accounts or to want to upgrade from Video to the full Prime account for the other services. I suspect they did the math and think their margins on Kindle wouldn't support this.

> Amazon does have digital purchasing of Video. Amazon added the ability to subscribe to a limited video version of Prime using in-app purchasing, and that kind of account will bill purchases using in-app purchasing.

Sorry, I do not parse this. What did they add?

Amazon Prime was originally an add-on to regular Amazon accounts that provided expedited delivery as a flat rate subscription. Later, Amazon got into the streaming business and bundled access to films and shows into the Prime subscription. For a while it was kind of a useless perk since the available content was old or low quality.

Later, as Amazon acquired more popular content and then created an in-house production studio, they added the ability to rent or "purchase" (rent) streaming video content on a per-episode/season/film basis without requiring the full Prime subscription service.

This was designed to address Amazon customers who were primarily (pun intended) interested in the video content, not the physical goods.

I think he’s saying you can subscribe to Amazon Prime Video via in-app purchase.

Yep, not the full Prime account, but a cheaper video-limited one.

The DMA did not mandate that they decouple their commission structure. That is Apple’s interpretation of the DMA which seems to change every few weeks so far. PWAs on home screens were disallowed and then allowed again. Apple looks like they do not have legal and execution discipline and is being caught flat footed. It is somewhat alarming that they have made so many mistakes (see Epic being revoked from their third party marketplace and then Apple being strong armed to re-allow because of a EU comment about investigation).

The idea that Apple is compliant with the DMA has yet to be tested. There are many direct statements by the enforcing commissioner and complaints from third parties that I think only a direct ruling will settle things.

I forgot about Prime Video purchases having a special back door deal for some of their purchases. I wasn’t referring to the subscription service but the purchase of digital books/movies. My point stands though. Digital goods could be sold and bought without special exceptions or loopholes from the 30% fee. That alone is a huge market opportunity.

Forget iMessage, I just want media messages from iPhone to not be sub-144p pictures/videos. I know sms is limited but I doubt that's a technical limitation.

And yea, Gamepass was an immediate thought of something a company wanted to ship but Apple blocked. Between that and the Epic Games store it looks like there's gonna be a lot more options to game on IOS by the turn of the decade.

It's not sms, it's mms, and it is in fact a technical limitation.

Honestly we should just sunset MMS entirely. It's like using 56k dialup.

  it is in fact a technical limitation.

No, it's not. Carriers limit the attachment sizes quite severely, but that's not an inherent limitation of MMS.

The file size limits on iOS for MMS are far below what most carriers permit, making photos and videos sent from iPhone look much worse when sent via MMS.

Doubt that. AT&T still limits attachments to 1 megabyte for picture, video, and audio files. That's not an iOS limitation. I just sent an animated GIF to a Google Voice number and it was compressed to about 800 kilobytes.

I suspect the people whining the most are communicating with folks that have "Low Quality Image Mode" enabled on their iPhone.

https://www.att.com/support/article/wireless/KM1041906/

Below are the limits per carrier. You are correct AT&T is 1m. The iphone has a limit of 200k which can be raised to 300k. Parent was correct.

https://www.infobip.com/docs/mms/message-types

Did you not read what I wrote? There's no 200 kilobyte limit. I literally sent a GIF from my iPhone that was compressed down to 800 kilobytes. Even the JPEG images were compressed to 300+ kilobytes.

If you're unable to send files that large from an iPhone there's a carrier issue in play.

Their link references MMS not iMessage.

How does Apple get around that MMS limitation?

  How does Apple get around that MMS limitation?

They don't, nobody does. Android users exchanging high quality media are using RCS, iPhone users exchanging high quality media are using iMessage. Fanbois pinning the blame for this on Apple are missing the role of telcos entirely.

Yes I know, it was sarcastic. They don't get around it, they use a different technology all together.

Are you sending that to another iPhone? Trt exchanging text messages between an Android phone and an iPhone. It's completely broken. Apple wants to force Android users into iPhones so that their tect messages stop sucking, as if it's and Android issue.

Does the MMS protocol allow querying the receiving device capabilities? As far as I know it doesn't, and I don't know how else iOS would know the receiver is an android phone to be able to purposefully downgrade the experience just for them. Unless your theory here is that if a contact number is in your contacts list as ever being iMessage compatible that it will always use higher quality even when sending over MMS? That seems easily testable by sending to an iPhone over MMS, and then removing the contact from your address book and messages and sending again over MMS

Why would you think that discovery would have to be an SMS/MMS thing?

Since you’ve never used an iPhone, let me explain the experience. When you type in a random new number it starts off green. If the user uses iMessage, once you finish typing it magically turns blue. Apple doesn’t care about whether the other number is an Android phone per se, although if it’s not using iMessage then it’s almost certain that the number routes to an android phone.

Because the assertion was that the OP's experience with sending MMS media in excess of the supposed 200k limitation must have been because they were sending to an iPhone. In order for that to happen, the sending phone would have to know the receiving phone was an iPhone so that it could enable "send bigger pictures to iPhones over MMS" mode. They can't retroactively change the media size once they've sent the message, so either somehow Apple is determining the receiver capabilities over MMS before sending the message, or the 200k limit isn't real / is a carrier imposed limit.

  because they were sending to an iPhone

No, I was sending it to a Google Voice number which means it goes out via MMS. Google no longer does SMS/MMS forwarding so I logged into the Google Voice site and downloaded the image that Google received via MMS. There is no 200 kilobyte limit.

I really love how folks are frothing at the mouth over things they don't understand.

  Are you sending that to another iPhone? 

No, I'm sending them from an iPhone to Google Voice via MMS. iMessage does not work over Google Voice. All that an iPhone knows is that the Google Voice number is not an Apple device.

  It's completely broken.

Yes. MMS implementations are terrible, just like carrier implementations of RCS.

   Apple wants to force Android users into iPhones so that their tect messages stop sucking, as if it's and Android issue.

Repeat after me: Poor MMS implementations are not Apple limitations.

> No, I'm sending them from an iPhone to Google Voice via MMS. iMessage does not work over Google Voice. All that an iPhone knows is that the Google Voice number is not an Apple device.

> Repeat after me: Poor MMS implementations are not Apple limitations.

Except that some of my family cannot send me a text on my Android phone because iOS absolutely refuses to treat it as anything other than an iMessage. Their contact for me does not have my iMessage/iCloud email. My iMessage/iCloud account has had my phone number deregistered from it. However, their iPhones cannot send me a text. It always sends it as an iMessage, even on threads where I send a text from my Android phone. Any reply just goes straight back to iMessage.

There are plenty of instances where Apple just does not care about text messages and protocols and will refuse to treat them properly. It is absolutely anti-competitive. They have been taken to court over this, which is why there is even a website that allows you to deregister your number. You used to have to use your iPhone to do it, which isn't exactly convenient if you lose or steal it. If you switched to Android, there was no way to get a text message from an iOS device while your number was registered with iMessage.

Now try sending to an at&t iPhone. By your experience it seems that Apple is limiting iOS-iOS image size, to promote iMessage. That's inherently not a bad thing, and wouldn't matter if iMessage wasn't a platform gatekeeping/discrimination tool. I say discrimination because of the GenZ opinion on blue/green bubbles.

  Now try sending to an at&t iPhone.

Why? Sending a message to a Google Voice number will always happen over SMS or MMS. iMessage does not work over GV. RCS does not work over GV. If you mean try receiving messages from an AT&T Android phone, sure, I've done that. No complaints, although AT&T seems to throttle the image size more than other carriers in my experience.

  By your experience it seems that Apple is limiting iOS-iOS image size, to promote iMessage

What? If I were sending messages to an iOS device directly it would go out over iMessage. Instead I chose to send a message via MMS to a Google Voice number where Google serves as the end device. iMessage does not work over Google Voice. There. Is. No. 200. Kilobyte. Limit. There's no gatekeeping, just shitty carrier MMS implementations.

The other thing though is that even if attachment limit were not a thing, I don’t think it’s spec compliant to send a video codec other than 3GP or whatever the format is formally called (ironically it’s a QuickTime format dating back to when 3G was an exciting up and coming standard and the iPhone didn’t exist).

If you sent an h.264 for instance, many flip phones would be unable to play it. So I think the MMS standard itself is holding us back.

I still blame Apple. If they prioritized the experience of their own customers above the value of the blue bubble in getting teens to bully Android users they could have obviously been the ones pushing a good RCS implementation with carriers by threatening credibly to drop MMS support. Instead they left it to carriers and Google who each screwed things up pretty well.

H.264 is indeed part of the MMS spec. As for which carriers support it, who knows.

yeah, but the one blocking its sun-setting is apple with their artificial barriers. if apple didn't do it's shenanigans, RCS or something similar with a different name would've have replaced MMS by now.

  if apple didn't do it's shenanigans, RCS or something similar with a
  different name would've have replaced MMS by now.

The only reason there's any RCS interoperability right now is because most carriers have bought into the Google RCS stack. Before that you absolutely had to be aware of which carrier the recipient was using. If memory serves T-Mobile is running both a Google and non-Google RCS stack. RCS is and was a mess.

Hell, if you've a rooted Android you can't access Google RCS and any RCS messages sent your way will disappear into the ether.

There are no third party RCS apps outside of hardware manufacturer skins on Google Messages as Google has shut them all out.

If you want to interact with the RCS world as a non-wireless carrier, expect to pay upwards of 10 cents a message and have a minimum revenue commit of thousands of dollars a month. Carriers also don't get paid for inbound texts on RCS, creating a huge new cost center instead of symmetrical texting volume resulting in minimal costs like the current SMS/MMS ecosystem.

This is untrue, the US carriers had a "cross-carrier" consortium that had built most of its own RCS stack, complete with animating dots when the other party was typing, and good image and video support. But Samsung refused to use it (not sure if Google was bribing them in the background) so it got killed in favor of supporting Google's flavor of RCS.

Any source for that? Afaict, every Telco now use Google's RCS stack.

I also can't remember what it was called, but every Telxo uses Google's because of its failure.

> In October 2019, the four major U.S. carriers announced an agreement to form the Cross-Carrier Messaging Initiative to jointly implement RCS using a newly developed app. This service was to be compatible with the Universal Profile.[34] However, this carrier-made app never came to fruition. And later, both T-Mobile and AT&T signed deals with Google to adopt Google's Messages app.

https://en.m.wikipedia.org/wiki/Rich_Communication_Services

Lots and lots of things have replaced MMS. MMS, like having a phone number, is just a lowest common denominator for people who don't take advantage of any of the plethora of free and vastly superior messaging options that are out in the wild. For years now, you or the person you're messaging with have to be lazy or incompetent to end up looking at an MMS message.

That is a shockingly user hostile take, especially considering you call out the reason why so many people still use it: it is the only solution for most users that consistently works.

The main reason people still use it is despite the issues with MMS (and SMS in general) the reality is that every vendor wants to own the messaging stack to build or strengthen moat, and the regulators who are in a position to enforce standard protocols have incentives in many or all countries to weaken the security of messaging protocols to meet surveillance objectives (whether those objectives are well scrutinized methods with judicial oversight, or blanket surveillance requirements).

Blaming the user as lazy or incompetent completely overlooks the significant financial incentives that platform owners and network providers have to maintain the status quo, or force the new status quo to strengthen their moats.

Most people couldnt care less with sub par video message security for most (not all) uses. The fact that every vendor want anything but a good standard stack for keeping their users captive is imo a more powerful incentive.

Both your post and OP's are confident and emotionally forceful without any reasoning why. On one hand, in most of the world, especially countries less developed than the US, messaging apps are very popular and SMS is either not even provided in the plan or barely used. On the other I do think that at the very least phone manufacturers consider MMS/SMS to be a core functionality because it's built into most phones. As such it does feel user hostile to not care about MMS/SMS. I can see the merits of both but don't know why I'd believe one over the other.

I'm curious where y'all's confidence comes from in user hostility or not and what indicators you have to tip your hand one way or the other. That might result in more elucidating conversation too.

Sure, I consider calling users lazy and incompetent very hostile because I have spent nearly 22 years building, testing and securing systems starting with ecommerce apps in the early 2000s, through government, finance, browsers and supporting services (Mozilla), internet scale infrastructure at OpenDNS, Cisco, And Fastly, and now at Amazon.

All along the way people routinely attack users for making poor decisions when they are simply using defaults, or the easiest to use and most compatible technologies.

* Pffft... Of course they got hacked, they used IE * Of course they got hacked, they opened an email attachment * Of course they got hacked, they clicked that homoglyph

In this particular case, SMS and MMS are baked into the phone, and delivered by the wireless provider, and for better or worse on the UX front, work with just a phone number and across all mobile OS. For anything other than that, if users have peers using other device or services, the alternative is to use multiple services to communicate with different groups based on which services they use. That means repeating messages across multiple providers, and/or missing folks because all the platform services have actively silo'd their platforms to prevent interoperability.

Yeah, SMS and MMS suck, but they suck less for the simple use case of messaging folks with cell phones, because the barrier to messaging those folks is having their phone number.

It's lazy and incompetent to attack users when users actually have very little control over the actual security or usability of the services and systems they use, especially as everything is hosted in cloud platforms.

Please don't conflate messaging apps with texting, it's disingenuous. Texting is the feature users expect of any smartphone to be able to send a message to any other user who has a smartphone, regardless of what apps they have installed.

This might be an unpopular opinion but I'd be delighted if the legacy phone system was forced to shut down in an orderly fashion. It's archaic and holds us back from adopting modern technology.

Start with brownouts, make them more frequent, and in a few months we could all be off that whole mess. There'd be some chaos for a bit, but future generations would look back and wonder why we clung to this antiquated pile of wires for so long.

The legacy phone system has a lot of features that aren't present in its replacement, such as freedom to connect with anyone who has a phone number, the ability to move your phone number from carrier to carrier, and the knowledge that as an individual the phone company can't block me from contacting its subscribers entirely for free as long as I pay a fee to my own phone company.

It's way better than being on Whatsapp or iMessage or Slack or Teams or whatever you're proposing to replace it because I have a lot of control over who can contact me and nobody is using my presence on the phone network as a means to drag all of my friends over to the same phone network.

The legacy phone system currently enables breathtaking amounts of abuse and fraud. I know all the benefits you're listing, and I would enthusiastically surrender them just to watch the legacy phone system be decommissioned.

If we invented the legacy phone system today, it would be illegal to operate because it's so insecure. We certainly wouldn't dream of forcing everyone to use it.

Any replacement would have the same fraudulent traffic migrate to it.

You can already see this type of fraudulent traffic occur on Telegram with the constant crypto bots and on Signal with the romance scams.

A PSTN sunset would force this fraudulent traffic to migrate to the over the top communications platforms, eliminate many people's ability to access emergency services reliably, destroy reliable voice quality on cellular networks as there's no consistent way to prioritize third party voice and video traffic.

> Any replacement would have the same fraudulent traffic migrate to it.

We've had SSL on the web for 30 years now. We don't visit our bank's web site and wonder if we're really talking to our bank, but we casually accept that of course someone calling from our bank's phone number could be a fraudster. There might be some fraud that is able to migrate, but it wouldn't be the smorgasbord for fraudsters that the legacy phone system has created.

> eliminate many people's ability to access emergency services reliably

This is like saying that we can't put out the dumpster fire because it provides some people with warmth. The 911 system (at least in the US) is already a travesty. Caller locations are a crapshoot for wireless calls. Call centers aren't centralized, standardized, or coordinated, and they're overloaded. The technology is outdated. Moving it off the phone network and onto a centralized digital platform would be a massive improvement.

Right now it's easy for me to buy a look-alike domain name for a bank, host a page on that domain that looks like a bank's login page, and pass through to the real bank to take over someone's account in an automated fashion. TLS doesn't prevent me from doing that.

What TLS does do is ensure that when I communicate with a third party on the internet, that communication can't be intercepted by any intervening switches or routers. TLS per se does not have any other properties. However, we've constructed a system of chains of trust using TLS certificates and trusted third parties. That system is not a technical system and TLS does not have the innate property of enabling you to trust or not to trust someone.

It's an important distinction because the PSTN and our system of TLS Certificate Authorities is a social solution to a social problem. And so suggesting that TLS somehow magically has a property that it prevents fraud is hard for me to follow, because fraud is also a social problem and you can't use technology to solve social problems. Technology can be used to lubricate, to bring people together, and to ensure that conventions are followed and that peoples' solutions can interoperate. But the real innovation in TLS from a fraud perspective is actually the network of companies, nonprofits, third parties, and government agencies who have collectively established root Certificate Authorities and who have ensured that those CAs control who you trust. None of that is specified in any RFC. It's entirely something we humans made up after someone created an enabling technology.

As for problems with PSTN, there are similar technical solutions, but largely PSTN fraud and spam are a social problem and require social interventions. This is why we have the FCC in the US, for example, because when the scope of an intervention becomes large enough it has to be administered by someone. When you say PSTN doesn't work because of fraud and spam, in my mind what you're saying is that the FCC does not do enough to prevent fraud and spam.

> freedom to connect with anyone who has a phone number

This is actually a bug, not a feature, as it enables all kind of robocalls and sms spam. That's why I love the iPhone feature that allows me to block all the calls from numbers not in my contact list. It does not allow this for SMS though...

It does allow it for SMS apparently, but the UI is easy to misunderstand. In the "Unknown & Spam" settings where you picked "Filter Unknown Senders" there is an option below it marked "SMS Filtering" and you need to set that to... "SMS Filter".

https://www.guidingtech.com/how-to-block-text-messages-from-...

Even if it couldn't do this, that would just bolster the case that Apple is making SMS worse than it has to be on their platform to promote iMessage and its network effects.

EDIT: I booted up my iPhone 14 on the latest iOS and I guess this has changed? There isn't a "SMS Filtering" option near the Filter Unknown Senders option which has moved to the top level Messages settings page versus when the guide was written.

I'm not sure if that means it always filters SMS or it never does, but again if it doesn't filter SMS at all that's an Apple choice, it doesn't mean you can't do it on SMS.

When I was on Android it did allow me to do this for SMS.

All you would need to replace this is a messaging app that uses email addresses as identifiers and then falls back to sending messages via email if the recipient doesn't have the app.

What organization runs the messaging app? Do we have some kind of consortium of companies? And how do we add or remove companies from that list? There are actually a lot of social problems around this that are already solved by the network of arrangements between the companies that run our phone system and the users of the phone system and so on. You'd likely end up recreating that and at the end of the day you'd have rebuilt the phone system. The technical problems are a very small part of this.

No organization runs the messaging app, it's a protocol that anyone can implement. Publish an RFC. The first time you contact someone who uses a different provider, their messaging app or service sends you an email asking you to confirm that you sent the message, after which your app is associated with your email address on their provider. A combined messaging+email app could handle this automatically. At that point you can make calls, video chats, group chats, E2E encrypted direct messaging etc., using an email address as an identifier.

In general, solve problems in the same way that email does but add protocol support for realtime direct communications and end-to-end encryption.

Somebody has to pay for the infrastructure. You can either have a very loose federation of a lot of individuals running their own infrastructure like in the early Internet on one end of the spectrum or a couple of big companies that essentially run everything like we have now with Google and Meta. But someone has to run it. If you rely on a single company to stand up everyone's instance of the application, then you're right back where we are right now. And how do you manage all of the configuration data for all of the users? There are a lot of practicalities here that I worry you don't appreciate when you say "It's a protocol that anyone can implement." Well, so is PSTN. It just so happens that you need a certain amount of infrastructure to implement it, which is true of everything, even email. I'm not convinced that a new protocol gets us anywhere because it doesn't solve the underlying very human tendency to want to pay someone to deal with all the unsightly stuff so you can get on with your life, which is incidentally also the problem we have with email vis a vis Google.

> You can either have a very loose federation of a lot of individuals running their own infrastructure like in the early Internet on one end of the spectrum or a couple of big companies that essentially run everything like we have now with Google and Meta.

Or you could have thousands of medium-sized companies that each operate nodes that interoperate with each other even though none of them is the size of Google or Meta, and users could choose one based on whether they want to see ads or pay a few bucks a year, or run their own if they're into that sort of thing.

> It just so happens that you need a certain amount of infrastructure to implement it, which is true of everything, even email.

The infrastructure you need for email is any functioning general purpose computer, including ones you can find in the trash, and a domain name, which you can also get for free if you really want to and in practice costs around $15/year to do it properly. Anyone with the inclination can do this and many solitary individuals actually do.

The infrastructure you would need for this thing would be even less, because the premise is that you already have an email address/provider, so all you'd really need is the ability to map a port so you can make a direct connection to the other endpoint -- or IPv6.

Whereas the infrastructure you need to participate in the PSTN... I think you're required to be a CLEC to even have a block of numbers assigned. If all you had to do was install Asterisk on the trash PC it would be something else entirely, but the telcos do a lot of regulatory gatekeeping, which is another reason the legacy phone network should be decommissioned and replaced by a modern IETF protocol.

My understanding is that used to be how most text messaging was done pre-smartphone in Japan.

Currently the only similar thing I'm aware of is https://delta.chat/en/, though I believe it does all of its networking over email, rather than only using it as a fallback.

I wonder what the pitfalls of using email this way are; it seems like a great way to get a free backend and growth-hack a chat app, so there must be some reason it's not more common.

It's the idealist's solution because it benefits the user. Companies typically want to use phone numbers because they're more expensive for users to maintain separate identities with, which helps when you want to track them. Moreover, companies want lock-in to their own network effect, not a federated network that anybody else can permissionlessly join.

It's the sort of thing you get when somebody builds it as a hobby project, or a skunkworks project escapes from a large corporation and is already open source by the time the MBAs get their hands on it. Or, in the old days, DARPA funding.

99 standards on the wall, 99 standards... take one down, pass it around, 101 standards on the wall.

https://xkcd.com/927/

Except that the popular messaging apps don't have published standards and you can't interoperate with them even if you wanted to. How do you implement the iMessage protocol on Android or Windows?

Point me to the existing IETF RFC for e.g. mapping email addresses as identifiers for use in a standard communications protocol for voice and video calls.

You used to be able to, with tools like Trillian and Gaim.

Not any more, at least for any semi-popular chat. The throwaway and no-names? Yeah you can, well until IF they get big. And well, they won't.

https://delta.chat/ does this.

> I have a lot of control over who can contact me

This might be the funniest thing I’ve ever heard. It’s literally legal in my country to spam me on my phone number and there is ZERO I can do to change that. Ergo I have fuck all control over who can contact me.

US should sue themselves for requiring a phone number for a person to exist to begin with.

> holds us back from adopting modern technology.

Where we're all captive subjects of some cloud asshole spoon-feeding us bits of infrastructure we used to be able to run ourselves

My vague understanding is nobody uses SMS outside America and the entire population is on WhatsApp.

If only! My wife seems to juggle her friends between SMS, iMessage, WhatsApp, Telegram, and Signal.

Sounds complicated. No wonder people in the US don't want to do that when texting is 100% free (with their phone plan) and universal.

Yeah I’m not installing an app to send a message. I get video and gifs and all sorts of whatever I need with iMessage.

Only android people fuss with third party apps because their phones can’t reasonably send messages by default.

Android devices can reasonably send messages between each other, by default. The whole issue here is that Apple has been intentionally holding back the cross-platform messaging experience in order to make competitors seem less appealing.

I can easily send SMS to any Android phone from my iPhone. I really dont understand your reasoning.

IOW, SMS is cross-platform. Whats the issue?

As an iOS user myself, SMS is still a low quality messaging experience, cross platform or not. Apple could have taken RCS seriously years ago, raising the standard of cross platform messaging for everyone. This would result in an objectively better experience for users of all platforms, including iOS.

Contrary to you, I only have a subjective opinion on the matter. In the 12 years that I sometimes use SMS on iOS, I never missed anything. What is it that I am apparently not intelligent enough to miss?

In no way am I intending to insult your intelligence, and I apologize for any lack of clarity that could lead to such a misunderstanding.

Unlike modern messaging platforms, SMS has no:

- guaranteed delivery

- read receipts

- proper support for group chats (MMS adds this, but the implementation is poor compared to modern platforms)

- support for multimedia (again, MMS added this, but support is poor)

- support for replies

- support for reactions

- support for any kind of encryption

- support for typing indicators

- ability to work independently of an active cellular connection

If SMS works for your needs, and you have no issues with it, that’s great. Ultimately, SMS does work, but many users rightfully expect more of a messaging platform at this point. There are real benefits to users from upgrading to a more modern system.

And without wanting to insult your intelligence, none of the features you listed were something I really wanted or needed from SMS. Its just that, a short message service. Relying on encryption in a world where each and every country does an attack on E2EE every two years is unrealistic. Read notifications are just a "let me spy into your day" feature that I, no-control-freak, never ever needed. The rest also just reads like a corporate feature list, many nice to haves, but nothing, for me at least, essential.

I am fine with using SMS, and it has always served me well.

The difference between SMS and iMessage doesn't really count in this context, since usage is largely transparent. Its the same app, and the same contact list.

They have completely different privacy and reliability expectations: SMS is ephemeral, unreliable, unencrypted and short; whereas iMessage is semi-persistent, reliable, end-to-end encrypted and long.

TLDR: It has nothing to do with MMS

But that didn't address GP's comment. Apple states that green bubbles are pariahs because messages can't be sent to androids so it breaks the system, or something like that [BS]

Iphone users think that green bubbles are pariahs because they aren't part of their exclusive group, and because green bubbles turn chat groups into rubbish, because yada yada not iphone. (spoiler alert, apple does it on purpose)

https://www.msn.com/en-us/news/technology/android-users-stig...

For laughs: Tim Cook telling someone he has to buy her mom an iphone (1hr 0mins 17secs)

https://m.youtube.com/watch?t=3615&v=sdvzYtgmIjs&feature=you...

Um no, if the powers that be who control the LTE and 5G (and soon 6G) standards would improve or replace MMS, apple would be forced to improve their ability to send images/videos because they must comply with the standards to have their phone allowed on the carrier networks.

This is a dumb complaint honestly. The carriers and Qualcomm closely control the standards bodies and could address this problem. Instead they focused on the bag-of-garbage that is RCS, which Apple has finally said they will support. But because RCS is a bag-of-garbage, Apple plans to support a different flavor (the basic standard) from Google's. $0.50 says Google will magically start supporting the basic standard too once Apple ships it.

I can count on one hand the number of MMS messages I've ever received.

MMS was much more common before data messaging apps like Discord or Facebook Messenger became some of the normalized places for cell phone chatter, which anecdotally I think that switch started happening (or at least I began recognizing that switch) around the early 2010's.

So I'm guessing you're a very young person based on how little MMS you claim to have received. Which is fine, it's fair to point out that technologies us old folk use may differ slightly from what the whippersnappers are doing. And there are no wrong answers there, except that it's also fair to point out that when you purchase a cell phone, before you install any apps, you have some ingrained cell phone messaging features. One of which is a messenger app built on top of SMS and MMS.

I've probably sent and received thousands of MMS messages over the years, because it was the primary method for a cell phone user to send a picture to your friends and family. Back in the day, at least, and still today for some. It was also the way that us old folk were able to send group texts at a time.

I'm in my forties! It may depend on the region of the world you grew up in, but in the UK at least MMS was quite expensive for what it offered.

Until 2010 I worked for Route Messaging (now they are called Telesign) on internal systems as well as integrations with mobile operators and other "messaging brokers" around the world.

MMS was indeed order of magnitude more expensive than SMS and several orders of magnitude less used.

Reasoning for such high prices was more about mobile internet/data back then being really expensive "1G" - and MMS was (still is I guess) using mobile data to send/receive "multimedia messages".

At this point I expect that cost of MMS is more about maintaining legacy systems/servers for that.

Although in something like 2008/2009 integrating through legacy SMS protocols (those previously used by beepers/pagers) was cheaper than through modern protocols. Some operators had hardware boxes supporting those that were already paid off long time ago.

Ah then I was very wrong, you are in fact a bit older than me :)

Thanks for teaching me a new thing about life outside of the US. Out here, cell data plans (which is the budget that sending/receiving MMS would eat into) were relatively affordable (even for my somewhat modest household) through the latter half of the 2000s and early 2010s. And now it's basically assumed that most people have "unlimited" data. So I guess MMS was a regional phenomena based on prices.

You didn't miss out on much, not that you probably thought you may have. MMS was a useful tool for sharing pictures digitally, but it was somewhat poor user experience waiting for it to reach the other person. Sometimes waiting for a reaction for an hour because the person on the receiving end wasn't near enough to a cell tower owned by their provider. Less of an issue with all the cell towers around now, but there are better mediums than MMS now.

MMS has always been extremely rare here, and I am around ~30 years old, so I guess it depends, of course. Personally I have never received, nor have I known anyone who has either received or sent a single one that was not by accident.

Must be a regional thing. Where I live in Europe, MMS were just too expensive to use regularly, roughly 5-10x more expensive than SMS, and they came roughly around the time when phones were slowly getting simple email clients and usable data (GPRS and sane pricing).

I’m around 30, I grew up with a dad who was a fan of modern phones and technologies (first camera phones, Windows smartphones, PDAs) so I always had fancy phones, and I’ve received < 20 MMS in my whole life.

I remember MMS being used here (Poland) as, essentially, faster postcards. Most people would only use it when on holiday to send pretty pictures to their family back home.

That might be it then. I'm around your age from the US, and the cell phone plans I grew up with were not prohibitively expensive, even for my somewhat modest household.

I still want to see Matrix get adopted for messaging by default. Purism actually did it with their Librem 5 (probably one of the few good things about that company, but that's a rant for another day).

That sounds like hell. If you think that carrier interop is bad now, wait till everyone is using a different matrix provider with different optional features turned on or off. At least today there are some barriers to SMS spam, matrix would open the floodgates while making blocking it exponentially worse.

That is, indeed, a technical limitation of MMS.

The newer RCS standard would be better, but Apple has already announced they're going to support it this year (after dragging their heels for a few years).

  That is, indeed, a technical limitation of MMS.

No, it's not. It's an implementation detail. MMS is basically just SMTP on the back end. There's no technical reason you couldn't allow much larger attachments aside from cost and shitty implementations.

The last time folks got worked into a frenzy over RCS I ended up looking at the MMS specs. If memory serves 3GPP recommended an upper bound of at least 5 megabytes. American carriers typically limit attachments to like 3 megabytes or less and they mandate ancient video codecs.

I guess rephrasing it to a practical limitation of MMS would be fair, though? Insofar as it’s not something we’re blaming Apple for.

Apple has a 200k limit. We can blame Apple for having the worst mms limits

Prove this, because I'm pretty certain this is not the case. I helped build a messaging app for iOS (Technically a TeleHeath app that needed to accept MMS/SMS also) and I saw absolutely none of this. That was a few years ago so it's possible it's changed but I'd have to see actual documentation for that. Otherwise I firmly believe this is BS and completely made up.

I’m curious how you did that, given that iOS doesn’t allow 3rd-party SMS/MMS apps.

https://videoconverter.wondershare.com/compress/mms-video-si....

No, they don't.

Do we really believe though that Apple doesn’t like it? I believe their top executives are glad it sucks because things like this make people (especially teens) bully anyone who’s not on iMessage, resulting in additional sales.

I think Apple has enough pull with carriers to tell them whatever configuration parameters for MMS they want.

This. And it actually doesn't even need to be done through SMTP.

MMS being basically SMS with a link/url to where the phone fetches multimedia part from - it could also be sent via older EMI-UCP (that was originally used for pagers).

At some point pre 2010 (when I worked in Routo Messaging - now called Telesign) we also got an SS7 connection - so we could finally start doing stuff like a real mobile operator/provider.

If you pay for iCloud ($4 a month) you can send an iCloud link easily to any video that anyone else can access at full resolution

I realize this isn’t what you are asking for. But it works well and doesn’t depend on Google’s closed version of RCS

long-time iPhone user here, i did not know this!

thank you for posting!

FYI for those others who don't know: click on a video in your photos app. click share --> "Copy iCloud Link"

Careful, it will leak your real name. It's no good for anonymous sharing.

Indeed, your real name will come out.. but otherwise its a nice feature

Pretty sure Apple will make the recipient sign up for an Apple account to view the content. At least it does this for notes sharing.

EDIT: Tried it on my iPhone and it does not require an Apple account, kudos Apple. It does show my full real name as others have mentioned.

That’s via email, right? Or is there something they offer in the messages app now?

you can send the icloud link via SMS or really anywhere, telegram whatever, using the copy icloud link button

Media messages from Androids to iPhones are in fact technologically-limited by MMS. That's not an Apple-imposed limitation, it's written in stone in the MMS standard.

Please show me where that's written because iPhones have no problems sending full-resolution images to my droid device but I can't do the same to them.

Works fine over WhatsApp/Telegram/…. Not a technological limitation.

What do you think those have to do with SMS/MMS?

The GP comment is about sending media between iPhone and Android, and claims that that is limited by MMS. That’s obviously not true. And has nothing to do with SMS/MMS.

Huh? Sending MMS between any two devices is pretty clearly limited by MMS.

Sending media isn't.

Other mechanisms of sending media are entirely irrelevant to a discussion about using MMS and the technical limitations of the MMS spec.

We're not in that discussion.

I was referring specifically to using the text messaging system, not the Internet.

You still cannot send livephotos via Whatsapp/Telegram. They convert to still photos. So you still lose something there.

MMS limitations are only relevant because Apple makes them relevant. I have never sent or received an MMS outside of the iMessage interoperability context. This is obviously deliberate.

You can send whatever you want through SMS, as a link.

Apple opened up the app store for game streams back in January.

https://www.theverge.com/2024/1/25/24050430/apple-app-store-...

Why don't twitter. com just do the super apps w/ e-commerce thing? It's financial regulations, not App Store regulations, isn't that the case?

What are challenges for implementing such "payment" system on iOS that can transfer, say Monopoly money vs real USD? Aren't those almost entirely legal or compliance matters for very good reasons? The Alaskan 737 MAX 9 landed largely intact thanks to still-working parts of regulations and we all value that.

So why not they just do that? Or CAN'T they?

> Why don't twitter. com just do the super apps w/ e-commerce

X, the company formerly known as twitter, fairly explicitly plans to, they are just taking time to pivot, in part because they don’t seem to have any real clear roadmap from where they are to where they want to be.

>fairly explicitly plans to,

>don’t seem to have any real clear roadmap

not your fault, but that's pretty funny

I see the apparent contradiction, but the goal has been made pretty explicit, but from the outside the plan seems to be missing.

Sounds like you meant fairly explicit goal, not fairly explicit plan.

s/plans/desires/

And also because they're in a technical quagmire of their own creation

> And also because they're in a technical quagmire of their own creation

Could you expand on that?

What you call "fairly explicitly plans to" I call "supposedly is working on, according to statements by its owner, who has a history of vaporware announcements".

Fair enough.

But also having a history of announcements that take longer than expected, and come true. (Reusable rockets come to mind.)

Facebook tried this with games and cash transfer within Messenger but it never really took off.

Personally, I don’t think Western (or at least American) consumers are all that interested in a super app. Asia has a ton of players in this space like WeChat, QQ, Line and Kaokao but those have never taken off in the West outside of diaspora communities.

Kind of sideline here but..

Tim Hortons had gift and loyalty cards ("every 7th coffee free"). Then they introduced an app with "rewards" as an alternative to loyalty and gift cards. Then the app turned into a bank. Then they stopped the physical loyalty cards. Now you can't "earn" free coffee without giving them your personal information and signing up for the bank of Tim Hortons. It's ok though. I stopped being a customer because of it.

Facebook’s attempt didn’t work out because they lost the youth market to Snapchat, TikTok, Discord and Instagram(It’s funny, I know). They tried to bring in Instagram users into Facebook but that didn’t(hasn’t) work out yet.

I mean even the old people barely play Facebook games or use Messenger money transfer. Western consumers just tend to trust product specialists rather than an all in one app.

Facebook marketplace has been the unexpected success in drawing Instagram users and youth in general. It's thrifting central for Gen Z.

I would be happy if iMessage threads could be exported and saved.

if I was going to dream big, I would like to point the iCloud hooks to a personal server instead of apple in a meaningful way.

If you have a Mac, your messages are stored locally with SQLite, so you can export them that way.

It is possible to export iMessage threads by purchasing an Apple computer and enabling "iCloud for Messages", at which point the messages will be synced to the computer and stored locally in an SQLite database then exported using open source tools... unless you sent too many messages or attachments, at which point you also have to purchase an additional iCloud subscription based on how much storage you need.

Hopefully you can accomplish all this within the return window of the computer (or purchase a used one). The iCloud subscription fees are non-refundable. You can also just give up, keep the computer, and embrace the Apple ecosystem.

Thank you Tim Apple, very cool!

Sent from my iPhone

> It is possible to export iMessage threads by purchasing an Apple computer and enabling "iCloud for Messages"

And hoping Apple's broken client actually downloads full history or by forcing it to download by scrolling up through years of chat by hand.

And hoping Apple doesn't interpret a read lock on the db as malicious activity and temporary ousting you from iMessage and causing every message you send on unrelated hardware to drop to SMS until you login / logout from every device you "own".

nothing you’ve cited has any factual basis in reality other than that you have convinced yourself that it’s a possibility. it’s purely a mirror of your own personal preconceptions and fears, none of which have a supportable factual basis.

gotta love when someone is so deep into fanboyism that they go through life utterly paralyzed and victimized by the apple that only exists inside their head.

literally, unsarcastically, why do you do this to yourself? it’s a fearsome depth of parasocial attachment in a way that’s incredibly unhealthy and warping. Why do you choose to get this bent out of shape about what phone other peolle buy? it doesn’t matter.

https://paulgraham.com/fh.html

Everything above is an anecdote that happened to me personally when I pointed a SQLite client at chat.db on my Mac.

I'm someone who has primarily used OS X, iOS, and Linux for pretty much the entirety of my life. The story about getting data out of iMessage comes from 100% personal experience. This isn't fanboyism — Apple's hostility toward people like me is palpable and factual.

Interacting with Apple's products as a software developer who cares about open source, data portability, etc. is getting harder and harder to justify. The same goes for Google.

What drew me to Apple initially was that they had an actually-existing polished POSIX-compliant desktop environment that was far more open than anything Windows had (or has, to this day).

What you're seeing here are the lamentations of early adopters witnessing all those great features, and the philosophy behind them, slowly going away.

- Music Apps (Spotify) that properly integrate with Siri, like on Amazon and Google devices.

I'd just like to be able to get music off my iPhone to my mac without having to buy a third party app or buy a subscription to Apple Music.

Your Mac has a microphone. A less analog option is Air Drop.

This is one thing that no-one else seems to mention (not even Spotify).

When Apple Music launched it was around the time that 3rd party apps were allowed to hook into Siri - so you could say "Hey Siri, tell MyToDoApp to remind me to do X in six hours" and MyToDoApp would add the reminder.

But it was only allowed for certain categories of app (strangely enough, categories where Apple didn't have a paid service). It wasn't permitted for music apps until a few years later, by which time Apple Music was established.

Similarly - when I connect my iPhone to my car over Bluetooth or wired connection[1] - with Spotify I get the normal play/pause/skip controls. But I can't see the upcoming play-queue, nor browse my playlists through the car's interface. If I listen through Apple Music, I can see not only my queue, playlists, albums and artists but also podcasts from the totally separate Apple Podcasts app.

Of course, the car interface is shite, but why can Apple's app do this and the third party not? Is it just that Spotify didn't bother implementing the relevant APIs or because those APIs were not available?

As a long-time Apple fan, my distrust of them is so great at the moment, I suspect the latter.

[1] The inbuilt head-unit doesn't do CarPlay, but I have a standalone wireless CarPlay screen. I like to connect the phone through Bluetooth (or wired) so the display unit shows my apps but I can adjust the volume and skip tracks using the steering wheel controls.

> It wasn't permitted for music apps until a few years later, by which time Apple Music was established.

My understanding - Siri is at its heart a command and control system. It was able to do Music (and iTunes before) because it knew The Who and The Rolling Stones from the hosted music catalog, even if those weren’t downloaded locally.

Apple needed to provide the localized commands, but also still needed the nouns to go with the verbs.

> Is it just that Spotify didn't bother implementing the relevant APIs or because those APIs were not available?

The former. There are plenty of other CarPlay media apps. They are all limited (first and third party) in that CarPlay is basically like a low bandwidth VNC display.

I meant the Bluetooth API so the head unit can see playlists and so on. the Spotify CarPlay interface is OK, but if I'm just on bluetooth, the head unit can't see my Spotify playlists, but it can see Apple Music's.