Great news for any parsimonious enterprise IT group was Apple’s announcement last week that iWork is now free on all new iOS devices and Macs. iWork is Apple’s productivity suite for iPhone, iPad, Macs, and–with a web version–PCs running Windows or other OSes. iWork includes Pages, a word processor; Numbers, a spreadsheet; and Keynote, a presentation program.

While iWork isn’t direct competition for Microsoft Office on the desktop, it is certainly good enough for just about any productivity needs on a mobile device. And, unlike Office on Windows RT on the Surface 2, iWork is optimized for touch-based devices and small screens, so it’s very easy to learn and use.

What’s nice about the new versions of iWork is that they share the same feature set across all 3 platforms: iOS, OS X, and Web. (I predicted as much in an earlier blog post here.)

There has been some hand wringing about how Apple got there, though. What Apple did was basically port the iOS versions to the Web and OS X. That was fine for the Web version, as it’s brand new. What happened with the OS X version, though, was that some features got cut. Long term, this makes perfect sense, but if you used the previous version of Pages, for example, and really depended on a feature that was cut out, you’re kind of stuck.

One small consolation: When you install iWork in OS X Mavericks, it won’t overwrite your existing iWork suite, so you can still edit those older files. Just don’t open them up in the new version, or you’ll lose that feature in that file. Also, on a Mac that is still running an older version of OS X, you can still download the older version of the iWork suite from the App Store.

But, clearly, the idea is that, going forward, you’ll use the new versions because then the files will work seamlessly across iOS, OS X, and the Web versions of iWork.

Which brings us to my final point. In order to get all these iWork apps on different platforms to work seamlessly together (having files stored in iCloud), Apple devised a new, common file format (which I also predicted in my earlier blog post). Again there has been some hand-wringing (by Nick Heer on his Pixel Envy blog), where he ends with this concern:

I think the new file format is a regression, though. I would love to know the justification for these obfuscated data files, and what advantages they bring over the previous XML-based format.

Well, as anyone who has written code for mobile devices will tell you, the justification is simple: efficiency. On a mobile device, you’re dealing with a slower (although with the A7, not much slower) processor with more limited RAM and storage space than a desktop or laptop (that gap, too, is closing), and a much smaller battery.

Battery life is critical on a mobile device, and it’s clear that Apple puts a huge premium on battery-saving technologies and techniques. Processing a native binary format is much more battery-efficient than parsing, re-parsing, generating, and re-generating XML or some other human-readable format on the fly.

So, like any great idea, the common feature set and file format across iOS, OS X, and the Web brings many plusses and a few minuses. But Apple is always focused on what is most important to users. In mobility, one of those things is all-day battery life, even while using productivity apps like iWork.