Apple has made it difficult to use web-based technology on its platforms(onezero.medium.com)
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!?!"
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 )
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.
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.
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.
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.
The largest ash pile does get addressed eventually.
> The App Store Developer guidelines state that “going to the press won’t get you anywhere”
Where does it state this?
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.
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.
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 ?
They are now because they both use those APIs. You can read about the impact of this specific one here:
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.
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.
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
Firefox does not use CALayerHost. It uses the public IOSurface and CALayer.contents APIs.
Are those mentioned in the Mozilla post?
“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...
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.
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
> 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...
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.
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...
They'll just stop distributing versions through the Mac App store and the Mac App store will become even more irrelevant.
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...
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.
Electron doesn’t run on iPhone?
it does with cordova
Nope, Electron is a platform that Cordova runs on.
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.
Or perhaps fork Electron to provide a version which uses Safari or even WPE . I’m using WPE in an embedded device since it has better memory and GPU usage than chromium.
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.
+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.
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.
> 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.
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.
Are you sure? I have Chrome on my iPad.
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.
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.
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.
Right, but that comes out of the exact same code with some minor feature flags.
Besides technical limitations: the iOS App Store rules are clear: it is simply not permitted.
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.
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.
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 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.
It does. Type into the address bar, scroll to the bottom of results.
That is a chrome skin over safari
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.
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.
"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.
If the software runs on the browser, you don’t need a Mac or an iPhone to get it.
Yes, curation is an important service that provides great value to end users.
Good software not exclusive software sells a system for me.
> 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 , 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.
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.
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.
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 (perhaps some would argue duopoly?)
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.
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.
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?
> 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.
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.
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.
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.
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
> 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.
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
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.
I don't understand these articles that are coming out recently, and I don't want to seem like I'm attacking the people who use these tools...
But, its starting to feel like the people who want to use tools that allow them to build apps and programs that are cross-platform (NodeJS, Electronc, etc) are trying to use their weight as "the most popular programming language" to get platforms to conform to whatever they want.
Why should Chromium be allowed to use private APIs that native developers already knew "should NOT be allowed" especially those coming from iOS where its known using those would simply have your app rejected.
I don't have as much of an issue with Electron apps as most people do, but at some point you have to realize the short comings of cross-platform dev tools and work around them instead of trying to force everyone to just accept them.
> Why should Chromium be allowed to use private APIs that native developers already knew "should NOT be allowed" especially those coming from iOS where its known using those would simply have your app rejected.
Why should apple apps like Safari be allowed to use private APIs if they're not allowed?
This is blatantly non-competitive.
Also, they sit on these APIs for YEARS with no alternative.
I think every single platform is struggling with this. Even Electron or Chromium itself. They all have internal or private APIs or things that are not ready for prime time or just plain internal details.
Opening up private APIs is a commitment that you will support those. Which is no light decision.
Personally I think it is fine for any platform to have these.
But I do wish that the App Store rules around them were more permissive.
From Apples perspective: look at all the shit they are getting for dropping 64-bit support. This was known for a decade and they still are pictured as the bad guys who don’t support developers. A decade!
So you can imagine what happens when apps relying on private APIs suddenly break.
To be fair, Apple struggles with maintaining their existing APIs. Who cares about the private ones, they probably break or change just as unexpectedly as the public ones.
False equivalency. Changing private APIs without warning is not the same as actively breaking clients.
You know all the talk about Google or Facebook or Comcast both owning the platform and competing on the content layer with self-dealing is anti-competitive monopolistic behavior? Same goes for Microsoft Windows in the 1990s (actually litigated these very issues) and Apple today.
False equivalency. Changing private APIs without warning is not the same as actively breaking clients.
This distinction does not matter in the public sphere. When Apple releases an update — any update — that breaks a popular app, they are blamed for it. By putting their foot down, Apple is putting the onus back on developers to play by their rules.
This situation is essentially the normalization of deviance . If you do not enforce a rule, that rule becomes invalid and unenforceable. Apple does not want to lose control of their platform. If they give away all of their private, low level APIs, then cross platform frameworks like Electron will render their platform a commodity.
Do you mean 32 bit support instead?
Safari doesn't use private APIs. WebKit does.
And WebKit is a fundamental OSX library used for many purposes.
Also every "browser" on iOS has to be based on their webkit. So there is only a single browser implementation. And worse even, they purposely prevent royalty-free (WP9, AV1) codec support (they receive money from HEVC licensing fees), among other things. I remember days where they didn't even support file uploads.
Safari totally uses private APIs, just not for web rendering.
Yeah sure technically correct. But both ship with macOS and both are built by the same trillion dollar company who owns the whole ecosystem.
Electron could in theory use WebKit as well, and the main reason it doesn't is because Google decided to fork WebKit.
I don’t think it actually can because WebKit on macOS has been replaced by WKWebView which has a severely limited API surface that without doubt is way too shallow for Electron.
Because you don’t pay Apple to perform the necessary engineering investment to expose SPI as API. And the people who do pay Apple don’t care about this.
Where is the price sheet for the SPIs Electron is using?
Because they are not a monopoly so those laws don't apply to them.
This has never been a good argument if you look at what happens inside an ecosystem owned by a trillion dollar business.
So in that case the Amazon Fire tablet is a “monopoly” since it’s owned by a 1 trillion dollar company....
You do not have to be a monopoly to be in violation of anti-competitive business practice regulations.
> use their weight as "the most popular programming language" to get platforms to conform to whatever they want
I'd rather have an open committee tell a big corp what they have to do than the other way around.
The idea that all of the web is designed by an open committee is laughable. How much of the web is simply controlled now by Google doing whatever is wants in Chrome?
I was thinking about tc39 and the open js foundation.
Cross-platform apps isn't really the point though. It's about openness. Native Android, for example, is Java. Java tools are plentiful and open source. Android dev tools work on Macs, Windows, Linux. Google also invests heavily in Chrome allowing for robust apps that don't require an app install at all.
Compare that to Apple who rule the App Store with an iron fist. The don't allow native Chrome at all requiring instead that Google deploy a reskinned Safari. You can't deploy an app to a phone that you own unless you also own a Mac workstation running OS X and pay Apple $100/year for the privilege of using the very expensive hardware you bought from them. They built Swift, they built Xcode. It's total vertical integration and it's all managed at the pleasure of their bottom line.
> and it’s all managed at the pleasure of their bottom line.
As if Android’s come-one come-all is done out of benevolence. Google doesn’t have a heart, it had a bottom line too, and supporting those tools makes dollars come its way.
Google HAD an opportunity to ensure that one browser engine ruled the web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing. It propped up competitors. Google would rather have a competitive—-read, monetary—-advantage than ensure web technology is widely available for all to use.
For example, when Google refused to share the multi-process mode that differentiated Chrome from other browsers, it was a compelling enough security feature that Apple/WebKit reimplemented it independently so that everyone using WebKit could have it.
Google proceeded to cry crocodile tears, and then promptly forked the WebKit codebase into Blink. They claimed it was necessary to avoid having to carry around two multi-process models, but it was a A PROBLEM OF THEIR OWN MAKING.
So don’t imply Apple is profiteering, as if other companies are trying to give you hugs. Everybody’s finding cash in the ways that play to their strengths.
If Google was really interested in pushing the web forward, they’d swallow their pride, take the bottom line hit, and merge Blink back into WebKit.
> Google HAD an opportunity to ensure that one browser engine ruled the web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing.
Apple had the same choice when it forked KHTML to produce Webkit.
KHTML wasn’t anywhere near the same position as WebKit when Apple forked it. At the time, KHTML was niche beyond its use in KDE.
When Google forked WebKit, Safari and Chrome combined were something like 40% of the market.
Chrome was clearly the leader. Apple should have moved to their fork then if anything.
> but they chose to fork WebKit into Blink, in part _because_ they didn’t want to share the work they were doing
I believe that statement is false. As I understand it, from @tomalsky, Google simply had a different (superior) design for making WebKit multi-process, and Apple did NOT want to take those changes upstream into WebKit. So if Google wanted to use the better design, they had to fork.
According to this link:
Large parts of Chrome’s multi-process model were specific to Chrome, and not part into WebKit. Apple built “WebKit 2”, which integrated into WebKit at a higher level and allowed anyone using WebKit to get multi-process as a native part of the code base.
Three years later, Google forked Blink. According to this link:
“Specifically, [Google Engineering VP Alex] Komoroske noted, Chromium’s multi-process architecture is very different from the rest of WebKit (Chromium is the open-source project behind Chrome and Chrome OS). Having to integrate Google’s way of doing things with WebKit and what the rest of the WebKit partners were doing was “slowing everybody down,” Komoroske said.”
So, basically, Google built a version which was partially proprietary; Apple came in and built a completely open source version; and rather than standardize on a single code base, Google bailed, claiming it was too difficult to continue supporting two different multi-process models.
In the end, rather than collaborate, Google chose to keep their product proprietary and create a forked code base instead of doing the right, but admittedly difficult, thing and adopting the true open source option.
Google shipped their multi-process implementation years before Apple’s huge re-architecture of WebKit (which many forget now but lead to incredibly buggy behavior for years too).
They were able to ship earlier, and arguably at all, precisely because they just made separate processes that each had WebKit in them instead of doing a major change inside of WebKit. Had they tried to do the latter, the fork would have just happened sooner since everyone would have screamed that they were trying to completely change WebKit as complete newcomers: don’t forget, this was the major feature they shipped Chrome with. I’m personally happy that they set the standard that everyone then followed back in 2008 as opposed to having their initial foray into the browser space be some big RFC to change WebKit.
Having worked with it at the time, I was initially skeptical too. However, after working in the code, it definitely felt more natural to have the processes around WebKit instead of inside WebKit (as would be the case with most libraries). Ultimately, Apple’s approach took longer and lead to a big API-incompatible change (A “fork” level change arguably, but when it’s your own repo it’s not a fork, it’s just “2 point 0”). Not saying that’s bad, but Google's goal was to ship Chrome in 2008 and not have some huge incompatible diff with WebKit. Both made decisions appropriate to them, and in the end, gasp, we got two cool multi-process implementations, what a failure story for open source!
This whole storm about macOS. Which is an extremely open platform. You can develop apps with amazing tools by Apple or you can do C, C++, Ruby, Java, Electron you name it. You don’t even have to pay anyone money to build an app and share it.
There are a lot of misconceptions in this thread and claiming that macOS is not open is really the biggest IMO.
The OP is literally about Apple locking down a Mac API.
But only for App Store apps.
The platform is still wide open for non-App-Store development.
I don't get it. You can deploy apps when you pay both Google and Apple or you can work without a paid subscription if you are just a developer dabbling at home.
The vertical integration is true but that also has been the case with Microsoft products. Google basically doesn't have it's own desktop platform until pretty recently, of course their tools ran on other desktop platforms otherwise they wouldn't have any.
It's nice to install other browsers on Android though. Using Firefox wherever I can.
> You can't deploy an app to a phone that you own unless you also own a Mac workstation running OS X and pay Apple $100/year for the privilege of using the very expensive hardware you bought from them.
This hasn’t been true for a while now.
This strategy improves their bottom line because it enables products that users are more willing to spend money on.
If people want openness they can always buy Android. In fact most people do.
The whole point of different platforms is that they have different characteristics.
Openness is a characteristic of Android but not of Apple’s stores.
This means there will be limitations on what cross-platform software can do.
Is that correct? Is there a Mac App Store rule that says “thou shall use WebKit” ?
Do note that the point on macOS is kind of moot because it IS an open platform. Unlike iOS you do not have to use the App Store.
Yes. And it was crippled for a long while outside of Safari.
That's with regard to iOS, not the Mac App Store.
Alternative title “Developers wanting to ship an entire browser engine with their shovelware apps are salty about Mac App Store rules”.
1. The rules are the same for all apps.
2. Not Apple’s fault that Electron does not use the perfectly good browser engine shipping with macOS, but instead includes a separate browser with each app.
3. No one is forcing you to use the Mac App Store.
The private APIs rule is not new, Apple is just enforcing it harsher. Chromium has been breaking it at leisure, because Chrom(e|ium) itself does not ship via the MAS.
Yes, the people shipping Electron apps via the MAS have put themselves in a tough spot by skirting the rules. I can sympathise, but pretending that this is just Apple being mean and they couldn’t have seen this coming is downright disingenuous.
As for Safari, it would certainly be nice if they adopted new browser standards quicker, but being slow on the uptake is not the same as actively making things difficult.
> 3. No one is forcing you to use the Mac App Store.
If your users are on iOS, you are absolutely forced to use the app store. You simply cannot provide push notifications or any other services they require over web. They have intentionally crippled Safari so you HAVE to dance to the tune of the review board, have to give 30% of your profits. There's no alternative. Sideloading? No. Web? Enjoy being stuck in Gmail webview with no add to home screen functionality.
> If your users are on iOS
This discussion is about the Mac App Store. Electron apps have never been allowed on iOS (nor should they be, given the resource constraints of mobile devices - Electron apps would be murderous on battery life).
But there is an add to home screen functionality. I, for instance, have a Kindle Store “app”, which was added from safari.
If the application is important enough, a native version for iOS will be made.
Otherwise, mobile Safari (or any other browser) still exists.
Regardless of the reason, if Electron was using private APIs, and Apple doesn't allow Apps that use private APIs in the Mac App Store, I'm glad Electron isn't being given a free pass just because it's popular.
If this was iOS, where sideloading is basically impossible, I'd be much more sympathetic to the author's view. But we're talking about the Mac. Apple's quality control is the reason for users to choose the Mac App Store. Any users who don't want that control can easily go elsewhere.
Actually not. The appeal of the app store to users and developers alike, are access to already set-up Apple ID for auth and payment, and access to dependent APIs, like contacts
Non-AppStore Mac apps can use the contacts API, I'm not sure what you're referring to.
The ability to use an Apple ID for payment probably adds a bit of convenience for some people, but we have Apple Pay on the web, not to mention Stripe and Paypal. It really doesn't add all that much friction.
That incremental reduction in friction converts to substantial financial gains, being on the app store.
This is all a bunch of BS. Apple didn’t ban the apps because they were using “web technologies” or even because they wanted “everything to be in the Mac App Store” but because they use private APIs. He even admitted that.
Seeing that “thousands” of developers are depending on a framework that uses private APIs that will take a long time to fix, kind of proves Apple’s point. If Apple releases an update that changes the behavior of the private APIs in unexpected ways - which they have every technical right to do since it is not a vendor’s responsibility not to change the behavior of non published APIs without warning, all of those apps will break.
Right–Apple will make an update that breaks Chrome accidentally, and no one at Apple will notice that it happened.
So, are you saying that Apple should have to maintain any internal OS functions that Chrome uses as if they were stable API forever, because its Chrome?
Yes, many Apple critics just want it to be Microsoft.
So now we are back to having to do things like Microsoft where you have twenty different app specific hacks because developers wanted to use private methods.
There are hundreds of people at Apple that use Chrome as their browser of choice. Any obvious changes that break Chrome will be caught and dealt with quickly.
And that might be “caught” by letting Google know. If Apple was willing to piss Adobe off by cancelling Carbon64, and drop all support for 32 bit apps, do you think they are going to let Chrome stop them from making breaking changes to their OS?
A big piece of the WebKit 2020 conference was dedicated to web platform standards catchup in WebKit: https://trac.webkit.org/wiki/WebKitGoalsfor2020
That's pretty much the opposite of "trying to kill web tech".
The WebKit team just approaches things from a different angle than the Chrome team does. Google/Chrome jump on the new shiny features bandwagon right away to keep the favor of web devs where the WebKit team waits until they know they can implement new features in a way that doesn’t balloon resource consumption and prioritizes end users over developers.
There’s little need for most web apps to be riding up against the edge of standards anyway because 9 times out of 10 they’re bog standard CRUD apps that’ve been trivial to build since the heyday of Ruby on Rails.
The author makes some good points and IMO exaggerates the importance of others.
One nit to pick: Firefox 70's performance improvements didn't come from using private APIs. They used IOSurface and CALayer, both public API: https://developer.apple.com/documentation/iosurface https://developer.apple.com/documentation/quartzcore/calayer
You can read the details here:
The required bits for that work are not actually documented.
It is sad how inconsistent Apple's documentation has gotten. The lack of a list of types that can be used as CALayer contents is particularly bad given how useful it is in macOS applications. But these classes and properties are in the public SDKs and listed on Apple's API docs website, making them public API.
As an aside, I originally found out that they used IOSurface and CALayer from reading that post.
This is why I dislike the term 'Private API'; there's a big difference between using internal functions of a library, and using public functions which aren't properly documented.
In this case, there was a public method that took the public object Firefox needed, but wasn't documented as doing so.
How should I see this as anything but whining about producing lazy, resource intensive, non-UI-guideline adhering Electron apps?
Looking at you - Slack, Todoist, Monday.com. Your apps are very bad (and your native apps are Electron lies!)
Does anyone adhere to the guidelines? Apple doesn't, and they even have the ability to change them. They're guidelines, which if you look up the definition are not iron-clad rules.
A guideline is a rule, just a non-specific one. Sometimes it's more a suggestion, sometimes it is iron-clad. For example, HIPAA Privacy Guidelines will still land you into serious legal trouble if broken.
The fact that Apple are rejecting apps that break the guidelines (even if not consistently) is proof enough that guidelines can be iron-clad rules in certain cases. It depends entirely on the context and the authority setting them.
I think it's great that Apple chose not to pick favourites and treat the Electron the same as any other application platform. While the release of the latest version of macOS was rushed for many developers and came with some bugs, private APIs should not be used regardless. Ask the Electron people to fix this problem instead of complaining about how Apple is trying to bully web developers.
Or, if you want to build a decent application, make a native one, or make a website. Don't do this weird half-desktop, half-native just because it's easy for you; think about your customers instead.
I am thinking about my customers. The vast majority of them are on Windows, so Mac users are lucky to get anything nice at all.
VS Code is better than anything and it’s built with Electron. It’s not weird. It’s way, way better. And if you don’t think so, look at all the users it has who disagree with you.
As nice as VS Code is, it feels sluggish to me. I find it interesting how complacent we've become with slow software. I guess ease of development trumps performance in many cases.
How do you square this with Apple's new model of desktop Mac apps being repackaged iOS/iPad apps? Is that native or is it half-mobile half-native? What distinguishes that from Electron, in principle?
It sounds like what you want is for every application to be hand-written for the target platform using target-specific APIs, because code reuse and cross-platform tech are 'not native' and thus bad. QT and GTK? Not native. Java's UI toolkits? Not native. HTML? Not native. Perl, Ruby, Python? Well, they're not C or Obj-C and their standard libraries aren't libc so they're not native.
QT and GTK use native system code on most platforms to layout controls. This means the controls are mostly consistent with the rest of the system, even when Microsoft or Apple decides to add more functionality to existing components, for example. If I'm hovering over a button and a tooltip appears, I want it to show in my OS colour theme and font instead of whatever flavour of Helvetica the web designer who made the application found fashionable today. The developer may not like that I can set my system to be in ugly high-contrast mode when I'm tired and don't want all the OS fluff, but please be nice enough to just follow the system theme instead of being the special little app that thinks it knows better.
Electron uses an HTML renderer instead of the system compositor. This is the main difference between what I call native and what I don't.
If you write an application in Python using standard operating system controls (say, with Gnome/Cacao/Win32 bindings), I'd call it more native than an Electron app, even if the Electron system is more deeply integrated into the system API. I'd also call Java non-native as it decides to drop all system UI components and draw its own.
The repacked iOS apps being released on macOS are somewhere in the middle of the void between native and non-native in my opinion: while they use the OS compositing and controls, the layout is often not designed for the platform they run on. Perhaps "badly-designed native" is the best way to describe them.
It's Apple's call, isn't it? On what they allow and don't allow on their stores and platforms. It is the end-consumer's call, that they are happy with the product functionality and ecosystem that Apple enabled/allowed. Then the developer's call is to support a platform or not - a business decision, really.
I prefer not to support Apple, personally, but if it represents a 40%~60% uplift in sales, and after their rake, 25%~50% in earnings, at some point, I'm probably going to invest in that. If not, then, not.
I'm baffled that anyone thinks that any corporation "should" operate any particular way (as long as they are not breaking the law). Government, sure - everyone is probably entitled to that, but otherwise, why not just "walk away"?
> But Apple has a reason not to like this recycling of web technology. It wants its Mac App Store to be filled with apps that you can’t find anywhere else, not apps that are available on every platform.
And that's where I stopped reading. Apple doesn't give a toss if your app is cross platform. Frameworks that started back in the day like phonegap have matured into things like Electron, and the core problems are the same:
They run like crap. Animations are jerky, oftentimes the app simply "refreshes" when things go too far off the rails. This is a poor UX.
The apps are not able to adapt to newer devices without additional work. For MONTHS after the release of the X, looking at the Spotify app on it, the controls at the base of the screen were below the multitasking gesture indicator. If this app was built with AutoLayout as Apple encourages, this would've never been an issue.
I know, instantly, when an app I've downloaded is using web based cruft, I can catch it at a glance with the first tap, and the first slow interaction begrudgingly kicks off. Yep, it's a web-based one, and no, I will not be keeping it unless I have no choice to. Unless it's critical in some way, it's gone.
Apple outright banning Electron-powered crap is the best reason I've heard yet for buying my new iPhone.
Edit: I'm removing this, I'm embarrassed that I conflated mac OS electron and phonegap. Please stop upvoting :/
If Apple wants to have exclusive content on their platform, their not going to worry about small time developers who can only write iOS apps, they are going to fund the development themselves - see Apple Arcade.
They care much more about the big name developers like Adobe and Microsoft bringing their apps to iPads - even if they don’t see one dime of revenue from the subscriptions to encourage people to buy top of the line high margin iPad Pros with all of the accessories.
What are you talking about? Electron apps don't run on iOS.
Hey, you're totally right, I misread the article, conflated electron with phonegap (have never worked with electron and haven't touched iOS in years), thought apple was pushing out some cross platform mobile apps. Totally off-base comment I'm embarassed about and would love to remove.
I do maintain that the parent's poster takes joy in deliberately ignoring that apple obviously has incentives around building their ecosystem, but yeah, that was dumb.
To be fair, all the performance issues of Electron apps on Mac are the same issues leading to the same problems that PhoneGap apps face on iOS.
> Apple doesn't give a toss if your app is cross platform
They seem to have some incentive to make it harder for you to switch platform. By restricting developers from using some of the common tools to build cross platform they are able to build an ecosystem that's harder to leave.
Not only doesn’t Apple stop people from using cross platform tools, Microsoft has said that they work closely with Apple on Xamarin and we know that Apple works with the game engine makers to make sure they support Metal.
I want to very lightly push back here, not to say you're wrong, but just to say that this particular argument is not persuasive to me.
Of course Apple is working with game engine makers to support Metal, because otherwise those engines wouldn't export to the Mac. Gaming is still a Windows-centric activity, and it's mostly because of cross-platform game engines that indie designers have started to say, "yeah, I'll support Mac/Linux as well."
As an OS maker, when your choice is between having an app not come to your platform, and having it come because you contributed to a cross-platform framework, you opt for the cross-platform framework. But I'm not sure that proves anything. Literally any intelligently run company would push for compatibility with a more dominant platform.
Even a company like Oracle will push for compatibility with dominant competing product offerings; at least until Oracle's offering gets big enough that the compatibility is no longer in their best interest.
Even with games for mobile platforms iOS is dominant once you consider where all of the paying customers and high end hardware is. What hand developer if mobile games is going to target the relatively small number of high end Android phones? The ASP of S droid phones is something like $250. Most Android phones out there are low end.
No, the web isn't greater for the class of apps that Apple is targeting with the App Store. Or at least, it's not so much of a better platform that devs in this specific category are going to decide to ship a webapp instead of charging for a native app.
A lot of this comes down to monetization. There are more Android devices out there than iOS devices, and more apps on Android. So is Android a better platform? No, the distinction is that iOS users buy apps, and Android users don't.
So if you're not trying to build an ad-supported, microtransaction-fueled experience, iOS is just a better platform to release on.
Similarly, the web is a very powerful distribution network for online apps, but there aren't many good ways to make money except via advertising, Patreon, and SaaS. The apps being sold on the Mac App Store mostly don't fit into those categories.
That means as a developer, if you want to build something that just works, that you just charge money for, that you don't need to host on some kind of remote server, or manage accounts for -- the web becomes a much less attractive platform.
The question is, once you decide to look at native, do you first look at Windows or Mac? I think that depends on what kind of app you're trying to build and who your target market is. For desktop games, 9/10 times you target Windows (which is why Apple cares about cross-platform game engines). For an app like Robomongo, I dunno. Maybe the economics become more interesting -- I'd be curious to see the revenue breakdowns for an app like that.
Interestingly enough, the lack of (well-designed) PWA features are one of the big reasons why the web is still not particularly attractive for certain classes of apps. (You can't store information offline in an accessible format, your webapp breaks whenever the browser cache is cleared, you can't make arbitrary cross-domain requests). I'm not a conspiracy theorist, and I don't see strong evidence that Apple is trying to kill the web. But it's not necessarily a crazy idea in the abstract, because I don't see the web as a dominant player in that space, and I don't see any economic incentive for Apple to care about making the web into a dominant player.
They are restricting one very particular tool, not a set of tools or category of tools. I can write an iOS application using a veritable shit-ton of different toolchains. It sounds more like you're locked into a particular toolchain more than Apple has locked all the other toolchains out.
I don't personally develop anything using Electron. But given it's popularity as a way to build desktop apps, it seems reasonable that people are concerned even though they haven't also blocked QT or React
I think the concern should be on why the electron devs found it appropriate to use a private API, which is against App Store guidelines, risking/preparing rejection for any app using their framework.
The rejection of private keys used, by frameworks, is in no way new (2009 ) or misunderstood.
I find it very difficult to understand why Apple is getting any blame/concern for enforcing the violation of a very very old requirement.
> The reason this has become news recently is the creator of a framework used by several apps used a private API, so when developers who included his framework updated their apps, they were rejected
What’s old is new.
One of the biggest reasons Apple fans like myself remain Apple fans is precisely the ecosystem. I've no desire to leave it, and so your app allowing me to isn't a selling point.
Doesn't this confirm the parent's point? You like the ecosystem, so Apple makes sure it's the only one with such an ecosystem - part of which is making cross-platform apps more difficult.
Nothing Apple is doing prevents people from writing good native apps for any of the other platforms. They are just forcing developers to meet a miniscule quality cut off to be in the App Store.
This word is not present in the post you replied to. I said more difficult - and forbidding some cross-platform libraries certainly has that effect.
I guess you're a big fan of monopolies, huh?
The Apple "monopoly" is the biggest driver of progress in consumer computing.
Microsoft only sells adware. Google is spyware (and crapware). Linux tablets don't even exist.
Apple focuses on compatibility, user experience, performance, hardware, ease of use (yet still useful for power users). Sure it's been dropping the ball a bit in the past few years, but it's still lightyears ahead of any competitor.
It amazes me that Google's managed to maintain this sense of being the underdog with almost 80% share worldwide. Apple is far from a monopoly. Hilariously far, in fact.
Both Google and Apple have monopoly power.
Pure monopoly means single supplier, but companies having monopoly power where they have the ability to increasingly behave independently of competitive pressures is more common. https://en.wikipedia.org/wiki/Lerner_index
Apple should be forced to stop these anticompetitive practices.
When your differentiation is in your ecosystem how is this action independent of competitive pressure? Their customers are end users and the App Store is one (and how they've run it) of their best selling points.
Your line of thought only works if the developers are the customer- they are not in Apple's case.
It's not just my personal line of thought.
Your line of thought is the narrow "Chicago School" thinking Robert Bork in the US in the 90s where the sole focus is on the benefits to consumers and overall efficiency.
Just to clarify, you are saying Apple and Google are a co-monopoly because there is no third choice, or what? The link to Lerner index says it's pretty much impossible to actually calculate so I don't see where that's going.
An instance, but in no way covering the entire picture.
One of the reasons why Google Chrome enjoys its monopoly is because Apple does a terrible job with its browser Safari. Terrible. I mean it's a train-wreck! Since iOS 10 or probably little later they have done nothing but destroy how the web apis are supposed to function, abusing every single accessibility guideline into something that is at best a line of defense to promote their app store.
I hesitantly moved away from iPhone X to Android Pixel last month.
Or could it be that the reason Chrome “enjoys” a monopoly is because Apple doesn’t care about “winning” the browser war? Why should it? That was last decades battle. Not even MS cares about the browser enough anymore to invest in its own engine.
This is the difference between companies trying to sell products and companies trying to sell attention. Apple doesn't benefit at all from people using Safari, because Safari is not a surveillance tool. Therefore, "marketing" Safari is at best, an afterthought.
Chrome on the other hand... well, it's Google, one of the largest purveyors of advertising. If you don't think Chrome is watching you, I've got a bridge to sell you.
If they didn't care then we would have alternative rendering engine along with safari. They know that allowing competition is a threat to their business model.
Since the submission is about MacOS and Electron....
And are you commenting about just macos and electron? Anyway does not change my answer.
It should since MacOS allows alternate browser engines....
But there is no option in iOS. Why are Apple afraid of the competition?
So Apple “is afraid of competition” on an app it makes no money off, but allows the Kindle book store, Spotify, plenty of streaming services, Google Maps, two popular Office alternatives to iWork, has built in extensibility points to allow alternative storage providers to iCloud, alternate podcast providers, it basically built a feature into iOS just for alternative password managers, etc.
Maybe it’s telling the truth when it says there are security concerns?
Funny how you seem to be tortured by even the idea of Safari, while I (and millions of other people) use it every day and haven't even noticed these supposed atrocities.
…do you see the actual funny in your comment? lol
Chrome has 1.5% marketshare on iOS but 70% on desktop. So "Mobile Safari sucks" doesn't seem like a good theory.
Having a favorite competitor in an industry is not that same thing as being a big fan of monopolies. That doesn't make sense. Having a healthy competitive industry does not mean that every person uses products from multiple competitors.
Having a favorite competitor is fine. Having so much loyalty to that competitor, however, is cultish. What happens when you get tired of that competitor, and some other competitor is offering something better? Or your favorite becomes abusive and you want to move? By supporting that competitor so strongly, you've encouraged monopolistic behavior, and now you're going to suffer for it, because there won't be good competitors any more, or you'll have a very hard time freeing yourself and migrating to the competition.
That is about the worst faith interpretation of parent's comment I would come up with, even if I paid a consultant.
That's not what a monopoly is.
Once again HN posters fail to understand the definition of a monopoly.
Not a monopoly, but a walled garden.
Walmart has an incentive to keep people from shopping at Target. Do they have to have to stock everything people are selling on their shelves?
To be locked into Apple’s software means buying Apple hardware.
Do they control all the PC sales?
An Electron app is a web site shipped with a browser. Last I checked both browsers and websites still work on Mac.
All the real invention of value is still open and useable.
One customized way of packaging it all is not.
This is whining about a business model being upended by a technical decision.
Apple has not locked their platform to open technologies. Just their privately owned & operated market place.
They also have incentive to make it easier for you to switch platform. People are more likely to adopt a platform in the first place if it lets them escape, e.g., Joel Spolsky said Excel 4 was the tipping point because it allowed users to transparently write Lotus files:
> The trouble is that most managers only think about strategy one step at a time, like chess players who refuse to think one move ahead. Most of them will say, “it’s important to let people convert into your product, but why should I waste my limited engineering budget letting people convert out?“
I see this every day. People are much less likely to adopt Apple-only services than, say, Facebook and Google services that they can use on all of their devices and with all of their friends.
Electron doesn’t target iPhone, and Spotify mobile does not use electron.
This article is about the Mac App Store.
> Apple outright banning Electron-powered crap is the best reason I've heard yet for buying my new iPhone.
The article is about the Mac App Store, not the iPhone App Store. Not suggesting Apple's motives is "a good thing" but lets be accurate before going off on one.
> Apple outright banning Electron-powered crap is the best reason I've heard yet for buying my new iPhone.
Why not let the consumer decide of they want the app on the phone they bought vs letting Apple decide?
Personally: Part of what I buy from Apple — the “job” I “hire” them to do — is curation.
> Apple doesn't give a toss if your app is cross platform.
Maybe but they sure as hell don't make it easy for cross-platform software to target their platforms. As far as I'm concerned, the only feasible way to target Apple platforms at this point is to:
1. Buy a Mac so you can officially run macOS and Xcode.
2. Spend $99 every year for an Apple developer license.
3. Spend the time to learn Swift, a language which despite being touted by Apple fanboys as being cross-platform is basically useless unless you're targeting the official Apple APIs.
4. Learn and stay up-to-date with Apple's ever-changing APIs (just wait until Cocoa and Cocoa Touch are completely deprecated in favor of some other API that is only accessible via SwiftUI... calling it now)
5. Keep up with Apple's ever-changing policies around what and what is not acceptable within their walled garden.
6. Give 30% of your profits to Apple.
Why are you so angry, to the extent of blurring the truth, about something which apparently has zero impact on you?
I think listing “need to learn to program” as a negative prerequisite of “want to build apps” is somewhat disingenuous.
> Why are you so angry
I'm not angry although I am somewhat frustrated with some of the fragmentation that exists in software, especially when so many on Hacker News are quick to dismiss projects that try to bridge that gap. I understand why Electron is hated but why isn't there a better alternative? How many attempts have there been at providing a good cross-platform UI toolkit that can build applications which look and feel "right" on the platforms they target? Gtk+, Qt, WxWidgets, etc. all suffer the same fate over time and a lot of it has to do with growing technical debt as a result of endless domain-specific iteration. New UX patterns to account for, more OS-specific APIs to learn, etc.
Compare Apple's strategy to that of Microsoft. macOS Catalina has this new feature called Catalyst which lets you run apps written for iOS on macOS. Very cool although you'll have to write your app in Xcode which only runs on a Mac and that app you wrote won't run on any other platform. Meanwhile, Microsoft maintains a free IDE that works on all of the major operating systems (Visual Studio Code), they let you easily set up a Linux environment in Windows using WSL, they're focusing on languages like TypeScript etc. With how profitable Azure is for the company, it makes sense the company is not interested in locking you into a Windows-only world. In the same way, I'm not surprised that Apple development is so specific to the Apple ecosystem.
> I think listing “need to learn to program” as a negative prerequisite of “want to build apps” is somewhat disingenuous.
If you think "need to learn to program" and "need to learn Swift, Apple-only APIs, etc." are equivalent, then you're the disingenuous one.
That is all just nonsense.
You don't have to use Swift as there are plenty of alternatives many of which run on Windows or Linux. So in theory you could do all your development on a non-OSX platform and then just use one of the Mac hosting providers for CI/CD.
And you don't have to give Apple 30%. Just notarise your app and add a link from your website.
> You don't have to use Swift as there are plenty of alternatives many of which run on Windows or Linux.
I'd use an application written in Java or one built with a cross-platform GUI toolkit like Gtk+ or Qt in Windows or Linux. I wouldn't in macOS and most users won't either. They're ugly in macOS. They stick out like a sore thumb. It's not that it's impossible for a cross-platform approach to produce an application that is nice to use in macOS, it's that there is technical debt in the libraries and frameworks that attempt cross-platform and usually it's a failure to keep up with the constant changes in the Apple ecosystem. A few years ago Apple removed support for OpenGL so now if you want to write 3D applications you have to use Metal. Thankfully, there's MoltenVK so if you want to target multiple platforms you can use Vulkan but how do you know that approach is sustainable? MoltenVK only uses public APIs so its safe to use for the time being. That said, any number of decisions Apple makes moving forward could potentially rule it out as a viable option.
> And you don't have to give Apple 30%. Just notarise your app and add a link from your website.
That's a fair point although maybe not the best UX for all purposes.
Apple really doesn't care about those $100/year or even all the hardware all developers in the world together buy. So you have to wonder why they require people to jump through these hoops, and a wish to focus on native, high-quality software does seem to be the best explanation I can come up with.
> Apple doesn't give a toss if your app is cross platform.
This is an outstandingly silly statement. If I followed your example, that's where I would have stopped reading your comment.
Apple's entire business is built on trying to capture users, keeping them using all and only their computing products. Some aspects of this overall strategy (making beautiful devices that people want) are positive for customers. One of the less positive parts, discouraging cross platform software, is an essential part of the overall strategy.
> discouraging cross platform software
That is a patently ridiculous statement.
Apple would obviously prefer you write apps for its platform only, but as long as you don’t _defect_ to another platform, why would Apple care whether an app you use on its platforms is written in one language or another? If an app you want to use is available for its OS, it makes you that much more likely to start/continue using Apple products.
> why would Apple care whether an app you use on its platforms is written in one language or another?
Because they want to hold people exclusively on their platform for upgrade & services revenue. They obviously have no scruples about the means. The more difficult it is either to use devices on various platforms, or to migrate away from Apple entirely, the better for Apple.
> Because they want to hold people exclusively on their platform for > upgrade & services revenue.
Yes, so would any vendor, if there's more money to be made by keeping people in your sphere. I mean, there's a reason that movie theaters and restaurants don't let you bring food from the outside. They want to be the exclusive provider of food and beverages in order to increase their revenue, so they can charge you $5 for a Diet Coke that might cost you $2 at the corner store.
But for Apple, it's a calculus: does Apple make more money at Thing X by keeping it open, or by keeping it closed and potentially reducing their customer pool? Where there's more money to be made in openness, in a way that aligns with Apple's other priorities, they'll be open. If there's more money to be made in keeping it closed, they'll keep it closed.
For example, I'm so glad you mentioned services revenue. Apple TV, at least the software portion, is now shipped _from_the_factory_ on smart TVs made by Samsung, LG, Sony, Vizio, and a handful of other vendors, as well as Roku and Amazon Fire TV. Apple Music has an Android app on the Google Play store that is kept up to date and integrates nicely into the Android OS, and actually holds a 3.7/5 rating (surprising considering how many Android fans review-bombed it in the early days simply for being an Apple app).
If Apple really wanted to "hold people exclusively" to their platform, none of those things would be available outside Apple products. There's more money to be made on services outside Apple hardware than there is in keeping those things exclusive to it.
> The more difficult it is either to use devices on various platforms, or > to migrate away from Apple entirely, the better for Apple.
The better for any vendor if it's harder to migrate from that vendor to a competitor. That's what smart competitors DO, is make it difficult to leave. Your argument is that Apple should make it painless to switch away from Apple--so let me ask you, what _benefit_ does it incur to Apple to make it easier to switch away from Apple products or services?
If your entire argument is that Apple should do whatever it takes to make customers lives easier, then my response is, that's not a bad perspective to have, but it's unrealistic unless all aspects of the industry adopt the same attitude. If Apple makes it easy to leave, and the Googles, Amazons, and Microsofts of the world continue to make it easy to capture customers and difficult for them to leave, then there's zero benefit to Apple for being the pioneer in this new world order.
> If Apple really wanted to "hold people exclusively" to their platform, none of those things would be available outside Apple products.
Rubbish. They can easily do both, and there's an existence proof that they do.
> Your argument is that Apple should ..
I didn't argue that Apple 'should' do anything. I just described what they do, in the real physical world, actually do.
Who cares if an app has a lousy UX? Doesn't the market filter these out?
How is it any of Apples concern if I want to make the ugliest most useless app ever? If people love it, and everyone wants it, isn't that enough reason to sell it?
Letting anyone sell anything they want is how you get the Play Store, a monument to bad experiences. Pages upon pages of cloneware apps, asset-flip games, on and on and on, all of which of course are drowned in advertisements. In my last year of owning an Android before I got my first iPhone, the 6 Plus, I didn't even open the Play Store anymore. It was awful.
That's not to say everything on the App Store is great, of course, but it's a hell of a lot better.
Edit: Upon further thought I should really go further with this: The quality of the App Store is part of the marketing of iDevices. This is why Apple's app review process also looks for things like apps that crash too much, apps that run slowly, apps that are burning through system resources, on and on. It's why you generally won't have an app on their store that will, for example, destroy your battery, or games that show you ads every 15 seconds.
I know the attitude on HN generally prefers freedom over curation, and in many ways I'd agree, but when it comes to the walled garden Apple provides, sorry friends, I just like being here.
Edit's edit: In fact, I can even take this one step further: this is, I believe, part of the reason iOS users are far more likely to be willing to PAY for their apps: because Apple checks them at the door. And sure, quality isn't guaranteed per say, but at least you know someone is trying at it. You can be assured that this app isn't going to damage your device somehow, and you can be reasonably sure that it's going to do what it says on the tin, at least competently. And if not, Apple has your back with refunds, too.
The apps in app store is as bad as play store. There are clones as well. A competition to app store would cause serious revenue fall for apple thats why they want to control.
Apple can do what they want with their store, everyone agrees.
But does everyone agree with Apple's decisions on what is bad UX?
I cant think of a tenet I disagree with.
Do you think a purely subjective rule is the right way to determine if software should be allowed to be sold or not?
Look around on the Google Play store and you'll see that no, the market does not filter out crap. Crap is most of what you can find on Google's store. Just try to find a proper mail client or file manager, there is so much junk in there.
I don't have this problem because I'm not addicted to apps like you. "My Files" that came with the S10 is great for file management and Outlook works fine for my mail.
There isn't a single app on my phone that's junk.
What on earth are you talking about? We were comparing quality of apps in the App Store versus Google play store, that was the whole premise of the discussion. How does that make me an addict?
I also didn’t say there weren’t any proper apps in the google play store. I said there is lots of crap in there. I also didn’t say that stock apps of all vendors are crap. Obviously file management and email were examples. You can apply my statement about general quality of android apps to practically any app category. There are so many half baked, proof of concept, abandoned hobby project, malicious data hoarding apps on the google store that you waste lots of time looking for something that can do something that should have been solved already. It is hard to filter through the crap.
This is not a useful response. If you're going to make an assertion, don't run behind false pretences and logical fallacies to defend yourself from a cogent argument.
Your phone didn't come with carrier-bundled bloatware?
One app form vodafone which is for account management purposes. That is all.
"There isn't a single app on my phone that's junk. "
I use that app to pay my bill and enabled roaming charges when I travel. It has two very clear use cases.
Being a consumer, you would be part of helping the market filter these out. I don’t want to help my grocer “filter out” spoiled foods too often. I’ll go to a grocer that filters a bit before stocking.
Who is the arbiter of bad UX? Everyone can agree on rotten fruit, what is a rotten user interface?
Everything I've learned about UX is that a spreadsheet will solve tons of problems that it's the worst interface for. Yet that is what people often want.
If you want to use web based technology, embed WebKit instead of Chromium. I'd think there would be huge memory savings, since the OS only has to load one dynamic library for N web-wrapper apps, as opposed to one Chromium instance per app.
The most likely reason developers don't do this is that it isn't really about targeting web-based technology. It's about targeting Chrome.
Kinda weird how many people seem to think that it is good when Apple boycotts modern web technologies.
I mean, we all know that electron has its downsides (large downloads, old versions, etc.). But PWAs are the technology to overcome those problems and instead of supporting PWAs, Apple doesn't seem to care to bring crucial features like web push notifications to PWAs on iOS (it is not about pushing ads message, but about being able to efficiently send a message to a phone while the app is in the background, e.g. for chats).
So I can definitely follow the argument of the author.
Kinda weird how many people seem to think that Electron is a web technology.
Fucking everything is a web technology; and if it isn't, then we are obligated to make it one so we can gain leverage from the huge base of developers trained in web technology but nothing else. That's the point of Electron.
The author's main points are that:
1. Apple has started rejecting Electron apps from their app store.
2. Apple's "Hotel Cupertino" - you can bring any browser you want, but you can never leave Safari. (That is, the iOS versions of Chrome, Edge, Firefox are merely glorified Safari skins; Apple doesn't allow independent browsers on their platform.)
3. Apple ignores, or is slowest to implement, open web standards like RTC, progressive web apps, push, and more.
As someone involved in the progressive web app (PWA) standards space, I unfortunately must concur with the author's observations: Apple is soft-suppressing web standards, especially in the PWA space.
> That is, the iOS versions of Chrome, Edge, Firefox are simply Safari skins; Apple doesn't allow independent browser on their platform.
I don't like Apple's policy, but my understanding is that's not exactly right. It's the web browser engine that must be WebKit, like Safari. But browsers can have some other differences beyond the "skin" like networking code, and my understanding is at least Chrome does.
The point remains: one cannot bring a fullly independent browser on iOS. Microsoft was successfully sued for much less in the late '90s.
It's a business practice that reduces user choice and freedom, and stifles innovation and competition.
Yes. Why haven't they been fined for anti-competetive practices already? How can they still force developers to use their only webkit implementation? Is it because people think there are more browsers on iOS, forgetting that actual layouting, rendering and scripting, most of the web browser work is done in the single Apple's implementation? Also online video streaming providers are forced to encode in HEVC, because Apple refuses to support royalty-free VP9 and AV1, despite the fact that even HW implementation of VP9 is available for some time already in many SoCs and Intels (and chips with AV1 are being produced now as well). Microsoft was fined a lot in the past, forced to ask people for app defaults (full-featured alternatives), but Apple seems to have some special treating... and people don't care. As long as Apple says it's "for their security" (which is not true), they believe it. It's sad.
No MS was sued for much more like forcing third party OEMs not to bundle Netscape and forcing them to pay for Windows for all of their PCs whether or not they shipped with Windows.
Mostly exists to protect iOS users from all the security issues that browsers always seem to have.
Not that Safari doesn't have security problems, but Apple trusts themselves a lot more than the other companies for security.
I would doubt that Safari is significantly more secure (from a "buffer overflow took over your phone" perspective) than what Chrome could be on iOS.
How do feel about ChromeOS? You can't really bring a fully independent browser there either - you have the Android APIs but they make for a pretty crappy desktop browser experience.
You can run Linux apps and Android apps on ChromeOS, but this is just whataboutism.
Does it make the device less susceptible to malware?
What’s good for google doesn’t mean it’s good for user. Google doesn’t own any operating system (that hs a market share) and they are doing everything to destroy ideas of operating systems
As someone getting into a PWA for an easy mobile app, any issues I might need to be aware of with iOS PWAs?
> Apple is soft-suppressing web standards, especially in the PWA space.
Yeah, yeah, when the PWA community screams “JUMP”, Apple is supposed to ask “How high?”.
Never mind that this is a tiny subset of the entire web cosmos.
I build web apps for a living, and I don’t use a single PWA on iPhone/iPad. I’m sure Apple has noticed that these kind of features are going mostly unused on their devices, and are prioritising accordingly.
Don’t get me wrong, I’d be happy to see Apple make PWA stuff more a priority, but I can’t really blame them for not prioritising it higher.
Electron was simply caught doing something it was not supposed to be doing.
As someone who has spent a lot of time on web and Apple.. this article reads a bit like a conspiracy theory. Apple has allowed a lot of web features on to their platforms and App Store's, like hot code push, PWA, etc.
Uhhh Apple is not banning electron. It is banning the use of private APIs.
The only reason Electron is in the news is because it uses some of those APIs.
Now you could argue that private APIs are a stupid idea. But turning this into a conspiracy theory that Apple is on a mission to kill non native apps is a bit far fetched in my opinion.
Isn’t it slightly more nuanced than that? Electron is being banned because it relies on Chromium—a Google-sponsored project—which uses macOS private APIs?
If Chromium developers care about this outcome, they’re incentivized to remove use of those APIs and potentially impact the performance of Chromium on Macs.
What's shocking about this post is there is no mention of what private API(s) are being used by Electron. The link to the Mozilla blog post has nothing to do with Electron.
Edit: Google to the rescue:
This notion that PWAs are a real kind of thing that the open web is excited about and not a hamfisted attempt by Google to force us into certain web development practices is, in my opinion, farcical.
“Technology” is such an optimistic statement... You mean slow memory hungry crap?
Alternative theory: electron apps are universally shitty.
I wouldn't say _all_, just most. With optimization, resource monitoring, disabling unused APIs, plenty of treeshaking and other such techniques, it's quite possible to do a near-native experience (think: performing like C#/Java).
However, whenever I see an Electron app in the wild, those optimizations don't seem to be done very often. Perhaps it's the fact that companies don't care about speed now that computing resources are cheap, or that companies are hiring web devs for desktop applications, but in the wild most applications sure do end up feeling like someone installed a buggy second copy of Chromium onto my machine.
Visual Studio Code is an example of an experience that feels like it might as well have been written in a language like C# or Java. With some extensions the lag quickly becomes noticable, but as far as text editing goes, it's a pretty nicely optimized tool. In my experience, typing in VS Code is slightly faster than typing in Jetbrains IDEA/etc., for example, which is based on the more desktop-oriented Java.
Of course it will never be as fast as Vim or Notepad++, but those tools are harder to extend, which can make the disadvantage of the slight input lag worth it for the extra functionality when debugging or running automated tests.
Electron can be a useful tool for writing maintainable, extendable, cross-platform desktop applications. It can also be a handicapped browser. While most companies choose to use it as the second option, this doesn't have to be the case.
TBF, Electron doesn’t sell itself on performance. It sells itself of minimizing redevelopment cost to support multiple platforms.
However, performance is not a “pit of success” feature with Electron, and Electron doesn’t exactly advertise that performance requires explicit effort, so it’s fair to put some (not all, but some) blame on Electron for implicitly encouraging the perception it is a “silver bullet” solution for cross-platform apps.
It's interesting. I like my windows-electron signal app a lot. But using e.g. windows-electron slack seems really silly for me. why have a bloated wrapper for what is exactly the same as the website version of slack?
One could argue “Electron developers” have abandoned open technologies (vanilla web browsers), for heavily customized to taste versions.
And expect us all to gift them the CPU, memory, storage overhead of their preferred distribution model.
> But Apple has a reason not to like this recycling of web technology.
Yeah: native apps consume fewer resources and generally provide a better user experience. This is like, Apple's whole schtick with iphones. The hardware is historically low spec compared to contemporaneous android, but the device performs better, and old devices perform better on new ios releases.
> It wants its Mac App Store to be filled with apps that you can’t find anywhere else, not apps that are available on every platform.
Sure, that's a take.
Thank god. An Electron app is essentially a kiosk-mode web browser, and offers (almost) no advantages over just running the application in your real browser... except you lose browser extensions and customizability and everything else that makes browsing the web bearable.
If you're going to publish an "app", do it properly (natively) or not at all.
Good. Web UI is terrible.
Looking back at the number of stupid mistakes, missteps, and general clumsiness which have come out of Apple's App Store review process, it's far more likely this is just another boneheaded gaff somewhere on Apple's review team.
This is quite clearly one of those cases where people are attributing malice where incompetence of one sort or another is almost certainly the cause.
Most likely either: —This should have been nipped in the bud years ago when they added the private APIs to electron. —They are taking a ham-fisted approach to cleaning up some App Store abuses. —They've updated the tools they use to review App Store submissions.
Or maybe a little of all of the above. The big problem is Apple is again stumbling around with little or no communications to the developer community, fucking up a lot of developer's lives. This isn't some conscious malicious scheme... just frustrating corporate blindness.
> with little or no communications to the developer community,
About the use of private APIs in App Store apps? The communication has been consistent and loud enough that most non-Apple developers are completely aware that using a private API will get your app rejected.
I agree with you that private APIs should be off limits, particularly to the author of a library which has broad use. But at this point, Apple's previous inactions sent the wrong message and by acting on this now with zero grace period a lot of developers are left in the lurch. Whether you want to point the finger at Electron or Apple doesn't matter, Apple has the opportunity to make developers lives easier here and instead they are just indifferent to it which is frustrating.
From reading the issue on GitHub, I see that there was a failure, then it started working, then two months later it started failing again.
I suspect there was a two month grace period. The problem would be that they gave that grace period to a developer (like Slack) rather than working with some Electron framework team.
I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March.
> I also suspect a reason the tools were revised to reject apps with use of these internal functions is that some of them are going away in March.
This is the thing, there are good reasons Apple should reserve certain libraries as private and not support them. The fact that Electron dipped into private libraries and didn't have a fallback plan for WHEN Apple clamped down on this is just poor planning. That said... a small amount of communications and/ or tolerance from Apple would go a long way towards developer good will here. Lots of small developers getting burned here.
This is a good take. In particular ObjC is highly dynamic and a simple `nm` isn't sufficient to catch all private API usage. The strategies for detecting private API usage are evolving.
FWIW, Electron directly links against the private APIs.
Just learn Swift and Apple frameworks if you are building an App or use a template if your actual product is content and your app is just a delivery medium.
Just because it's JS, it doesn't mean that it is web technology. It's simply a way to build apps using technologies that are traditionally used for the web, making it approachable for people who know JS so that they can build bloated apps.
Apple's toolchain is so much superior to anything JS-Frankenstein and the Swift itself is a pleasure to work with, probably easier to learn and manage than to try to adopt your JS skills to a mutant JS. Almost always results in better UX and I think it's O.K. to care for the users, something that apparently never crossed the minds of the WebTech people(through the years, all the frameworks were about making developers life’s easier, rarely anything was about the user ).
The comments here are missing the real issue - its the inconsistent application of the private API rule by the app store teams that is arguably the worst part of this. Apple have a terrible track record in consistent application of App Store rules. I'd argue there's enough evidence now to support a theory that some apps are considered just too important to reject.
When will they pull big Electron apps like Slack et al? I'm guessing never. It's often the little guys whose business gets stomped on by the unfair application of these rules.
As far as I can tell, they are not pulling any apps. They are simply rejecting updates to the apps already on the store.
I haven’t seen any indication that special consideration is being given to Slack or other big brands.
Objective C is magic and you and get around the static checker with using Ducks and NSClassFromString. This is how all mac and iOS devs have done this is the past and will continue doing this forever. Apple will never close the Duck hole, because it doesn't want to, but it will always slap devs on the wrist for using private APIs in a non-duck compliant manner.
Java is no better, and even with C there's nothing stopping you from finding code in your process and calling it by casting its address to a function pointer.
Quote: "Apple’s control over its app ecosystem is a new type of monopoly..."
Very poor choice of words, it's their walled garden, nobody's holding a gun to your head to go there, especially since Android's walled garden is growing bigger by the day while Apple's one is shrinking.
Here is a better choice of words: "-Let it shrink, I couldn't care less".
As a freelancer I always say to my clients they have a choice of whatever they like between big 4's (Win/Droid/iOS & MacOS/Linux) but in reality I do it quietly on Win and Droid 1st, then during the final stages I kinda forget about the other 2. If any of them is asking, I have other means to stop them going there. I don't like Apple and I don't like Linux. Apple for reasons including those in the article as well plus more, and Linux for their snobbish. Until both of them will act pro-customer and non-anti-developer I will be against them as well, and I am not the only one. There is a reason why Win is king in desktop (backward compatibility & pro-developer) and Droid is king in mobile (non-anti-developer, though lately Google is kinda of following in Apple's footsteps here). And I know I am not the only one with this mindset.
I wonder why apple expects that if I you have to write separate apps for iOS and android, people will choose to write an app only for iOS and not only for android, given that android's market share is so much higher. Maybe developers are more likely to own iOS devices?
Apple definitely doesn't have monopoly over anything. They are popular, but their market share doesn't put them in a monopoly category. And of course Apple doesn't like cross-platform Apps, especially PWAs. Because how else would they make money off of them. It is all about business.
Let's be real. Apple doesn't like low quality apps on its platform. Does that mean it rejects low budget open source apps that use shoddy frameworks like Electron? Yes.
Apple charges an arm and a leg for its hardware ($25 per GB of RAM, with vendor lock-in via solder, 400% markup over every retail price, and similar for SSD), so they don't want any software wasting that precious power and capacity.
Yes, it is bad for non-wealthy power users, but that's never been Apple's market.
Fortunately for us, on the hardware side, Apple has been making shoddier hardware (soldered components, broken keyboards, missing Esc key), while Dell and LG and others have been improving their premium lines.
On the OS side, Apple and Microsoft have been working hard to close the quality and power gap, with Microsoft shipping Linux on Windows and investing in Open Source, and Apple trying to turn their machines into iPads and Adobe boxes.
It's hard to dig through the clutter in the PC side, but if you are willing to research and to pay close to Apple prices, you can get great Windows+Linux machines from Syatem76, Dell XPS/Precision, LG Gram, Lenovo, and others.
The anti-Safari sentiment comes from a pro-Chrome world. But I honestly think you should stop using chrome as your main browser, and stop developing for chrome primarily also. Use Firefox or Safari, develop for Firefox & Safari, and then fix for Chrome afterwards.
For security-sensitive work, there really is nothing comparable to Chrome. It's light-years ahead of any other browser on the security front, sadly. It's why I haven't switched.
I'm always amused by people who use those clickbait titles originating from Daily Mail, just to make shit storm and for few minutes of fame. Something like this should be banned from HN and many other mediums, but sadly this will never happen... :(
As a native Apple Swift app developer, this doesn't bother me too much. I tend to like Apple for the same reasons that many people hate them.
That said, I spent a significant part of my career writing cross-platform SDKs, and am quite aware of the business case for hybrid apps. I think there are many places where they make a great deal of sense.
In fact, just a couple of days ago, I suggested that a developer replace a set of apps that I wrote in Swift, along with a powerful SDK, with apps written in Ionic, because I thought that the use case made sense for that.
I just like writing fairly restricted-domain, local apps that are optimized for the end-user, and that often interact with devices, so using hybrid apps doesn't really make sense for me (they are optimized for the developer; not the end-user).
How about a progressive web app? That's what I do for Apple apps.
Sure, it's just a web app but most apps need an internet connection anyway.
I know there are some drawbacks, but you can work around it.
Then it is not a Mac app.
Which is fine, but if I'm looking for an application in the app store (as opposed to looking for some service on the web), I want a Mac application, not a web app.
One hint: if I'm looking for a Mac app, there's a good chance one of my requirements is controlling the data the app generates.
What I would like to know is why I have to go through an f'ing CAPTCHA every bleeding time to read an f'ing medium article.
Oh, the irony of publishing this on Medium.
would a less misleading title read differently?
It seems apps have to honor the (battery preserving, e.g.) appstore rules, plain and simple.
That said, the fact that _some_ web-based technology apps don't does NOT imply the title of this post.
Apple keeps making it harder and harder for developers on mac. The amount of effort my teams have to put into the apple side of our cross platform apps is silly.
I wish this was more feasible with less collateral damage over a shorter time. The web is a trash fire of absolutely historic proportions, from the frameworks/APIs to the languages to the UI/UX. The world deserves better.
Alternative headline: “Apple makes the web safer by enforcing safety standards”
But that doesn’t get the clicks Owen and medium need
and as the article states - that argument is weak
I can speak to this problem as I develop an Electron app that targets MacOS, Windows, and Linux (as well as the web).
I'm just a humble independent software developer so I can't really target every platform 100% so having cross-platform code is really nice.
Unfortunately, every platform seems to want to screw you over somehow. I've written about this on our blog before:
Even CREATING the MacOS build for MAS is such a pain that I gave up. I tried going to the Microsoft Store but that also was a nightmare.
Every platform has hurdles and roadblocks designed to screw over developers and bring more money to Apple, Google, Microsoft, etc.
With Microsoft, for example, you HAVE to use their monetization platform. You can't use stripe.
With Google, they seem mostly just incompetent and not directly malicious.
The discussions on /r/androiddev are enough to scare you to NEVER build an Android app.
Have a business making 7 figures on the app store for the last 5 years? 10k revies? 5 stars? Not anymore. They just killed it and they won't tell you why.
Or someone files a trademark in a 3rd party jurisdiction and you lose your app entirely.
Then there are the big boys like Uber that just flat out ignore the rules because they know Apple won't remove them.
OR.. I could just bypass the app stores entirely right? Just distribute my app on my own site. Don't play these games.
However, now I've basically abandoned a massive source of users.
If you've never built an app and experienced how hard it is do to customer acquisition you're NOT going to appreciate how much of a challenge this issue is for ISVs.
Some apps simply would not exist without the app store distribution.
Getting featured by Apple could make or break a company. Just getting featured ONCE could mean the difference between your startup succeeding or failing.
... but they won't feature you if you're not in the app store. They also won't feature you unless you really do EVERYTHING they say including completely tailoring the app for their platform.
No updates for WhatsApp??
TL;DR Title is misleading hyperbole, it's talking about Apple not allowing Electron-based apps that access undocumented APIs into their App Store.
This has "fragile" written all over it.
Honest question: who actually uses the macOS App Store?
My anecdotal experience has been that the macOS App Store is a popular distribution platform with developers.
As a user, I don't use it because I don't want to give Apple more information about me, and I will regularly find Mac apps online that don't have a download/purchase link -- they just point to the app store. It's at least popular enough with devs that avoiding it as a user is a pain.
22,361 apps on the Mac App Store. And probably tens of millions of users worldwide.
Discovering Mac apps is quite a bit harder than Windows given the difference in market share. So the Mac App Store will be disproportionately popular.
You still can't use service workers in WKWebViews, right?
That'll be a feature. Service workers are web-based workarounds for what should be a native application...
You must be fun at parties
iOS is pretty bad. For a modern device that can do anything, it's awfully pegged to how Apple wants you to do things. It does not feel very liberating to use an iphone. It's too much of a commercial experience, not the World Wide Web.
I'd like to point out that Apple does not natively support MPEG DASH on iOS Safari, and I have always considered Apple to be the problem child of the Internet.
Please don't spam the app store with redundant Electron-hosted web applications. Just tell me the URL so I can load it in my (non-Google-compromised) web browser, or use the OS' native web frameworks so I don't have to waste hundreds of megabytes of disk space.
A great example is the beta of Apple Music - it pushes the state of the web forward by embracing Web Components, ES6, modules and more. It's probably one of the most modern websites out there at the moment. And Apple Music is serious business to Apple's whole ecosystem. If they were trying to kill the web, they would have just remade the old iTunes client.
That's interesting. I'm pretty much done developing for the Apple platform. If I need to create an app, it will be a web app. I'm sick of xcode, sick of swift, and sick of "professional" grade mac hardware. All this technology to make pretty UIs on top of API calls.
>But Apple has a reason not to like this recycling of web technology. It wants its Mac App Store to be filled with apps that you can’t find anywhere else, not apps that are available on every platform. With a recent policy change,
It's not a "recent policy change", it existed since the App Store was created.
>The Mac App Store has quietly started rejecting apps made with a popular tool called Electron that allows developers to base all of their apps on the web-based code. Some of the most popular apps in the App Store, like Slack, Spotify, Discord, and WhatsApp, fall into this category.
We can only hope they are remade with proper native technologies, to save out batteries and performance...
It's orders of magnitude more expensive for a company to have swift specialists, kotlin specialists, and js specialists for a user experience that is meant to be fluid (or at least consistent) across platforms. Design consistency ends up being manually maintained, which is extremely faulty.
My company uses react-native for iOS and Android, and it works pretty well. We sell a web product, but for certain use cases our users need to be able to use a phone or tablet without internet connection.
I'm really surprised Apple's not cracking down on react-native yet. I wonder if it's because they don't want to get in a fight with Facebook?
> I'm really surprised Apple's not cracking down on react-native yet.
The design should be consistent not across platforms but across the particular platform. Don't use Android conventions on iOS, don't use iOS conventions on Android.