Hacker News Reader

Comment by integralid | Hacker News Reader

I wanted to be outraged at apple, but I really can't. Read WinAPI documentation and try to count all "reserved" parameters for example. OS developers build features just for internal use all the time.

Granted, this is just UI tweak so I'm not convinced it has to be private, but they probably just don't want to have to maintain that forever.

View on HN

The key distinction is the withholding from your competitors part. WinAPI may have a ton of features labelled "pls no use thx" but MS doesn't block you from distributing a program that uses them anyway.

That used to be true but they absolutely do this today :(

Spent so much time trying to repro some functionality only to realize that Windows has an allow list for what apps it listens to for certain APIs.

Did it? I worked on an EDR product for a decade and the window internal gurus were always talking about undocumented API parameters

Microsoft considers documentation status and long term support status to be the same thing. If the behavior of a function / API is not going to remain stable, it isn't documented. If they don't want to pay maintenance/support costs for an API (more rigorous testing, sample code, etc) the API won't be documented.

Historically Microsoft had a 100% back compat guarantee for APIs, so the second an API was documented its external interface was frozen in stone forever. There are still APIs around to this day that have misspelled struct fields because someone made a typo 30+ years ago.

If an API isn't documented it is "use at your own risk", although if enough large software starts depending on it, the API may have to be frozen anyway (or compatibility shims put into place) to avoid breaking popular software programs.

The "turn off Windows Defender PLS, I am an antivirus" API being a principal (and well-justified) example.

The only APIs that are locked this way AFAIK are PPL, Defender-disabling, and AV registration, all not exclusive to Microsoft, you just have to sign up to an antimalware developer program and sign an NDA.

That's not the key distinction -- of course Windows will likely have internal-only APIs for its own internal use. The problem is when e.g. there are special internal Windows APIs that Office can use but Lotus/etc. can't, or that Edge can use but Firefox/Chrome/etc. can't.

Sorry, yes. To clarify, it's about withholding features of a product in one market from your competitors in the other market.

Yeah, I wasn't trying to be snarky, rather there often seems to be a "private code shouldn't exist, code wants to be free!" ethos that makes my eyebrows twitch in PTSD from reading all of Raymond Chen's tales of depending on undocumented code, e.g.

*https://devblogs.microsoft.com/oldnewthing/20031015-00/?p=42...

*https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...

*https://devblogs.microsoft.com/oldnewthing/20230113-00/?p=10...

*https://devblogs.microsoft.com/oldnewthing/20060109-27/?p=32...

It's not withholding, it's just not part of the AppStore if you do it. There are plenty of other ways to distribute your software, and yes, Apple will also still co-sign it or provide entitlements if you need those. Just not in the AppStore.

That seems like an unnecessary and unreasonable trade barrier. There isn't a technical or user-experience reason to exclude these sorts of apps.

That's not the argument; the argument is that this would be some form of "there is only one method and it is being withheld", which simply isn't the case.

Yeah, this seems reasonable to me. The better thing to get annoyed at Apple for is being slow to implement web standards. I guess you could make the argument that they are choosing to work on stuff like this instead, but I think that’s a weak argument.

The better thing to get annoyed at Apple for is being slow to implement web standards.

Now that Safari supports the HTML5 date picker (since iOS 14.1 - five years ago), this is more of a meme than fact-based reasoning. Unless you believe Google including something in Chrome automatically makes it a "standard."

I have a list (unfortunately on a device I can't access now) of web standards that are supported on Safari and Firefox, but not on Chrome. I need it because one web site I work on is 100% Safari users (about 800 people), and another is mostly Android (about 70%). So I need a cheat sheet of which does what.

>>The better thing to get annoyed at Apple for is being slow to implement web standards.

>Now that Safari supports the HTML5 date picker (since iOS 14.1 - five years ago), this is more of a meme than fact-based reasoning

Apple forces all browsers on iOS to use the Safari browser engine, which they intentionally hobble by not implementing APIs that other browser engines have had forever so that Apple can force developers to create native apps for iOS which Apple then can extract 30% (or whatever they decide it is today) revenue from, where they can't do that from a web application. This is one of many reasons Apple is being sued by the DOJ for antitrust violations, and one reason they got sued by the EU and lost.

https://www.justice.gov/archives/opa/media/1344546/dl

Maybe 5 years ago this was a true, they accelerated development and their standards support is pretty good now, better than FF. Again, not counting Chrome's "EEE" non-standard API's, they largely move fast and implement most modern ones. Some PWA stuff is missing which is valid, while Chrome is behind on a few nice design-focused standards Safari has.

Go here:

https://caniuse.com/?compare=chrome+143,safari+26.0&compareC...

Note the non-supported Safari API's, the vast majority are not web standards.

Maybe you should read the DOJ suit against Apple. It's pretty clear that one reason (among many) that Apple is getting sued is because of abusive business practices exactly as I described.

Apple forcing Safari on iOS is present day, today, not 5 years ago (but it was also 5 years ago too, ever since there was an iOS webview). If Apple doesn't want to implement it, then they shouldn't force other browser makers to use their hobbled browser engine.

So you’re ignoring my entire comment and re-iterating the part I didn’t respond to.

Nothing in your comment makes any difference so long as Apple blocks other browser engines on iOS. I honestly don't give a fuck what they do with Safari as long as they allow real Chrome to exist on iOS, which I can then instruct my users to install because Safari is a piece of shit browser.

Safari is better than Chrome imo, technically, UX and otherwise, but you're entitled to be mad about lock-in. I just wasn't responding to that part.

technically?? With all those modern and useful APIs they don't implement? That's how they're technically better by not having useful tech? Wow. Okay, you do you.

I linked to my source, I think you haven’t updated your priors in >5 years or so.

Apple sez: We don't want to implement any of those APIs, and we forbid you to use a browser that implements them, because reasons.

Your comments are some Stockholm-syndrome level nonsense you're spouting to protect your favorite brand.

Which API's did they not implement?

I really never commented on lock-in, even said it's fine to dislike it. You're fighting an imaginary opponent here.

I really just pointed out that Safari largely caught up on web standards. It's Google doing the whole "embrace, extend, extinguish" thing that IE pioneered by stuffing non-standards into their browser so they can lock people in.

>It's Apple doing the whole "extinguish" thing that Apple pioneered by forbidding other browsers so they can lock people in

FTFY

Without IE we wouldn't have XMLHTTPRequest, something used by practically every web developer in existence today. Innovation happens, and apparently so do walled gardens that outright forbid any competition.

It's one thing to not implement web bluetooth, web midi, and other APIs on your own browser, it's quite another to block anyone else from doing so with their web browsers. The EU thought so too and forced Apple to let other browsers use their own engines. But not in the US yet, until the DOJ completes the case against Apple.

The only two APIs you listed aren’t web standards ;)

I’d love to debate you on the rest, but it’s a debate that’s been had here at least a thousand times.

I don't care that they aren't web standards, and I don't care if Apple ever implements them in Safari.

** What matters is that Apple is still blocking other browser vendors from using anything but Safari. **

The fact you can't or won't see how fucked up that is tells me everything I need to know about you.

And even then, they've made efforts to get better. Safari is starting to edge out Firefox for support of the features I actually want to use

I just want to use color SVGs as favicons. One file format- looks great on any screen at any size. But no, Safari isn’t interested in that feature.

Edit: I looked it up, and apparently its added in Safari 26!

Relative privation fallacy.

“Timmy got away with it. I should get away with it, too.” -Elementary school students

Private/secret APIs in DOS/Windows were a prominent part of the US and EU antitrust lawsuits against Microsoft in the 90s/00s.

> Private/secret APIs in Windows were a prominent part of the US and EU antitrust lawsuits against Microsoft in the 90s/00s.

It mattered because Microsoft had 95% of the operating system market at the time and was using its monopoly position to take over the web, even after signing a decent decree with the US government.

Edit: It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?

The current web monopolist (Google) was coincidentally founded 2 months after the US antitrust lawsuit against Microsoft was decided (july - september 1998).

Similarly meh results with US vs Google two weeks ago.

> It can probably be argued that Apple is a acting like a monopolist in one or a few areas though?

I don't think that's a credible argument. Apple, at best, has about 55% smartphone marketshare in the United States--and significantly less in most other countries.

Remember, having a monopoly isn't itself illegal; it's using the monopoly to disadvantage competitors, especially in emerging markets, which was what the Microsoft case was all about.

I don't think there's a legal justification for suggesting that Apple creating a private feature only they can use--for now--gives them unfair advantage in the market.

I wouldn't be surprised if Apple makes it a public feature in a future release of iOS 26.

https://www.justice.gov/archives/opa/media/1344546/dl

Microsoft doesn't punish you for using those though.

> I wanted to be outraged at apple, but I really can't. Read WinAPI documentation

But this is exactly why you SHOULD be outraged.

Reply on news.ycombinator.com