Microsoft introduceert testversie Mac Office 2019 voor systemen met Apple M1-soc

Microsoft heeft een Universal-build van Mac Office 2019 in zijn Beta Channel geïntroduceerd. Deze build bevat ondersteuning voor Mac-systemen met een Apple M1-soc, in aanvulling op ondersteuning voor systemen met Intel x86-processors.

De testversie van de Universal-build van Mac Office 2019 is in het Beta Channel vrijgegeven, meldt Erik Schwiebert, die bij Microsoft aan Office-software voor Apple werkt. Wanneer de final release plaatsvindt, maakt hij niet bekend. Volgens hem gaat dit om een vroege blik op de software voor mensen die Mac-systemen met de M1-soc kopen.

Verder maakt hij duidelijk dat de uitvoerbare bestanden voor de universele build zo'n 50 procent groter in omvang zijn dan de bestaande build van Mac Office 2019. De apps zijn zo'n 12 procent groter en de installer is ongeveer 12 procent in omvang toegenomen.

Microsofts Office-producten draaien tot de release van de Universal-versie via Apples Rosetta 2-emulatielaag in MacOS Big Sur op systemen met een M1-chip. Microsoft meldt dat als gebruikers Office-apps voor de eerste keer starten, deze er ongeveer twintig seconden langer op doen voor ze gereed zijn om te gebruiken, omdat macOS de code moet optimaliseren voor de M1.

Microsoft adviseert de November 2020 release, build 16.43, te draaien van Word, Excel, PowerPoint, Outlook, OneNote en OneDrive. Deze bevatten de laatste optimalisaties voor mac OS Big Sur. Inmiddels is die laatste versie van Apples besturingssysteem beschikbaar, zoals Apple dinsdag aankondigde. Apples eigen apps zijn al Universal-apps. Apps op Apples Universal Platform draaien native op zowel de op Arm gebaseerde M1-soc en de Intel x86-processors. De Rosetta 2-emulatie is er voor apps die nog niet Universal zijn.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (90)

Verder maakt hij duidelijk dat de uitvoerbare bestanden voor de universele build zo'n 50 procent groter in omvang zijn dan de bestaande build van Mac Office 2019. De apps zijn zo'n 12 procent groter en de installer is ongeveer 12 procent in omvang toegenomen.

Omdat ik hier niks van snapte, heb ik het maar even opgezocht wat ze nou eigenlijk bedoelden:

De executables zijn ongeveer 50% groter, maar omdat andere resources (teksten, plaatjes) maar 1x nodig zijn en dus niet zijn 'verdubbeld', is de totale omvang van de individuele apps maar 25% gegroeid. Omdat een aantal resources hetzelfde zijn tussen de applicaties, maar slechts 1x in de installer zitten, is de installer maar 12% gegroeid.

[Reactie gewijzigd door RefriedNoodle op 12 november 2020 21:40]

Wat ze hiervoor gebruiken zijn zogenaamde "fat binaries" (zie ook https://en.wikipedia.org/...#Apple's_Universal_binary, die kunnen uitvoerbare code voor meerdere architecturen bevatten.

Dit is door Apple een tijd geleden al eens gebruikt toen ze overgingen van PowerPC naar Intel x86. Gedurende die overgang was het vrij normaal om binaries (dwz uitvoerbare bestanden) te maken met zowel PowerPC als Intel code erin. Hetzelfde geintje kunnen ze nu weer opnieuw doen, maar dan dus met binaries met zowel Intel als ARM64 code erin.

Dat neemt niet weg dat voor moderne applicaties die in zogenaamde bundles worden geleverd, zoals vrijwel alle macOS apps, de binaries zelf meestal niet de meeste ruimte innemen. Dat gaat hem vooral zitten in resources zoals iconen, plaatjes en tegenwoordig ook nog video. Maar vrijwel al die resources zijn onafhankelijk van de architectuur, dus die hoeven er maar 1 keer in.

Veel van de huidige Apple applicaties zijn al fat binaries, zie bijvoorbeeld Safari:

/Applications/Safari.app/Contents/MacOS/Safari: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/Applications/Safari.app/Contents/MacOS/Safari (for architecture x86_64): Mach-O 64-bit executable x86_64
/Applications/Safari.app/Contents/MacOS/Safari (for architecture arm64e): Mach-O 64-bit executable arm64e

Interessant dat de arm64 versie van Safari de arm64e variant is. Die heeft pointer authentication voor runtime hardening.

Veel iOS ontwikkelaars zullen het al weten, maar met Apple’s lipo tool (vernoemd naar liposuctie denk ik) kan je met FAT binaries werken.

iOS software ontwikkelaars zullen soms lipo gebruiken als onderdeel van bijvoorbeeld een automated build proces. Om tijdens het bouwen van een app één binary te maken die zowel geschikt is voor de simulator (x86) en de mobiele telefoon (ARM).

Ik ben zelf al jaren MAC gebruiker.

Voordat echt de groter jongens om zijn.. zoals MS met een native ARM based Office.. Zal ik nog wel een even niet upgraden naar de M1.. Al kijk ik er wel naar uit..

Het is een grote stap van Apple om zo over te stappen.. Ze hebben er al ervaring mee met de overstap naar Intel.. Nu is de vraag hoe wordt de apple soc omarmt.. Het is toch de gebruikers base die daar voor moet zorgen..

Nou ja als ik zo kijk naar mijn applicaties (Van de Affinity Suite, tot verschillende andere software) zie ik dat er behoorlijk veel en snelle updates zijn voor de M1 chip. Ik denk dat de transitie voor de eindgebruiker een heel stuk soepeler en sneller gaat dan van PowerPC naar Intel.

Serif steekt hier een mooie middelvinger op naar Adobe die haar software pas volgend jaar uitbrengt. Ik vraag me af of het met DRM te maken zal hebben.

Misschien omdat Adobe enorm veel pakketten heeft? En ze wel alle pakketten in 1 keer willen beschikbaar maken voor hun abonnees?

Nou de eerste generatie intel macs (ore solo en duo) hadden een enorm kort leven en support is snel gevallen voor deze producten.. Dus zo geweldig was de transitie naar intel ook niet voor early adopters ik heb nog heel lang met mijn G5 imac gedaan.

Mijn Macbook Pro begin 2008 dat is geloof ik 1,5 jaar na dat de eerste Mac met een Intel CPU geleverd werd. Is toch tot 2017 ondersteund geweest door Apple.. In augustus 2014 heb ik deze dan wel vervangen, maar in 2017 was het echt einde support... Vind ik toch wel netjes, zeker tot 2013... Altijd prima mee kunnen werken.. Na 10.8/9 werdt het wel tijd om te vervangen..

Hij heeft het over software en jij over hardware. Het een sluit het ander niet uit. De transitie qua software kan vlotjes gaan terwijl er tegelijkertijd kinderziektes zijn qua hardware.

Ik had een G5 PowerMac uit 2005 of 2006 en dat was een van de eerste modellen met loodvrij soldeersel. Daar kwamen haarscheurtjes in waardoor hij uitviel. Had weinig met de software te maken maar daardoor de kortstlevende Mac die ik ooit gehad heb.

Huh? Maar je kunt de huidige niet-arm-apps toch gewoon draaien met Rosetta 2?

Lijkt me dat de performance van niet-arm-apps dat met Rosetta 2 draaien minder preseteren dan dat ze native op een Intel hadden gedaan. In dat opzicht zou ik er niet blind op vertrouwen dat de M1 chip direct klaar is om je huidige Apple machine te vervangen, software die je gebruikt kan zomaar een stuk trager zijn vergeleken nu.

Dat zal natuurlijk na verloop van tijd steeds minder worden als ARM support toegevoegd wordt maar wel iets om rekening mee te houden

Ik vind het lastig voor te stellen dat je dit echt merkt in een programma zoals office.
We moeten het uiteraard ook niet heel veel groter maken dan het is.
Ik denk dat office een mooi voorbeeld is van een programma wat iedere Mac gebruiker (geclassificeerd als niet van oudsher gebruiker) graag zal gebruiken en te cruciaal voor Apple om te laten liggen (en Microsoft).
Daar zullen best wel wat telefoontjes tussen de twee giganten aan vooraf gegaan zijn.
Apple die het voorlegt Microsoft die beaamd dit al te kunnen en vlak na release werkend beloofd.

Maw, ik had niet anders verwacht, en zie geen grote problemen nu en voor de toekomst.
En verwacht daarna dat vele zullen volgen. Er zal verschil zitten tussen de iOS en MacOS versie, maar qua taal is er voor de programmeurs weinig aan de hand.

Het is meer ff lastig (en kostbaar in sommige gevallen) voor de end-users.
Ik heb het gehad bij de switch van PP naar Intel, en recent nog van 32 naar 64 bits (een reden dat ik bij Mojave ben gebleven).

Maar Apple beschuldigen van vast geroest zitten kan iig niet.

Ik denk dat power users idd best nog een generatie wachten tot de ‘M2’ chip uit is met GPU support en tegen die periode zullen de meeste apps wel geport zijn.
Ofwel native, ofwel via Rosetta2. De Rosetta2 port zou simpel zijn en de M1 chip lijkt (met native apps) op i9 niveau te presteren. En dat met 10watt Tdp incl 16Gb ram +’GPU + neural engine.

PowerPC naar x86 ging al vlot, dus dit moet nog vlotter gaan. Zeker omdat het marktaandeel gestegen is. Combineer dat met het feit dat Ipad apps nu toegang hebben tot MacOS en ik ben er zeker van dat het App aanbod voor Apple silicon binnen het jaar op niveau zal zijn.

Apple gaat letterlijk ‘all in’ voor hun ARM chips. Ik maak me meer zorgen over de levensduur van mijn i7 macbook pro 15” dan de M1 macbooks. Die laatste worden per definitie alleen maar sneller door native support van apps + macOS terwijl oudere macs na 2-3 jaar zullen verbleken met m2-m3 powered chips. De M1 10watt tdp veegt nu al de vloer (volgens Apple) met i7-i9 intel mobile chips, laat staan zijn opvolger met 40wat tdp.

Indien Apple silicon native apps effectief x5+ sneller zal worden dan x86 apps denk ik niet dat App developers nog veel zin gaan hebben om x86 mac apps nog lang vol te ondersteunen.

Niet alleen volgens Apple, op macrumors stond een artikel van weer iemand anders die had zitten kijken, en daarbij gekeken heeft naar de benchmarks van de A14 tov Intel’s CPU’s.

Ik denk dat de Intel mac’s nog wel even meegaan, en Apple heeft zelf ook altijd gezegd dat ze nog jaren ondersteund gaan worden. Er zijn zelfs nog Intel Mac’s in ontwikkeling. (Juist voor de segmenten van de markt die niet early adopter kunnen zijn). Als je een 16” MBP van 3600 euro koopt mag je dat ook gewoon verwachten volgens het Nederlands en Europees recht. Laat staan de high end Mac Pro’s in video suites.

Die ondersteuning zal inderdaad heus niet zomaar stoppen, maar uiteindelijk kom je hoe dan ook op het punt cat macOS niet meer uitkomt voof x86 Macs en dat de M1 dan nog wel ondersteund worden. Daarnaast zie je ook binnen de Apple lineup een gekke scheur, zeker bij de 13” MacBook Pro: het ‘high-end’ model met 4 TB poorten en meer RAM en SSD mogelijkheden draait volgens Apple zelf op een inferieure CPU en GPU.
Als je dus meer dan 16gb RAM, 2TB SSD of 2 TB3 poorten nodig hebt, ben je feitelijk overgeleverd aan een computer met minder rekenkracht, toekomstbestendigheid en accuduur.

De MacBook Pro 13” is meer een pro light. Het wordt meer gebruikt door sales mensen. Ik denk dat Apple het op basis van die gegevens heeft bepaald. De reden waarom je geen 16” variant ziet is omdat die variant de echte powerbak moet zijn, en omdat het nu allemaal samenkomt in 1 SoC verwacht daar een M1X of andere variant van, die wel 32 of 64 GB gaat bieden. (En meer thunderbolt poorten, grotere SSD’s). Het is een iteratief proces. Alle techneuten die ik ken met een Mac hebben allemaal de 15”/16” varianten.

De vraag is ook: heb je bij de ARM variant wel zoveel geheugen nodig? Het kan simpelweg zijn dat ARM danig efficiënter is dan x86 dat de memory impact ook kleiner is. Al jaren wordt de iPhone afgekraakt om “weinig geheugen”, maar in werkelijkheid blaast het ding qua performance. Mensen lopen gewoon niet tegen echte memory constraints aan.

Ik denk dat het een ander verhaal wordt als je echt Pro- software wilt gebruiken. In mijn PC heb ik 128GB zitten. En dat is hoofdzakelijk omdat After effects bakken met RAM nodig heeft als je een stuk HD / 4K animatie wilt previewen. (deze frames worden in RAM geladen). Dan kan een architectuur misschien efficiënter om gaan met ressources, maar als je botweg je geheugen vol gaat laden met video beelden, dan moet die RAM-ruimte toch ergens vandaan komen.

Die ondersteuning zal inderdaad heus niet zomaar stoppen, maar uiteindelijk kom je hoe dan ook op het punt cat macOS niet meer uitkomt voof x86 Macs en dat de M1 dan nog wel ondersteund worden.

Wat je ook koopt, elke machine wordt na 5 - 7 jaar tot legacy-model verklaard, waarna de ondersteuning stopt, maar de vraag is natuurlijk hoeveel eerder het stopt in geval van de Intel-varianten.

De vorige keer werd de transitie van PPC naar Intel aangekondigd in januari 2006 en werd de eerste Intel versie, 10.4 uitgebracht en stopte de ondersteuning voor PPC met 10.6 halverwege 2009.

Eerlijk gezegd verandert er de laatste jaren niet zo heel veel per update. De vraag is dus of je er veel aan zal missen als je een keer niet mee kan met de nieuwste release.

Verder houden ontwikkelaars hier ook rekening mee waardoor sommigen juist extra lang de Intel-variant zullen ondersteunen.

Ik zie het wel zitten, al draai ik ook Windows op mijn MacBook. Dat doe ik via VMware Fusion, maar ik verwacht niet dat dit ooit goed zal gaan werken op de M1. Mijn Windows VM’s migreer ik nu dus naar de cloud, want zeg nou eerlijk: Wanneer heb je nu geen internet toegang tegenwoordig?

Het gegeven dat er nu al een MS Office versie voor de M1 is, verrast me positief. Dat gaat dus wel goed komen. Reden te meer om serieus naar de nieuwe Macs om te gaan kijken.

Apple stopt gewoon met leveren van zijn Intel-based MacBooks. Dan heb je als gebruiker geen keuze. Fabrikanten zullen wel een keer moeten op deze manier.

En waarom ook niet? Vooruitgang hoort er nou helemaal bij in deze wereld.

Helemaal eens, het is veelbelovend qua energieverbruik én prestatie. Maar zo'n transitie wordt ook een bug fest. En voordat ook vele kleine handige appjes om zijn...

• Easyress,
• Cryptomator,
• Itsycal,
• Rectangle,
• Poc,
• Kap,
• Unarchiver,
• Pacifist,
• GifCapture,
• Standard Notes,
• OpenShot,
• Calibre,
• DRM removal tooltje,
• beide VPN clients die ik gebruik,
• printer drivers, etc

Als dat allemaal via Rosetta moet twijfel ik of er nog enig voordeel overblijft van de nieuwe architectuur.

Tegen de tijd Rosetta bijna uitgefaseerd kan worden is het interessant om zo'n Mac te hebben. Dat lijkt me eerlijk gezegd een kwestie van jaren.

Wel jammer dat de software 50% meer ruimte nodig heeft op een apparaat waar storage extreem duur is en niet zelf uit te breiden is.
Zou Apple dit ook zo bedacht hebben?

Als dit zo is zou dat inderdaad vervelend zijn. Bij de transitie naar Intel had je apps als Xslimmer die onnodige resources weg kon gooien. Benieuwd of er weer dit soort apps gaan komen.

Dat is tijdelijk - zolang nog niet alles over is naar Mx chips.
Je software op zich is lang zo groot niet, het is vooral de data die je genereert.

Dat de software 10 to 50% meer ruimte nodig heeft, is vooral in het installatie medium. Het is maar net hoe de binaries zijn opgebouwd en hoe het wordt geoptimaliseerd.

Het kan zijn dat de installatie media gewoon 2 (of meer) binaries aan boord heeft en bij de installatie ziet wat nodig is en die installeert. Dan heb je run-time toch het optimum.

Het kan zijn dat de installatie media binaries aan boord heeft die multi-platform zijn en dus pas run-time kiezen welk deel van de binary wordt uitgevoerd. Omdat arm en intel ergens een gezamenlijke voorvader hebben zou dit zomaar kunnen werken. Vooral portable software zal zo worden opgebouwd.

Het kan zijn dat de installatie media op 1 of andere manier bij installatie een laatste compileer en/of link slag maakt en zo optimaliseerd. Een vorm van 'just in time compilatie'. Dit is meestal te herkennen aan dat er een runtime-library nodig is. Dit start wat minder snel (traag) op vanwege de compilatie-slag die iedere keer gemaakt moet worden.

Bij Apple is er een geschiedenis. Volgens mij zijn ze ooit met 32-bits begonnen (op 68000 of zo iets), toen naar (64 bits) PowerPC, van PowerPC naar Intel en dan nu van Intel naar arm. Naar mijn idee is dit van intel naar arm de kleinste stap: De woord-breedte blijft 64 bits en de bit-volgorde verandert ook niet. Er wordt gehakt, er vallen spaanders maar het zal goed komen.

68k->PPC PPC->G4(alvitec)->G5(64Bit)->x86(32bit->x86(64bit)->ARM(64bit)
Zeer indrukwekkend, maar verreweg de moeilijkste stap was Mac OS9->Mac OSX.
Dusdanig moeilijk dat er ook een classic modus was met MacOS9 dat zelfs nog apps ondersteunde van system 7

Ik denk niet dat dit waar hoeft te zijn. Na installatie verwijder je de installatie file toch gewoon? Alleen de ARM versie in the FAT binarie word geinstalleerd veronderstel ik.

Ik denk niet dat dit waar hoeft te zijn. Na installatie verwijder je de installatie file toch gewoon? Alleen de ARM versie in the FAT binarie word geinstalleerd veronderstel ik.

Tegenwoordig zie je het iets minder, en komen er installers aan te pas, maar zeker vroeger was een macOS applicatie iets wat je downloade en vervolgens kon draaien. Misschien hooguit even in de applications folder droppen. Dat was je installatie. Het is mogelijk dat @ first-run het OS even kijkt wat de .app bevat, en overbodige architecturen wegmikt, maar dan heb je wel problemen als je een nieuwe Mac koopt en een time machine recovery doet naar je nieuwe machine. Dan werken je apps opeens niet meer. Dus ik denk dat dat een handmatige actie gaat zijn.

Als ze zo snel (wanneer zijn ze begonnen?) dit voor elkaar hebben, hoeveel moeite zou het kosten een Debian/Ubuntu build van Office te produceren?

Ja je hebt LibreOffice (maar soms rommelige UI en vaak lastig te wennen komende vanuit MS Office) en WPS Office (prima, want of het nou uit China komt of US, boeiend, maar geen NL versie en geen NL spellcontrole) en OnlyOffice Desktop Editors (prima, maar beperkt) en dus ben je weleens gebonden aan Office Online (hopeloos beperkt).

[Reactie gewijzigd door Jazco2nd op 12 november 2020 22:28]

Office had al een versie voor OSX maar nu dus ook een build voor een andere architectuur. Als MS X-Code hiervoor gebruikt dan is compileren voor een andere architectuur voor hetzelfde platform eenvoudig.

Dat is zo'n beetje hetzelfde dat je vrij gemakkelijk Samba, PostgreSQL, MySQL etc... op voor ARM kunt compileren alsmede voor Intell.

Omdat office niet bestaat voor het Linux platform, is het helaas dan wel een heel stuk lastiger om Office ook voor Linux beschikbaar te maken. Want je hebt niet alleen met het platform te maken, maar ook met desktop managers want je wilt natuurlijk wel goede integratie hebben. Denk ook aan clipboard gebruik tussen applicatie wat onder Linux best lastig kan zijn als je het goed wilt doen, dus helaas geen gemakkelijke port...

Maar er is wel een versie voor Android.. maarja alleen een Linux kernel wordt gedeeld door Android, dus daar heeft een app die op Android draait verder niet zoveel mee te maken.

Je moet hier even de kernel buiten laten, die heeft er weinig tot niks mee te maken. Waar het hier vooral om gaat is de gekozen UI technologie. Zover ik weet is er geen QT/GTK versie van Office, dus moet Microsoft die bouwen, testen, Office erin bouwen en/of zorgen dat de huidige codebase de juiste bindings heeft en dan nog eens per distro packagen en releasen (of in ieder geval een .deb, .rpm / PPA en COPR).. Het is dus niet zo dat omdat er iets is voor "Linux" (android) dat het meteen voor alles er is.

Als ze zo snel (wanneer zijn ze begonnen?) dit voor elkaar hebben, hoeveel moeite zou het kosten een Debian/Ubuntu build van Office te produceren?

Moeite? Waarschijnlijk niet heel veel. Maar vergis je niet, Microsoft had al office voor de Mac (notabele, de eerste grafische versie van word was voor de Mac, Windows bestond toen nog niet eens). De API’s voor de Mac en iOS/iPadOS komen doorgaans aanzienlijk overeen, wat het eenvoudiger maakt. Als je niet veel wielen uitvind en veel de API’s gebruikt kan het zelfs bijzonder snel gaan.

De vraag is: is het het waard? Mac, iOS, iPadOS hebben een enorm marktaandeel, net zoals Android. Linux desktops daarentegen zijn ... haast verwaarloosbaar. Onder de Linux techs en developers kom je het wel tegen, maar ook daar zie je er veel op de Mac.

Als Microsoft er geld in zou zien hadden ze het gedaan. Maar met het marktaandeel Linux op de desktop denk ik dat dat simpelweg geen business case is die je rond krijgt.

Maak je geen zorgen: microsoft heeft al jaren een zekere drive om voor apple ook software te maken..Het gerucht gaat dat ze ooit bang waren dat apple weg zou vallen en dat microsoft daarmee een monopolie zou krijgen en daar voor gestraft zou worden. Ze zouden op 1 of andere manier heel lang apple in de lucht gehouden hebben zodat ze zicht zelf niet als monopolist hoeven te verantwoorden.

Daarnaast zijn apple gebruikers goede en betrouwbare gebruikers die in hun (werk-) omgeving investeren. Ze betalen (wat meer) als ze er maar een noodzaak voor hebben. En er is vanuit het apple platform ook zakelijk een zekere vraag. Om kort te gaan: apple gebruikers betalen.

Praktisch: Microsoft heeft al jaren een msOffice variant voor de apple omgeving. Apple heeft ongetwijfeld al een tijdje een software-bouw-omgeving beschikbaar met daarin een redelijke methode om te bouwen voor het nieuwe platform. Microsoft zal daar zeker een gebruiker van zijn en deze software door die molen gehaald hebben. Het resultaat treffen we hier nu aan.

De bovenstaande voordelen heeft de linux omgeving allemaal niet: Gebruikers, zeker particulieren, zijn niet echt bekend als grote investeerders. De ervaring van microsoft om msOffice (toen nog msWord en msExcel) op unix te leveren zijn op zijn best roestig. Ik weet dat ze op HP-UX en Solaris beschikbaar waren, ergens in 1995, maar daarna niet meer.

Daarbij: in het algemeen is microsoft bezig over te stappen naar 'in browser' mode met office 365, al is dat volgens mij een heel ander verdien model....

Ze hadden al een aparte Office versie voor macOS, ze gaan niet uit van de Windows variant van Office. Opnieuw compileren voor hetzelfde OS op een nieuwe architectuur, waarbij de transitie zo makkelijk mogelijk wordt gemaakt door Apple, is ordes van grootte makkelijker dan daadwerkelijk porten naar een ander OS, omdat de onderliggende frameworks totaal anders zijn. CPU-architectuur is in dat geval bijna triviaal omdat de compiler die vertaalslag maakt.

Money money money. İs een liedje. Luister en huiver. Jaren terug en een dingetje.

Ja ik ben van die tijd hoor. Ik vraag ook niet waarom ze het niet doen, maar hoeveel moeite het zou kosten.
Is het een kwestie van de broncode builden voor Linux systemen.. of komt er (veel) meer bij kijken.

Dat is wel meer werk, hier kon je grotendeels dezelfde code gebruiken en op recompile drukken. Ga je een ander OS ondersteunen, dan moet je veel meer code aanpassen omdat je niet dezelfde frameworks tot je beschikking hebt. Bijvoorbeeld in dit geval waarschijnlijk UIKit om de interface te bouwen. (Als één van de vele OS supplied frameworks die ze waarschijnlijk gebruiken)

Thanks, dat is wel een logische ja.
Ik zie dat OnlyOffice Desktop Editors niet echt in de UI integreert. Ze hebben dus wel iets werkends gebouwd, maar wss een shortcut genomen en ze laden volgens mij gewoon een Chromium browser window die de OnlyOffice webversie laadt. WPS integreert ook niet in de UI dus zal ook wel iets geks doen.

Nee hoor, samenwerken is in deze het devies. You pay me, I pay you. We bashen allebei dus waarom niet.

Aah man. Dit moet je niet onderuit schoppen. Apple heeft koud twee dagen geleden een cpu release gedaan en Microsoft kondigt nu al een Office* versie aan. Dit is gewoon knap en goed gespeeld.

Er is een aanzienlijk deel van Mac gebruikers die Office moeten gebruiken in een professionele setting. Dit is goede service door beide partijen.

* edit: die ook goede implementaties heeft op Android en iOS.

[Reactie gewijzigd door oef! op 12 november 2020 23:49]

Ik durf te stellen dat ver voor de aangekondiging van arm mac’s, de key players als Microsoft, Adobe, etc al developer stations hadden met die A14Z processor. Want bij de aankondiging van WWDC zag je al wat hints op dat vlak. (Adobe in dat geval, parallels dacht ik ook).

?

Als en multinational met 90% marktaandeel iets niet doet, dan heeft dat niets te maken met een gebrek aan 'inzet' of 'middelen'. Het is gewoon een bewuste keuze om Linux niet te ondersteunen.

Je moet 2 dingen niet vergeten :
- MS ondersteunt van oudsher al Office for Mac
- MS is zelf ook al aan het proberen met ARM etc. (De surface pro is bijv ook gewoon ARM, windowsphone was ook ARM, er is gewoon een windows 10 versie voor ARM etc.)

En een Linux versie van MS Office kan je denk ik rustig wel vergeten, server side zijn ze wat dingen aan het verkennen, maar zolang ze heer en meester over de desktop zijn zullen ze zich niet snel aan andere desktops wagen.

Mooi om te zien dat Microsoft de Apple systemen echt serieus neemt. Er was een tijd dat Office voor Mac eerder een zwak afkooksel was van wat er op Windows beschikbaar was. Nu lijken die applicaties toch op een hoger niveau te draaien. Ik hoop dat ze juist de performantie van Excel nog wat kunnen opkrikken bij grotere en complexere documenten. Misschien is dat met deze nieuwe processoren meteen ook een feit?

Ben zelf gebruiker van Office365 (Enterprise) op MacOS en dat werkt al lange tijd prima - ook met Teams en Onedrive for business. Al veel langer is Office in grote lijnen hetzelfde als onder Windows. Er is wel een gemis aan Projects, Visio, PowerBI en diverse plugins voor Powerpoint, Word en Excel. Daarvoor biedt bootcamp of de bootcamp partitie opstarten in Vmware fusion toch wel een oplossing.

Wat Microsoft echter nog niet aankondigd is Office365 voor MacOS on ARM; ze kondigen namenlijk Office2019 aan. In sommige office365 Enterprise en business versies zitten geavanceerde security functies voor gegevensbescherming die niet in de koopversie office 2019 beschikbaar zijn. Dit is inherent verbonden met het gehele office365 systeem.

Ook zijn de office apps al enorm groot op MacOS en die worden nog groter. Neem de Outlook app, die neemt al 2GB in beslag, en dat worden er dan 3GB?

Office 365 voor macOS en Office 2019 voor macOS (eigenlijk is de correcte naam tegenwoordig M365 Apps for Mac) zijn identieke builds, het licentie model is alleen anders (subscription versus volume license).

Als je met een subscription service je apps activeert krijg je meer functies die actief worden in de apps t.o.v. de volume license plus de maandelijks updates met nieuwe features.

Overigens: de OneDrive, Teams en Edge voor macOS versies zijn nog niet beschikbaar met de universal binary in Beta Channel maar ze zijn er al mee bezig. Teams wordt wel interessant qua performance omdat die draait op het Electron framework: https://www.electronjs.org/blog/apple-silicon

Teams is sowieso op dit moment om te janken qua performance op macOS. Vooral als 9 personen hun webcam aanzetten. Dan is de batterij binnen 1.5 uur leeg en de laptop functioneert als een extra verwarming voor de kamer.

Is dat een feit of een mythe?

Ik wil misschien de MacBook M1 kopen en Teams is een groot onderdeel van mijn werk in deze coronatijd.

Ik heb een MacBook Pro 16 inch uit 2017, met de snelste Intel processor die ze toen verkochten. Dus qua mac op Intel is het een feit.

Edit: Maar het werkt wel en het crasht nooit. Of dat voor de ook M1 op gaat weet ik niet.

[Reactie gewijzigd door CaptainCapslock op 13 november 2020 11:29]

De apps(bundles) zelf groeien ca 12%, dus Outlook zou van 2gb naar 2,24gb groeien. Reken dus op 1gb extra voor de gehele office suite.

Ik hoop op Access maar dat zal wel niet gaan gebeuren

Dat zou inderdaad nog een mooie zijn! Ik las dat Microsoft hun ODBC binnen Excel wel al naar ARM hebben omgezet.
Ik vrees alleen dat Access te veel VBA bevat en daardoor moeilijker om te zetten is naar Mac.

Dat is snel.

Microsoft maakt goeie software voor zijn grote concurrent. Office op MacOS ziet er mooier uit dan op Windows, naar mijn mening.

Niet echt een concurrent, meer een medespeler. MS heeft zelf in Apple geinvesteerd en bouwt er apps voor. Ze spelen ook helemaal niet in elkaars vaarwater. macOS draait niet op non-Apple-apparatuur, Apple heeft geen aanwezigheid in public cloud-landschap en het aantal macOS-gebruikers vs Windows is verwaarloosbaar. Dit is een beetje alsof Volkswagen Ferrari een concurrent noemt.

Ik zou MacOS niet echt verwaarloosbaar willen noemen tov Windows, als ik deze grafiek mag geloven. Als ik eerlijk moet zijn, moet ik zelfs mijn eerdere opvatting over Linux op de desktop op dat vlak wat afzwakken, waar ik hetzelfde stelde. Linux is niet verwaarloosbaar, maar niet significant genoeg.

https://www.statista.com/...arket-share-of-windows-7/

(Laat je niet verwarren over die 7 achter windows, het gaat om Windows als totaal desktop product, dus alle versies)

Pay wall.

Hier is een open statistieken website waar je een stuk beter kunt zien hoe de verhoudingen zijn.

https://gs.statcounter.co...monthly-201601-202010-bar

Je moet eens spelen met de jaren en je zult zien dat OSX over de jaren maar paar procent is gegroeid. Je zou dit ook hebben geweten als je de sales cijfers van Mac zou zien. Die zijn voor de corona crisis jaren beperkt gegroeid. En linux blijft al jaren op hetzelfde niveau hangen.

Mee eens! En het biedt ook de ‘snappy’ gebruikerservaring zoals je op een Mac gewend bent. Dit in tegenstelling tot Teams... daar is nog een hele wereld te winnen.

De Mac versies van Office software worden weliswaar steeds beter, maar we lopen er regelmatig tegenaan dat ze toch nét iets minder functionaliteit bieden dan de Windows tegenhangers. Qua functionaliteit zitten ze tussen de webversies en de windowsversies en dat geldt eigenlijk voor alle Office apps.

Ik hoor inderdaad wel eens dat Mac-Excel niet tegen de Windows versie opkan.

Ik had eigenlijk gehoopt dat ze Office in deze release gelijk zouden trekken met de iOS + iPadOS-versies qua functies.

Op internet begrijp ik dat veel mensen met VBA willen werken en met macro’s in Excel.

Zelf zou ik graag zien dat functies als Verwijzingen (m.n. bijvoorbeeld bronvermeldingen toevoegen en een inhoudsopgave toevoegen) in Word zouden komen in de iOS + iPadOS-versie. Dan zou het (m’n iPad) voor m’n studie echt een volwaardige vervanger zijn voor m’n laptop.

Waarom zouden ze dit niet doen? Zijn de volledige applicaties te zwaar/groot? Of concurreert het anders teveel met de Surface-tablets?

Code-executie binnen je iPad/iOS app mag sowieso niet van Apple. Je mag dus geen Swift-app schrijven die vervolgens C# gaat lopen compilen en uitvoeren. Aangezien er al flink wat exploits waren voor Excel-files met VB erin, zullen ze dit al helemaal niet willen.

[Reactie gewijzigd door ItsNotRudy op 13 november 2020 09:33]

En toch zijn die mogelijkheden 1 van de redenen dat MS Office de vloer veegt met de concurrentie.

De Mac versie van Word/Excel ondersteunt bij mijn weten gewoon macro’s hoor, maar er zijn wel vaak compatibiliteits issues met macro-enabled bestanden.

Sorry, ik bedoelde apps voor iPad/iOS/watchOS.

iSH en a-Shell hebben wel een soort achterdeurtje gevonden. In principe mag je wel WebAssembly uitvoeren binnen WKWebView.

Is de Company Portal nu ook native ARM?

Wel frappant dat Office 365 voor macOS wel ARM is, maar voor Windows moet Office 365 op een ARM systeem nog in x86 emulatie draaien.

Voor zowel Windows en voor macOS zijn delen van Office native ARM, en delen zitten in x86 emulatie. Dat wordt ook duidelijk uit dit persbericht:

Microsoft meldt dat als gebruikers Office-apps voor de eerste keer starten, deze er ongeveer twintig seconden langer op doen voor ze gereed zijn om te gebruiken, omdat macOS de code moet optimaliseren voor de M1.

Weet je dat laatste wel zeker?

Wel frappant dat Office 365 voor macOS wel ARM is, maar voor Windows moet Office 365 op een ARM systeem nog in x86 emulatie draaien.

Dat heeft, denk ik, iets te maken ook met de manier waarop Apple hier achter de schermen mee omgaat. Die hebben meer controle over het buildsysteem van A-Z, en hoeven minder frameworks te supported in hun OS. Windows heeft een veel grotere "back catalog" om te supporten, waardoor een applicatie porten naar een andere architectuur niet zo snel (lijkt?) te kunnen.

Is maar een gok trouwens!

Houdt dat dan in dat je weer van die app-slimmer tools gaat krijgen om ruimte te besparen? Ik weet nog heel goed dat ik vroeger op mijn Intel Core 2 Duo Mac gigabytes extra ruimte kreeg na het “app-slimmen”, dit kwam doordat de PowerPC binaries verwijderd werden uit de apps die onnodig op m’n Intel Mac geïnstalleerd waren.

Ben benieuwd of dat nog gaat gezien de nieuwe security in Big Sur / M1.

Ben benieuwd of dat nog gaat gezien de nieuwe security in Big Sur / M1.

Niet via de AppStore. Maar apps die buiten de AppStore worden aangeboden mogen unsandboxed draaien als ik me niet vergis. Kwestie van privilege escalatie aanvragen (sudo, in weze) en het kan nog steeds.

Met een beetje mazzel heeft Apple daarvan wel geleerd en zit iets degelijks al ingebakken in het OS, en wordt de binary gestripped na installatie.

Bij MacOS is dat niet eens heel lastig, aangezien een .app in wezen een directory structuur is, met daarbinnen een x86_64 directory voor Intel en een arm64 directory voor arm. Manifest files aanpassen en overbodige architectuur directory weggooien en je bent er.

mooi dat het werkt

Nou, ik vind ze er snel bij zijn, fijn om te zien inderdaad.

Het blijft jammer dat een grote speler zoals Adobe nog steeds die apps niet in orde heeft. Ja, het is veel code, en ja ze hebben veel apps. Maar ze hebben ook veel ontwikkelaars én veel resources, en toegang tot de developer's kit van Apple.

Dat doet Microsoft een heel stuk prettiger zo te zien.

adobe is complete rotzooi volgens mij (van iemand die er dagelijks mee werkt)

Zou liever werken op een versie van 5 jaar terug.

Oh, dat absoluut. Ik ben al jaren steeds meer geirriteerd door wat ze met hun Adobe pakket doen, en in mijn geval met name bij Photoshop en Illustrator. Trage rommel, en als je te snel op de Enter-knop drukt klapt Illustrator er de helft van de tijd uit. Tot CS4-CS6 (afhankelijk van wat je er mee deed) was het prima, maar sinds ze hun abonnementsvorm hebben geintroduceerd is het er niet beter op geworden.

Maar het is de industry-standard helaas. Overstappen naar Affinity heb ik al een aantal keer geprobeerd. Prachtige apps hoor, en ze kunnen relatief veel m.b.t. kleurbeheer en CMYK-profielen (beide handig in drukwerk), maar qua workflow lopen ze nog wat achter. Dat duurt nog wel even eer ze zover zijn jammer genoeg.

Adobe… de gift that keeps on giving.

Nu ben ik geen fan van Powerpoint en Excel (en Word ook niet bijzonder veel), maar wat Microsoft doet met hun updates en ontwikkeling is zoveel beter dan wat Adobe voor elkaar krijgt. Ook de stabiliteit en uniformiteit van hun Office-pakket op de Mac is een stuk beter.

Hoop dat er meer programmas zoals figma komen, wat een verademing was dat.

Wat is een goede vervanger voor excel? Ik ben serieus benieuwd

helaas is dat er niet

Dat is er niet echt. Je hebt o.a. LibreOffice en OpenOffice, en ook Apple's eigen Numbers. Die kunnen allemaal wel wat, maar niet zoveel als wat Excel gebruikt… het hangt er dus een beetje vanaf wat je er mee wilt doen

Wat wil je er mee? Mijn eerste schot: LibreOffice Spreadsheet. En volgens mij heeft het apple-platform ook 'eigen' spreadsheet programma's. Maar je hebt vast noten op je zang en gebruikt vast zaken die buiten excel omgaan.

Gebruik je excel niet als reken-blad, dan zou je de heel functionaliteit moeten bekijken en daar software bij zoeken.

Voor 'management porno' moet je gewoon bij excel blijven, dat doen de managers ook. En daarvoor een windows machine regelen, eventueel virtueel.

Kan microsoft deze builds ook gebruiken voor zijn eigen arm64 surface?

Ik draai zelf ook 365 op Mac OS Catalina maar de Finder integratie met One Drive laat nog wel eens wat
twijfelachtige dingen zien.

Ben heel benieuwd of dit beter wordt met ARM/ M1.

https://itdaily.be/nieuws/kantoor/office-2019-apple-m1-arm/