I was able to submit my app after an upgrade to Electron 6 with no issue whatsoever.
Only issue was first with the signature of the app, got fixed with later updates.
My app is up in the AppStore with latest Electron 6.
Electron apps cannot be submitted to the Apple store
361–370 of 441 posts
Re: Electron apps cannot be submitted to the Apple store
#362Re: Electron apps cannot be submitted to the Apple store
#363Earlier quoted context omitted.
Knowing every transitive dependency in your application stack is totally unrealistic and is pretty much impossible for any modern commercial software outside of specialized/embedded systems. Having knowledge of every dependency explicitly linked into your application is a basic tenet of software development that literally every software professional would endorse as a necessary best practice, but it's not what we're…
> outside of specialized/embedded systems. I think you're conflating platforms and dependencies. The OS it runs on is a platform that the the user already trusts, left-pad is a dependency the developers are responsible for. There's some grey area like electron or the JVM but even there electron sticks out as a huge binary blob the user isn't explicitly asked to install.
I never brought up operating systems in the context of this discussion on dependencies. Electron is not an operating system, so I am not sure what your point is.
Re: Electron apps cannot be submitted to the Apple store
#364Earlier quoted context omitted.
Apple often straight up breaks the implementations of public APIs leaving developers scrambling to fix them. See modals in iOS 13, or title bar styling. I work at a development agency and on both macOS and iOS every release is a race to figure out which breaking changes have been sprung by Apple (including crashes caused by silent changes in behavior of existing APIs, people have had apps rejected for breaking on pre…
There is a difference between breaking a public API which is a defect and that’s done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately. Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn’t work with the 68040 cache. Whose fault was that Apple’s or the devel…
It is not a defect. It is literally intentionally broken! Do you actually know this space?
The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way.
Catalina removed XML exports used by music apps. There was no deprecation warning.
Apple's recommended fix? Don't update if you need one of those apps.
These are not defects, they are literally breaking changes intentionally made with no warning.
I don't understand why all of you seem to be operating underthe assumption apps using "public APIs" just work with each OS update. It just doesn't work like that. They break and crash not due to defects but due to intentional changes
Re: Electron apps cannot be submitted to the Apple store
#365Earlier quoted context omitted.
There is a difference between breaking a public API which is a defect and that’s done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately. Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn’t work with the 68040 cache. Whose fault was that Apple’s or the devel…
It is not a defect. It is literally intentionally broken! Do you actually know this space? The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way. Catalina removed XML exports used by music apps. There was no deprecation warning. Apple's recommended fix? Don't update if you need one of those apps. These are not defects, they are literally brea…
It was part of the first beta release that the new iTunes wouldn't support XML exports. So there was warning that it wouldn't work. Public API's doesn't mean "something will never change". It should mean that API's won't change between minor version numbers. The entire purpose of semantic versioning is that there might be major breaking changing when there is a major release.
Apple did in fact provide a method to share music between apps and some apps do take advantage of it. Do you really think that Apple didn't need to do a major overhaul of iTunes?
Of course it's Apple's advice and common sense not to upgrade your OS until the apps you use are updated to support it.
This is all modern software engineering 101.
As a developer there are a few expectations.
- depending on private method may break your code with any point release. The vendor has no obligation not to break code if you depended on a private API.
- 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 API's when releasing a point release.
- If the vendor makes a breaking change during a major release (x.0.0). It's the vendor's responsible to communicate the breaking change and give enough notice to developers/users about breaking changes so that either the developer can fix their code, the user can find a replacement app, and/or the user not upgrade.
Re: Electron apps cannot be submitted to the Apple store
#366Earlier quoted context omitted.
Getting out of iOS development and back into web dev was the best career decision I ever made. I feel like I escaped an abusive relationship. So much of what's wrong with computing and tech right now stems directly or indirectly from the culture at Apple.
It's funny how the general consensus on here is against Microsoft's abuse of private APIs in Windows to help Word and DOS against WordPerfect and DrDOS, 20+ years ago. But Apple doing it right now in a much worse way is considered acceptable and defendable.
Walled gardens weren't as normalized then.
Re: Electron apps cannot be submitted to the Apple store
#367Re: Electron apps cannot be submitted to the Apple store
#368Earlier quoted context omitted.
Getting out of iOS development and back into web dev was the best career decision I ever made. I feel like I escaped an abusive relationship. So much of what's wrong with computing and tech right now stems directly or indirectly from the culture at Apple.
I work in public digitisation and while we don’t build the apps, we’re now required to publish them if we want our name as the publisher. So I’ve had the pleasure of setting up our development account and it’s easily the works service I’ve ever had to go through, and we operate 300 different IT systems, some are old terminal systems that run on mainframe. I’m not sure why the process was so complicated either. A coup…
> we’re now required to publish them if we want our name as the publisher.
That seems reasonable to me -- they're just saying that if you want to be listed as the publisher, you need to be the publisher...
Re: Electron apps cannot be submitted to the Apple store
#369Earlier quoted context omitted.
It is not a defect. It is literally intentionally broken! Do you actually know this space? The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way. Catalina removed XML exports used by music apps. There was no deprecation warning. Apple's recommended fix? Don't update if you need one of those apps. These are not defects, they are literally brea…
It was part of the first beta release that the new iTunes wouldn't support XML exports. So there was warning that it wouldn't work. Public API's doesn't mean "something will never change". It should mean that API's won't change between minor version numbers. The entire purpose of semantic versioning is that there might be major breaking changing when there is a major release. Apple did in fact provide a method to sha…
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 API's when releasing a point release.
Not when the vendor is Apple.
This whole time you've been operating on the set of rules that apply when your vendor considers you a partner of sorts, maybe in the vaguest sense of the word, but a partner nonetheless.
iOS point releases break things literally all the time. Iirc we actually saw more fires on 13.1 than 13.0
This literally has nothing to do with semantic versioning or whatever else you want to confuse it with. It's a blatant disregard for developers that Apple has carried throughout it's operations, from APIs to app store rejections. If anything the only reason they get the slightest pass is they're not Google, who manages to make talking to a human, no matter how hard they stonewall you, a selling point in mobile developer relations now.
Re: Electron apps cannot be submitted to the Apple store
#370This is absolutely insane. Apple could learn a lot from Microsoft of how to treat developers. God i miss Steve Ballmer
It’s dumb too depend on private APIs and shows a complete lack of understanding how development works. Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?
> Have you read Raymond Chen’s blog about all of the obscure one off hacks Microsoft has had to add to keep misbehaving apps from breaking?
That is precisely why I mentioned Microsoft. They have historically gone through great lengths to keep devs happy.