Microsoft announced Thursday that the next edition of Microsoft Office for Mac will be released in late 2010. The new edition of the venerable office suite will include Outlook for Mac, a new application that will replace Entourage.
'We'll bring forward all the functionality from the Entourage Web Services Edition, including public folders, managed folders, and category syncing, but with Outlook we're going even further and building a whole new application,' said Microsoft Mac Business Unit general manager Eric Wilfrid.
Wilfrid said that Microsoft will create Outlook for Mac using Apple's modern Cocoa development frameworks, rather than the older Carbon system used by previous Office applications because of their legacy of having been originally developed for the Classic Mac OS.
Mac Pro (Late 2013, plus mid-2010 and mid-2012 models with recommended Metal-capable GPU) High Sierra compatibility High Sierra arrived in September 2017 and can run on the following Macs. Oct 20, 2010 Apple Event season 2010 episode 6 Special Event, Cupertino, OS X Lion/MBA (2010) On October 20, Apple CEO Steve Jobs revealed the new MacBook Air, Mac OS X Lion, and iLife '11. Also Classilla brings Firefox to OS 9, slow networking in OS X, iMac vs. Mac Pro, URL shortening software, Quicken update finally coming in 2010, and more. Optimized Software Builds Bring Out the Best in Your Mac, Dan Knight, Low End Mac's Online Tech Journal, 2009.06.30.
'We're building on the most modern OS X frameworks to make Outlook beautiful, to make it high performance, and to make it well integrated with the OS,' Wilfrid said.
Entourage has long been criticized for its large database, which is difficult to back up and can cause serious downtime if it gets corrupted. Wilfrid said that the new Outlook will use a new, modern database instead of the one used by Entourage.
'The new database gives us incredible reliability, better performance, and better integration with technologies such as Time Machine for backup and Spotlight for search,' he said.
Wilfrid emphasized that while Outlook for Mac won't be a feature-for-feature match with Outlook on Windows, Outlook for Mac will be extremely compatible. 'Outlook for Mac and Outlook for Windows work great together, and work great in an Exchange environment,' he said.
Among the features Wilfrid highlighted in Outlook for Mac is support for information rights management, which enables organizations 'to support cross-platform technologies to manage sensitive and confidential information.'
Outlook for Mac will be included in the next version of Office for Mac, which Wilfrid said is 'on track' for the holiday season in late 2010. Microsoft previously announced that Visual Basic will return in that edition, after being removed from Office 2008, which was released in Janaury 2008.
In a separate announcement, Wilfrid said Microsoft was simplifying its current Office 2008 offerings, going from three different editions down to two. The existing Home and Student edition will remain.
Replacing the $399 Standard Edition and $499 Special Media Edition is the new $399 Business Edition, which will include the Web Services Edition of Entourage and Microsoft Document Connection for Mac. Microsoft Office 2008 Business Edition also includes additional templates and clip art, and more than eight hours of Lynda.com training videos.
Michael Gartenberg, vice president of strategy and analysis at Interpret, said that with Macs becoming a more viable option for the enterprise, it is an important move for Microsoft to make its Mac version of Office more on par with its Windows version for those users.
However, Apple's next version of Mac OS X, Snow Leopard, will include native support for Exchange Server when it's released next month, which means business users can connect to Exchange data via Apple's built-in Mail, iCal, and Address Book applications. With this move imminent, Microsoft's inclusion of Outlook in Office for Mac at the end of next year might be too little, too late, he said.
'Apple is going after business users with these types of features,' Gartenberg said of native Exchange support. 'There are still some things Outlook could offer that Apple's integration with Exchange might not offer—we'll have to see. But it will be more than a year [after Snow Leopard]. That's going to give Apple a pile of time to evangelize to folks.'
Microsoft has definitely been feeling the pressure on its Office business not only from Apple's gains in PC market share, but also from free or low-cost competitive applications from Google and others. In fact, Thursday's announcement was the second the company made this week to expand its Office business, which next to Windows remains the main profit driver at Microsoft.
On Wednesday, Microsoft and Nokia unveiled a deal to put Office applications on Nokia's Symbian-based mobile devices, a move that will help Microsoft reach more mobile business users with its Office Mobile suite. The software currently only runs on Windows Mobile devices, which have less market share than Nokia's Symbian handsets.
Elizabeth Montalbano of IDG News Service contributed to this report.
Seasons (2010) Mac Os Catalina
[Updated at 11:47 a.m. PT to include comments from analyst Michael Gartenberg. Updated at 1:48 p.m. to correct statement about Snow Leopard compatibility with Exchange.]
Predicting the future of technology is a tricky business—just ask Bill Gates—but the allure of prognostication is strong. I've been known to try my hand at it. Sometimes I get a good read on things, like in 2008 when I wrote, 'in the grim future of Apple/Adobe, there is only war.' Vague, humorously hyperbolic, and with no explicit timescale: all the essential ingredients of a successful prediction.
Other times, I'm not so lucky. Five years ago, I wrote a three-part series of articles entitled Avoiding Copland 2010. This time, the message was earnest, specific, and had a year right in the title. In other words, a perfect setup for failure. Well, here we are in the year 2010—the future!—so it's time for me to take my lumps…or perhaps crow triumphantly? But first things first. What was this 'Copland 2010' thing about, anyway?
Seasons (2010) Mac Os Update
Background
Copland was the code name for the most infamous of Apple's severalfailedattempts at creating a next-generation operating system. In the 1990s, when Copland was initiated, 'next-generation' meant supporting memory protection and preemptive multitasking, both of which classic Mac OS lacked. Since then, Copland has become the poster child for Apple's nearly company-destroying failure to acknowledge and successfully address a serious technical gap in its software platform in a timely manner. It was only through the improbable acquisition of both a viable modern operating system and a formerly exiled company founder that Apple was saved.
In part one of the series, I put forward my thesis: that the Objective-C language and the Cocoa API are the parts of Mac OS X that are the most in danger of falling behind the competition, and that by the year 2010, Apple could find itself facing another Copland-like crisis due to its lack of a memory-managed language and API. In part two, I elaborated on the assumptions underlying my thesis. They were:
- that fully automatic memory management will eventually be an expected feature of the primary application development environment for a desktop OS;
- that by 2010, the rest of the industry will have adopted languages and APIs that feature fully automatic memory management;
- and that existing (2005) technologies, and obvious evolutions thereof, do not adequately fill Apple's need for a memory-managed language and API.
Many of these assumptions were hotly contested.
In part three, I surveyed the landscape for languages and APIs that could supersede Objective-C and Cocoa. I also tried to encourage those who doubted the specific timeline to at least look at the bigger picture.
After all, everyone can agree that Cocoa and Objective-C will be obsolete someday. Okay, maybe someone out there thinks that won't happen until in the year 2050, but someday, right? […] What should replace Cocoa? What can replace Cocoa? What's Apple's next big move in the language and API wars?
In the article, I considered Objective-C with garbage collection, Java/JVM, C#/.NET/Mono, and even obscure efforts from Apple's past, like Dylan, rejecting them all for some combination of practical, technological, and political reasons. Apple, I concluded, needed to start down what looked to be a long, difficult road to finding or devising its own successor to Cocoa/Objective-C as soon as possible.
AdvertisementThe future is now
So, how did things turn out? If we are to take the title and timeline literally, the conclusion is clear: Apple is not currently experiencing a Copland-like software platform crisis. It may be on the cusp of a very different kind of crisis, but that's another story. As far as Wall Street (and Apple's own balance sheet) is concerned, the future looks bright for Apple.
How did I get it so wrong? Or did I? Let's reconsider my assumptions. Is fully automatic memory management now an 'expected feature' of desktop software development? Not according to most Mac OS X developers, it seems. Garbage collection was indeed added to Objective-C, and Apple has made a considerable effort to promote its use. But the 'second-class citizen problem' I described five years ago has also come to pass. Most Cocoa developers, including Apple itself, are still using manual retain/release memory management in most of their applications. Garbage collection is not a no-brainer choice for all Mac developers today, and is still sometimes seen as a potential performance risk.
Contrast this with the most prominent competing desktop platform, the Microsoft .NET framework and C# language on Windows, where memory-managed code is the default and everything else is considered risky, literally being denoted with the 'unsafe' keyword in the source code.
Nevertheless, Mac developers and users are not panicking like they did in the Copland era about memory protection and preemptive multitasking. If there's a crisis coming, it's definitely not here yet. So much for '2010.' But why?
Now the future is later
Microsoft started working on the .NET Common Language Runtime over ten years ago. Since then, it's had four major releases which have included significant new C# language features as well as increased support for dynamic languages like Python and Ruby. If this is the desktop software platform competition, then Apple is getting its ass handed to it, technologically speaking.
Yet despite this reality, these technical issues are not exactly at the forefront of Mac developers' minds. The reason can be summed up in three words: mobile, mobile, mobile. The ascent of Apple's iOS (formerly iPhone OS) platform has been and continues to be dizzying. With it comes a set of constraints not seen in the desktop computer market in years: 128 to 256 MB of RAM, in-order CPUs that max out at 1GHz, and a complete lack of swap in the virtual memory system. It's been more than a decade since Apple shipped a desktop or laptop computer that was limited to so little RAM, and even longer since a Mac was sold that did not support virtual memory paging to disk. Oh, and by the way, there's also no Objective-C garbage collection in iOS.
This new hardware reality has effectively set the clock back on higher-level programming languages and frameworks in the minds of Apple developers, and Objective-C's nature as a superset of C has renewed its status as a perceived advantage. It's hard to get worked up about still dealing with low-level, per-byte-precise entities like pointers and C structs when your application is constantly receiving low-memory warnings from the OS.
AdvertisementThen there's the magnified importance of user interface responsiveness on mobile devices. Apple's ruthless dedication to maintaining a direct, lively user interface is a big part of what distinguished the iPhone from all earlier touchscreen phones and many of the copycat models that followed. Even today, the fractional second of latency that separates a new iPhone from lesser devices when scrolling a list or flicking through screens remains a subtle but perceptible differentiator. And as with the memory constraints, developers' minds can't help but draw at least a dotted line from the admirably reactive user interface to the low-level nature of iOS's native API.
Reality check
There's a problem with this narrative, however. Just like its biggest desktop competitor, Apple's fiercest mobile-market rival one-ups Apple in the modern development technology department by offering a memory-managed language and API on its mobile platform. And make no mistake, Google's latest Android release, with its don't-call-it-Java Dalvik virtual machine, is no slouch. (I'll claim a tiny nugget of foresight for having endorsed the idea of a register-based VM, the design approach that would eventually be used in Dalvik.)
To add insult to injury, Google is even building on some of the low-level libraries that Apple has helped to develop over the past few years, adding its own performance enhancements and embarrassing even Apple's mighty iPad with a mere Android phone in an old-school-Apple-style performance bake-off. Yes, WebKit is written in C++, and that's the point: providing a higher-level API to application developers does not preclude taking advantage of high-performance, lower-level libraries.
And it's not just Google. Microsoft, predictably, has brought over its .NET platform and added some even higher-level languages and APIs to its latest mobile efforts. Even poor Palm offered more abstraction and safety to its developers. This is the actual competitive landscape Apple faces.
Obviously, such technical details are dwarfed by larger issues when it comes to determining mobile-market success. Things seem to have ended pretty badly for Palm, for example, friendly web-technology-based SDK and all. But they were still one of the most credible threats to Apple's mobile user interface dominance. Google's still out there, of course, and it's not going anywhere. And Microsoft…hey, you never know, right?
The fate of individual competitors aside, the fact that the most dangerous players are all coming out of the gate with languages and APIs a generation ahead of what Apple offers should be a huge warning sign. And again, this is all happening in the memory-starved, CPU-constrained mobile world. On the desktop, Apple is even farther behind.
It is 2010, after all. 'The future' or not, it's getting a bit silly for GUI application developers to perpetually be one bad pointer dereference away from scribbling all over their application's memory. The world has moved on; Apple should too.
