201–210 of 441 posts
Earlier quoted context omitted.
Yep. If you can't avoid Apple's stores then make damn sure you fall in line as they effectively own you.
You can choose to distribute outside of the Mac App Store on macOS.
Unfortunately if you're popular they seem to let you bend the rules. AFAICT Slack has not been rejected and I believe Slack is electron based.
The issue is in Chromium. I have no idea if removing the API usage will be easy or hard but it's been
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…
Earlier quoted context omitted.
>Why the dislike, you ask? Nobody is asking that, there's a crowd in here that restates the same three points about memory, performance and native UI about once a week. I dislike waste, I have written assembly code for tiny processors. And yet, I run several Electron apps on my 8gb 2013 Macbook Air and it runs fine, especially VSCode. I am picking that over my previous choice which was native (vim), because I think i…
> there's a crowd in here that restates the same three points about memory, performance and native UI about once a week. Where else would users complain about undesirable developer trends if not on a developers' community?
For the record, I do think there are problems with Electron, just not the ones usually mentioned. A big (huge!) problem in my opinion is that two windows can't share JS context. It's the reason why VSCode is way behind in multi-monitor support for instance.
Earlier quoted context omitted.
Code signing does not do what you apparently think it does. They can’t block it unless it’s a windows store app/universal app, which is sandboxed. And that’s exactly what they do for those apps. Tim Sweeney ranted about this quite vocally!
I never said code signing DID do that. Of course it didn't, there were no secret high performance Microsoft only APIs in the first place. I said it COULD have easily been used to do that. E.g. make special API/syscall to unlock restricted APIs, Windows checks the signing status of the executable making the call and only grants permissions if it is signed by MS. It's actually also not true that Microsoft only ever blo…
This is how iOS works, FYI.
This is absolutely insane. Apple could learn a lot from Microsoft of how to treat developers. God i miss Steve Ballmer
The basic concept isn't too disturbing; Apple packages private APIs that have no guaranteed behavior or expectation of support. If you depend on those APIs, it's very possible that your app will break in a future OS update. This is conceptually no different than calling something in the sun.* packages in Java. For years it was ok, and then ... it wasn't. This, however, is draconian: > Continuing to use or conceal non…
> I did write back to Apple trying to explain that I am using Electron and I can't really change any of these public-framework usage Yeah. So? By linking a framework that's using private APIs, this becomes your problem now. And Electron's problem, by extension. Go bug them, not Apple.
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…
The prehistory is that developers for the Apple ][ had access to third party documentation, and made extensive use of unofficial system variables and entry points. The result was that it became impossible for Apple to update their own system without breaking popular apps and getting blamed for doing so. It turned Apple ][ technology into a dead end.
The Mac was intended to be a much more tightly controlled developer environment. And it came out at a time when there was still a lot of debate over the right way to develop a computing platform.
IBM had a different approach, which was to make things more open like the Apple ][, and they paid the price for it. For instance, a lot of the weird limitations of the IBM PC were caused by developers bit-banging hardware registers and video memory rather than going through "official" BIOS calls that were less efficient.
I don't personally know the right answer, but this is just the history as I recall it. At the time I preferred the IBM approach, because I could do some friendly bit banging and get stuff done, but my programs were mostly for a severely limited audience and lifespan. Today I try to do things in a way that insulates me from knowing anything about the platform that I'm using.