Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

411–420 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#411
post #407

Earlier quoted context omitted.

And where has that gotten them? Slow release cycles, unable to compete in mobile and now Apple alone sells more iOS devices than all Windows manufacturers combined. You create a compelling platform for users and developers will come along. That’s what happens when you focus on developers instead of users. How much smaller would Windows be if they didn’t have all of these backwards compstible hacks? Hell, they had a h…

Microsofts failure in mobile has simply been due to the fact that they weren't able to excite users with hardware. This changed with the Surface line.

Microsoft’s hardware was often the same hardware that ran Android especially from HTC.

But as far as the Surface. MS only made $1.329 billion on Surface devices. That’s less than a third of what Apple makes on Macs. Heck that’s less than Apple makes on Watches and AirPods.

https://sixcolors.com/post/2019/10/apple-results-64b-in-reve...

https://www.techradar.com/news/microsofts-surface-sales-keep...

Re: Electron apps cannot be submitted to the Apple store

#412

Earlier quoted context omitted.

You spent so many words to latch onto a single part of my entire comment, construct a strawman around it, and burn it down. But lo and behold something useful did come of it, I finally found the fundamental misunderstanding keeping you from understanding what the crux of the issue is. > If your code breaks calling a public method during a point release, it is a bug and the vendor has an obligation not to break public…

No one is going to argue that this entire release cycle hasn’t been a clusterfuck and the rapid release cycle of iOS/MacOS/watchOS this year is evidence of that. But your argument has nothing to do with this submission - using private APIs . At least one of your two examples - getting rid of XML exports - wasn’t about Apple breaking a public API during a point release. How is it a straw man refuting one of your major…

My point with that example was about how Apple doesn't treat developers as partners, something I said multiple times in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of.

You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it.

You ignored my comment you just replied to pointing out how irrelevant sem-ver is when your "vendor" doesn't care about you.

You are fixated on trying to nitpick the one tiny foothold you've found for your screed, one which only exists because you're ignoring the initial point I, not the article brought up, that this is an issue with Apple not caring about developers literally in the first comment you replied to.

Maybe spend more time reading and less time replying.

Re: Electron apps cannot be submitted to the Apple store

#413

Earlier quoted context omitted.

No one is going to argue that this entire release cycle hasn’t been a clusterfuck and the rapid release cycle of iOS/MacOS/watchOS this year is evidence of that. But your argument has nothing to do with this submission - using private APIs . At least one of your two examples - getting rid of XML exports - wasn’t about Apple breaking a public API during a point release. How is it a straw man refuting one of your major…

My point with that example was about how Apple doesn't treat developers as partners, something I said multiple times in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of. You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it. You ignored my comment you just replied to pointing out how irrelevan…

You gave two examples - the one I know about “broke” with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn’t say whether it was a point release or an iOS 13 change.

The electron rejection is not a symptom of Apple breaking a public API. It’s just the opposite. An API change didn’t break Electron apps - it was rejected for using a private API.

It’s not “nitpicking” to point out that your examples are completely irrelevant to the submitted article - Apple rejected an app that used private APIs. None of your examples have anything to do with the submitted post.

Would you also complain if you wrote a C program that depended on documented “undefined behavior”...

  int b= a++ + ++a;
and it broke with the next version of the compiler or broke based on which optimizations were turned on? Yes I am sticking with examples of how irresponsible it is to depend on private APIs and undocumented behavior - something you advocated in other comments because that’s the entire point of the submitted article.

Re: Electron apps cannot be submitted to the Apple store

#414

Earlier quoted context omitted.

Which is the same thing.

It isn't? There's a difference between dropping 32bit libraries from your OS (after a lot of time in which Apple clearly said "we will drop support!") and banning for using unauthorized APIs inside the MAS.

32 bit support is also an API. MacOS agreed to run apps compiled to target a particular instruction set. Arbitrarily refusing to honor that (undocumented) agreement is the same as breaking an undocumented API. Here they broke all the 32 bit interfaces for their OS.

Re: Electron apps cannot be submitted to the Apple store

#415

Earlier quoted context omitted.

My point with that example was about how Apple doesn't treat developers as partners, something I said multiple times in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of. You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it. You ignored my comment you just replied to pointing out how irrelevan…

You gave two examples - the one I know about “broke” with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn’t say whether it was a point release or an iOS 13 change. The electron rejection is not a symptom of Apple breaking a public API . It’s just the opposite. An API change didn…

Again you spend more time replying than reading.

I said this internal API rejection situation of Apple not treating developers like partners

Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text.

I'm done replying to this.

Re: Electron apps cannot be submitted to the Apple store

#416

Earlier quoted context omitted.

as CTO I know all the dependencies in the application stack of our company and I require developers to have sufficient understanding of their purpose, licensing model etc. There are tools to simplify this task. It’s much harder to do for TypeScript than for Java, mostly because NPM ecosystem is a huge pile of junk, but it’s still important part of developer's job.

I can't believe you check all the source code, dependencies source code and the rest of the shit show that npm brings to the party, that's very cool, all CTOs should be like you. As a CTO should you have to do this though? I'm not sure.

We are growing startup and it’s important to have this culture of understanding what and how you build from the very beginning. This responsibility is now transferred to technical leads, but I’m still aware of what’s going on and spend some time on the code reviews.

Re: Electron apps cannot be submitted to the Apple store

#417

Earlier quoted context omitted.

Is that a joke? Surely you aren't suggesting that developers should have full knowledge of all transitive dependencies that compose their application stack.

Honestly, it boggles the mind to think that a responsible developer would just pull in some 3rd party dependency without auditing what it does/calls and what other sub-dependencies it has, and then ship it as their product that their business relies on. Everywhere I’ve ever worked, adopting a dependent library was a HUGE DEAL. You don’t do it lightly. You have to know what’s in it, know what it calls, know what the l…

Can you even know every transitive dependency in an average Node.js project? I just looked at a simple web service we have, which doesn't use any framework or such, and it's 5 dependencies pull in 75 dependencies altogether.

Since most applications nowadays are server side, you would usually already pull 1 GB+ of Docker layers, before you even add application + libraries.

Facebook on iOS seems to be around 400 MB of size (first result from quick googling, might be wrong), and average Electron app is 120 MB+, so I don't think the size is a huge concern.

Re: Electron apps cannot be submitted to the Apple store

#418

Earlier quoted context omitted.

You gave two examples - the one I know about “broke” with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn’t say whether it was a point release or an iOS 13 change. The electron rejection is not a symptom of Apple breaking a public API . It’s just the opposite. An API change didn…

Again you spend more time replying than reading. I said this internal API rejection situation of Apple not treating developers like partners Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text. I'm done replying to this.

The internal API rejection is about not treating developers like “partners”. You aren’t their partner. Internal APIs are just that - for internal employees.

It’s dumb to use “internal”, private APIs. It always has been. It hurts your products stability, it hurts your customers, and it keeps the platform vendor from making rapid changes.

Microsoft never cared about you as a developer - they would just as easily run over you if it met their business objectives.

Re: Electron apps cannot be submitted to the Apple store

#419
post #396

Earlier quoted context omitted.

Sure, but that’s not actually what happened. I didn’t go into detail with that part, because it’s fine. We’re fine with someone else being the publisher and listed as such though, but you’re not allowed to do that on behalf of others anymore. The result is 98 muniplacities having to pay Apple developer fees, but it gets better because the app can’t be called the same thing anymore. So now there are 98 apps instead of…

Forgive me if I'm not understanding correctly, but in your description here it sounds like the problem is in how your organization functions around this, not in Apple's policies. It's not really fair to expect Apple to resolve or work around your own organizational problems.

Why not? Microsoft does it all the time. So does Google, to an extend.

Apples inability to work with us is the primary reason we replaced thousands of iPads for school children with Chrome books. Eventually Apple caved to our needs, but it was way too late. Google were “what can we do to make this deal work for both of us?” from day one.

Re: Electron apps cannot be submitted to the Apple store

#420

As a user I am glad. As is custom for all Electron discussions, someone must point out its flaws. Why the dislike, you ask? A picture is worth a thousand 64-bit words: https://imgur.com/a/XnCOHUD And mind you, GitHub Desktop is taking that much just for showing a mostly empty window! while Fork and Tower are displaying a lot more UI, more controls, trees, custom drawing, more text, and have overall more features (bes…

I uh...Sorry are you mad that an electron application is using ~80mb more than other native applications? I cannot fathom the indignity required to care about that difference.

Taking more to do less. Can you fathom the ability to read the rest of that comment and all the other comments about it?
Post reply on HN