Hacker News Reader

Comment by rubyn00bie | Hacker News Reader

Just my two cents...

The banning of Electron apps for using a non-public API just means it's consistent with any other application submitted to the app store... they cain't use them sweet private APIs neither. Users can totally still go and download a notarized application though and have no problems. It's something that'll very likely be remedied by the Electron team in its entirety if it hasn't already been...

As far as not giving a shit about Safari's ability to do WebRTC and PWAs properly; I don't really see that as Apple trying to kill web technology as much as them just not profiting off it. Apple doesn't make any money from the "web," they make it from their platforms which aren't HTML/JS/CSS. As a developer, that lack of focus does piss me off sometimes, but... as an end user I don't really notice. Safari is still the best mobile browser available, even if it is lagging behind the rest in terms of standards adoption.

...

And tangentially, in my opinion, the Electron apps being booted is a good thing, if even only temporary, as I really hate downloading an app from the Mac App Store only to find its a full blow fucking Chrome instance for something that would be literally be two NSViewControllers and a handful of "slightly" customized views. Like "Yo, player, your system tray app to show this red or green icon is using 400mb of ram and occasionally locks my CPU. WHY!?!"

View on HN

No app is being booted. New updates are being rejected because of private API usage.

If Electron fixes their usage of private APIs then this whole storm blows over.

Now if Apple introduces a rule that specifically says “non-AppKit apps are not welcome on the store” then let’s panic. But that is not happening here.

(I’ll be the first in line to admit that private APIs and App Store rules are mostly limiting creativity and competition )

+11 and thanks for the clarification, that even lessens the issue IMHO.

... my third and fourth cents.

I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it.

You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow.

The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it.

Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code.

Edit: Added MacOS or iOS for clarification since my point is the same for both.

This whole thing is about macOS not iOS.

Instead of raging at Apple, what all these people shipping Electron apps seem to not have realized yet and are about to learn is that 1) the private API use is not in Electron, its in Chromium 2) and Google won't fix it because they 3) do not distribute through the Mac App store and 4) use private APIs to be competitive with Safari on things like power consumption.

Your app now hinges on the ability of developers-that-are-not-you that you are not paying to maintain a private API free fork of Chromium and in the process not break such essential things like display composition where these APIs are used.

The right thing to do for the IOSurface or CALayer API is to file a radar and start a discussion with Apple to make it official. They do listen and this has happened plenty before. Rage tweets or Medium postings probably won’t help much though.

Apple will probably have to.

* I understand the prviate API was about reducing power-consumption.

* Apple sells itself on superior battery-life compared to Windows laptops.

* Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in.

* Despite the fact most of those apps are nominally free (Slack, Skype, etc), if they weren't available in the Mac App Store it would mean users would stop seeing the Mac App Store as the place to go for Mac software - thus damaging the brand.

In short: if Apple doesn't document this power-management API and make it public then significantly fewer _important_ apps will be available in their Store which is bad for Apple's current long-term vision. If these apps do modify themseles to not use the battery-life API then they'll reduce the computer's battery life which then makes Apple look bad.

It isn't a power management API. AFAIK Chrome is bridging in its cross-platform rendering at a late stage into CALayer, and the internal functions override CoreAnimation's handling of redrawing dirty layers.

Similarly, it is using internal functions to map mach ports onto file descriptors because their cross-platform bits do not understand mach ports.

Let’s be clear: they are important APIs that would allow non-Safari (WKWebView based really) browsers be competitive on macOS.

If GP is correct, that’s not the case. They are important APIs for someone who wants to maintain their cross-platform abstraction layer without muddying up their codebase.

This comment makes no sense to me.

How are Firefox and Chrome not competitive given that Safari isn't the overwhelmingly dominant browser ?

“On macOS” is the important part. Safari is by far the most battery friendly browser there and quite possibly has significant market share too. Mozilla has recently managed to reduce their consumption significantly using these APIs: https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

They are now because they both use those APIs. You can read about the impact of this specific one here:

https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

Before using those private APIs, with no other options to reach the same performance as Safari, both Chrome and Firefox were in a completely different league.

CALayer and IOSurface are not private...

CALayerHost and CAContext were listed in the offending apis in this rejection of an electron app https://github.com/electron/electron/issues/20027

Are those mentioned in the Mozilla post?

Firefox does not use CALayerHost. It uses the public IOSurface and CALayer.contents APIs.

https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-fr...

It is ridiculous to say that Chrome/Firefox are only popular now because they use private APIs.

Your own article says that Firefox only recently started using them.

Which Apple may keep private for any number of reasons, none of which have to do with hobbling competitors, nor is it proven that Safari uses these particular APIs to gain a performance advantage for itself in any way whatsoever.

So you’re basically just talking out your ass, saying that Apple should open up APIs that have always been private for the sole purpose of helping a competitor who knowingly adopted them in violation of platform rules.

“Yes, officer, I broke the law. But I think, now that I’ve broken it, you should just abolish the particular laws that I broke because some people think I’m a big deal.”

> Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in.*

Spotify and co will care more of getting into that 30% of the mobile market (and the more lucrative 30% at that) by doing whatever they can, than Apple would worry about them leaving because no Electron is allowed...

This isn’t about the mobile market...

The apps mentioned (Spotify, Slack) are also available on the mobile market.

Since they need to have them there, and don't use Electron there already, they can have them in macOS without it trivially.

Mobile market? Electron is a framework for desktop apps...

Electron is a tool for the desktop/laptop market where apple has a smaller share yet. It's more like 10%. It's also a market where people are used to manually installing apps.

The worst case scenario is that apple loses some revenue and major players avoid the mac app store for desktop apps.

Apple who gets most of their money from mobile will not care. App developers will lose some convenience but negligible money and they wont care.

Even so, there is a halo-effect - and customers’ expectations to meet.

> Unfortunately, the Electron ecosystem is too big to dismiss - there's a lot of software using it that could potentially pull customers away from Apple's App Store if they weren't allowed back-in.

I personally don’t care. In fact I grow tired of the throw everything in a webview cause we’re lazy mentality. Build a proper app that looks like it’s a mac app. Also I grow tired of the crap performance these “apps” have. I say remove the lot of them and force people to build a proper app. Electron is Flash 2.0

The App Store Developer guidelines state that “going to the press won’t get you anywhere”, but there has been countless examples of this just not being the case.

Radar goes nowhere, going public does.

I hate to be "that guy", but I can tell you of at least one instance in our case where going public went nowhere. It was more like, case dismissed with prejudice.

I don't know about radar. Never tried it.

Given my own experiences in the past, I would doubt that radar goes much of anywhere either. Apple just doesn't seem like they move unless and until they want to. But again, I can't say for sure about radar, as I said, I've never gone that route.

By far the best route to go is to be in a position where Apple was about to make the change you wanted anyway. But you probably have to get pretty lucky for that to happen.

> The App Store Developer guidelines state that “going to the press won’t get you anywhere”

Where does it state this?

https://developer.apple.com/app-store/review/guidelines/

Radars don't go nowhere. Each one is read and triaged by the product managers.

The question is whether there is merit from Apple's perspective in making these APIs public.

Because often we find out at WWDC a year later why they didn't make it public and it's because of some foundational rearchitecture.

And I'm sure the managers do a very tasteful ceremony where they read the radars out loud before they print and burn them on the sacred pyre at the end of the month.

The largest ash pile does get addressed eventually.

No they always stay there.

It's just that the world doesn't revolve around one particular issue. If your particular issue doesn't have lots of duplicates (i.e. common) or it isn't strategically important to Apple then it just doesn't get prioritised.

I don’t think Apple sees it as in their best interests to support Electron apps that use a private API to which they intend to make breaking changes. Effectively, this hampers their own ability to refactor and rearchitect their own products, all for the benefit of a competitor.

Not only that, but if Apple didn’t ban the use of private APIs then they would be blamed whenever one of their updates broke all these popular Electron apps.

In a sense it’s like letting squatters onto your land. If you ignore them long enough then at some point society decides they have the right to be there, and then you become the bad guy for deciding to enforce your own property rights.

What your parent is suggesting is to make those private APIs public, or at least make a public replacement. It's not calling into question the ban, but instead saying that there's a hole in the public API Apple provide and that they should bring in new public APIs to fix that hole. The last time this came up I asked why those APIs were being used, and was sent two interesting links by users skymt and Humphrey, explaining why both Chrome and Firefox use those private APIs:

- Chrome explanation: https://www.chromium.org/developers/design-documents/chromiu...

- Firefox explanation: https://mozillagfx.wordpress.com/2019/10/22/dramatically-red...

Windows has public APIs for doing those things. It's pretty clear that there's a need for them. Apple should absolutely design a stable solution for those, since there's a clear demand.

I don't think Firefox actually uses those private APIs. Do you have proof of this? That post only mentions CALayer and IOSurface, which are public.

I am not completely familiar with these APIs but from what I gather they are primarily intended for low level rendering and to support them means supporting frameworks that bypass all of Apple’s native APIs.

Apple does not want to do this for business reasons. Microsoft does, but they have a different business model than Apple. Apple is in the business of selling their own hardware which means they want exclusive apps. If everything is cross platform then Macs become an overpriced commodity. Why even develop macOS at that point?

Ultimately Apple wants to make users happy and I suppose therefore buying more Apple stuff.

If you think the only way to achieve that is inevitable pursuit of "exclusive apps" then fine. But I would say, a user who gets the apps they want and isn't artificially constrained in that goal is a happy user, who will be satisfied with Apple letting them achieve that.

I am all in favour of exclusive apps. I've been using Macs since the early 90s and I have long sought out the apps which show the most care and attention to detail by developers, conforming to all of the user interface guidelines. These apps feel so much better because they are predictable in a way that cross platform apps aren't.

Cross platform UI toolkits have their own internal "logic" that clashes with the native UI, frustrating user expectations.

I wonder if “these private APIs are about to change in the next release” is part of why they decided to stop giving Electron apps a pass on this.

They'll just stop distributing versions through the Mac App store and the Mac App store will become even more irrelevant.

App Store will always be relevant since it's such a popular distribution channel.

And one app not being on there isn't going to change that.

They're putting their apps out for the money, not for some principle.

If they need to drop Electron to get into the more lucrative 30% of the mobile market, iOS users, they'll do it as fast as they can...

Electron doesn’t run on iPhone?

it does with cordova

Nope, Electron is a platform that Cordova runs on.

Many of the apps in question are free apps... I tend to have Spotify and VS Code open most of the day. Then again, I replaced Mac on my home desktop with Linux, and getting rid of my rmbp in a few weeks.

>Many of the apps in question are free apps...

There's no such thing as a "free" app from a for-profit company -- except some neglected side project.

Spotify is only free because they want to hook people and then sell premium subscriptions to those that are up for it, others are monetized by ads, private info (eyeballs), etc.

"Free" means the app isn't charged for, not revenue generating directly... so jumping through hoops to satisfy Apples whims is not productive. Context matters, and I'm pretty sure you understood the context.

I don't see why Google would be inclined to fix anything related to iOS because they seem to be currently deploying a multi-channel strategy to put pressure on Apple to let Chrome be loaded as a native app alternate browser.

From Google's perspective, Chromium-based apps being booted from the iOS App Store is probably a fantastic thing if it leads to articles like the one linked up top here.

"Apple makes it hard to use the web" is a much better message for Google than "Apple doesn't let users install Chrome so we can't collect as much data from iOS users as we do everywhere else." Even though the latter is the truth behind their push to get Chrome natively onto iOS.

This is about macOS not iOS. Electron and Chromium on iOS is not a thing.

> 4) use private APIs to be competitive with Safari on things like power consumption.

Uh, if that's the case then I think they're barking up the wrong tree. Just given. How that's going for them.

Makes me think this is a move by Google to make Android more appealing.

Or perhaps fork Electron to provide a version which uses Safari or even WPE [1]. I’m using WPE in an embedded device since it has better memory and GPU usage than chromium.

1: https://webkit.org/wpe/

> Safari is still the best mobile browser available...

This is nonsense. Safari is the only mobile browser available on iOS, so if you're sorting by mobile available per platform, then of course it's the "best [of one]". If Chrome and Firefox had the opportunity to bring their platform fully to market on iOS, there would be some real competition there... They could still do what Android does with displaying any in-app web rendering like Android System WebView, while allowing users the option to use the same browser and experience they're used to on their desktops.

Are you sure? I have Chrome on my iPad.

They run Safari/Webkit underneath. The core engine is not Chrome code. What you use is the value-added trinkets like bookmark sync, different UI design. The important bits are still controlled and locked down.

If Safari for iOS could just add "Find in Page" like exists in Chrome for iOS, I would switch today. Chrome shows it's possible. Why can't my mobile browser have Find in Page? It's far more valuable in mobile, because you can see so much less of the screen.

It does. Type into the address bar, scroll to the bottom of results.

It does offer Find in Page, you tap the address bar to bring up the keyboard, type the word you’re searching for, then scroll down to the bottom of the search results to see if the word was found. Tapping that line gives you a way to navigate through all found results.

Well hot damn, it sure does. Thank you.

You have an app wrapping an iOS web view widget with some customized networking code. Apple's App Store policies prohibit Google from shipping a full browser engine.

No you can’t actually customize the networking anymore. On iOS Apple controls the whole web stack. Content, networking, JavaScript.

You are free to use the POSIX networking APIs in lieu of CFNetwork (or Network).

Yes of course. But you cannot replace the networking that WKWebView uses.

Any other non-Safari browsers on iOS/iPad are forced to use the same underlying WebView rendering technology for actual display of web pages. So Chrome on iOS is really just a wrapper around a WebView that adds things like Google login integration.

They are forced to use JavaScriptCore, in the sense that you can't execute JIT-compiled code except for within that one blessed, sandboxed framework.

I don't believe they have ever been limited in porting, but have decided the performance hit for using their own javascript engines (or compatibility issues in leveraging Apple's) aren't worth the effort.

Even more, the WebView on iOS is not Safari. It's dumbed-down Safari that does not support certain features that Safari supports (service workers and all PWA-related stuff). So it's not equal competition at all.

I'm pretty sure it's exactly the same code base just with some minor feature flags.

Not that minor, there are indeed 2 different engines.

One for Safari and one for the rest.

Right, but that comes out of the exact same code with some minor feature flags.

You're parroting old news. The different engine is for UIWebView which is now deprecated in favour of WKWebView which uses Safari's Nitro engine.

Websites saved to the home screen use UIWebView's engine — but that's not the discussion, the discussion is about browser apps which can and do use WKWebView.

Besides technical limitations: the iOS App Store rules are clear: it is simply not permitted.

That is a chrome skin over safari

I can't imagine the marketing shitshow that would happen if Apple were to allow this. Google already spams Chrome in popup banners on google.com, in popover divs on gmail, inside security alerts...

Basically Google would immediately use all of their properties and muscle to wrest control of iOS. And then why even bother to have more than one platform.

What does "use all of their properties and muscle to wrest control of iOS" even mean? Apple would still control the OS and how it works. They would just allow for a real web browser that can run web code as well as you can on Windows. That's not hurting Apple at all.

Apple should stick to making top notch hardware and software for their phones. Just allow users to run a real web browser as well.

And Google will have full control over the web. As soon as they have majority browser on all platforms, they will ramp up their “innovations” of web platform and leave competition in the dust. And then nobody will be able to stop “standards” that help Google, like substituting URLs on AMP pages for instance.

That's a problem specific to Chrome. Firefox and Brave do their own thing and lots of people choose to use those browsers instead. The fact is that people don't have that choice when using iOS.

Lots of people as in about 10% (brave probably less than 1%). As soon as Google is allowed to ship it's own browser engine on iOS, open web is doomed. Google will simply start to ship new “standards”, and web developers will use those standards, because who uses not-chrome anymore?

People like you for example? People who are and have been so deep in the Apple box that you probably won't even consider a different browser because Safari is the best.

On the other hand: Chrome only became so popular because of their shady propagating of the software. Through freeware installers etc. Something you can prevent very easy on a Apple phone.

Also: the market is not so big. Even if they'd "take over" iPhone, it wouldn't make a big difference on the control they already have.

Safari on iOS is faster than Chrome on Android and given how crappy Google apps on iOS are I have no reason to believe they could do a better job than Apple.

Chrome on Android is actually pretty fast.

For crappy aid, I only remember iTunes on Windows.

What the... Was that...

Chrome on Google’s flagship Pixel 4 is not as fast as Safari on a 3 year old iPhone 7: https://www.anandtech.com/show/15068/the-google-pixel-4-xl-r... (See the Speedometer, Jetstream and WebXPRT benchmarks. Admittedly these might not be representative of your browsing habits but the trend is clear)

> Safari is still the best mobile browser available

How much of it is because Safari is good, and how much is because Safari is the only option?

iPhone has a huge market share. It is not possible for web companies to ignore or deprioritize it. Safari is the only web browser available on iOS. So all website owners make damn sure their website works well on Safari. They may even omit features that Safari does not support for all browsers, because it is easier than graceful degradation.

Back in IE6 days, for best web experience, you would want to use IE6. It's not that it was so awesome and so far ahead of Netscape. It's just that all websites were designed for and tested on (objectively terrible) IE6. You could use the (objectively superior) Opera or Netscape, and you would have a worse experience, because websites were created with IE6 in mind.

Safari is not the best mobile browser. It is the browser everyone writes for and tests one. Chrome is not superior to Firefox. The reason so many web apps (e.g. Skype Web) do not work on Firefox or Google Maps is slow on it is not that Firefox is bad. It is that they only target Chrome when designing the website. Everything else is an afterthought, if even that.

Safari is not the best browser. Neither is Chrome, and neither is Firefox.

Each of them have their strengths and weaknesses. Safari is the best at low power consumption and integration in its environment. Firefox is the best at customizability and openness, and standards adherence. Chrome is the best at, well, popularity, I guess; innovating new web standards, maybe.

I've never used mobile Safari, but where mobile Chrome shines vs. Firefox is 1. speed. 2. easier to navigate through your tabs when you have many open.

If not for those, I'd just be using Firefox because the ability to add plugins (eg. Adblock) and have Youtube not stop playing when you minimize it are obviously huge advantages.

I think you should specify which platform you're using (I suspect Android.) On iOS all the different browsers are just different UIs for the same engine.

Yes Android on a Galaxy Note 5

I think you're giving the author too much credit. They recently chimed in on Twitter in a similar context- which I'm guessing is where the motivation for this blog post originates. And despite having a WebKit engineer publicly discuss design decisions and reasoning, they ignore them during that discussion and go on to write this article while making note of literally none of the context that was provided? https://twitter.com/johnwilander/status/1191185213012865025.

It's bad faith commentary, to say the least. Look at the level of accusation they're making "Apple Is Trying to Kill Web Technology" ... "It wants its Mac App Store to be filled with apps that you can’t find anywhere else." Leaving aside the fact that there's no way Apple makes enough from some imaginary exclusivity to justify trying to "kill web technology," none of their moves can even rise to that level. So they were slow to implement WebRTC? Service Workers? Both have massive privacy issues- and partitioning service workers out of process is the crux of how WebKit enforce's privacy- which they're pushing even harder these days. And according to said engineer they even added a compile flag so Google didn't have to use partitioning (I wonder why they wanted that...)- how very anti competitive of Apple. And suddenly mandatory WebKit on iOS is a "monopoly?" It's their platform- they define the security and privacy baselines. Apple has had a walled garden since before the "Web Technology" the author is referring to existed and this is a piece of that. It's another valid consumer selling point- their stores aren't cluttered with trash and I know what those apps can access. But, according to this person, every single point here is fake marketing speak because... checks notes... they want to force people to develop apps only for the Mac Store? Really?

We can be critical of Apple for a lot of web stuff, but it takes a delusional level of self-absorbance to think that Apple is bringing about the end of cross platform web tech because they put up a completely fair and valid barrier, that will probably be resolved shortly, as you said, on one's tech stack of choice.

Reading the attached twitter thread, I do believe the author is engaged in a bad faith argument.

WebKit engineers provided very reasonable arguments for why WebRTC and service workers took a while to build and diverges from the spec: privacy.

Mac AppStore and AppStore are literally filled with complete junk which has either not been updated in 3 years and crashes at every use cases or is just plain cheap trashware compiled and submitted by automated way and cloned again and again from template app in the first place.

Obtaining a refund for any purchase is furthermore a pain in the ass with no obvious or publicly available way without having to search the web so you just let it go instead of wasting your time in the process or just because the 24h grace period to do it just expired because you were in a hurry and didn't have time to scrap for a still relevant process on google.

Reporting scaming app with dark pattern is even worse with no direct access to Apple to do so and you end up giving up in the process because it's such a waste of time to report on just a kind of user forum with its own dark pattern or bugs which prevent you to do so and with no sign of Apple being in charge anyway.

AppStore and Mac AppStore are a disgrace which make it hard to justify their 30% ripoff on app price. In fact, they are just as happy you paid 8€/15€ for useless crap as they still have their share of the bargain in the process.

Time cook Apple is now just a rippoff of consumer money at every possible corner filled with dark pattern and thrown-away super cost-optimized flawed hardware working at the edge... And wait till notarization require you to pay an Apple tax and there is no way anymore to "sideload" an app without having to jailbreak your Mac, as it is the case with iOS.

I basically agree with the crux of your post. However:

> Apple doesn't make any money from the "web," they make it from their platforms which aren't HTML/JS/CSS

Apple makes their money from selling hardware, which is priced to provide a very healthy profit margin. Once upon a time, that seemed to be enough for them.

Now it's not, and Apple products are broadly worse as a result. The App Store should not have an entire tab dedicated to Apple Arcade, and the Music app should not be a giant ad for Apple's streaming subscription service.

"Software Sells Systems" used to be their motto and it's apt for how they treat the Mac and iOS. If the platforms don't have platform-specific apps, they become a commodity and lose those margins.

Software sells systems, so therefore they should reduce the amount of software available on their platforms by making it harder for developers to create?

The logical counterargument would be that good software sells system.

It's an argument I would be much more open to if Apple wasn't also pushing terrible Catalyst apps for the Mac.

Yes, curation is an important service that provides great value to end users.

If the software runs on the browser, you don’t need a Mac or an iPhone to get it.

Good software not exclusive software sells a system for me.

Apple’s decisions on this issue are entirely consistent with their business model as a hardware company. Allowing private APIs to be used liberally causes those to be de facto public APIs. When those APIs are very low level, they enable companies like Google to build frameworks that bypass Apple’s own.

In the long run, if nobody uses Apple’s APIs and everyone prefers cross platform ones, then they lose exclusive apps and Apple hardware becomes an overpriced commodity.

It’s the same business model as Nintendo, just with more expensive hardware and cheaper software. Really, none of the game console makers want all of their software to be cross platform. Exclusives are what sell consoles.

Or allowing undocumented, private APIs to be used liberally makes it harder for Apple to make important changes.

Certainly, Apple places a lower priority on backwards compatibility than, say, Microsoft, but they do give people warning when they’re going to change a public API.

> Apple doesn't make any money from the "web,"

Yep. Apple makes most money on $1k+ high end mobile devices, smart phones, tablets, watches, laptops. And now original contents, subscription services and financial services. Most Apple software are given out for FREE [1], macOS, iTunes, iWork, bundled Mail / News / Stock / Preview Safari apps, etc.

That reason alone it making Owen William's claim of "Apple’s control over its app ecosystem is a new type of monopoly" a moot point. Apple smart devices is less than 10% of the total market share.

And I agree with locking PWA and prefer native approach is a good thing for consumers - because if Apple didn't insist that, we'd be still running Adobe Flash on our smart phones these days.

End user cares more about user experiences, battery life and seamless integration working across all apps and services.

[1]: https://support.apple.com/downloads/

The Apple App store dwarfs the Google Play store as far as revenue is concerned. So at least as far as mobile is concerned I would say Apple is in a pretty monopolistic position as Developers are forced to follow what Apple dictates less they basically give up a majority of the market.

[1]: https://techcrunch.com/2018/07/16/apples-app-store-revenue-n...

Yes Apple App Store earns much more than Google Play Store does, that's not a news and every mobile developer know. But as long as Android exists, I would argue that Apple is not a monopoly[1] (perhaps some would argue duopoly?[2])

Here are a few reasons that will make it hard to convince Anti-trust judges that Apple is a monopoly:

- Apple doesn't control how much mobile apps would charge consumers. It simply provides a proprietary platform for you to reach out to 2 billion potential customers, for that they take 30% commission for distribution and access to their customer pool.

- Apple's platform is proprietary, they invest / build / maintain / distribute for you. You are not obligated to publish your mobile apps on it. You have the freedom to do it on your own (yes, on iDevices that means sideloading, jailbreaking, a web app etc.) or publish on competitor's platform (Android / Samsung / Huawei / Xiaomi / Kindle etc.) It's just so happened that Apple's devices are popular (2 billions of them) and you have much better upshot to make money if you charge customer for your app on App Store, but again, nobody force you to publish on Apple.

- There is no reason to believe that because Apple's devices are so popular (or in your words, dominant in terms of mobile app revenue) consumers are forced to pay higher price for mobile apps. Again, choices are there. There are tons of Android users out there, in fact, more than 3x of Android devices are there on the market.[3]

Lastly, have you wonder why Apple earns double what Google makes in being mobile app platform? If you want a premium product, a more unified user experience, focus more on security (make money on hardware instead of harvesting personal data and sell it to advertisers), perhaps you could earn much more margins but selling much less units and still getting rich? That's exactly what Apple did. Granted, they got greedy by jacking up the price even more on iPhone X/XR, market responded negatively. So they corrected themselves a little bit (got rid off the lady who sell luxury goods rather than consumer electronics.) And they diversify.

[1]: https://www.investopedia.com/terms/m/monopoly.asp

[2]: https://www.investopedia.com/terms/d/duopoly.asp

[3]: https://www.macworld.co.uk/feature/iphone/iphone-vs-android-...

The precedent of the Microsoft IE anti-trust case basically refutes your core arguments. It's not about Apple being a literal monopoly, it's about Apple holding a dominate position from which they make abusive anti competitive and anti consumer decisions which are propagated to the rest of the market. App developers are going to look at iOS market's dominate revenue stream and decided that if they are to maximize their potential profitability as per their likely fiduciary duty they will need to follow Apple's whims.

> it's about Apple holding a dominate position

Again, my core arguments is they are not in that position. Android marketshare is 3.3x of Apple's, if you want to reach out to more customer, you'd be releasing on android not ios, right?

This is a little ambiguous. How is “revenue” defined? Is it only purchases made directly by users or does it also include ad revenue? If former, then the comparison is useless because vast majority of users on android are using ad-funded apps where revenue flows from advertisers to the ad platform (Google etc). Devs could be using third party ad platforms too and it would be nigh impossible to estimate this revenue.

> As far as not giving a shit about Safari's ability to do WebRTC and PWAs properly

What's funny here is that many of Google's web initiatives such as PWA and AMP are at least partially constructed to increase Google's dominance and selling of ads. It's hard to fault any company that pushes against newer web standards and "progress" since it is so slanted in their competitors favor.

If you're a Google employee working on some such project you can probably convince me that the majority of the reasoning for PWA/AMP/etc are good, and assessed in its totality it is probably for the greater good, but you'll never convince me the mangers/directors/executives at the budgeting level of these projects are too dumb to understand and latter extract immense value at the expense of users as a final result.

All this stuff is too reminiscent of Facebook's Free basics project masquerading as Democratizing Internet "progress" with cool new features no user actually asked for.

I don't think they are even hiding their motivation. It's basically why Chrome exists, as well: Google needs the open web to stay competitive with native apps, because they only earn money on the web.

There isn't really anything nefarious about that, and at the moment it has the benefit of aligning Google's incentives neatly with users'.

AMP is about moving a huge portion of web hosting from other hosts to Google.com, while trying to hide that fact from users. Look at the antics Chrome does to hide the actual URL and the originally hosting site.

By that logic, Cloudflare is doing the same thing then, and on a larger scale.

You're lumping in PWAs with AMP and I'm confused why, they are apples and oranges.

PWAs are an outgrowth of web best practices and new consortium-ratified technologies. AMP is for Google search on mobile (and a couple other places.) To pull some examples from your comment:

> What's funny here is that many of Google's web initiatives such as PWA and AMP are at least partially constructed to increase Google's dominance and selling of ads. It's hard to fault any company that pushes against newer web standards and "progress" since it is so slanted in their competitors favor.

1. PWAs are not a Google initiative. AMP is.

2. Migrating to a PWA doesn't advantage Google vs. its competitors, either in search or the browser world. AMP on the other hand is specifically designed to get sites that adopt it better placement in mobile search.

3. Neither PWAs nor AMP are web standards. PWAs are a set of standards adopted by browser vendors (not just Google.) Vendors implement parts in different orders from other vendors (see the various Apple examples in OP.) AMP is not a web standard -- it is an open-source project governed by Google.

Please do not conflate PWAs and AMP.

GateKeeper is becoming onerous for Mac developers who maintain free applications, who don't want to pay a yearly fee to Apple. Telling users a program is damaged because this fee is not paid and moving it into the trash is now the default.

This is a free prefpane that can hide the cursor anywhere via hotkey or idle timer. It's fairly popular. I've written and maintained it since 2007. Try running it in Catalina. http://doomlaser.com/cursorcerer

I thought all you needed for the macOS app notarizing was a free AppleID and free developer account?

You don’t have to pay the fee to have signed apps.

Thank you. I was unaware of this and have updated the PrefPane and its invisible daemon as a result.

Apple is doing a poor job of advertising that you can get your app signed for free. Most developers and hardly anyone not involved in the Apple ecosystem no that.

Hmm, my understanding now is that I've got development certificates, and those certificates are valid, in conjunction with a provisioning profile for my specific machine. They are not valid distribution certificates, and I must buy into the developer program to be able to generate distribution certificates. So it is 100/yr after all, even if I want to distribute my free software outside of the Mac App Store. Am I missing something?

Random note (fully aware this isn't your main point): Electron for background/system tray is actually not too bad. It was about 12MB for a minimal tray app last I checked. At this stage it's just Node.js with some system API hooks, not chromium. It's only when a window launches that you get the chromium bloat to 80MB+.

If the current version of safari on iOS and iPadOS is the best mobile browser available then the mobile browser landscape must be raging crap. On my iPhone XR and iPad mini 4, it has numerous rendering issues and frequently requires being terminate by the task manager and restarted in order to load and display pages properly.

What kind of rendering issues?

Blank screens. The browser knows they layout of the page as the scroll bar indicator still functions, it’s just a white screen. Killing the browser and restarting will make the page load.

It sometimes loses its idea of where the top of the page is and all page elements are rendered normally, just a few hundred pixels above where they should be and no amount of dragging of the screen will get the top of the page visible.

On old reddit trying to touch a link sometimes results in text way up the page being rerendered with a different kerning, or font size, resulting in different line wrapping and making a bunch of page elements move and you get the wrong link.

I've seen this bug too - also on an XR

It's not just electron it's the fact that a $30 prepaid Android phone with chrome can be more web capable than a $1200 iPhone

> I don't really see that as Apple trying to kill web technology as much as them just not profiting off it. Apple doesn't make any money from the "web," they make it from their platforms which aren't HTML/JS/CSS.

While true, this was also the reasoning behind Microsoft's treatment of Internet Explorer which caused web tech to get stuck for a decade. I think we were all glad those times were over.

Its not a good thing. Like electron or not, apple needs to have very good reasons for blocking libraries.

I’ve made electron apps with electron that are 30mb on disk, and 90mb in memory, so it’s possible.

Safari is the worst mobile browser. It makes my life difficult every single day.

I'm assuming you're a web developer? I feel like users may have a different opinion.

Reply on news.ycombinator.com