19 ms·

Apple has made it difficult to use web-based technology on its platforms

509 points by Lordarminius 7y ago

xenospn 7y ago
Alternative headline: “Apple makes the web safer by enforcing safety standards”
- theklr 7y ago
  But that doesn’t get the clicks Owen and medium need
- Spooks 7y ago
  and as the article states - that argument is weak
FussyZeus 7y ago
> 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.
- izacus 7y ago
  Funny how the same kind of reasoning isn't enough for technology like AMP, where there's endless screeching. Brand cheerleading at its finest :)
  - zapzupnz 7y ago
    I don't understand this comment. Could you unroll it for me? After all, AMP is despised by the tech community — but ultimately still used by publishers because Google's more-or-less holding them to ransom. Apple's not holding App Store developers to ransom with regards to apps that use Electron; rather, the use of private APIs always has been and always will be forbidden. That people went all-in with a technology that depends on private APIs without properly vetting the underlying stack, or rather that the core developers of this technology knowingly make use of private APIs, isn't quite the same as Google's leverage over publishers via its monopolistic grip on the world's search and advertising businesses, surely. One is a matter of technology, possibly of security, and the other is a more political discussion. But if I'm missing an angle, I'm open to being let know!
- bearcobra 7y ago
  > 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.
  - FussyZeus 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - magduf 7y ago
nottorp 7y ago
“Technology” is such an optimistic statement... You mean slow memory hungry crap?
- dijit 7y ago
  "Slow, but javascript renders incredibly mega fast on my i7 MacBook Pro!- And electron works great on that same laptop with 32GiB of ram!" /s
helpPeople 7y ago
Apple being anti developer and anti consumer? What's the news? I make my users use my website, I won't submit to Apple's bullying.
wffurr 7y ago
A big piece of the WebKit 2020 conference was dedicated to web platform standards catchup in WebKit: https://trac.webkit.org/wiki/WebKitGoalsfor2020 https://trac.webkit.org/wiki/WebKitGoalsfor2020 That's pretty much the opposite of "trying to kill web tech".
- kitsunesoba 7y ago
  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.
nobodyandproud 7y ago
Good. Web UI is terrible.
dfcagency 7y ago
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!)
- kevingadd 7y ago
  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.
  - nvrspyx 7y ago
    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.
draw_down 7y ago
Medium has decided I can’t read this. But, I think this view stems from a misunderstanding of Apple’s priorities as a company. Accuse them of gross neglect with regard to some aspects of the web if you like, but for outright aiming to kill it, no way.
mrtksn 7y ago
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 ).
happytoexplain 7y ago
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.
evanriley 7y ago
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.
- tootie 7y ago
  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.
  - st3fan 7y ago
    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.
    - tootie 7y ago
      Yes. And it was crippled for a long while outside of Safari. https://arstechnica.com/gadgets/2016/01/new-chrome-for-ios-is-finally-as-fast-and-stable-as-safari/ https://arstechnica.com/gadgets/2016/01/new-chrome-for-ios-i...
Wowfunhappy 7y ago
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.
- throwGuardian 7y ago
  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
  - Wowfunhappy 7y ago
    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.
    - throwGuardian 7y ago
      That incremental reduction in friction converts to substantial financial gains, being on the app store.
russellbeattie 7y ago
This is hyperbole based on the recent issues with Electron and little else. I'm not a fan-boy, but the fact is Apple has, in its own apple-ish way, been at the forefront of web technology for a decade and is continuing to do so. Safari is continually updated with the latest specs and JavaScriptCore continues to compete with V8. Yes, they make random security/business/tech decisions which can be frustrating, but even Apple knows they can't dismiss web tech, and they're not. 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.
rubyn00bie 7y ago
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!?!"
- st3fan 7y ago
  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 )
  - rubyn00bie 7y ago
    +11 and thanks for the clarification, that even lessens the issue IMHO. ... my third and fourth cents. I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it. You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow. The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it. Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code. Edit: Added MacOS or iOS for clarification since my point is the same for both.
coupdejarnac 7y ago
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.
hcarvalhoalves 7y ago
TL;DR Title is misleading hyperbole, it's talking about Apple not allowing Electron-based apps that access undocumented APIs into their App Store.
judah 7y ago
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.
- abrowne 7y ago
  > 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.
  - judah 7y ago
    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.
    - zchrykng 7y ago
      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.
      - saagarjha 7y ago
        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.
chadlavi 7y ago
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?
- rimliu 7y ago
  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.
- ken 7y ago
  > I'm really surprised Apple's not cracking down on react-native yet. Why is this surprising? React-Native uses JavaScriptCore, which Apple has promoted since long before iOS or any of their App Stores even existed. Apple isn't (AFAICT) rejecting any apps for using JavaScript under the covers.
egdod 7y ago
Alternative theory: electron apps are universally shitty.
- jeroenhd 7y ago
  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.
  - darklion 7y ago
    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.
  - hackerbrother 7y ago
    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?
deleted 7y ago
[deleted]
arendtio 7y ago
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.
- Hamuko 7y ago
  Kinda weird how many people seem to think that Electron is a web technology.
  - bitwize 7y ago
    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.
ogre_codes 7y ago
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.
- nomel 7y ago
  > 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.
  - ogre_codes 7y ago
    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.
    - dwaite 7y ago
      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.
scarface74 7y ago
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.
- erichocean 7y ago
  Right–Apple will make an update that breaks Chrome accidentally, and no one at Apple will notice that it happened.
  - dwaite 7y ago
    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?
    - austhrow743 7y ago
      Yes, many Apple critics just want it to be Microsoft.
  - scarface74 7y ago
    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.
  - saagarjha 7y ago
    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.
st3fan 7y ago
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.
- mmcwilliams 7y ago
  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.
deleted 7y ago
[deleted]
maxsavin 7y ago
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.
jeroenhd 7y ago
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.
- kevingadd 7y ago
  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.
  - jeroenhd 7y ago
    I'm fine with Javascript itself, but I want the application render code to use native system APIs. 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.
mettamage 7y ago
Ehm, so... 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.
- __jal 7y ago
  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.
aj7 7y ago
No updates for WhatsApp??
sandofsky 7y ago
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.
badrequest 7y ago
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.
deedubaya 7y ago
You still can't use service workers in WKWebViews, right?
- inetknght 7y ago
  That'll be a feature. Service workers are web-based workarounds for what should be a native application...
  - deedubaya 7y ago
    You must be fun at parties
    - dang 7y ago
      Please don't do this here.
angel_j 7y ago
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.
nessup 7y ago
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: https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-from-the-mac-app-store/ https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-fr...
burtonator 7y ago
I can speak to this problem as I develop an Electron app that targets MacOS, Windows, and Linux (as well as the web). https://getpolarized.io https://getpolarized.io 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: https://getpolarized.io/2019/02/28/dear-app-stores-dont-block-apps-lead-with-the-carrot.html https://getpolarized.io/2019/02/28/dear-app-stores-dont-bloc... https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-Extension-Innovation.html https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-E... 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.
ChrisMarshallNY 7y ago
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).
monkin 7y ago
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... :(
KibbutzDalia 7y ago
The WebRTC thing is nasty. If I tweet or text a link to our company’s WebRTC application I have to detect it and explain how to reopen the link directly in safari.
parliament32 7y ago
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.
katabatic 7y ago
Oh, the irony of publishing this on Medium.
MaysonL 7y ago
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.
vkaku 7y ago
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.
youareostriches 7y ago
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.
bjustin 7y ago
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/iosurface https://developer.apple.com/documentation/quartzcore/calayer https://developer.apple.com/documentation/quartzcore/calayer
- st3fan 7y ago
  You can read the details here: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... The required bits for that work are not actually documented.
  - bjustin 7y ago
    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.
  - dwaite 7y ago
    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.
giobox 7y ago
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.
- mikl 7y ago
  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.
jjtheblunt 7y ago
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.
ryuukk_ 7y ago
and they made the right choice just like no JIT on iOS they always care about performance, efficiency and smoothness something MS doesn't care about for windows, and something Google doesn't care about for Android
ryuukk_ 7y ago
they should kill you too for spreading fake news, and for glorifying the people responsible of the trash electron app powered by trash javascript
mikl 7y ago
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.
- pentae 7y ago
  > 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.
  - ecf 7y ago
    If the application is important enough, a native version for iOS will be made. Otherwise, mobile Safari (or any other browser) still exists.
  - vasachi 7y ago
    But there is an add to home screen functionality. I, for instance, have a Kindle Store “app”, which was added from safari.
  - mikl 7y ago
    > 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).
jkrie9 7y ago
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.
tsp 7y ago
You can find more details on the issue of Electron using private macOS APIs in the following discussions: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/pull/20965 https://github.com/electron/electron/pull/20965
coldtea 7y ago
>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...
loeg 7y ago
> 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.
kevindong 7y ago
Honest question: who actually uses the macOS App Store?
- threeseed 7y ago
  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.
- danShumway 7y ago
  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.
unnouinceput 7y ago
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.
Koremat6666 7y ago
This has "fragile" written all over it.
jwlake 7y ago
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.
- saagarjha 7y ago
  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.
lonelappde 7y ago
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.
fouc 7y ago
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.
- sneak 7y ago
  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.
sally1620 7y ago
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.
amadeuspagel 7y ago
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?
ravedave5 7y ago
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.

509 points by Lordarminius 7y ago

xenospn 7y ago

Alternative headline: “Apple makes the web safer by enforcing safety standards”

theklr 7y ago
But that doesn’t get the clicks Owen and medium need
Spooks 7y ago
and as the article states - that argument is weak

FussyZeus 7y ago

> 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.

izacus 7y ago
Funny how the same kind of reasoning isn't enough for technology like AMP, where there's endless screeching. Brand cheerleading at its finest :)
- zapzupnz 7y ago
  I don't understand this comment. Could you unroll it for me? After all, AMP is despised by the tech community — but ultimately still used by publishers because Google's more-or-less holding them to ransom. Apple's not holding App Store developers to ransom with regards to apps that use Electron; rather, the use of private APIs always has been and always will be forbidden. That people went all-in with a technology that depends on private APIs without properly vetting the underlying stack, or rather that the core developers of this technology knowingly make use of private APIs, isn't quite the same as Google's leverage over publishers via its monopolistic grip on the world's search and advertising businesses, surely. One is a matter of technology, possibly of security, and the other is a more political discussion. But if I'm missing an angle, I'm open to being let know!
bearcobra 7y ago
> 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.
- FussyZeus 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - magduf 7y ago

nottorp 7y ago

“Technology” is such an optimistic statement... You mean slow memory hungry crap?

dijit 7y ago
"Slow, but javascript renders incredibly mega fast on my i7 MacBook Pro!- And electron works great on that same laptop with 32GiB of ram!" /s

helpPeople 7y ago

Apple being anti developer and anti consumer? What's the news? I make my users use my website, I won't submit to Apple's bullying.

wffurr 7y ago

A big piece of the WebKit 2020 conference was dedicated to web platform standards catchup in WebKit: https://trac.webkit.org/wiki/WebKitGoalsfor2020 https://trac.webkit.org/wiki/WebKitGoalsfor2020 That's pretty much the opposite of "trying to kill web tech".

kitsunesoba 7y ago
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.

nobodyandproud 7y ago

Good. Web UI is terrible.

dfcagency 7y ago

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!)

kevingadd 7y ago
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.
- nvrspyx 7y ago
  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.

draw_down 7y ago

Medium has decided I can’t read this. But, I think this view stems from a misunderstanding of Apple’s priorities as a company. Accuse them of gross neglect with regard to some aspects of the web if you like, but for outright aiming to kill it, no way.

mrtksn 7y ago

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 ).

happytoexplain 7y ago

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.

evanriley 7y ago

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.

tootie 7y ago
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.
- st3fan 7y ago
  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.
  - tootie 7y ago
    Yes. And it was crippled for a long while outside of Safari. https://arstechnica.com/gadgets/2016/01/new-chrome-for-ios-is-finally-as-fast-and-stable-as-safari/ https://arstechnica.com/gadgets/2016/01/new-chrome-for-ios-i...

Wowfunhappy 7y ago

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.

throwGuardian 7y ago
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
- Wowfunhappy 7y ago
  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.
  - throwGuardian 7y ago
    That incremental reduction in friction converts to substantial financial gains, being on the app store.

russellbeattie 7y ago

This is hyperbole based on the recent issues with Electron and little else. I'm not a fan-boy, but the fact is Apple has, in its own apple-ish way, been at the forefront of web technology for a decade and is continuing to do so. Safari is continually updated with the latest specs and JavaScriptCore continues to compete with V8. Yes, they make random security/business/tech decisions which can be frustrating, but even Apple knows they can't dismiss web tech, and they're not. 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.

rubyn00bie 7y ago

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!?!"

st3fan 7y ago
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 )
- rubyn00bie 7y ago
  +11 and thanks for the clarification, that even lessens the issue IMHO. ... my third and fourth cents. I don't think a lot of folks realize just how rich the ecosystem is for developing a MacOS or iOS application without writing ObjC or Swift. This is really one particular toolkit, that's doing something it's not supposed to, and that's it. You can write MacOS/iOS apps using C, C++, Java, JavaScript, .NET, Ruby, and I'm sure a bunch more each using something _not electron_ and are not having this problem right meow. The real pain I think for most people using Electron is that they're so far removed from the native SDKs it's scary to not know what the fuck really happened. That's fair, but that's also the price for using an abstraction like Electron. If you're not the one making the API calls, then you're opening yourself up to that potential issue and it's going to be scary until you understand it. Personally, I don't think I'm smart enough to understand that many layers of abstraction even if I wanted to; so, I don't use them and just write native code. Edit: Added MacOS or iOS for clarification since my point is the same for both.

coupdejarnac 7y ago

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.

hcarvalhoalves 7y ago

TL;DR Title is misleading hyperbole, it's talking about Apple not allowing Electron-based apps that access undocumented APIs into their App Store.

judah 7y ago

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.

abrowne 7y ago
> 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.
- judah 7y ago
  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.
  - zchrykng 7y ago
    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.
    - saagarjha 7y ago
      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.

chadlavi 7y ago

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?

rimliu 7y ago
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.
ken 7y ago
> I'm really surprised Apple's not cracking down on react-native yet. Why is this surprising? React-Native uses JavaScriptCore, which Apple has promoted since long before iOS or any of their App Stores even existed. Apple isn't (AFAICT) rejecting any apps for using JavaScript under the covers.

egdod 7y ago

Alternative theory: electron apps are universally shitty.

jeroenhd 7y ago
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.
- darklion 7y ago
  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.
- hackerbrother 7y ago
  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?

deleted 7y ago

[deleted]

arendtio 7y ago

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.

Hamuko 7y ago
Kinda weird how many people seem to think that Electron is a web technology.
- bitwize 7y ago
  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.

ogre_codes 7y ago

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.

nomel 7y ago
> 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.
- ogre_codes 7y ago
  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.
  - dwaite 7y ago
    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.

scarface74 7y ago

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.

erichocean 7y ago
Right–Apple will make an update that breaks Chrome accidentally, and no one at Apple will notice that it happened.
- dwaite 7y ago
  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?
  - austhrow743 7y ago
    Yes, many Apple critics just want it to be Microsoft.
- scarface74 7y ago
  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.
- saagarjha 7y ago
  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.

st3fan 7y ago

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.

mmcwilliams 7y ago
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.

deleted 7y ago

[deleted]

maxsavin 7y ago

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.

jeroenhd 7y ago

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.

kevingadd 7y ago
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.
- jeroenhd 7y ago
  I'm fine with Javascript itself, but I want the application render code to use native system APIs. 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.

mettamage 7y ago

Ehm, so... 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.

__jal 7y ago
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.

aj7 7y ago

No updates for WhatsApp??

sandofsky 7y ago

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.

badrequest 7y ago

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.

deedubaya 7y ago

You still can't use service workers in WKWebViews, right?

inetknght 7y ago
That'll be a feature. Service workers are web-based workarounds for what should be a native application...
- deedubaya 7y ago
  You must be fun at parties
  - dang 7y ago
    Please don't do this here.

angel_j 7y ago

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.

nessup 7y ago

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: https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-from-the-mac-app-store/ https://mjtsai.com/blog/2019/11/04/electron-apps-rejected-fr...

burtonator 7y ago

I can speak to this problem as I develop an Electron app that targets MacOS, Windows, and Linux (as well as the web). https://getpolarized.io https://getpolarized.io 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: https://getpolarized.io/2019/02/28/dear-app-stores-dont-block-apps-lead-with-the-carrot.html https://getpolarized.io/2019/02/28/dear-app-stores-dont-bloc... https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-Extension-Innovation.html https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-E... 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.

ChrisMarshallNY 7y ago

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).

monkin 7y ago

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... :(

KibbutzDalia 7y ago

The WebRTC thing is nasty. If I tweet or text a link to our company’s WebRTC application I have to detect it and explain how to reopen the link directly in safari.

parliament32 7y ago

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.

katabatic 7y ago

Oh, the irony of publishing this on Medium.

MaysonL 7y ago

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.

vkaku 7y ago

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.

youareostriches 7y ago

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.

bjustin 7y ago

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/iosurface https://developer.apple.com/documentation/quartzcore/calayer https://developer.apple.com/documentation/quartzcore/calayer

st3fan 7y ago
You can read the details here: https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-power-usage-in-firefox-70-on-macos-with-core-animation/ https://mozillagfx.wordpress.com/2019/10/22/dramatically-red... The required bits for that work are not actually documented.
- bjustin 7y ago
  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.
- dwaite 7y ago
  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.

giobox 7y ago

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.

mikl 7y ago
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.

jjtheblunt 7y ago

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.

ryuukk_ 7y ago

and they made the right choice just like no JIT on iOS they always care about performance, efficiency and smoothness something MS doesn't care about for windows, and something Google doesn't care about for Android

ryuukk_ 7y ago

they should kill you too for spreading fake news, and for glorifying the people responsible of the trash electron app powered by trash javascript

mikl 7y ago

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.

pentae 7y ago
> 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.
- ecf 7y ago
  If the application is important enough, a native version for iOS will be made. Otherwise, mobile Safari (or any other browser) still exists.
- vasachi 7y ago
  But there is an add to home screen functionality. I, for instance, have a Kindle Store “app”, which was added from safari.
- mikl 7y ago
  > 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).

jkrie9 7y ago

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.

tsp 7y ago

You can find more details on the issue of Electron using private macOS APIs in the following discussions: https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/issues/20027 https://github.com/electron/electron/pull/20965 https://github.com/electron/electron/pull/20965

coldtea 7y ago

>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...

loeg 7y ago

> 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.

kevindong 7y ago

Honest question: who actually uses the macOS App Store?

threeseed 7y ago
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.
danShumway 7y ago
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.

unnouinceput 7y ago

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.

Koremat6666 7y ago

This has "fragile" written all over it.

jwlake 7y ago

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.

saagarjha 7y ago
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.

lonelappde 7y ago

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.

fouc 7y ago

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.

sneak 7y ago
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.

sally1620 7y ago

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.

amadeuspagel 7y ago

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?

ravedave5 7y ago

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.