
Apple has made it difficult to use web-based technology on its platforms - Lordarminius
https://onezero.medium.com/apple-is-trying-to-kill-web-technology-a274237c174d
======
rubyn00bie
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!?!"

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

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

~~~
ralmidani
Are you sure? I have Chrome on my iPad.

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

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

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

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

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

~~~
NicoJuicy
Not that minor, there are indeed 2 different engines.

One for Safari and one for the rest.

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

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

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

~~~
darklion
> and it’s all managed at the pleasure of their bottom line.

As if Android’s come-one come-all is done out of benevolence. Google doesn’t
have a heart, it had a bottom line too, and supporting those tools makes
dollars come its way.

Google HAD an opportunity to ensure that one browser engine ruled the web—-but
they chose to fork WebKit into Blink, in part _because_ they didn’t want to
share the work they were doing. It propped up competitors. Google would rather
have a competitive—-read, monetary—-advantage than ensure web technology is
widely available for all to use.

For example, when Google refused to share the multi-process mode that
differentiated Chrome from other browsers, it was a compelling enough security
feature that Apple/WebKit reimplemented it independently so that everyone
using WebKit could have it.

Google proceeded to cry crocodile tears, and then promptly forked the WebKit
codebase into Blink. They claimed it was necessary to avoid having to carry
around two multi-process models, but it was a A PROBLEM OF THEIR OWN MAKING.

So don’t imply Apple is profiteering, as if other companies are trying to give
you hugs. Everybody’s finding cash in the ways that play to their strengths.

If Google was really interested in pushing the web forward, they’d swallow
their pride, take the bottom line hit, and merge Blink back into WebKit.

~~~
soperj
> Google HAD an opportunity to ensure that one browser engine ruled the
> web—-but they chose to fork WebKit into Blink, in part _because_ they didn’t
> want to share the work they were doing.

Apple had the same choice when it forked KHTML to produce Webkit.

~~~
darklion
KHTML wasn’t anywhere near the same position as WebKit when Apple forked it.
At the time, KHTML was niche beyond its use in KDE.

When Google forked WebKit, Safari and Chrome combined were something like 40%
of the market.

~~~
soperj
so?

Chrome was clearly the leader. Apple should have moved to their fork then if
anything.

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

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

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

------
scarface74
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
Right–Apple will make an update that breaks Chrome accidentally, and no one at
Apple will notice that it happened.

~~~
dwaite
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
Yes, many Apple critics just want it to be Microsoft.

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

------
bjustin
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
You can read the details here:

[https://mozillagfx.wordpress.com/2019/10/22/dramatically-
red...](https://mozillagfx.wordpress.com/2019/10/22/dramatically-reduced-
power-usage-in-firefox-70-on-macos-with-core-animation/)

The required bits for that work are not actually documented.

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

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

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

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

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

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

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

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

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

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

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

~~~
dijit
"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

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

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

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

------
nobodyandproud
Good. Web UI is terrible.

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

~~~
ogre_codes
> I also suspect a reason the tools were revised to reject apps with use of
> these internal functions is that some of them are going away in March.

This is the thing, there are good reasons Apple should reserve certain
libraries as private and not support them. The fact that Electron dipped into
private libraries and didn't have a fallback plan for WHEN Apple clamped down
on this is just poor planning. That said... a small amount of communications
and/ or tolerance from Apple would go a long way towards developer good will
here. Lots of small developers getting burned here.

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

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

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

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

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

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

------
amadeuspagel
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?

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

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

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

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

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

------
katabatic
Oh, the irony of publishing this on Medium.

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

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

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

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

~~~
theklr
But that doesn’t get the clicks Owen and medium need

------
burtonator
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-
bloc...](https://getpolarized.io/2019/02/28/dear-app-stores-dont-block-apps-
lead-with-the-carrot.html)

[https://getpolarized.io/2019/04/05/Google-Will-Kill-
Chrome-E...](https://getpolarized.io/2019/04/05/Google-Will-Kill-Chrome-
Extension-Innovation.html)

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.

------
aj7
No updates for WhatsApp??

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

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

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

~~~
magduf
I guess you're a big fan of monopolies, huh?

~~~
FussyZeus
It amazes me that Google's managed to maintain this sense of being the
underdog with almost 80% share worldwide. Apple is far from a monopoly.
Hilariously far, in fact.

~~~
marvindanig
An instance, but in no way covering the entire picture.

One of the reasons why Google Chrome enjoys its monopoly is because Apple does
a terrible job with its browser Safari. Terrible. I mean it's a train-wreck!
Since iOS 10 or probably little later they have done nothing but destroy how
the web apis are supposed to function, abusing every single accessibility
guideline into something that is at best a line of defense to promote their
app store.

I hesitantly moved away from iPhone X to Android Pixel last month.

~~~
scarface74
Or could it be that the reason Chrome “enjoys” a monopoly is because Apple
doesn’t care about “winning” the browser war? Why should it? That was last
decades battle. Not even MS cares about the browser enough anymore to invest
in its own engine.

~~~
hesarenu
If they didn't care then we would have alternative rendering engine along with
safari. They know that allowing competition is a threat to their business
model.

~~~
scarface74
Since the submission is about MacOS and Electron....

~~~
hesarenu
And are you commenting about just macos and electron? Anyway does not change
my answer.

~~~
scarface74
It should since MacOS allows alternate browser engines....

~~~
hesarenu
But there is no option in iOS. Why are Apple afraid of the competition?

~~~
scarface74
So Apple “is afraid of competition” on an app it makes no money off, but
allows the Kindle book store, Spotify, plenty of streaming services, Google
Maps, two popular Office alternatives to iWork, has built in extensibility
points to allow alternative storage providers to iCloud, alternate podcast
providers, it basically built a feature into iOS just for alternative password
managers, etc.

Maybe it’s telling the truth when it says there are security concerns?

~~~
hesarenu
Those are installed using apple approved app store. Which requires a
subscription and payment of 30%. You can give behind security but the truth is
they are afraid.

If they allow alternate app store or browsers then yes apple is bold. Until
then they need to consider their bottomline which requires sometimes bowing to
China as well!

~~~
scarface74
That’s also not true. You don’t have to go through Apple to run a subscription
service. You can have people subscribe/buy content outside of the store and
let them use it within the store. Netflix, Spotify, Amazon (Kindle, Audible,
etc.), AT&T Now, Sling, LinuxAcademy, and countless others make you pay for
subscriptions/content outside of the store.

------
egdod
Alternative theory: electron apps are universally shitty.

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

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

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

------
Koremat6666
This has "fragile" written all over it.

------
kevindong
Honest question: who actually uses the macOS App Store?

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

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

~~~
inetknght
That'll be a feature. Service workers are web-based workarounds for what
should be a native application...

~~~
deedubaya
You must be fun at parties

~~~
dang
Please don't do this here.

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

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

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

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

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

------
chadlavi
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?

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

