As cool how unified the Apple ecosystem is, I do think the EU is right that it's extremely unfair for Apple to give its own smartwatches access to the phone that other smartwatches have zero chance of getting access to.
Nothing restricts Apple from continuing to be this unified in their ecosystem. What the EU DMA tries to break, is Apple's "weaponization" of iOS to gain an unfair advantage in sales of accessories.
So if Apple (the product-company) requires changes in iOS to realize a new feature in an accessory product, the changes in iOS will have to be opened to accessory-competitors as well.
They would still be first-to-market with such new features (because they had a head-start in implementing and launching them with their accessory), they would just be facing competitors catching up over time like in every other balanced market.
Open protocols are great but they are also absolutely a hindrance on change. If you’ve ever worked on a public API you know how painful making a breaking change to that API can be. Inevitably something you want to change becomes some one else’s “hold space bar to heat room” feature. And sure you can have “private”
Or reserved spaces in APIs, but that can often lead to messes like needed 5 different vendor specific CSS tags to accomplish the same thing in all browsers, which in turn really leads to consolidation around one “winner” (see also IE6 and Chrome). They might very well still be able to make unified systems on open APIs and platforms, but it’s not clear whether they would be able to make them as well as they do when they control and own the whole stack and can change it without having to worry about anyone else.
> Open protocols are great but they are also absolutely a hindrance on change. If you’ve ever worked on a public API you know how painful making a breaking change to that API can be.
I worked on public API's. If there's a justified need for a breaking change, make a new API and deprecate the old one. It can of course be harder than this, but its complication mainly comes from proper PLANNING of the action and AWARENESS of the environment.
It's an OS, let's treat it as such and not buy into this narrative how hard and unfair the world is to this trillion dollar company.
Agreed it is an OS. How many years will it be before audio on the Linux OS doesn’t suck? It’s way better than it used to be, but I still spent weeks this year trying to sort out what magic combination of alsa, and pipewire and pulse-audio and wireplumber setting, configs and launch timings would get HDMI audio to not come up muted on a mini PC with integrated Radeon graphics in Ubuntu. Surely the openness of the x86 platform and Linux itself would mean that these sort of experience should be easy and painless in the way that audio on macOS or even windows is right?
Or how about the huge fight that systemd has been (and continues to be). If we imagine a world where os init was regulated by the EU, what do we imagine the systemd integration into RedHat would have looked like? We might imagine it would have looked the same, or we could also imagine that it gets challenged and beaten down in court because it’s breaking the current open standards “for no reason”.
The world already has an open phone os with multiple hardware vendors platform. It’s called Android. What do we expect actually gets better if iOS is forced open and why is that not already an option on Android?
> How many years will it be before audio on the Linux OS doesn’t suck?
Bad example. It's a bad example because in order to achieve that Linux has has many, many sound API's over the years. Most of them interacted in bad ways. Often the new boy on the block had emulate all the previous ones to have a hope of being adopted. If a great, reliable sound system depended on the ability to iterate on API's Linux's should have been stellar in very short order.
That said, Linux's sound is very good now. Echoing other responses here, it's now much better than MacOS. Given your your "easy and painless" comment about it, I'm wondering it you've used a modern mac. "You can't hear me? Wait, while I turn sound off and or, restart the app, restart the laptop" is a very familiar ritual now work forces me to use a mac.
As for standard's causing ossification - you're wrong on that too. What causes ossification is a wide deployment. Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it. Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that.
The way you fix API fragility isn't by avoiding standards. A successful API will become a defacto standard - whether you want it to or not. You fix the issue by designing your API's so they can be upgraded. This is why Google's Protocol Buffers allow you to add stuff at the end, and IP has a version field. Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6.
> Often the new boy on the block had emulate all the previous ones to have a hope of being adopted.
> ...
> Once it's out there you can't change the API without breaking all the deployments. Yes, a successful standard means it's been widely deployed, but it doesn't cause it.
Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API. Or as I put it in the original comment: "Open protocols are great but they are also absolutely a hinderance on change"
> Apple has so many watches out there it can't make breaking changes to the API it uses to talk to the iPhone. Publishing that API as a standard doesn't change that.
They can, all they have to do is push out an update for those watches. That's the point. Because that API is private an exclusively used by Apple and Apple's software, they can replace it as many times as they want provided they are willing to push the updates. On the other hand, if hundreds of third parties are using that API independently, even if they push an update they still have to contend with a whole ecosystem of products that will or won't update on whatever schedule those developers feel like operating on. Apple already catches a bunch of flak for the speed at which they update and abandon their current public APIs, hardly an incentive to also open up their private APIs.
> Without those things API's based on Protocol Buffers would be hard to change, and we could never have had IPv6.
I'm not sure I'd call the transition to IPv6 an example of a resounding success of fast iteration on a change to a protocol or API. It's only been 30 years and we're still using IPv4 for most things and slapping band-aid upon band-aid on the problems, never mind the list of headache switching to exclusive IPv6 (for example, unless something has changed recently, you still can't use DHCPv6 to manage IPs for android devices)
> Yes, that was the point. A public API in use by its very nature will have negative impacts on future development of that API.
And my point was I don't agree. It's not that it's public. It's that it's in use.
> They can, all they have to do is push out an update for those watches.
An update they can't be sure every watch has done. The usual solution is to that situation is to plan for it from day 1, design the watches so the very first ones you release can detect that's happened, and when it has issue an error message like "sorry, you'll have to update your watch to continue". Compare to: you design an API, as part of the design it queries what version the servers support, and issues a message like "your new end point doesn't support me any more, you need to upgrade something". Sounds very similar, doesn't it?
Example: ssh will stop running if your old client connects to a new server. It's a public API.
Example: SSL/TLS has moved through multiple incompatible versions. It's a very public API.
So apparently the API being public didn't stop transitioning to new, incompatible versions when the need arose. What will stop it is not designing your API with upgrades in mind. If you don't do that, you will end up in a world of pain regardless of whether the API is public or not.
You say it slows things down, but that's not necessarily correct either. Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem.
> It's not that it's public. It's that it's in use.
And an API that isn't public can have its use restricted to a controlled set of environments and places, which inherently makes it easier to update.
> Apple can continue to update it's API's and devices at any rate it pleases. If the 3rd party devices don't updates fast enough to follow, well that's their problem.
Until the EU decides that a public API that changes without warning and "arbitrarily" to suit Apple's needs is also anti-competitive. An argument that would easily be made the first time Apple shipped an update to the API that broke a bunch of third party devices even while their own devices continued to work fine because they received an update at the same time, or even early in preparation.
Again, my argument is not that it is impossible to make a public API or to transition that API. My argument is that a public API by its very nature often implies a slower pace of change. Even in your examples, SSL and TLS upgrades often happen over many years, with deprecated older versions being supported along side the current version for a while.
In fact, TLS is a great example of this, where TLS 1.1 had fixed the vulnerabilities that made the BEAST attacks possible, and yet in 2011, when BEAST was discovered, it was still a problem because in 5 years, TLS1.1 still hadn't had a lot of adoption. Or consider that TLS 1.3 has been out since 2018, and yet I can still connect to this very site using TLS 1.1 with weak encryption keys. In fact, if I change firefox to require TLS 1.3, I can't even connect to this site. Or consider further that initial TLS 1.3 rollout was hampered by middle layers that had implemented the spec badly (https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...).
Again these are not insurmountable problems, but they are problems inherent with a public API or protocol that multiple vendors are implementing, and problems that Apple either does not have to deal with, or deals with on a much smaller scale with their private internal APIs and therefore can move faster when iterating on those APIs.
> Until the EU decides that a public API that changes without warning
The usual solution is not to break the existing API, but to add new features and deprecate old ones. I doubt the EU will demand Apple not improve their API's.
The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden, but it can't be that bad as Linux, Windows and Android have maintained old API's for literally decades, so I'm sure Apple would cope.
Or to put it another way, the fact that Apple has to support a depreciated API for a while doesn't mean they are forced to use it. If they want to make a change, they publish their shiny new API and move to it immediately. The existence of the old one doesn't need to slow Apple down at all.
> In fact, TLS is a great example of this
If you're using it as an example of how a public API can't evolve then it's a lousy example. TLS did evolve, and fairly rapidly. The fact that some people elected to stay with the old version doesn't change that.
Frankly for most people BEAST didn't matter, as what they were doing on the internet didn't need a lot of security. But when it did matter, like say for a bank, then you were forced to upgrade. And guess what - that new browser still worked with old sites that support the new version. So some people chose to not move didn't slow the protocol's evolution at all. I think you are confusing the rate of adoption of something new, and the rate new things can arise and change. They are at best vaguely related.
And to state the obvious, the old SSL API's being public had no effect on speed of the introduction a new version, which is the opposite of what you seem to be claiming.
> The EU may have something to say about the rate Apple drops of depreciated API's. Maintaining them does impose a burden,
So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page.
> If you're using it as an example of how a public API can't evolve then it's a lousy example.
I agree, so it’s a good thing I have never once claimed that a public API can’t evolve, or that would have been a terrible example of that. In fact that argument would be completely ridiculous in the face of a number of APIs that have absolutely evolved in public.
What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change. And TLS absolutely backs that up. If you want to use TLS1.3 everywhere, you can’t. If you don’t want any sites to use TLS1.1 anymore, you can’t make that happen either. And the folks that make TLS can’t do anything about that either.
> So you agree then that a public API would likely necessitate a slower pace of change. It’s good to finally get on the same page.
Not at all. The pace of change is determined by how fast you introduce new API's. Apple in particular can change API's the iPhone talks to their watches as fast as they want, because they control both ends. Them publishing the protocol has absolutely no effect on that.
> What my argument is and always has been since the beginning is that a public API imposed costs on that evolution and almost certainly implies a slower pace of change.
Despite everything you've said here, I still don't know what those costs are beyond maintaining deprecated API's and documenting the API.
> If you want to use TLS1.3 everywhere, you can’t.
You're not Apple. Trust me, if Apple decided their watches and phones should only connect using TLS 1.3, then that's what would happen on the next release. You apparently are claiming being forced to publish they are now using TLS 1.3 would slow them down, but haven't offered a shred of evidence or a coherent reason on why that would be so.
On looking back, you haven't said anything new in this reply - you just repeated the same assertions. Sadly I have said anything new either, which means it's time to move on.
> How many years will it be before audio on the Linux OS doesn’t suck?
to be blunt, it doesn't seem to suck whenever someone designs a consumer product around it. I have DVD-Players, BluRay Players, Network Radios, all based on Linux OS, and I never have to hassle with alsa and pulse-audio. In fact I never interact with the underlying Linux, just like accessory vendors don't use linux APIs to communicate with iOS.
> If we imagine a world where os init was regulated by the EU
We don't need to imagine anything like this, the EU is not regulating any OS.
The EU identified that Apple is a gatekeeper to a market and simultaneously a player there, controlling the market in its favor.
To ensure fair competition, Apple is required to ensure that it's a fair market for all players.
As stated elsewhere, Apple is still enjoying a significant advantage, because they could still develop i.e. a Airpods feature which relies on a newly developed iOS-feature, launch both simultaneously and be the only one on the market using it.
The only major impact is that they are not allowed to restrict competitors from ever catching up with them.
> We don't need to imagine anything like this, the EU is not regulating any OS. The EU identified that Apple is a gatekeeper to a market and simultaneously a player there, controlling the market in its favor.
That market being… software development for their OS? And the features they are regulating being OS features (see “newly developed iOS feature”). So they are trying to regulate the OS then right? Like if Apple release iPhones with two OS options, “iOS Core” with not private APIs and no developer restrictions, but limited (even for Apple products) to all their things any external developer is limited to now and “iOS Apple Edition” with a model exactly like the current iOS and reserved all their “competitive advantage” features to interactions running against that OS, this clearly wouldn’t be good enough to satisfy the DMA requirements right? The goal isn’t that Apple competes “fairly” on any arbitrary platform, it’s specifically that Apple competes “fairly” on the platform that Apple puts their best features on.
The market being the sum of iPhone end-users buying other stuff than iPhones.
> The goal isn’t that Apple competes “fairly” on any arbitrary platform, it’s specifically that Apple competes “fairly” on the platform that Apple puts their best features on.
It's about putting features on the platform which are beneficial only to other products of Apple.
The goal is that if Apple offers products on the market it is gatekeeping, it does so in a way that doesn't hinder fair competition on that market.
Apple competing on headphones for iPhones while offering features that require iOS functionality not accessible to competitors is not fair competition.
> The market being the sum of iPhone end-users buying other stuff than iPhones.
Which seems a little ridiculously narrow doesn’t it? Why does any hardware vendor have an obligation to open all of their APIs and functionality to all comers just because they open some of them? Why is selling a highly sandboxed product not a valid thing to do? And especially why is that not valid when there is an entire other half+ of the market that is completely open and exactly the sort of free for all people are apparently looking for?
Ultimately it always comes down to this. Apple is one vendor, selling one piece of hardware that runs one OS. You can not buy or run iOS on anything other than Apple supplied phones. You can not run anything on an iPhone except an Apple supplied OS. Apple does not force carriers or retailers to exclusively carry Apple phones. They don’t require hardware manufacturers to buy iOS licenses even when they sell a phone without iOS. They don’t require 3rd party iOS developers to sign exclusivity contracts when developing for iOS. They don’t fine developers for making better versions of their software for other platforms. They don’t do those things for accessory manufacturers either. Apple sells Apple phones that run Apple software in a way that Apple feels is best for that phone. Why is this a problem? Yes I understand that iPhone users who want a pebble smart watch are given a worse experience. But they don’t have to use an iPhone. Nothing at all stops them from buying any of the hundreds of Android phones on the market and having the ultimate pebble smart watch experience. This whole thing feels like the equivalent of demanding the government force GM to support CarPlay. GM has decided they don’t want to do that. They think they can sell a better product without it. That might suck for people who want a Chevy and also want to use CarPlay, but is that really unfair competition and worthy of government regulation to force GM to open up their in-car entertainment systems?
Because competitors do not play the line as badly as Apple does and also because they are not trillion-dollar companies ruling every single thing that a billion-dollar generating platform is doing.
I am at a loss when people defend Apple that much. You can prefer their stuff and are free to stick to what they offer only, but there is no reason to prevent others making other choices and allow other manufacturers to compete on features.
Apple has to allow access to their OS so that others can interoperate with it, and that's that.
If Apple is not happy it can go into other business where interoperability is not required like say frying pan manufacturing or whatever.
But they won't because the reality is that Apple has been investing from the large supply chain and innovations of other companies since the late 90's while refusing to play ball in recent years.
In the early 2000's Apple was promoting open source and open standard, how time have changed...
> there is no reason to prevent others making other choices and allow other manufacturers to compete on features.
Who is preventing other people from choosing an open platform and who is preventing other manufacturers from competing on that open platform? Certainly it’s not Apple. There are no requirements that app developers exclusively publish for iOS only. There are no requirements that accessory manufacturers manufacture for iPhones only. Retailers are no required to sell exclusively either iPhones or Android phones and no one is charged any per device fees for iOS even if those devices don’t ship with iOS. How does a single manufacturer with less than half of the market share and no presence on any devices other than their own prevent other people from making different choices?
> Apple has to allow access to their OS so that others can interoperate with it, and that's that.
Why though? Why is it not a valid choice to sell a highly sandboxed device that limits the access developers of additional software can have to the device hardware? Why should it be illegal to sell a device where 3rd party developers can’t run their software as root?
> I still spent weeks this year trying to sort out what magic combination of alsa, and pipewire and pulse-audio and wireplumber setting, configs and launch timings would get HDMI audio to not come up muted on a mini PC with integrated Radeon graphics in Ubuntu.
This sounds very much like an edge case. Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so?
> Or how about the huge fight that systemd has been (and continues to be).
That fight was over pretty much when Devuan and Artix formed.
> If we imagine a world where os init was regulated by the EU,
The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position.
> Why didn't you use Windows or MacOS on the mini PC instead? Was it because you were unable to do so?
Because despite what you might assume from reading what I've written here today, I'm not against or opposed to open source and open protocol stuff. Everything I personally write I release open source. I push my own company to publish as much as we can as open protocols. I've been running some form of linux in one form or another since I first pulled down the MkLinux CDs over a 33.6 modem. I don't hate open systems. But I recognize that open systems have their own disadvantages and that a system being open doesn't inherently mean it's going to be a better experience or solution.
> The EU would only be interested in regulating this if it were an OS init controlled by a monopoly abusing their position.
And so as I've asked before in other places, what monopoly are they regulating here? If the other comments in this discussion are to be believed, iOS represents < 50% of the EU market. Not only that, but iOS represents a single os and a single hardware vendor. The only way to run iOS is to buy Apple hardware, and the only OS you can run on the Apple hardware is iOS. Meanwhile the entire rest of the cellphone market exists, has a fully open OS just like people want, and supposedly has an equal or superior experience to iPhone/iOS. Apple doesn't do anything to prevent retailers from selling non-Apple devices, they don't require app developers to sign exclusivity agreements, they don't require accessory vendors to sign exclusivity agreements. They don't require retailers to buy iOS licenses even for hardware sold without iOS. The only way one can construe Apple to have a monopoly is to say that they have a monopoly on the hardware that they manufacture. Which is a tautology. Sony has a monopoly on their TVs, Bose has a monopoly on their stereos, and Nintendo has a monopoly on their consoles. This is not a useful definition of a "market"
> Because despite what you might assume from reading what I've written here today, I'm not against or opposed to open source and open protocol stuff.
And the point of asking what I did was to point out maybe you wouldn't be able to get as far as you did without linux; certainly macos wasn't an option, right? Not a modern version at least. Why criticize an area linux is falling short when you're preferred OS isn't even an option? It just doesn't make sense in this context.
> And so as I've asked before in other places, what monopoly are they regulating here?
Are you the same type of person who would argue never had a monopoly because Apple and Netscape were available?
> And the point of asking what I did was to point out maybe you wouldn't be able to get as far as you did without linux; certainly macos wasn't an option, right? Not a modern version at least. Why criticize an area linux is falling short when you're preferred OS isn't even an option? It just doesn't make sense in this context.
That’s an awful lot of assumptions about both what I’m doing and what my preferences are based on the fact that I’m defending Apple having private APIs. To answer those assumptions:
1) my preferred OS for projects is actually Linux, because as I said I don’t hate open standards. Where I can get a better experience, or where I feel the trade offs are worth it, I prefer to start with an open resource
2) both macOS and windows would have been viable options for the project
3) in the project space, windows is actually the preferred os (or the one with the most general support anyway), but it’s not my preference (again see 1)
4) I’m criticizing an area where Linux is falling short because I’m using it as an example of open systems and standards not being some panacea or guarantee of a better experience. If open automatically meant better, one should be able to have a superior experience on Linux for this project. And yet…
> Are you the same type of person who would argue never had a monopoly because Apple and Netscape were available?
I assume you’re talking about Microsoft here, and no I’m would not argue they didn’t have a monopoly. But surely you can see the difference between a software vendor having 95% of the market for operating systems across multiple competing hardware vendors ( and that same software vendor forcing hardware vendors to buy licenses even for hardware that doesn’t include the OS) and a single vendor of both a piece of phone hardware that only runs one os and that same os which only runs on that hardware (both from the same vendor) who has less than half of the market for phones in general and does nothing to discourage retailers and sellers of their phones from selling competing products.
i do not know about ios as i don't own an iphone, but sound has sucked on macos for every single macbook i have had the displeasure to use.
- random full drop (have a little script to reboot the stack)
- device aggregation failing when i add my motu interface and no obvious way to debug it (that's on a mac mini)
- random semi-persistent stuttering when linking my mixer to my macbook via bluetooth (which did not happen on windows)
windows has not given me pain around audio for the longest time.
for some reason my ipad has been running smooth though, no complaint even with semi-exotic stuff
If your question is whether it will be more work for Apple, the answer is yes, to some point.
If you're also wondering whether Apple being mildly inconvenienced matters for the EU court or most users in general: honestly no.
They're at fault in the first place, and if for a new feature that took 2 years to build, users have to wait some extra months because of that decision, so be it IMHO. That has always been happening with the US only launch features, and nobody's been crying a river.
Physically can they? Sure. But there’s costs associated with that too. They’re clearly not hugely concerned with developer relations right now, but an ever changing “public” api certainly can annoy and drive off your developers in a way that a private and non existent api won’t. Likewise there’s an argument to be made that a constantly changing public API is also anti-competitive. If every iOS release winds up with breaking changes that force developers to update their devices and kill off devices that aren’t being updated anymore is that really any better than a private API? We already see a lot of anger over Apple dropping 32 bit libraries or how quickly they drop developer support for older OS versions and “force” developers to keep making updates to stay current on their public APIs.
the existing os alongside the new instructions could restrict apple plenty
unless you are saying you have inside knowledge about the amount of refactoring and new development necessary to comply, that would be fascinating to hear more about
such restrictions would be likely to spill over into customer impact
> you’re speculating
which is essentially the same as providing an estimate in a work setting
I don't think it would actually restrict Apple. So far they are the owner of the playing field (iOS) and also invite other players (vendors) to play there, but whenever they also play they reserve the right to step in areas of the field noone else is allowed to.
They are now no longer allowed to play like that, so that maybe adds a new burden to them compared to before. But I wouldn't chime in on the framing how much they are suffering from that...
Most here would agree that a public API is a liability regardless. Anything you can keep private (SPI) you should.
Opening up an API that has all manner of hooks into your Apple device is going to be (obviously, I think) one of the most challenging of API to expose. While a 3rd party watch might needs these API, a whole lot of n'r-do-wells (looking at you, Meta) will likely figure out a way to exploit it in their apps.
It's a can of worms or a Pandora's Box if you will. If Apple is forced to expose these API, but only after kicking and screaming, I would not be surprised.
Apple has many, many tools to prevent this from being a problem. To name a few:
- They can lock the API behind entitlements that must be manually requested and reviewed by Apple
- They can lock the API behind a user approval
- They can regularly prompt the user if they still wish to share notification data with the watch (same way they do to keep giving an app localisation data)
- They could enforce that the notification is sent encrypted over bluetooth, without giving access to it to the app itself - forcing its handling to be done on-device - if they're so concerned about this.
It's also worth noting that this problem is a complete non-issue for Android, and nobody seems to believe it is an issue there...
> Apple is already in trouble for requiring prompts for 3rd party vendors
Well yeah, they're specifically in trouble for requiring prompts *only for 3rd party vendors*. The problem is that Apple treats their own platform differently. There would be _no issue_ with a prompt if the apple watch required it too. Case in point: Apple Maps has the same localisation prompt as Google Maps, and as such, there is no regulatory problems here.
Entitlements are a lot more complicated, and here the DMA isn't very clear about whether or not it's acceptable or not - it's really up to the regulator.
Apple, probably due to their success and size, are trying "Make me!" as a response until, you know, someone makes them. But they're not willing to voluntarily offer these API up.
Apple is using closed-down features in iOS to gain an unfair advantage in Sales of accessories.
They are still fine to do that, but at the moment such a new feature/accessory is launched by Apple the necessary interfaces in iOS also needs to be available to competitors.
The result is that Apple will still be first with such features as they can orchestrate the launch of the feature in iOS with the product. They will still have a leg up in marketing and scale, as they will be able to market directly to their users and instantly sell in much larger volume.
They will JUST face a better balanced market where competitors will be able to catch up and match the experience.
The fact that this is causing any backlash at all is surprising. Apple still has the best cards in this game, they are just not allowed to change the rules in their favor all the time.
I feel like it would be easier to believe that Apple locking down access to things is the problem if anything at all comparable to their experiences existed outside. Yet whenever this discussion comes up, the answer to “why not just use Android’s ecosystem” largely seems to be that no such similar experience exists for Android. But why would that be the case if this was about Apple locking stuff down? Surely if a lack of open phone OS and feature access was the problem, we’d see a rich ecosystem of integrations that exist on Android devices that are just impossible to achieve on iOS right?
Don’t get me wrong, I would love to see a comprehensive and more open integration ecosystem for non-Apple devices, if only to encourage Apple to keep building. But it doesn’t exist now, why would I expect it to exist if Apple is also open?
> Surely if a lack of open phone OS and feature access was the problem, we’d see a rich ecosystem of integrations that exist on Android devices that are just impossible to achieve on iOS right?
It's entirely possible on Android? Pebble used to have decent integration with Android, from notifications/calls, to music controls, to sports tracking/health data. You could even get navigation integration! And that was a decade ago. That's what makes it so painful: the pebble android experience is really nice and integrates very well, while the iOS one is terrible due to the Apple lockdowns.
> Surely if a lack of open phone OS and feature access was the problem, we’d see a rich ecosystem of integrations that exist on Android devices that are just impossible to achieve on iOS right?
...yes, and that's exactly what has happened. Android has a thriving ecosystem of excellent smartwatches (Garmin, Pebble, Fitbit, Samsung & Pixel watches, etc) with lots of features (particularly around notifications and interactions with apps on the device) that are impossible to support on iOS. https://ericmigi.com/blog/apple-restricts-pebble-from-being-... has some concrete details.
So what is the problem needing to be solved then? If there’s a thriving open ecosystem, that currently enjoys the majority of the market share in the EU per other commenters in this discussion, and the only way to get “locked in” to the closed ecosystem is to buy a phone and 100% of your accessories from a single minority vendor, why is this a problem? Why don’t people just chose the more popular, more diverse, open and thriving platform?
They famously did basically nothing to Microsoft and Microsoft continued to maintain a near monopoly for many years and do all the same things it had always done to keep its monopoly.
Some people apparently don't remember Windows 98 and how Microsoft tried to demonstrate that Internet Explorer is suddenly such an integral part of the OS that it's technically impossible to separate it.
It didn't work, they were forced to decouple it again (which was susprisingly simple), and despite the somewhat weak result for Win98 I think we can be thankful for that.
I don't want to imagine how Windows 2000 would have looked if they would have continued cementing IE6 into the frontend...
> Some people apparently don't remember Windows 98 and how Microsoft tried to demonstrate that Internet Explorer is suddenly such an integral part of the OS that it's technically impossible to separate it.
Heh ye. That was obvious BS. Wasn't there like, sometimes, it looked like IE was running as a widget inside an window? Like search or something?
You mean the "Active Desktop" I think, some small widgets on top of the desktop wallpaper which usually showed 404's because you didn't dial up to the Internet yet :)
You are confused about Microsoft.
They did (do?) have some bad anti-competitive behavior but they won because ultimately, they provided a competitive OS (and software suite) at a very competitive price and nobody was able to successfully offer a combination of hardware/software that could match that offering. Not Apple and not even Linux with their free stuff, and it still stays true after all these years.
If one company were to make a compelling OS as good as Windows for as cheap or cheaper, people would flock to them really fast.
We can talk about the software coupling all day, but similarly devs are going there primarily because that is where their customers are because of the cheap costs.
Gaming and 3D software are notoriously Windows only because it's the only OS that has provided decent stability/features while allowing access to a competitive hardware proposition.
Now that Linux is somewhat viable, we can actually see some high-end software working there, in the 3D effects and video business.
Microsoft might be shady but at least they are providing good value. Apple is a major dickhead clamoring how much better they are while failing to actual value.
I am an Apple customer and I do think their OS is nice for many things but the reality is that outside of their laptop the value is extremely questionnable (and even for the laptop, because of RAM/SSD pricing you better have some justification for the benefit of battery life, otherwise its mostly a luxury).
No emoji is a reason HN is still good. Among many.
Your comment IMO has little value to a reader. You forcefully state your opinions but give me no reason why I should adopt them or any basis on which I could challenge them. I am more interested in why you think what you do than in what you actually think.
Why is that the only feature worth paying for? How are watches an "extension of this behaviour"? Why should everything be "mandated open protocol"? Do you see how that can lead to ossification and the stifling of innovation?
Amazon offers returns... so what? I haven't bought anything from Amazon for years. Some people don't want unreliable crap they have to constantly fight over warranties on, even in places with good consumer protection laws. Some just want something that actually works.
Sure, but most comments on the internet (very much including this forum) offer zero or negative "value" to the reader. What we're doing now is typically called "socializing and discussing topics of the day", which is typically a non-transactional sort of relationship. Notably absent from this is any obligation to persuade you of anything. I won't waste my time; I know this forum and the kind of discourse people want to have. What I say on this forum is self-actualization and deep therapy saying all the stuff I can't say to my coworkers' faces when they wag their jaws.
> Some just want something that actually works.
Sure! Some people are rich and assign little "value" to money relative to time (including me). This doesn't change anything: apple still operates at deep cost to the public. All that profit could be being put to productive use outside the reach of centralized capital. But as it stands they're basically lighting aforementioned cash on fire for the vibes and quarterly reports. If I see you with white earbuds in, I'll start selling you a bridge.
>What I say on this forum is self-actualization and deep therapy saying all the stuff I can't say to my coworkers' faces when they wag their jaws.
This is not what HN is for. We should not use it as a place to vent frustrations.
>This doesn't change anything: apple still operates at deep cost to the public. All that profit could be being put to productive use outside the reach of centralized capital.
That makes no sense. If that profit were put to better use elsewhere it would be. Either Apple itself would invest it elsewhere or people would invest it elsewhere instead of giving money to Apple in exchange for their products.
If you think a business making money "costs the public" that money you fundamentally misunderstand the very most basic principles of economics. It is the equivalent of saying that you think integers in computers are stored in base 3 or confidently proclaiming that "single entry accounting is the standard way to do it" or something. It is so so so wrong.
I think it’ll be good for Apple. Everyone will go “yay” and buy another brand of crap smart watch, realise it’s total garbage and buy an Apple watch anyway.
I'd love to use a Garmin or a Suunto, but they aren't integrated very well on iOS and I like the convenience of my iPhone and Macbook too much to switch to an Android. I think there are a lot of people who're not very satisfied with Apple Watches for sports tracking or who'd just like something that lasts a week at least. There are quality options outside of Apple Watches if you don't need it to feel like a tiny iPhone. Most of the UX I need was available on a Chinese smartwatch almost ten years ago (though super buggy back then), the basics aren't that hard and seeing how a fair lot of iOS apps have dropped their WatchOS apps for lack of usage I don't seem to be so singular in that.
But I don't think it'll hurt the Apple Watch sales all that much either, they still work very well as a fashionable accessory.
I have been using an Apple Watch since 2018 (bought for the "superior" swim tracking back then) and I think they are really not that good for sports tracking.
There is 3rd party software that makes the deal much better but it's ridiculous that they aren't able to provide the same quality/usefulness natively and it's added costs/frictions in the use experience.
I don't care much for the smartwatch thing (I think they are largely useless for the most part) and I believe this is exactly why Apple is trying very hard to not open up.
For smartwatch purposes, something as expensive (and with such a small life) as an Apple Watch doesn't make a lot of sense. You are spending way too much on some basic functionality and for sports tracking Apple really needs to step up to provide value matching the price.
The Apple Watch Ultra is decent but widely overpriced for what it does, even the most ardent Apple fans will say as much (like MKBHD who basically acknowledged that the Ultra primary feature was to be able to show that you had the most expensive watch from Apple).
I have both a Garmin (Instinct solar) and an Apple Watch (S10). The Apple Watch is actually slightly more useful even if it doesn't last more than a couple of days. Actually if I'm honest the Apple Watch saved my life a couple of times. The Garmin is nice, but it's just not as useful.
