Live data from Hacker News

Electron apps cannot be submitted to the Apple store

david.dev

371–380 of 441 posts

Re: Electron apps cannot be submitted to the Apple store

#371

Earlier quoted context omitted.

How exactly do you miss a dependency?! If it's not your code, then it's a dependency that you need to look at.

Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph.

> You may not have time to inspect every single node in the dependency graph.

You may not have time to do your job properly?

If you're using libraries in your project, it's normal and expected that you know what those libraries are doing and what those libraries depend on. You should know this stuff regardless of what Apple (or anyone else) may require.

Re: Electron apps cannot be submitted to the Apple store

#372

Earlier quoted context omitted.

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…

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 points? It was about Apple changing an API during a major release and letting developers know. This is how a vendor should behave.

Now whether they gave developers enough of a warning is a completely separate argument.

BTW: While it is a major change and no longer automatic. There is a manual workaround...

https://djtechtools.com/2019/10/10/update-to-catalina-heres-...

Re: Electron apps cannot be submitted to the Apple store

#373

Earlier quoted context omitted.

> Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph. Excuse me, are you, the developer, telling me, a user, that you don't know what you're giving me to run on my computer?

Hi my name is node_modules have you met me? If you invite me to a party I bring my 500 closest friends as my plus one! I just looked at the node_modules folder for a project that runs user configured code when your imap server gets a new mail via imap idle. It's called imapnotify and inside its node_modules dir I see it pulls in 549 js files. The majority are under 100 lines per file dozens are between 1 and 30. Cutt…

> If you invite me to a party I bring my 500 closest friends as my plus one!

That sort of thing is a big red flag that perhaps you should reconsider using that package.

But even if you do use it, that in no way reduces the fact that it's your responsibility to know what you're shipping.

Re: Electron apps cannot be submitted to the Apple store

#374

Earlier quoted context omitted.

> Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph. Excuse me, are you, the developer, telling me, a user, that you don't know what you're giving me to run on my computer?

With NPM as an example to fully know every dependency is a highly time-intensive and complicated task due to following: * you can't be sure code in package is same you see on github as npm doesn't do signatures * code already in node_modules is usually minified and obfuscated So only real way to be sure is to make own repository, copy every dependency, check code, build own packages and only use packages from your re…

That's an excellent reason to avoid using apps.

Re: Electron apps cannot be submitted to the Apple store

#375
post #238

Electron apps can be submitted to the Apple store... Slack has recently been updated for example. This seems to only affect some developers, especially electron <= 5

Does Slack use private APIs?

No electron application use private APIs, it's the embedded chromium that do.

Re: Electron apps cannot be submitted to the Apple store

#376

Earlier quoted context omitted.

> Dependencies of your dependencies! Imagine installing a library that depends on a couple dozen libraries in its own right. You may not have time to inspect every single node in the dependency graph. Excuse me, are you, the developer, telling me, a user, that you don't know what you're giving me to run on my computer?

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

I think that's not an unreasonable thing to expect at all. If the libraries you're using make that impossible, then you shouldn't use those libraries. You should know what you're shipping.

As a developer, I'm honestly and utterly stunned to see other developers arguing otherwise.

Re: Electron apps cannot be submitted to the Apple store

#377

Earlier quoted context omitted.

I would assume that a quick grep through your project for the symbols mentioned would tell you where the issue is.

it would but it wouldn't solve the problem. This would require the developer to modify electron and basically run his own branch. It would then make your package possibly acceptable (but attention here: as Apple clearly stated keeping too use private APIs can get you banned so if you miss something you can lose your access to the apple store) leaving however everyone else using electron with the same problem. So the…

> So the solution has to come from Electron.

And until it does, developers should not use Electron.

There's a number of reasons why I refuse to use Electon-based apps, and this is one of them.

Re: Electron apps cannot be submitted to the Apple store

#378

Earlier quoted context omitted.

Hi my name is node_modules have you met me? If you invite me to a party I bring my 500 closest friends as my plus one! I just looked at the node_modules folder for a project that runs user configured code when your imap server gets a new mail via imap idle. It's called imapnotify and inside its node_modules dir I see it pulls in 549 js files. The majority are under 100 lines per file dozens are between 1 and 30. Cutt…

> If you invite me to a party I bring my 500 closest friends as my plus one! That sort of thing is a big red flag that perhaps you should reconsider using that package. But even if you do use it, that in no way reduces the fact that it's your responsibility to know what you're shipping.

That is every javascript package ever incidentally. Do you have an alternative suggestion as far as connecting to an imap server and responding to events? Not a library to write such a thing but an actual implementation.

Re: Electron apps cannot be submitted to the Apple store

#379

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.

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.

Re: Electron apps cannot be submitted to the Apple store

#380

Earlier quoted context omitted.

> If you invite me to a party I bring my 500 closest friends as my plus one! That sort of thing is a big red flag that perhaps you should reconsider using that package. But even if you do use it, that in no way reduces the fact that it's your responsibility to know what you're shipping.

That is every javascript package ever incidentally. Do you have an alternative suggestion as far as connecting to an imap server and responding to events? Not a library to write such a thing but an actual implementation.

No, I don't, but even if there are no such alternate packages, that doesn't mean it's OK to use one that you can't sufficiently understand.

If you can't find an acceptable package, then I'd absolutely recommend writing that functionality yourself. connecting to an IMAP server and responding to events aren't complicated tasks, after all.

Post reply on HN