Apple weigert Electron-apps in de App Store voor macOS wegens private api's

Diverse ontwikkelaars melden dat Apple hun app of app-update voor macOS heeft geweigerd omdat ze gebouwd zijn met Electron. Hierdoor maken de apps gebruik van private api’s, wat indruist tegen de Mac App Store-regels. Tot nu toe werden Electron-apps gewoon goedgekeurd.

De regels van de Mac App Store voor macOS zijn dat ontwikkelaars uitsluitend apps mogen indienen die leunen op openbare api’s en api’s die door Apple zijn gedocumenteerd. Toepassingen die gebouwd zijn met private api’s worden tijdens het validatieproces automatisch geblokkeerd.

Volgens MacGeneration zijn veel ontwikkelaars zich echter niet bewust van het feit dat ze private api’s gebruiken. Het gaat om de groep programmeurs die gebruikmaakt van Electron, het framework van GitHub om crossplatformtoepassingen te ontwikkelen voor macOS, Windows en Linux aan de hand van JavaScript, html en css. Apple heeft ontwikkelaars nooit aangemoedigd om met Electron te werken, maar de apps werden tot nu toe wel probleemloos goedgekeurd. Een van de bekendste voorbeelden hiervan is de samenwerkingstool Slack.

Het is nog niet duidelijk waarom Apple ingediende Electron-apps plots weigert. Mogelijk gaat het om aangescherpte maatregelen met betrekking tot private api's, waardoor de toepassingen tijdens het verificatieproces worden geblokkeerd. Een andere mogelijkheid is dat Apple voortaan voorrang wil geven aan zogeheten Catalyst-apps, een nieuwe functie van macOS Catalina 10.15 die het mogelijk maakt om iOS-apps om te bouwen naar programma’s voor de Mac.

Reacties (66)

[Mavamaarten]

Het is inderdaad zo dat Electron private API's gebruikt. Meer informatie vind je hier: https://github.com/electron/electron/issues/20027
Apple heeft blijkbaar de API-blacklist aangepast, waardoor er API's niet meer toegestaan zijn die dat vroeger wel waren. Dat zou een foutje zijn geweest van Apple, de rejected apps zijn ondertussen alweer toegestaan.

[R4gnax]

Het is inderdaad zo dat Electron private API's gebruikt. Meer informatie vind je hier: https://github.com/electron/electron/issues/20027
Apple heeft blijkbaar de API-blacklist aangepast, waardoor er API's niet meer toegestaan zijn die dat vroeger wel waren. Dat zou een foutje zijn geweest van Apple, de rejected apps zijn ondertussen alweer toegestaan.

Dat is niet wat er in die issue op de issue tracker staat. Rejected apps zijn nog steeds rejected. Er zijn alleen oudere apps waar nog geen update op doorgevoerd is, en die nipt aan de dans ontsnapt zijn. Bijv. Slack.

De 'private APIs' die Apple aan de black list toegevoegd heeft betreffen overigens allemaal de kern-API calls die nodig zijn om de Core Animations API te gebruiken. Apple staat niet toe dat andere ontwikkelaars dan zij zelf deze gebruiken, en de reden daarvoor is simpel als je dit artikel leest: https://mozillagfx.wordpr...acos-with-core-animation/

Omdat het enorme performance en batterij-winst oplevert gebruiken tegenwoordig vrijwel alle browsers op MacOS deze APIs. Dus ook Chrome; dus ook Chromium; dus ook Electron.
Het is gewoon een ordinaire manier om Electron en alternatieve browsers op MacOS vleugel-lam te maken. Meer pushen van locked-platform Store apps voor MacOS wat Apple wil positioneren als beter alternatief? Stukje promoten van Safari tov andere browsers? Gewoon terraforming van hun eigen interne markt om de hekken te sluiten en de muren van de walled garden weer op te metselen.

In die zin niet anders dan dat het jaren geleden bewust onmogelijk werd gemaakt voor iOS web-views om de optimizing JS compiler te gebruiken, waardoor hybrid web-apps zoals op Cordova gebouwd kunnen worden geforceerd werden om puur in interpreter mode te draaien op nog niet de helft van de performance. Dat alles ter meerdere ere en glorie en sterke promotie van native apps in de app store, om vendor/platform lock-in te creeëren. (Als ontwikkelaars het hele budget moeten besteden aan het populaire Apple segment, wordt de Android versie van de applicatie achterwege gelaten.)

Gewoon; omdat ze de platformhouder zijn, en er mee weg kunnen komen.
Wordt eens hoog tijd dat er een mooie anti-trust zaak tegen Apple's wanpraktijken komt.

[Reactie gewijzigd door R4gnax op 22 juli 2024 16:09]

[Mavamaarten]

Misschien had ik er iets te snel over gelezen, maar deze comment beweert iets anders: https://github.com/electr...27#issuecomment-527027676

[snerual-bre]

Wat is precies het verschil tussen een private api en een public api in deze context? Wat valt bijvoorbeeld onder een private api?

[RobinJ1995]

Een besturingssysteem stelt APIs ter beschikking die het mogelijk maken om software te bouwen voor dat besturingssysteem en hiermee te integreren. Een private API in dit geval zou een API zijn die er wel in zit, maar die nergens gedocumenteerd staat en dus eigenlijk volgens Apple door niemand gebruikt hoort te worden. Denk aan APIs om de stroomtoevoer naar bepaalde componenten te regelen, bijvoorbeeld. Dat zal het in dit geval niet zijn, maar dat zijn APIs die het besturingssysteem mogelijk heeft maar waarvan je niet wil dat derde partijen ze gaan gebruiken.

[SuperDre]

Ik denk eerder dat het bij 'private API' hier gaat om API's van thirdparty.. En deze electron based apps hebben dus nog een extra framework nodig wat niet rechtstreeks via de MacOS app store geinstalleerd wordt. Ze willen dus graag apps in hun MacOS appstore die niet afhankelijk zijn van 3rd party frameworks die nog eerst geinstalleerd moeten worden.

[RobinJ1995]

Your app app links against the following non-public framework(s):
CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

Nope, gaat wel effectief om OS APIs

(Thanks, @xvilo)

[Reactie gewijzigd door RobinJ1995 op 22 juli 2024 16:09]

[bigbadbull]

[...]
Your app app links against the following non-public framework(s):

Nope, gaat wel effectief om OS APIs

(Thanks, @xvilo)

hoewel de term private-api fetieleijk het zelfde betekend als non-publicapi, vind ik de laatste term veeeel duidelijker.
zoals de verwarring hierboven zijnhet zelf gemaakte (3rd party) of zijn het os-interne.

[ikweethetbeter]

Daarbij kan Apple bij een upgrade besluiten om private api's niet mee te nemen zonder dat te communiceren.

[MacWolf]

Het zijn ook soms APIs die nog niet definitief zijn. Zo kan Apple eerst in eigen apps uitvogelen hoe een API goed opgezet kan worden en eventueel aanpassen, tot de API in zoverre intern getest is dat deze publiekelijk gebruikt kan worden.

In de tabel op deze pagina kan je een aantal private APIs zien die in de loop van de tijd publiek zijn geworden. Voorbeelden daarvan zijn:
- CoreTelephony
- JavaScriptCore
- MapKit
- MessageUI
- WebKit

[- peter -]

De vraag is dan of Electron under de hood idd dan private APIs gebruikt. Ben benieuwd.

[Xerxes249]

List of private APIs detected:

_fileport_makefd
_fileport_makeport
CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

[bruinebeer]

Electron is een combinatie van NodeJS en Chrome. Beiden niet installeerbaar via de app store zelf.

Ik denk dat ze ontwikkelaars hiermee willen pushen om hun ecosysteem te gebruiken (Xcode, swift, ...).

Vreemde move aangezien webbased apps juist aan het opkomen zijn, elektron apps en ook PWA's.

[Travelan]

Dit is pure speculatie en tevens fout. Electron gebruikt API’s die Apple niet heeft vrijgegeven en zijn daarom niet toegestaan in de App Store. Dat heeft verschillende redenen, maar het weigeren van Chromium/Node is daar zeker geen van. Als de code die de private API’s gebruikt wordt aangepast, zal de app gewoon weer toegelaten worden.

[MacWolf]

Ik denk dat ze ontwikkelaars hiermee willen pushen om hun ecosysteem te gebruiken (Xcode, swift, …).

Ik denk eerder dat Apple wil voorkomen dat apps instabiel worden. Voor wat betreft Private APIs zou Apple in principe vrij moeten zijn deze op ieder moment te wijzigen. De externe ontwikkelaar kan er niet vanuit gaan dat private APIs nu en in de toekomst hetzelfde zullen werken. Mocht Apple op een bepaald moment besluiten om bijvoorbeeld functionaliteit van CAContext of CALayerHost (beide doen iets met animaties, want onderdeel van het CoreAnimation framework) te wijzigen, zou dat in dit geval mogelijk crashes kunnen veroorzaken in een Electron app. Dat is geen goede gebruikerservaring.

[Reactie gewijzigd door MacWolf op 22 juli 2024 16:09]

[Mrten]

Lijkt me wel, anders zouden ze het niet weigeren.

[cracking cloud]

Electron is toch super traag?

[Gamebuster]

Electron is helemaal niet traag Electron is gewoon een dunne wrapper dat web-applicaties kan draaien, vergelijkbaar als een lichtgewicht browser.

De web applicatie die je daarin draait kan natuurlijk wel traag zijn, maar zo kunnen ook "normale" applicaties traag zijn.

Als tegenhanger zijn electron apps goedkoop te ontwikkelen en cross-platform, en dat kunnen we alleen maar aanmoedigen toch?

[Reactie gewijzigd door Gamebuster op 22 juli 2024 16:09]

[johnbetonschaar]

Als tegenhanger zijn electron apps goedkoop te ontwikkelen en cross-platform, en dat kunnen we alleen maar aanmoedigen toch?

Als ontwikkelaar: misschien, als eindgebruiker: twijfelachtig.

Als eindgebruiker interesseert het me weinig hoe makkelijk of goedkoop het was om een bepaald stuk software te maken, en al helemaal niet of het cross-platform is. Als het maar beschikbaar is op het platform dat ik zelf gebruik, en voor een prijs die ik er voor over heb. De rest is voor mij niet relevant.

Dat bedrijven er graag voor kiezen om een cross-platform applicatie te bouwen omdat dat makkelijker en goedkoper is snap ik best, maar doorgaans betekent dat wel dat de applicatie slecht integreert, bepaalde specifieke functies van het platform niet gebruikt, meestal minder efficient is, de UI non-standard is, etc. enz. Allemaal nadelen voor de eindgebruiker. Dus 'dat kunnen we alleen maar aanmoedigen'? Wat mij betreft niet.

Specifiek over Electron apps: het eindresultaat van zulke applicaties is doorgaans wel degelijk traag, log en gebruikt meer geheugen dan nodig. Een complete Chrome omgeving opstarten om een stom chatvenstertje te (denk aan Slack) te kunnen laten zien is wat mij betreft gewoon absurd.

[dmjdebruin]

Ik ben anders als gebruiker super blij dat MS teams / outlook, chrome, firefox en lastpass om een paar voorbeelden te gebruiken op al mijn platformen beschikbaar zijn en goed integreren.

[klakkie.57th]

Maar die hadden net zo goed geschreven kunnen worden in een geoptimaliseerd framework.

[johnbetonschaar]

Sterker nog, met uitzondering van MS teams zijn die applicaties ook gewoon allemaal native. Van MS teams weet ik het niet zeker, maar ik verdenk inderdaad dat dat een Electron-achtige applicatie is want het is zo traag als de neten en niks aan de UI integreert met de rest van het systeem.

Maargoed mijn punt was niet dat cross-platform of Electron per definitie slecht is, ik gebruik ook VS code en dat is gewoon een nuttige Electron app die redelijk goed werkt en anders waarschijnlijk nooit gemaakt was. Maar van die constatering naar 'want cross-platform dat kun je alleen maar aanmoedigen toch' als dat betekent dat al die applicaties werken als de typische Electon app: nee dank je.

Overigens zal waarschijnlijk een volkomen verwaarloosbaar percentage van alle gebruikers van die cross platform applicaties ze ook daadwerkelijk op meerdere platforms tegelijk gebruiken. Wat is dan nog het voordeel van de eindgebruiker dat de applicatie ook op bijvoorbeeld Linux werkt?

[mjz2cool]

Overigens zal waarschijnlijk een volkomen verwaarloosbaar percentage van alle gebruikers van die cross platform applicaties ze ook daadwerkelijk op meerdere platforms tegelijk gebruiken. Wat is dan nog het voordeel van de eindgebruiker dat de applicatie ook op bijvoorbeeld Linux werkt?

Het voordeel is dat er dan sneller een applicatie voor bijvoorbeeld Linux wordt ontwikkeld.

[R4gnax]

Van MS teams weet ik het niet zeker, maar ik verdenk inderdaad dat dat een Electron-achtige applicatie is want het is zo traag als de neten en niks aan de UI integreert met de rest van het systeem.

Het is Electron.
Dankzij een fubar van Microsoft's zijde heb ik al eens korte tijd op mijn workstation een update gehad die de debug opties van Electron in het right-click context menu in de systeem-tray gooiden.
Naast andere 'handige' opties zoals van het release update kanaal naar interne beta kanalen over kunnen schakelen of handmatig instructies op te zetten richting een voip backend...

[Xalephsis]

Die redenatie snap ik niet; minder kosten = meer tijd voor leuke features? Ik zie daar dus geen verband in.

Als ontwikkelaar of bedrijf dien je gewoon te zorgen dat je applicatie goed functioneert. Juist die Electron apps zijn echt een draak om te draaien, dat zijn de grootste memory hogs voor een systeem!

Als je dan toch 'leuke features' wil bouwen, zorg dan dat zo'n simpele app als Slack binnen 1 seconde klaar is voor gebruik, of dat ik niet hoef te wachten met een chat openen als ik op een persoon / team klik.

Begrijp me niet verkeerd, het is supppperr leuk dat ik de kleurtjes kan aanpassen, of gifjes kunt inladen, maar als dat betekent dat die applicatie vervolgens soms tot 1Gb aan RAM loopt te vreten.. meh dan sla ik 'm wel over.

Jezus, wat zijn die Electron apps slecht zeg..

[Xalephsis]

Je hebt dus 8 Chrome vensters open en je zit op meer da 8GB ram.. m.a.w. je hebt meer dan 1GB ram per venster open.. Ik ga er voor het gemak even vanuit dat je 2 VMs 2GB aan ram vreten?

Jezus, in welk tijdperk leven we dat een simpele browser venster 1GB aan ram vreet?

Ik heb hier 32GB aan ram en ik zit met enige regelmaat op 20GB ram aan druk, waar meer dan 14GB weg komt uit mijn browser gerelateerde apps. Alle andere apps (Jetbrains, CLI's, VMs, DB tools ) vreten 6GB ram.

[TheBoneJarmer]

Je hebt dus 8 Chrome vensters open en je zit op meer da 8GB ram.. m.a.w. je hebt meer dan 1GB ram per venster open.. Ik ga er voor het gemak even vanuit dat je 2 VMs 2GB aan ram vreten?

Ik heb nooit iets gezegd over Chrome. Laat staan 8 GB ram vebruik voor 8 vensters. Ik gebruik Firefox en nee, die vensters gebruiken geen 1gb ram per venster. Neemt niet weg dat ze allemaal volstaan met tabbladen. Ik draai een Ubuntu Desktop en Windows Server als VM. Waarbij de Ubuntu 2 GB ram ter beschikking heeft en de Windows Server 4 GB.

Die vensters van VS Code gebruiken daar in tegen zo'n 4-5 GB ram als ze staan te debuggen met zijn allen. Indien niet merk ik niet eens dat ze openstaan. Dat jij met 32 gig zo'n machtig vebruik hebt vind ik echt wonderswaardig. Hadden wij dat maar voor onze servers joh

[Xalephsis]

Ik wou dat het niet nodig was, maar met 16GB ram merk ik snel al dat het op de swap komt, dat is de enige reden, het is eigenlijk te zot dat het nodig is.. Maar goed, ik wil zeker niet dat mijn PC mij niet kan bijbenen, dus ik spec alles wel zodat de PC nooit een bottleneck kan zijn. Nu moet ik zeggen dat VS Code het ook nog redelijk netjes doet qua geheugen, hoe dat mogelijk is, geen idee, misschien dat het komt omdat er een groot team achter zit die nog af en toe eens benchmarkt hoe veel hun processen vragen en daar voor optimaliseren, Microsoft kennende willen ze dat wel een klein beetje in de gaten houden

[GekkePrutser]

Outlook, Chrome, Firefox zijn geen electron applicaties dus slecht voorbeeld. Teams en lastpass inderdaad wel.

[Creesch]

Als eindgebruiker interesseert het me weinig hoe makkelijk of goedkoop het was om een bepaald stuk software te maken, en al helemaal niet of het cross-platform is. Als het maar beschikbaar is op het platform dat ik zelf gebruik, en voor een prijs die ik er voor over heb. De rest is voor mij niet relevant.

Hier spreek je jezelf enigszins tegen, de eerste twee argumenten waar je zegt weinig interesse in te hebben zijn wel van invloed op het beschikbaar zijn van applicaties op meerdere platformen en dus ook jou platform. Met native code is het zo dat een ontwikkelaar voor elk platform een aparte code base moet onderhouden, programmeurs beschikbaar hebben, etc. Dit zorgt ook vaak voor een gefragmenteerde gebruikerservaring aangezien de diverse versies op diverse platformen enigszins anders werken en niet altijd gelijk lopen qua features.

Met een framework zoals electron speelt dat dus allemaal niet en zijn updates voor alle gebruikers van alle platformen tegelijk beschikbaar. Bovendien kan je dus je hele team dedicated inzetten op één applicatie en dus ook focussen op dat aspect.

Heel veel van de applicaties die nu op macOS beschikbaar zijn zouden dat wellicht niet zijn geweest zonder electron. Sterker nog, ik durf te stellen dat sommige applicaties niet zouden bestaan zonder electron aangezien kleine start-ups niet de middelen hebben om een applicatie native op meerdere platformen neer te zetten wat wel noodzakelijk is voor het succes van de applicatie.

Neemt niet weg dat (zeker slecht gemaakte) electron applicaties frustrerend traag en groot kunnen zijn. Daar tegenover staan tools die het verdomd goed doen. Zoals Visual Studio Code die ook electron is gebaseerd en (voor mij iig) op diverse machines en platformen een zeer prettige en consistente gebruikerservaring weet te bieden.

[Reactie gewijzigd door Creesch op 22 juli 2024 16:09]

[Verwijderd]

1000% mee eens. Pragmatisch gesproken is Electron wel degelijk traag. En niet een beetje traag. Stroperig, hoge latency e.d. Het verschil met een klassieke desktop app geschreven in C/C++ is dag en nacht.

Veel gebruikers weten niet beter en denken dat de typische Electron performance normaal is, slechte performance is genormaliseerd, men weet niet beter.

[Blaise]

Electron is echt géén dunne wrapper. Electron dupliceert een groot deel van Chrome waardoor de simpelste Electron app al 120 MB is. Het geheugengebruik is ook fors vergeleken met native apps doordat HTML, CSS, JS vrijwel altijd langzamer zijn dan een native app.

Desalnietemin ben ik blij met Electron omdat het er wel voor zorgt dat apps op alle platformen beschikbaar zijn met volledige functionaliteit.

[Reactie gewijzigd door Blaise op 22 juli 2024 16:09]

[Xalephsis]

Helemaal mee eens. Het is echt een draak van een platform, die zwaar geoptimaliseerd dient te worden. De meeste apps die er nu op draaien en veelgebruikt zijn, zijn echt memory hogs. Een standaard app draaiende maken kost al 120MB, zodra je wat features toe gaat voegen, zit je echter al snel over de 200MB. Zodra je ook nog eens meerdere 'tabs' gaat draaien, groeit het extreem snel. Zo heb ik Slack wel eens over de 800MB gehad. Voor een simpel chat programma..

Het is leuk hoor, dat je je software op meerdere platformen draaiende kunt maken door middel van 1 framework, maar niet als dat zo ontiegelijk veel resources gaat kosten op die verschillende platformen, los van het feit dat de UI vaak ook 'sluggish' aanvoelt, ondanks een redelijk zware PC/Mac die ik hier heb staan. Nee, doe mij maar native dan.

[Maverick2001]

Helemaal eens! Ik Juich deze toepassing ook toe. Het maakt het een stuk eenvoudiger apps te ontwikkelen voor zowel windows als OSX. Electron is idd niet zwaar / traag maar de ene applicatie leent zich er wel beter voor t.o.v. een andere. Zo gebruik ik bijvoorbeeld Atom en dat wordt met een paar piugins toch wel vrij snel traag.

[dakka]

Vscode, bijna hetzelfde als atom, draait ook op electron en daar heb ik nooit last als ik tig plugins nog aan heb staan van andere projecten

[Maverick2001]

Bedankt voor de tip. Ik zal Vscode ook een kans geven, ben wel benieuwd. Al ben ik eigenlijk met spanning aan het wachten op Nova van Panic.

[Jerie]

Als je geen volwaardige IDE nodig hebt, kan ik Sublime Text aanraden. Die heeft zat plugins, maar is toch gebruikersvriendelijk en makkelijk. Zelf gebruik ik Sublime Text en Vim.

[Maverick2001]

Bedankt voor je tip. Heb ik we geprobeerd en ik geloof wel dat het een top programma is maar kan er niet aan wennen. Hou het eerst op Atom icm Coda (straks Nova).

[Jerie]

Electron is idd niet zwaar / traag

Dit is altijd relatief. Zwaar tov wat? Traag tov wat? Latency van hardware is van hierbij ook van belang, en die is er niet op vooruit gegaan:

https://danluu.com/input-lag/

https://danluu.com/keyboard-latency/

Vscode, bijna hetzelfde als atom, draait ook op electron en daar heb ik nooit last als ik tig plugins nog aan heb staan van andere projecten

De latency ligt met Vscode en Atom gewoonweg vele malen hoger dan Gvim (heb ik het niet eens over Vi en Vim).

Bron, o.a: https://pavelfatin.com/typing-with-pleasure/ reproduceren kan met https://github.com/pavelfatin/typometer

[WoutervOorschot]

Je draait een browser en webserver bovenop je benodigde code, er zijn betere alternatieven voor cross platform (xamarin), en het is wel degelijk traag (zeker op windows, waar bijvoorbeeld touch- en touchpad invoer erg langzaam is door chromium).

[klakkie.57th]

Hmmm , ik verkies toch geoptimaliseerde applicaties. Dit soort “truukjes” gaat steeds ten koste van performance.

[Gamebuster]

Makkelijk te zeggen als jij niet de rekening betaalt voor de applicatie

Als je 2 offertes eruit gooit, 1 voor strak geoptimaliseerde native app, en 1 2x zo goedkoop in Electron die misschien net wat trager is (maar wel te optimaliseren is met wat trucjes), wat denk je dat jouw klant gaat kiezen?

Ik weet wel wat onze klanten gaan kiezen hoor...

[klakkie.57th]

't ja ik kom uit het assembler tijdperk... 16KB was alles wat we hadden

[Gamebuster]

Ik weet niet wat voor development jij doet dan, maar in mijn development wereld is software ontwikkeling immens duur en kan Electron een hoop geld besparen vergeleken een native app per platform.

Electron is even traag als de web applicatie die erin draait, en daarin valt immens veel te optimaliseren. Met de juiste webpack instellingen kan je compacte, snel te laden bundles maken om snel een interactief scherm te tonen aan je gebruiker, waarna je op de achtergrond de rest vd applicatie inlaadt. Dit combineer je met een vlot API & een lokale cache en je kan gewoon hele vlotte applicaties bouwen, zonder dat je meerdere versies moet gaan bouwen & supporten.

Als bonus is het allemaal webtechnologie, dus is het relatief goedkoop kleine wijzigingen te maken.

Gezien jouw sterke meningen en de ervaringen vermeldt in je profiel kan ik wel concluderen dat we werkzaam zijn in een andere omgeving met andere prioriteiten, en dat is prima. Blijf jij lekker leuke native apps maken, dan blijf ik stomme web meuk maken. Voor beiden is een legitieme use-case.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 16:09]

[Verwijderd]

Ik weet niet wat voor development jij doet dan, maar in mijn development wereld is software ontwikkeling immens duur en kan Electron een hoop geld besparen vergeleken een native app per platform.

Ik ben Serverside Swift Developer. Ik bouw backends, websites en RESTAPI's met Swift. Ik werk nu aan een Firebase alternative met serverside machine learning compleet geschreven in Swift en (En eigen leerplatform, waar je grappig genoeg wel Electron courses gaan aanbieden ). (Om even te antwoorden op je eerste zin niet om een discussie over wie beter is of wat beter is te ontketenen.) (Ben trouwens ook IOS en macOS Developer als ik er de tijd voor heb)

Development is in elke development sectie duur. Of je nu web developer bent of Native iOS developer het ontwikkelen van software kost altijd geld. Ik vind alleen dat "geld" en de gemakzucht van bedrijven geen
excuus om Electron te gebruiken.

Electron is even traag als de web applicatie die erin draait, en daarin valt immens veel te optimaliseren. Met de juiste webpack instellingen kan je compacte, snel te laden bundles maken om snel een interactief scherm te tonen aan je gebruiker, waarna je op de achtergrond de rest vd applicatie inlaadt. Dit combineer je met een vlot API & een lokale cache en je kan gewoon hele vlotte applicaties bouwen, zonder dat je meerdere versies moet gaan bouwen & supporten.

Hier leg jij dus al een van de grootste pijnpunten van Electron blood. Optimalisatie. Waar trouwens Electron zelf ook gewoon optimalisaties mist is t met de applicaties die erin draaien vaak ook gewoon veel mis. Er zijn gewoon een berg Electron applicaties die gewoon bagger zijn. De enige applicatie die ik wel goed vind met Electron is VSC.

Kijk als je perse goedkoop of gemakzuchtig wilt ontwikkelen kies dan React Native, Flutter of Xamarin. In mijn optiek lost Electron geen enkel probleem op en zijn de genoemde alternatieven gewoon stuk beter.

Als bonus is het allemaal webtechnologie, dus is het relatief goedkoop kleine wijzigingen te maken.

Ik ontken dit ook niet. Ik zeg alleen dat applicaties in Electron vaak gewoon garbage zijn.

Gezien jouw sterke meningen en de ervaringen vermeldt in je profiel kan ik wel concluderen dat we werkzaam zijn in een andere omgeving met andere prioriteiten, en dat is prima. Blijf jij lekker leuke native apps maken, dan blijf ik stomme web meuk maken. Voor beiden is een legitieme use-case.

Waarom doe je nou zo Ik beweer helemaal nergens dat je web meuk ontwikkelt of dat web development überhaupt meuk is... Ik beweer alleen dat Electron in mijn optiek gewoon garbage is en in mijn optiek gewoon geen bestaansrecht zou mogen hebben. En deze mening is gebaseerd op 2 jaar werken voor een bedrijfje waar Electron werd gezien als de heilige graal. Zijn nu ook failliet gegaan maar bedoel ik vond t echt vreselijk om mee te werken.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:09]

[Tokkes]

Hoe niet? Omdat er platform-specifieke API calls worden gedaan. Zoals in Discord om je game te detecteren.

Mijn browser? Ik doe geen team workspaces/editing/voice chat/.... via webpaginas of andere web apps - mijn browser is om naar webpaginas te gaan, informatie op te zoeken, Google Music, een youtube filmpje, ... En daar hoef ik niet per 'applicatie' (website) 500 megabyte geheugen aan op te leveren.

Als die 'webpaginas' in Slack nog een hoop emoji en gif bevatten, evenals een lijst aan de zijkant met pakweg 50 channels in, staat dat ding toch flink overtoeren te draaien.

"electron slechts een kleine wrapper, lichter dan je browser" - het feit dat je een (vrij kale) chromium browser + een node.js backend hebt, is het per definitie al zwaarder dan een browser.

En ja. Zoveel onnodige zeik in je geheugen is kut als je er maar 8 GB te besteden hebt. Atom open met een paar projectjes, een paar browser tabs open, een slack open, je anti virus op de achtergrond, VPN client(s!), ondertussen file system cache - dat zorgt wel voor een aanslag op je IOPS want er gaat gegarandeerd geswapt worden.

Toegegeven, 8GB is te weinig voor mijn workload. Maar dan nog liever een kale 50MB IRC client dan een Slack waar mensen gretig afbeeldingen en emoji in rondstrooien.

[Reactie gewijzigd door Tokkes op 22 juli 2024 16:09]

[Murfy]

Electron op zich niet, Slack is een voorbeeld van een trage implementatie van Electron helaas

[Frikandel]

Slack heeft laatst een flinke performance update gehad en is naar mijn idee nu prima bruikbaar, en het is al helemaal een stuk beter als je meerdere workspaces hebt.

[Stefan22]

Jammer, ik ben zelf eigenlijk wel te spreken over Electron apps, aangezien deze vaak cross platform zijn en prima werken. Het enige wat er op aan te merken is, uit mijn eigen ervaring, is dat ze traag opstarten.

[Wokker]

Slack is volgens mij ook een elctron app. Wordt een mooi verhaal zo...

[dakka]

Electron word o.a gebruikt door discord, bunqdesktop, slack....

[laptopleon]

Ik lees dagelijks Apple-nieuwsberichten op Tweakers. Meestal over zaken die alleen een tech-site vermeldenswaardig vindt.

Ik had daarom op zijn minst ook een berichtje over de nieuwe streaming dienst Apple TV verwacht, die sinds 1 november online is.

Zelfs niet-tech-gespecialiseerde media zoals Ad.nl en de NOS gaan hier uitgebreid op in. Waarom Tweakers niet?

[noes]

Is dat ook een electron app?

[mjz2cool]

Je bedoelt een artikel zoals deze: nieuws: Apple TV+ start 1 november voor 5 euro per maand?

[WhatsappHack]

Interessant. Volgens mij zijn bijvoorbeeld WhatsApp en Signal ook Electron. Kan er niet rouwig om zijn om eerlijk te zijn, die dingen werken wel maar daar is alles ook mee gezegd.

[mjz2cool]

Whatsapp Web draait met Electron, de iOS app niet.