Lion is the first OS X release to drop support for any Intel processors – machines using 32-bit Core Solo and Core Duo machines (sold mostly in 2006 at the very beginning of the Intel switch) aren’t able to install the new OS without hacking (which is outside the scope of this review). This is common practice for Apple, whom habitually irks a small but vocal portion of its userbase who insist (not altogether unreasonably) that their Macs are still running just fine.

Apple usually doesn’t do this lightly – in most cases, dropping support for older models is done to move the platform forward (though, as when 10.4 dropped support for Macs without FireWire, it can also be done to push particular proprietary technology). Just as Snow Leopard pulled support for PowerPC Macs to emphasize Intel development, Lion will pull support for x86 to push 64-bit development.

I’ve seen quite a bit of confusion on this topic (and there was quite a bit when Snow Leopard trumpeted full 64-bit support at its release), so I want to go into some detail about the history of 64-bit OS X. If you’re not interested in that, though, let me lay out the most important stuff in brief:

  • Core Solo and Core Duo-equipped Macs are the only Intel Macs being dropped by Lion. Even if it can’t boot the 64-bit kernel of Lion or support 64-bit EFI, any Mac that came with a Core 2 Duo (or any 64-bit capable Intel processor) can install and run Lion without modification.
  • Core 2 Duo-equipped Macs that don’t support OS X’s 64-bit kernel or 64-bit EFI can still run 64-bit apps, which can address more than 4GB of RAM.
  • The Lion installer isn’t actually doing checks for processor capability, but for your Mac’s model identifier, meaning that Core Solo and Core Duo Mac Minis and iMacs that were later upgraded to Core 2 Duo processors will still fail to install Lion without modification because the installer assumes they’ll be running 32-bit processors (though if you can get Lion running, your processor should be able to run everything just fine). Remember that these processor upgrades, while technically possible, were never supported by Apple.

Now for a history lesson, combined with about as much information about Lion’s 64-bit support as you could ever want.

64-bit in Mac OS X 

OS X’s 64-bit implementation differs significantly from that of Windows, which treats its 32-bit and 64-bit versions as two distinct operating systems stored on different install media. This is done mostly to maintain Windows’ compatibility with older applications – moving or renaming things like the System32 folder would break programs that expected it to be there – and as a result the two are separated to the point that there isn’t even an upgrade path between 32-bit Windows and 64-bit Windows. Because of this, and because Windows applications and drivers usually have distinct 32-bit and 64-bit versions, Windows’ transition to 64-bit has been slightly rockier and slightly more visible to the user.

OS X, on the other hand, has made a more gradual transition between 32-bit and 64-bit, with support added slowly over the course of multiple releases. OS X 10.3 and 10.4 came with some basic support for 64-bit underpinnings, but support for 64-bit applications didn’t come until 10.5 Leopard (which included the 64-bit version of Cocoa, OS X’s primary API). The same technology that allowed developers to offer Intel and PowerPC programs as a single Universal Binary also allows developers to release single packages that support both the x86 and x64 architectures.

While Leopard brought support for 64-bit apps that can address more than 4GB of memory, Snow Leopard actually introduced an OS kernel (along with 64-bit kernel extensions and drivers) that was 64-bit, though a 32-bit kernel was used by default on almost all Macs whether they supported the 64-bit kernel or not. This was done mostly to give software developers time to get 64-bit KEXTs and drivers ready – since Snow Leopard’s release, Apple has released both Mac Pros and MacBook Pros that boot with the 64-bit kernel by default (and OS X Server uses a 64-bit kernel by default in even more models, as outlined in this Apple support document).

Lion pushes this a bit further by booting a 64-bit kernel on basically any Mac that supports it – the 2007 aluminum iMac, the 2009 unibody MacBook Pro, and the 2010 MacBook Air I used booted Snow Leopard with the 32-bit kernel by default, but booted with the 64-bit kernel for Lion (and the iMac and the Air didn't even support the 64-bit kernel in Snow Leopard). That being said, Lion still includes the 32-bit OS X kernel, and will use it on machines that don’t support the 64-bit kernel – you can still make full use of 64-bit apps and more than 4GB of RAM, even though the OS kernel itself can’t. This won't usually be a big deal, since the Macs that can’t use the 64-bit kernel are mostly older models with RAM caps at or under 4GB anyway.

In both Snow Leopard and Lion, you can check your kernel's 64-bitness by opening up System Profiler/Information, going to the Software section, and looking at the "64-bit Kernel and Extensions" field. Yes means a 64-bit kernel, No means 32-bit.

Lion with a 32-bit kernel on a 2008 MacBook

Support for the 64-bit kernel requires four things to be true: You need (obviously) a 64-bit Intel processor, a Mac that supports 64-bit EFI, hardware for which OS X has 64-bit drivers (graphics cards are usually the problematic area here), and a Mac that has not been specifically disallowed from booting the 64-bit kernel – most new Macs support the 64-bit kernel, but white MacBooks are still artificially limited by Apple from booting the 64-bit kernel in Snow Leopard despite hardware that fully supports it. Most if not all of these artificial limitations have been removed in Lion for machines that meet the other 64-bit criteria.

Apple began really pushing 64-bit with its marketing for Snow Leopard, and has been dropping support for 32-bit APIs like Carbon for years – giving developers aiming for Lion guaranteed 64-bit capability both enables them to better take advantage of the architecture improvements and saves them the effort (and file size) of also supporting a 32-bit version. That said, 32-bit programs will continue to run fine in Lion, just as they ran fine in Snow Leopard and Leopard before it.

The hidden downside of the 64-bit push for Core Solo and Core Duo users is that, as developers slowly move to 64-bit only applications, we’ll start getting more and more things that won’t run on 32-bit Snow Leopard despite being supported on 64-bit Snow Leopard (the same thing is currently happening to Leopard users still using PowerPC processors – Flash Player, Google Chrome, Firefox 4, and Microsoft Office 2011 are all fairly mainstream apps that run in Leopard but only on Intel machines). The disappearance of 32-bit programs will be gradual, but it is something to be wary of if you continue to use a Core Solo or Core Duo Mac going forward.

What gets dropped next?

This discussion isn’t complete without a look into our murky crystal ball to see what Macs will be dropped by the next version of Mac OS. The continued push for 64-bit makes me think that we could see machines incapable of running the 64-bit kernel dropped, though that line in the sand could be too faint for most consumers to see, especially given the scarce and not-always-clear documentation on what Macs support it in the first place.

It’s worth noting that Apple could easily issue EFI, KEXT, and driver updates for any Macs it wants to enable to run the 64-bit kernel – there are some models like the 2007 aluminum iMac (iMac 7,1, for those who prefer information pulled from System Profiler) that didn’t support Snow Leopard’s 64-bit kernel, but boot with Lion’s 64-bit kernel by default.

The more likely cutoff point for 10.8 (or OS XI, or whatever comes next) is graphics-related – Apple has been shipping mostly OpenCL-capable products since 2009, and by the time the next Mac OS is upon us (2013-ish, at the current rate), products pre-dating OpenCL support will mostly be four and five years old (roughly the same age as the current Core Solo/Duo Macs). If Apple continues its trend of dropping products that hold back the platform in one way or another, pre-OpenCL machines seem to be the most likely candidates on the chopping block.

Screen Sharing, Boot Camp, Migration Assistant SMB File Sharing in Lion
Comments Locked

106 Comments

View All Comments

  • ebolamonkey3 - Thursday, July 21, 2011 - link

    Not seeing them :(
  • LeTiger - Thursday, July 21, 2011 - link

    Ever fix the 17in Sata 3 bugs????

    Such a shame to belligerently cripple their flagship laptop...
  • Conficio - Thursday, July 21, 2011 - link

    "There is one huge limitation though: running apps in full screen in multi-monitor setup is unusable."

    As full screen apps are essentially spaces, there is a huge need (and there was for a long time) to be able to manage spaces per screen. All that would be solved if I coul switch between the spaces in a single screen only or move around entire spaces from one screen to another. That would solve this issue and allow a more task oriented kind of work, where you open a space for every task (or project in a multi tasking sense) you are working on and you can open the various apps you need to work on that project. But then that is the opposite of opening all past docs in an app (?)
  • Conficio - Thursday, July 21, 2011 - link

    "If you were able to include the location in the Quick Add, Quick Add would actually provide a great overall solution for adding new events, but now you need to add the location separately, which kind of defeats the purpose."

    This concept is as ripe as a green banana. I want to be able to mark the text in an e-mail in order to create an event (with link back to the original e-mail). That way I can work with the lazy people that send invitations in any other format than calendar.

    Byt the way go even one more step Appple, and scan all e-mail for addresses, contact info and events and highlight those and with a single click allow me to add the info to my address book or calendar (and with an option send to others in a iCal or vCard format). That would be real progress!
  • teryan2006 - Saturday, July 23, 2011 - link

    umm… I've been doing what you describe, highlighting text in Mail in order to create an event since 10.5. (screenshot: http://cl.ly/25402N2W2E0n281W0r09 )

    Same thing with the email address and contact info. They've been in Mail ever since they added data detectors. http://cl.ly/3V2q0D1z1x1M1X2q0v1v

    If you hover near an email address, time, date, street address, there's a dropdown button that shows up. New in 10.7 is QuickLook style preview for URL in a message

    Did you disabled data detectors? Maybe that's why you're not seeing these things?
  • name99 - Thursday, July 21, 2011 - link

    "I don’t find any use for Launchpad. It's one of the less successful iOS imports - it doesn’t fit in, nor does it bring anything truly new,"

    I think this was a foolish comment. The first sentence is fine, the second is not.
    Not every feature in an OS upgrade is targeted at the same collection of users --- I, for example, couldn't care less about full disk encryption.

    I know for a fact that naive users (precisely the people who don't understand the file system, a class you seem to accept does exist) are completely unfamiliar with the Applications folder. For THIS sort of user, Launchpad is exactly what they need --- an easily understood way to run programs they don't frequently run.

    As for you and I, we can just ignore it --- just I like ignore Japanese input methods, or LDAP support, or a hundred other aspects of my mac that aren't relevant to my particular situation.
  • name99 - Thursday, July 21, 2011 - link

    To follow up on what I said, comparing Launchpad with a Stacks view of the Application folder kinda misses the point. The sort of naive user we're discussing doesn't understand that he may have apps sitting on the desktop, or in the Downloads folder, or in the Utilities folder of /Applications.

    The Stacks view you describe is limited precisely because it is based on PLACE, not on on TYPE, whereas what users almost always want is based on TYPE.

    The fact that it does not honor your pre-existing folder structure is, I would say, in Apple's eyes a temporary issue. Consider iTunes. iTunes doesn't create playlists based on how you grouped songs in the file system --- it assumes that your songs are stored in some bag in the file system somewhere that you will never look at, and imposes its own structure on that content. Launchpad is a vastly simplified version of that same idea, and part of the constant theme throughout Apple's past five+ years of UI work --- arrange content using appropriate metaphors in a high level app, NOT using a limited set of constructs at the file system level.
  • hanssonrickard - Thursday, July 21, 2011 - link

    For example, then macbook pro 15" 2.4 Ghz Core2Duo from early 2008 does NOT support AirDrop.

    Here is compatiblitly list for it and maybe the article shouldbe updated with some kind of note that not all macs will support airdrop.

    Info from "http://support.apple.com/kb/HT4783"

    ----
    Macs that support AirDrop in OS X Lion

    The following list shows the earliest of each Mac model type that is supported. If your Mac is the same, or newer than the model listed, then it supports AirDrop.

    MacBookPro (Late 2008 or newer)
    MacBook Air (Late 2010 or newer)
    MacBook (Late 2008 or newer)
    iMac (Early 2009 or newer)
    Mac Mini (Mid 2010 or newer)
    Mac Pro (Early 2009 with AirPort Extreme card, or Mid 2010)
    ------
  • makruger - Thursday, July 21, 2011 - link

    Too bad it won't run on normal PC hardware without becoming an iHack
  • Sapan - Thursday, July 21, 2011 - link

    Does anyone know for sure if OSX Lion enables TRIM Support for 3rd Party SSDs?
    I know 10.6.8 enabled TRIM for Apple SSDs.
    Could you provide some background/link to how you got that info please?

Log in

Don't have an account? Sign up now