Apple to drop in-house X11 support and more in Mountain Lion
When Apple introduced OS X, it was exploring where the new OS would take the Mac platform. In doing so, and to promote development and compatibility for its OS, Apple included support for a number of popular existing technologies that were appealing to developers. A couple of these were its Unix underpinnings and inclusion of a Java runtime, making it compatible with a plethora of existing Unix and Java tools.
Along with the new OS, Apple promoted its native Cocoa development environment, but also included a library of programming tools called Carbon that allowed older code built for the Classic Mac OS (version 8 and 9) to be easily ported to the new OS.
Over the years of its development, Apple implemented a few other compatibility environments, including "Classic" emulation, which launched OS 9 within OS X to allow nonported Classic programs to run; the X11 windowing system to bring even more Unix-based programs to the Mac; and when the Intel transition occurred, Apple provided Rosetta to allow PowerPC applications to continue working.
As OS X matured and Apple's Cocoa development tools established themselves, Apple began progressively moving away from in-house support for its compatibility layers. With the release of OS X 10.5 Apple shelved the Classic emulation environment, and in OS X 10.7 Apple removed Java from being included in the OS, though makes it available as an on-demand download should a user need it. Additionally, Apple announced it will be stopping its own in-house Java runtime and rely on Oracle or other third parties to provide a compatible runtime for use on OS X (similar to how Java is done on other platforms).
With the release of OS X Mountain Lion, Apple's inclusion of the X11 windowing system in its OS will also be halted. As with Java, instead of releasing an in-house version of the X11 system, Apple will be relying on the separate XQuartz development team to keep a stable version of the X11 windowing system available for OS X. When you open a program that requires X11, the Mac will give you a notification and a link to the XQuartz project Web site so you can download the latest version of X11 for your system.
Given Apple's move from Java and PowerPC support, this development with X11 does not come as a surprise, but people might wonder what it means for their systems. If you are wondering what X11 is, then as with the vast majority of Mac users you will not see any difference by this development. Most consumer applications use Apple's Aqua interface for managing windows and window elements, and those that require X11 or which run in Java usually are specialized technical programs.
For troubleshooting OS X, it sometimes helps to have a secondary command line utility besides Apple's Terminal for accessing the system's underpinnings, and X11 provides this with its XTerm tool; however, this is usually just a minor side benefit. If you need or wish to have a Terminal alternative, you can always download X11 or another third-party tool.
This development in the Mac OS with Mountain Lion does not just stop with X11. According to MacNN, Apple will also be dropping support for some of its Carbon APIs used to run older Classic Mac OS code in OS X.
These efforts seem overall to be a push for developers to write programs in Apple's preferred Cocoa programming environment, rather than relying on older technologies and merely tweaking existing code to run in the new OS. This might cause some concern for end users who still use programs based on the older code set; however, despite the potential for problems, this pushes developers to keep their programs updated, which overall may be a good thing for the end user.
Apple's multiple compatibility layers has made some developers lazy; instead of updating their programs to work well and efficiently in OS X, they have relied on tweaking older code to keep it running. This has resulted in programs running slowly and being limited in function, and also has resulted in frustration for end users when programs have not been updated. One prime example of this was Quicken 2007 no longer working when Apple dropped Rosetta support in Lion, primarily because Intuit relied on Rosetta and did not update its code.
In classic Apple style, the company is continuing to narrow its focus and support to select areas of development, and encouraging developers to jump onboard its bandwagon so programs will run more efficiently with the OS and the services that Apple provides in its products. This will greatly increase the potential for end users to have far more seamless workflows, even if they choose not to use Apple's services.
Luckily, even though X11 will no longer be included in OS X, as with the similar move with Java (and even Rosetta in Snow Leopard), Apple is not shutting it out. While the technology will not be included with the OS, by linking to the XQuartz development page, Apple will be offering people who need X11 a quick way to install it if they open a program that requires it.
This means it will require an extra step or two to get X11 running in OS X; however, as with the move with Java, this shift does a couple of things that might be beneficial for people who use these technologies:
The minimization of the number of runtimes and execution environments will reduce the possibilities for untested or even malicious software to run, giving tools like Apple's GateKeeper and XProtect technologies a greater chance at protecting OS X.
- Keep users up-to-date
Supporting these technologies with in-house development means Apple often resorts to using older versions in its releases, which resulted in users having to wait for the latest features. Relying on separate developers to keep the technologies going ensures that people who need them will have a better option for getting the latest technologies without waiting for Apple. The one caveat here is that new releases might have compatibility bugs that users might have to contend with, but hopefully this will be a minimal occurrence.