Earlier quoted context omitted.
Hence why you should audit your third-party dependencies in cases like these.
I suspect that most devs don't do that. I can't imagine finding the time fir that.
Electron apps cannot be submitted to the Apple store
381–390 of 441 posts
Re: Electron apps cannot be submitted to the Apple store
#382Earlier quoted context omitted.
How short are memories. I remember how Microsoft was vilified for supposedly having secret Windows APIs that allowed Microsoft apps to get better performance. That was mostly made up and even if such APIs existed, any program could have used it. Even at the height of corporate arrogance Microsoft didn't dream of banning developers for using undocumented APIs. Apple seems intent on becoming more evil than Microsoft ev…
There are no such things as “secret APIs”. By definition an Application Programmers Interface is the vendors promise to other developers that when you call it, it will have well defined results no matter if the implementation changes. Every modern programming environment has the concept of public and private methods either enforced by the language (with hacks to get around it) or by convention (prepending a function…
I don't know what Apple means by "secret APIs", but I'm assuming they mean "undocumented APIs". Those are certainly real things that commonly exist.
> By definition an Application Programmers Interface is the vendors promise to other developers that when you call it
Yes, but those "other developers" may be other engineers in the same company. The APIs they use are still APIs, but are not intended for use by anyone outside the company.
Re: Electron apps cannot be submitted to the Apple store
#383As 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…
What a ridiculous question... why would you not want the option to download Electron apps through the app store?
Re: Electron apps cannot be submitted to the Apple store
#384On one hand I am not fond of Apple in general at all. On the other hand when I see developers using Electron as a GUI layer I think it is pure insanity. It is an absolute resource and performance hog that in my opinion has no place outside of browsers context.
I'm an old dinosaur who used to do GUI development way back, and while I completely agree that Electron is a beast, I also haven't seen almost reasonably cross platform app toolkit that isn't either ugly, or worse than Electron. So what are the options I am missing?
1) wxWidgets
2) QT
3) Delphi with Firemonkey
4) Lazarus
Whole bunch of other which you are welcome to Google and explore
Also it depends on your type of application but I am seriously considering using 3D rendering library as a basis for multiplatform GUI. This one does not look too native but it looks like it may be the leanest, fastest option. This would require some groundwork first.
Re: Electron apps cannot be submitted to the Apple store
#385Earlier quoted context omitted.
There are no such things as “secret APIs”. By definition an Application Programmers Interface is the vendors promise to other developers that when you call it, it will have well defined results no matter if the implementation changes. Every modern programming environment has the concept of public and private methods either enforced by the language (with hacks to get around it) or by convention (prepending a function…
> There are no such things as “secret APIs”. I don't know what Apple means by "secret APIs", but I'm assuming they mean "undocumented APIs". Those are certainly real things that commonly exist. > By definition an Application Programmers Interface is the vendors promise to other developers that when you call it Yes, but those "other developers" may be other engineers in the same company. The APIs they use are still AP…
Say Team A within Apple creates a module that is only to be used by Team B and C. Then Teams D creates a module that depends on Team A and B and they release a public API.
Team A should publish an internal documentation and Teams B and C should also not use methods that were not documented by Team A and Team A shouldn’t follow standard semantic versioning. If Teams B and C need some functionality they should inform Team A.
The same goes for Teams B and C. Also, Apple controls the release schedule for any internal teams. If they want to move to ARM tomorrow they can coordinate it within Apple without breaking any third party apps. The only team that has any responsibility to not break external developers is Team D.
If Apple starts allowing external developers to use private functions now their release schedule is tied to when enough major third party developers update their documentation.
Amazon is even a better example. They have a policy that everything should be a service internally and no team should reach “inside” of the implementation of another team.
Re: Electron apps cannot be submitted to the Apple store
#386Earlier quoted context omitted.
No, it’s almost certainly just a search for strings and looking through the symbol table.
That would be very easy to work around with dlopen and some string obfuscation. It's probably a bit more involved.
Re: Electron apps cannot be submitted to the Apple store
#387Earlier quoted context omitted.
Another interesting question is how Chrome itself gets approved for the Apple web store then, right? https://apps.apple.com/us/app/google-chrome/id535886823
That's the mobile version of chrome, which as required of all browsers on iOS, is using the Safari web renderer under the hood.
Is the desktop version of chrome not in the app store? Maybe not.
Re: Electron apps cannot be submitted to the Apple store
#388Earlier quoted context omitted.
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.
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 half dozen different ways to define a string that you actively had to convert back and forth between just to call various APIs and that was back in the early 2000s. I’m sure it’s gotten worse since then.
You don’t have to make developers happy. Developers will go to where the users are. Where is all of the development energy these days? It’s definitely not on Windows. What makes developers “happy” are paying customers.
Microsoft has been trying and failing for years to produce a viable ARM laptops. Partially because of an insistence on backwards compatibility and all of the code bloat that entails. Apple transitioned the Mac platform four times since 1984 and created four successful ARM based platforms in the last decade.
Re: Electron apps cannot be submitted to the Apple store
#389Earlier quoted context omitted.
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.
Re: Electron apps cannot be submitted to the Apple store
#390As 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…
The memory usage issue is insane. My work laptop is regularly at 20GB memory usage partly because all of these electron apps take up 300mb to sit in the background and show me a notification every now and then. Its hugely refreshing to see my notes app (Zim Wiki) using 19mb of ram while being super fast and providing a huge amount of utility.