Discord biedt canary-macOS-versie app met native Apple M1-support

Gamingcommunicatie-app Discord heeft een canary-versie van zijn macOS-app uitgebracht die native op de M1-hardware van nieuwere Apple-hardware werkt. Gebruikers maken melding van sterk verbeterde prestaties met deze variant van de app.

Een Redditgebruiker ontdekte M1-support in deze versie van de app. Reageerders maken melding van verbeterde prestaties, wat ook hard nodig leek want men stelt onder andere dat 'iets doen in de app altijd met een vertraging van 1 seconde gebeurde'. Daarnaast werkt de Krisp-achtergrondgeluidsonderdrukking nu ook; dat deed het niet bij de middels Rosetta draaiende variant. De app in de browser draaien kan overigens ook, maar dat leidt bij Discord tot problemen met push-to-talk en schermen delen.

Discord is een communicatie-app gericht op gamers. De applicatie biedt de mogelijkheid om eigen 'servers' aan te maken, met tekst- en voicechatkanalen en een rechtensysteem voor gebruikers. Verder ondersteunt het schermen delen, ingame-overlays en bestanden versturen. Naast macOS is de app beschikbaar voor Windows, Linux, Android en iOS, maar hij kan ook draaien in browsers.

Softwareontwikkelaars moeten hun macOS-programma's herschrijven voor M1-hardware omdat deze op de ARM-architectuur draait. Apple's Rosetta-software kan hun code wel on-the-fly compatibel maken met de M1-variant van macOS, maar dat is inefficiënter. Dat uit zich in verslechterde prestaties en verkorte accuduur op M1-laptops.

Discord op macOS (beeld via Chip.de)

Reacties (50)

[graceful]

Ik ben recent nog “perongeluk” verbannen van Discord door het gebruik van de canary versie. Na week ruziën met de support kwam eruit dat door een technische fout ik tig tal requests naar hun back-end gedaan zou hebben. Dit werd geflagged en “ToS” overtreding zijn. Echt een aanrader voor je main-account..

Anyway, dit is niet meer dan een nieuwe electron build. Mensen klagen al een flinke tijd over dat discord nog een vrij oude versie gebruikt van electron, dit is ook voor de normale architecturen een probleem omdat de nieuwe versies van electron eenmaal efficiënter zijn.

Discord had in een van die tickets al aangegeven dat ze heel veel custom plugins gebouwd hebben en gebruiken, waardoor overstap naar nieuwste electron versie erg lastig is en tijdrovend. Er zullen dus wel een en ander aan features missen, waardoor het nog steeds een dev build is.

[Jerie]

Kun je dit niet gewoon native in een browser op een M1 draaien?

[Sandor_Clegane]

Is dit niet gewoon omdat Electron op M1 draait?

https://www.electronjs.org/blog/electron-11-0

[Mark_88]

Ja, geloof het wel, men zegt in de reacties in ieder geval dat het nog altijd een app is die op Electron draait, maar dat Discord ook daadwerkelijk deze bijgewerkte versie van Electron (of nieuwer) gebruikt en de app (zonder aankondiging) ook verspreid wordt, is het nieuws.

[Rinzwind]

Oftewel niet native, maar een webapp... native is wel aan deflatie onderhevig zeg... Electron wordt te pas en onpas gebruikt. Efficiëntie doet er niet meer toe blijkbaar.

[Anoniem: 1302638]

Het is een "webapp" omdat je de UI bouwt in tooling die je ook van webapps kent. Maar een taal als Javascript is niet beperkt tot het interweps en kan je ook op de commandline gebruiken als je dat wilt.

De term webapp, die is pas aan inflatie onderhevig.

[Sandor_Clegane]

Het is meer een "bespoke" browser die toevallig maar 1 pagina kan renderen.

[supersnathan94]

Maar een taal als Javascript is niet beperkt tot het interweps en kan je ook op de commandline gebruiken als je dat wilt

Maar dat wil je niet. Echt de enige reden om het te doen is dat je op dat moment geen tijd hebt om een andere taal te leren die daar wel echt voor bedoeld is (zoals Python, GOlang, Rust, Java, C).

Het kan zeker, maar je moet het niet willen.

[copi]

Off topic : Als ik het mij goed herinner: Java is ook niet helemaal native. Daar zit ook nog altijd een JIT compilatie slag tussen, zij het efficiënter dan vroeger.

[supersnathan94]

Dat maakt niet zoveel uit. Er is ook een mogelijkheid voor AOT compilation. Iets wat meer tijd kost, maar wel siginificant voordelen op kan leveren.

Daarnaast is het natuurlijk geheel afhankelijk van wat je wil doen, maar bijvoorbeeld wiskunde gaat bijvoorbeeld veel sneller met C. Tenminste, als je je nummers goed typeert. Leuk leesvoer hierover:

https://newbedev.com/how-...node-js-c-java-and-python

C is significant sneller met grote getallen (64-bit waarden)

Maar goed. Het kan. Maar met zoveel dingen die technisch kunnen is het belangrijk om je af te vragen of je het ook moet doen. En meestal is het antwoord ja, maar in dit geval zou ik toch zeggen: mja misschien niet.

[q-enf0rcer.1]

Hangt er vanaf wat je bouwt natuurlijk. Een next-gen videogame ga je niet bouwen met HTML, CSS en Javascript. Een simpele UI waar het renderen van een videostream het meest intensieve proces is kan dat prima. Grote voordeel is dat je dezelfde code kunt hergebruiken voor de browser versie en de app versie. Dat scheelt heel veel development kosten terwijl je op performance vlak niet heel veel inlevert. Als je weinig resources nodig hebt valt er tenslotte ook weinig te optimaliseren.

[supersnathan94]

Maar we hebben het hier over een commandline tool. Binnen die context is het dus absoluut niet per se de bedoeling dat er een webversie en een UI bovenop komen.

Dan ga je op performance (en heel wat andere zaken) wel wat inleveren.

Dus daarom. Het kan en als je moet kiezen tussen en hele nieuwe taal leren of ff snel iets in elkaar klussen, dan zou ik voor dat laatste gaan, maar neemt niet weg dat je het gewoon niet zou moeten willen aangezien de omliggende tooling daar bijvoorbeeld ook niet voor gemaakt is.

[Stoelpoot]

Electron-apps zijn niet enkel webapps omdat ze dezelfde tooling gebruiken, maar ook omdat ze op dezelfde render-engines werken. Under the hood gebruiken ze namelijk ook Chromium. Het zou een native app zijn als met Javascript, zonder tussenkomst van een zwaar gestripte browser, met het OS kon communiceren.

[Gropah]

Tja, het is en blijft een webapp, maar als de javascript engine voor x86 gecompileerd is, dan zal het wel een stuk minder presteren dan een ARM gecompileerde versie van diezelfde engine.

Ik ben het helemaal met je eens qua electron gebruik. Het is alleen wel heel handig voor bedrijven, omdat je daarmee je app bij (ongeveer) 1 codebase kan houden.

[Zezura]

Als je het goed doet dan kan je ook 1 codebase hebben voor je native-programma’s. Game-engines zijn bijvoorbeeld grotendeels gewoon 1 codebase. Oké links of rechts heb je een paar onderdelen die voor andere apparaten wel ander zijn. Maar dat heb je met electron op andere vlakken ook. Punt is electron verplaatst deze differentiatie naar een hoger niveau. In plaats van diep bij het OS verschillen te hebben, heb je ze meer highlevel.

[raidlabs]

Het is natuurlijk wel heel efficient bekeken vanuit vereiste resources.

[dvdmeer]

Vandaar dat iedereen ook klaagt over de performance van Microsoft Teams. Electron is blijkbaar killing voor de cpu en batterij

[Heroic_Nonsense]

Teams is daarnaast zelf ook nog eens erg infficient (zelfs voor een Electron-app).

Ook op platformen waar Electron native draait, is Teams traag en een memory- en batterij slurper.

[MrFax]

Dan vind ik het toch jammer dat Discord nog steeds niet overgegaan is op 64-bits Electron op Windows. Zo moeilijk kan het niet zijn toch?

[supersnathan94]

De grap is dat ze op macOS dat wel hebben.

Je kan veel vinden van Apple, maar het uitfaseren van 32-bit applicaties is helemaal niet zo’n gek idee.

[field33P]

Apple heeft dan ook niet zijn marktaandeel te danken aan legacy support en heeft al meerdere breuken in backwards compatibility geïntroduceerd. (dumpen van ondersteuning van Mac OS classic en daarmee m68k-applicaties in Leopard), dumpen van Rosetta in Lion, dumpen van ondersteuning voor x86-32-applicaties en over enige jaren zal x86-64-ondersteuning eraan moeten geloven). Voor Windows komen er ook nog vandaag genoeg applicaties uit die met een 32-bits target gemaakt zijn.

[1973booterror]

Maar daarentegen heeft Microsoft zelf WindowsMobile om zeep geholpen door steeds de codebase te veranderen.

[Stoelpoot]

De vraag is, is dat wel nodig? Het voornaamste voordeel aan 64-bits apps is dat je meer geheugen kan gebruiken, en voor een app als Discord is dat voordeel niet nodig en ook absoluut niet gewild onder de gebruikers. Er wordt nu al geklaagd dat er te veel geheugen gebruikt wordt!

[MrFax]

Het is een misconceptie dat het enige waar 64-bits zin voor heeft meer geheugentoegang is.

The larger number of registers, and increase of their size, allow the processor to handle large memory areas simultaneously, to handle variables and arrays more effectively, and to pass function arguments in registers instead of the stack.

Ook zijn 64-bits apps over het algemeen veiliger dan 32-bits apps, als de code hier ook voor gemaakt is.

Als laatste heb je nog het feit dat Windows zo nu wel een keer 32-bits support eruit mag slopen voor de gemiddelde gebruiker. 32-bits wordt op een hart-longmachine gehouden door Microsoft.

[Reactie gewijzigd door MrFax op 25 juli 2024 02:28]

[Stoelpoot]

Daarom zei ik ook dat het geheugengebruik de voornaamste reden is. Ik weet dat er inderdaad nog andere redenen zijn, maar alleen daarvoor zou ik geen switch maken als 32-bits ook nog prima volstaat.

[Sandor_Clegane]

Snap ik, alleen doet "herschrijven" hier wel wat anders vermoeden.

Electron heeft weer de mazzel dat Chromium en V8 op M1 draait.

[etiennebruines]

Code herschrijven klinkt wel wat overdreven. Vaak is het een kwestie van een build target toevoegen

[MrFax]

Dat ligt eraan. Dr compiler moet het wel aan support toevoegen, en vaak zit je dan nog met honderden kinderziektes waar je (tijdelijke) workarounds omheen moet schrijven.

Ja het is build target toevoegen, maar het compileren moet wel slagen, en je zal grondig alles moeten testen.


Maar Discord is een webapp, en maakt gebruik van Electron. Zo moeilijk zal het dus inderdaad niet zijn, omdat Electron een M1-versie heeft.

[Reactie gewijzigd door MrFax op 25 juli 2024 02:28]

[Wolfos]

Voor sommige applicaties ligt het wat ingewikkelder inderdaad, maar volledig herschrijven zal bijna nooit nodig zijn.

[Frame164]

In de ideale wereld: ja. De werkelijkheid is echter vaak anders. Als het allemaal zo makkelijk zou zijn als we graag zouden hopen, dan kan de ICT sector veel mensen ontslaan omdat die niet meer nodig zijn....

[Frikandel]

De canary versie van Discord bestaat al jaren en wordt onder andere deze pagina aangeboden: https://support.discord.c...1-Discord-Testing-Clients

Ik zou deze niet aanraden voor dagelijks gebruik, want er zitten meestal wel een aantal bugs in.

[yefox]

Ik draai al een aantal dagen de canary build voor Apple Silicon. Ik moet zeggen dat het mij totaal niet tegenvalt, niks geen 'hick-ups' of andere problemen gehad. Voor elke Apple Silicon gebruiker is dit wel een grote uitkomst. Je merkte dat bij de x86 versie je veel vertraging had in animaties en soms kortom gewoon 'lag'. Daarbij neem ik de invloed op het batterijleven nog niet mee. -- Ik ben er helemaal blij mee, zelfs in de huidige staat.

[Frikandel]

Ja, het kan best dat de hudige versie goed draait. Maar als de M1 ondersteuning uit is, zou ik zelf switchen naar de PTB of Stable build voor dagelijks gebruik. Meestal werkt de Canary build namelijk prima, maar het komt vaak voor dat er irritante bugs in Canary zitten. Het is niet voor niks een referentie naar de Kanaries die vroeger in koolmijnen werden gebruikt

[yefox]

Zeker zal ik gaan switchen! Maar, voor de aanstaande tijd gaat dit prima. Leuke ref. ook

[R0BK3]

Discord en zovele andere Electron-apps zoals Slack, Signal, enz., hebben een echte native iOS app. Waarom brengen ze deze via catalyst niet naar Mac? Luiheid, koppigheid, slechte UX op desktop gelijk houden met Windows?
Vraagt wel ff wat aandacht, maar is zeker geen grote klus.

[GekkePrutser]

Catalyst apps vind ik over het algemeen helaas qua gebruiksgemak niet veel beter dan Electron. Zelfs die van Apple zelf (Homekit bijv) vind ik nogal flut op de Mac. Nog steeds het hele 'dumbed down' gevoel, weinig opties, veel te verkwistend met schermruimte.

Maar het zou wel helpen om de hele vertaalslag van HTML over te slaan en het wat efficienter maken ja. Efficiente Electron apps kan vreemd genoeg wel maar niemand doet het (behalve VS Code).

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 02:28]

[deedree]

Discord is React. React Native om precies te zijn. Een native iOS app is geschreven in Objective-C of Swift.

https://discord.com/blog/...ticking-with-react-native

[Stroper]

Softwareontwikkelaars moeten hun macOS-programma's herschrijven voor M1-hardware omdat deze op de ARM-architectuur draait.

Tenzij de software obsure calls gebruikt(of slecht geschreven is), hoeft die meestal niet herschreven te worden wel gehercompileert.

[DaveFlash]

bijzonder!

[Jan Onderwater]

Nu nog meer native games voor Apple Silicon om de gamers blij te maken, en een console gebaseerd op Apple silicon, die kan dan gemaakt worden met een versie die wel cpu, gpu en nou heeft, maar geen dingen als video encoding of encryptie nodig heeft

[Wolfos]

Wat zou Apple toevoegen in de console markt? Dat past totaal niet bij hun manier van zaken doen. Hardware subsidieren en veel samenwerken met game ontwikkelaars.

[Keypunchie]

Apple lijkt met Apple Arcade een beginnetje te hebben gemaakt met het omgekeerde model: games subsidiëren en een veel te dure AppleTV, en nu samenwerken met hardware-ontwikkelaars (AirPlay 2, Apple TV+)

Tot nu toe heeft Apple maar heel bescheiden impact. Hun shows hebben wat prijzen en dat is het wel zo’n beetje.

Niet dat het *niet* aanslaat, maar als het over content streaming gaat dan is het rijtje Netflix, Amazon, Disney… Apple zit bij “other”.

[SwaggyEggs]

Apple verdient al meer met gaming dan Sony, Nintendo en Microsoft samen en dat doen ze niet eens via zelf games maken maar alleen door apple tax te heffen: https://screenrant.com/ap...-sony-nintendo-microsoft/

[Keypunchie]

Jazeker, maar dat is niet ‘streaming’. En het specifieke business model staat enorm onder druk van marktautoriteiten en regelgeving.

Dus Apple zou graag ook een wat grotere partij meeblazen in de ‘content streaming’ anders dan muziek (waar ze een reus zijn).

Voorlopig met weinig succes.

[SwaggyEggs]

Waar heb je het over? De omzet via muziek streaming van Apple is nog niet eens de helft van de profit die ze via gaming krijgen. Games streaming stelt sowieso niks voor.

[Keypunchie]

En het valt allemaal in het niet bij wat ze met iPhones verdienen.

Ik heb het over hun diensten in context van de rest van de(zelfde) markt, niet in vergelijking met de rest van het bedrijf.

Dus Apples inkomsten via de App Store met games vergelijken met Microsoft et al. hun consoleinkomsten... dat is appels met peren (excuseer de woordkeuze).

[Heroic_Nonsense]

Apple heeft al eens geprobeerd om een console te maken. Dat was geen succes; zeg maar gerust een flop.

Het ging om het PIPP!N-platform; een op 32-bit PowerPC (603) en Classic MacOS gebaseerd systeem dat autoboot HFS-CD's kon starten die speciaal voor de PIPP!N waren geauthored.

Apple Pipp!n-platform:
Bandai Pipp!n

[Keypunchie]

Mja, ze hadden voor de iPhone ook al ooit een handheld gemaakt, de Newton. Dat was ook geen doorslaand succes.

Toch was de op zijn minst spirituele opvolger de iPhone dat wel!

Overigens hebben ze wel een kans laten schieten om met de AppleTV meer marktaandeel te halen…

(Homepod zelfde verhaal)

[Samplex]

Als ik Electron zie staan sla ik deze over, gewoon luie developers die niet swift/catalyst apps voor de mac willen maken of hongerige ceo's/aandeelhouders. 1Password is zo'n partij die is overgegaan is op Electron, scheelt ze geld omdat ze nu ook Windows en Linux ondersteunen. De fijne gebruikers ervaring op de mac is helemaal weg, het is een cpu en memory vretende applicatie geworden met limitaties.

[BikkelZ]

Zeker nu je zowel Mac als iOS kunt targeten met één codebase inclusief de UI.

[Reactie gewijzigd door BikkelZ op 25 juli 2024 02:28]