And then the reveal: Mac OS X — sorry, OS X — is going on an iOS-esque one-major-update-per-year development schedule. This year’s update is scheduled for release in the summer, and is ready now for a developer preview release. Its name is Mountain Lion.1
Mountain Lion is the next iteration of Mac OS X. And while there are some changes since the original Lion was released just this past Summer, they are more like further improvements than real changes. I say this in part due to the concentration on aligning the OS X apps with iOS apps for small things like using the same name:
iCal versus Calendar
iChat versus Messages
Address book versus Contacts
Reminders versus Notes
Under the facial, superficial level more of the Carbonized libraries and apps are being factored out and being given full Cocoa libraries and app equivalents where possible. But one of the bigger changes, one that’s been slipping since the release of Mac OS X 10.7 is the use of ‘Sand-boxing’ as a security measure for Apps. The sand-box would be implemented by the Developers to adhere to strict rules set forth by Apple. Apps wouldn’t be allowed to do certain things anymore like writing to an external Filesystem, meaning saving or writing out to a USB drive without special privileges being asked for. Seems trivial at first but on the level of a day to day user of a given App it might break it altogether. I’m thinking of iMovie as an example where you can specify you want new Video clips saved into an Event Folder kept on an external hard drive. Will iMovie need to be re-written in order to work on Mountain Lion? Will sand-boxing hurt other Apple iApps as well?
Then there is the matter of ‘GateKeeper’ which is another OS mechanism to limit trust based on who the developer. Apple will issue security certificates to registered developers who post their software through the App Store, but independents who sell direct can also register for these certs as well, thus establishing a chain of trust from the developer to Apple to the OS X user. From that point you can choose to trust either just App store certified apps, independent developers who are Apple certified or unknown, uncertified apps. Depending on your needs the security level can be chosen according to which type of software you use. some people are big on free software which is the least likely to have a certification, but still may be more trustworthy than even the most ‘certified’ of AppStore software (I’m thinking emacs as an example). So sandboxes, gatekeepers all conspire to funnel developers into the desktop OS and thus make it much harder for developers of malware to infect Apple OS X computers.
These changes should be fully ready for consumption upon release of the OS in July. But as I mentioned sandboxing has been rolled back no less than two times so far. First roll-back occurred in November. The most recent rollback was here in February. The next target date for sandboxing is in June and should get all the Apple developers to get on board prior to the release of Mountain Lion the following month, in July. This reminds me a bit of the flexibility Apple had to show in the face of widespread criticism and active resistance to the Final Cut Pro X release last June. Apple had to scramble for a time to address concerns of bugs and stability under Mac OS X 10.7 (the previous Snow Leopard release seemed to work better for some who wrote on Apple support discussion forums). Apple quickly came up with an alternate route for dissatisfied customers who demanded satisfaction by giving copies of Final Cut Pro Studio 7 (with just the Final Cut Pro app included) to people who called up their support lines asking to substitute the older version of the software for a recent purchase of FCP X. Flexibility like this seems to be more frequent going forward which is great to see Apple’s willingness to adapt to an adverse situation of their own creation. We’ll see how this migration goes come July.
In the bad old days of 1996 when Apple’s marketshare hit rock bottom, everyone fled to Windows 95 en masse. Disparaging the Mac OS every single one of the ‘professional’ technical press predicted the end of Apple. Oh, how wrong they were and the Mac loyal fan-base crowed and shouted with joy that Apple has now achieved a terrific comeback. But, whither the loyal fan-base from days gone by from the Dark Ages pre-Steve, 1996? They will all become part of the iOS collective, they too will be assimilated. Read On:
Rumors of an ARM-based MacBook Air are not new. In May, one report claimed that Apple had built a test notebook featuring the same low-power A5 processor found in the iPad 2. The report, which came from Japan, suggested that Apple officials were impressed by the results of the experiment.
Following up on an article they did back on May 27th, and one prior to that on May 6th, AppleInsider does a bit of prediction and prognosticating about the eventual fusion of iOS and Mac OS X. What they see triggering this is an ARM chip that would be able to execute 64-bit binaries across all of the product lines (A fabled ARM A-6). How long would it take to do this consolidation and interweaving? How many combined updaters, security patches, Pro App updaters would it take to get OS X 10.7 to be ‘more’ like iOS than it is today? Software development is going to take a while and it’s not just a matter of cross-compiling to an ARM chip from a software based on Intel chips.
Given that 64-bit Intel Atom chips are already running on the new Seamircro SM10000 (x64), it won’t be long now I’m sure before the ARM equivalent ARM-15 chip hits full stride. The designers have been aiming for a 4-core ARM design that will be encompassed by the ARM-15 release real soon now (RSN). The next step after that chip is licensed and piloted, tested and put into production will be a 64-bit clean design. I’m curious to see if 64-bit will be applied across ALL the different product lines within Apple. Especially when the issue of power-usage and Thermal Design power (TDM) is considered, will 64-bit ARM chips be as battery friendly? I wonder. True Intel has jumped the 64-bit divide on the desktop with the Core 2 Duo line some time ago and made them somewhat battery friendly. But they cannot compare at all to the 10 hours+ one gets on a 32-bit ARM chip today using the iPad.
Lastly, App Developers will also need to keep their Xcode environment up to date and merge in new changes constantly up to the big cutover to ARM x64. No telling what that’s going to be like apart from the previous 2 problems I have raised here. Apple in the 10.7 Lion run-up was very late in providing the support and tools to allow the developers to get their Apps ready. I will say though that in the history of migrations in Apple’s hardware/software, they have done more of them, more successfully than any other company. So I think they will be able to pull it off no doubt, but there will be much wailing and gnashing of teeth. And hopefully we’ll see something better as the end-users of the technology, something better than a much bigger profit margin for Apple (though that seems to be the prime mover in most recent cases as Steve Jobs has done the long slow fade into obscurity).
If ARM x64 is inevitable and iOS on Everything too, then I’m hoping things don’t change so much I can’t do things similarly to the way I do them now on the desktop. Currently on OS X 10.7 I am ignoring completely:
AppStore (not really because I had to download Lion)
Let’s hope this roster doesn’t get even longer over time as the iOS becomes the de facto OS on all Apple Products. Because I was sure hoping the future would be brighter than this. And as AppleInsider quotes from May 6th,
“In addition to laptops, the report said that Apple would ‘presumably’ be looking to move its desktop Macs to ARM architecture as well. It characterized the transition to Apple-made chips for its line of computers as a ‘done deal’.”
Different Mac websites have been touting the advantages of upgrading to the latest version of the Mac OS. It’s known as Snow Leopard, OS X 10.6 and so forth. But what great re-engineering lies within the new OS cannot be easily tapped by us average users. Why? There’s lots of gotchas and dependencies to get a 64bit clean piece of hardware to use the 64bit clean software.
There is no doubt 64-bits is nice architectural change but it doesn’t mean you’re receiving all the benefits of the change. If Apple doesn’t quickly upgrade it’s vast stable of killer multimedia applications, it doesn’t really matter how good Snow Leopard is. Even after installing Snow Leopard it is hard for me to notice a significant difference. I would settle for some extra quickness or capability in iLife that wasn’t possible before Snow Leopard.
Add to this the fact you need a full 64-bit clean environment to really guarantee you are in 64bit mode. The boot-up environment known as EFI was n ot 64-bit clean until after 2008. The Intel CPU wasn’t 64-bit clean until after 2007. Two strikes against me as I was an early adopter of the Intel Architecture and am relegated to good ol’ 32-bit compatibility mode. Unless I decide to upgrade of course, which isn’t going to happen because I have a sworn duty to first replace my wife’s old PC after Windows 7 is formally released. Once that purchase is done and out of the way, then I will consider getting a re-furbished post 2008 Mac Pro tower with a fully OpenCL compatible graphics card. There’s just so many considerations, you need to keep writing all of them down so you don’t lose track.
Of course, Apple itself needs to deliver 64-bit versions of its own Logic Studio, Final Cut Studio, and Aperture, too. The company was previously outpaced by its third party developers in the move to PowerPC, and to a lesser extent, in the move to Intel Macs. Apple’s position as both a platform vendor and an application developer should help it to deliver practical, usable tools for its own developers.