In the unlikely event that you haven’t yet heard, let me be the one to break the news to you: the new iWork ’13 apps for OS X have been “dumbed down.” At least that’s the prevailing view. Distressed at the loss of numerous significant features from the previous iWork ’09 versions, including vanishing AppleScript support, many users have lamented that the new apps amount to “an unmitigated disaster.”

At the same time, other users have just as strongly cautioned against over-reacting to these changes. For example, in his Macworld review of Keynote 6.0, Joe Kissell wrote:

 “Despite the missing features, it would be unfair to characterize Keynote 6 as being ‘dumbed down.’ Indeed, Apple has added splendid capabilities that make Keynote smarter in several respects.”

Matthew Panzarino, writing on TechCrunch, offered a similar reaction:

“Lots of folks are getting all worked up about iWork being ‘dumbed down,’ but it feels like a reset to me.”

These more benign interpretations emphasize that the new iWork ’13 apps are not really upgrades from the previous versions. Rather, they are entirely redesigned-from-the-ground-up new programs. Having to make this sort of drastic revision, especially within the inevitable time and resource constraints, almost guarantees that some features will get dropped along the way.

So why did Apple make such drastic changes? The obvious and conventional wisdom answer is that Apple wanted to bring parity and cross-platform compatibility to the OS X and iOS versions of the iWork apps. Doing this required a rewrite of the software. In this goal, almost everyone agrees that Apple succeeded. You can seamlessly move among the apps on each platform without skipping a beat. As Jeffery Battersby put it in his review of Pages for iOS:

“There is now no noticeable difference between all of Apple’s Pages apps.”

Or, as Nigel Warren explained:

 “The fact that iWork on the Mac has lost functionality isn’t because Apple is blind to power users. It’s because they’re willing to make a short-term sacrifice in functionality so that they can create a foundation that is equal across the Mac, iOS, and web versions.”

Given the tortured history of cross-platform file syncing among iWork documents, this is great news. As for the lost features, the optimists expect them to return over time. There is certainly precedent for this expectation, most notably with Final Cut Pro X. Similarly, just last week, after the release of a new version of iMovie met with the same sorts of criticism, Apple promised that it will at least return the ability to import movie projects between iOS and Macs. Even better, Apple just announced that it intends to “reintroduce some of the [missing iWork] features in the next few releases.” [Update: See this Apple support article for more details.]

Still, there is a big question that remains: How far will this recovery go? Can we really expect that all or almost all of the MIA features will be restored? My answer is: No.

Given the admirable intent to maintain seamless cross-platform compatibility, Apple cannot restore features to the OS X versions of iWork apps unless those features can be matched on iOS devices, especially if the inconsistency would break the ability of a file to look and act the same on both platforms. Given the inherent limitations of iOS compared to OS X, including the more severe restrictions of sandboxing in iOS, this means that certain iWork ’09 features will be lost for a long long time. Perhaps forever.

As one example, I believe AppleScript falls into this category. There is no AppleScript in iOS, and I don’t expect this to change. As such, I doubt will we ever see any significant restoration of AppleScript in the OS X iWork apps. [Update: Despite Apple’s promise to “make improvements to AppleScript support” in future versions Keynote and Numbers, I don’t expect this to amount to much.] This doesn’t mean that Apple intends to entirely drop AppleScript from OS X. But it does mean a lessening of support for it going forward. There’s a chance that Apple might introduce some entirely new method of automation, one that works on both Macs and iOS devices. But I wouldn’t assign a high probability to this.

Apple’s actions here should not be a big surprise. They continue a trend that has been developing and growing over the past several years. Apple’s mobile devices have eclipsed Macs as the company’s primary source of revenue and profit. The result is that the evolution of OS X and OS X apps is driven by how well they integrate with iPhones and iPads.

Apple isn’t abandoning its power users. At least not yet. There’s a new Mac Pro coming (although it has already caused some grumbling due to its lack of internal expandability) and Apple continues to support apps such as Final Cut Pro. But these make up a shrinking portion of Apple’s revenue. And they live in an environment separate from concerns about iOS compatibility. There’s no iOS equivalent of Final Cut Pro.

The consumer market is Apple’s future, its “bread-and-butter.” Many analysts have predicted that, over the next several years, desktop machines — and perhaps even laptops— will all but vanish as users increasingly adopt tablets as their only computing device. To the extent that this happens, for any consumer Mac software that survives, compatibility with iOS devices will far outweigh any consideration about what “pro” features may be missing. Marco Tabini makes a similar point in a recent Macworld article:

 “…it’s also possible that Apple is ‘dumbing down’ its apps because the company believes that the kind of comprehensive software to which we have become accustomed will no longer belong in the personal computing landscape of the future.”

I agree. For the vast majority of users, what we used to do with apps such as iWork (and Microsoft Office, for that matter) will become an increasingly distant and irrelevant memory. What we expect from computing devices and how we interact them is undergoing a dramatic shift. Inexpensive, more focused, simple-to-use software is the currency of the day. The new iWork apps are not an aberration. Despite what concessions Apple may make going forward, Apple has no intention of reversing directions. Whether you call it “dumbing down” or “iOS-ification,” whether you view it as an overall positive or negative shift, this is where things are headed. Get on board, get out of the way, or get run over.

What happens at WWDC, stays at WWDC. At least that’s what Apple warns its attendees.

Prominently displayed at several locations in Moscone Center during WWDC week were signs stating in no uncertain terms that all sessions, labs and everything else at WWDC — with the exception of the keynote — were confidential. Attendees were bound by an non-disclosure agreement (NDA) to say nothing publicly about any of it. Not to a reporter. Not in a blog. Not on a cloud. Not in a fog.

At first blush, this seems quite reasonable. Apple’s WWDC sessions and labs go into unpublished and publicly unannounced details about the workings of its future products. This year, this meant primarily iOS 7 and OS X 10.9 Mavericks. Apple provides this information to developers so that they can update their apps in time for the release of the forthcoming OS versions. For everyone else, Apple wants the information to remain confidential — until the release date of the software.

That would all be fine except for one thing. The supposed confidential information isn’t confidential. Apple makes it freely available to everyone. And I mean everyone.

Yes, you too can access all the videos from the WWDC sessions as well as all other pre-release developer documentation. All you need to do is register as an Apple developer. There are no prerequisites, no qualifications and no cost for obtaining this status.

If you are willing to spend $99 to join a developer program, you additionally get access to beta versions of upcoming software. Again, anyone with $99 can do this. Journalists, bloggers, even engineers from competing companies. There are no restrictions.

So what’s the point of holding developers to an NDA for this material? If everyone on Earth can obtain the information, with Apple’s permission, in what sense does it make sense to call it “confidential”? As far as I can tell, the answer is “in no sense.”

Okay, I can see one potential basis for a legitimate case here. While anyone can legally acquire Apple’s confidential information by becoming a developer, they remain restricted from writing or talking about it. This, in theory, limits the public distribution of the information. As most people will never bother to register as a developer, most people would never find out about the NDA-restricted material.

The problem with this case is that it doesn’t work in reality. Once non-developers get access to the information, often by registering to be a developer, at least some of them wind up writing about it or telling others who then write about it — NDA or not. And the rest of the media wind up linking to those articles. In the end, everyone winds up with access to the supposed confidential everyone.

Perhaps if Apple threatened or carried out legal actions against such violations, people under the NDA would be reluctant to make these disclosures. This hasn’t happened, at least not in many years. Without even a half-hearted pretense of such a threat, the NDA has no teeth. While many developers may honor it, the information leaks out anyway. So, again I ask, what’s the point?

Perhaps you’re thinking: Apple may be protecting confidential information that can get exchanged between Apple employees and developers during WWDC. Doubtful. Apple employees are well trained to know what they can and cannot say. It would be rare for an Apple employee to spill the beans on anything Apple really wanted kept secret.

Making things more difficult, there is often a blurry line between what is okay to talk about, because it was covered in the keynote or on Apple webpages that preview forthcoming products, and what is not okay.

Even the OS beta software is hardly kept under wraps. Apple actually provides the beta software to selected media. For example, you may have noticed that Macworld is running a series of “Hands on with Mavericks” articles by Jason Snell. Snell is using a beta copy of Mavericks that Apple provided without any NDA or other restrictions attached. This permission was presumably granted because Apple recognizes that it gets more benefit from the free publicity than it risks harm from the information being exposed.

Once Macworld (and similarly Apple-favored sites) can write about working with these beta versions, the cat is certainly out of the bag. I see no point in Apple maintaining NDA restrictions for “the rest of us.”

Bottom line

I’m not saying that all Apple confidentiality restrictions should be eliminated. There are times when they are appropriate. For example, in the months prior to WWDC, Apple seeded a few Mac Pros to developers for testing. These people were under an NDA not to reveal anything about these machines. Totally understandable. And the NDA worked, primarily because very few people had such access — and  because I’m sure Apple made it clear that there would be serious sanctions for violations.

Apple’s general restrictions surrounding material released at WWDC, however, have become almost meaningless. Really, the same can be said about any information that can be accessed simply by registering for free developer status — as well as for beta OS software. Maybe there was a time, years ago, when these restrictions made sense. That time has passed.

Apple is already unofficially behaving as if the NDA hardly matters here. The end result is about the same as if Apple abandoned these restrictions. About the same that is for everyone except the people caught in the middle — the developers and journalists who want to do the “right” thing even when it seems as if everyone else, including Apple, does not care.

I am not optimistic that Apple will change its official policies any time soon. Secrecy is so much a part of Apple’s DNA that I imagine it’s very hard for them to pivot on this matter. Still, this year’s WWDC announcements remind us that Apple retains the capacity to surprise us with big changes. So I maintain a glimmer of hope that Apple may eventually drop, or at least significantly curtail, these unenforced and largely unnecessary NDA restrictions.

One of the more intriguing revelations from Apple’s recent WWDC was that iOS 7 will ship with support for physical game controllers, much like the ones that now come with game consoles from the likes of Nintendo, Microsoft and Sony. While this nugget was barely mentioned during the keynote, its ripple effects may be huge — as I’ll get to shortly.

But before getting there, I want to explore what initially struck me as two likely obstacles in the way of success for iOS game controllers.

Touch vs. controller

First, iOS is all about a touch interface. Touching the screen is the main way, almost the only way, you interact with an iPhone or iPad. With a game controller in your hands, you won’t be touching the screen at all — at least not during game play. As such, the game controller is in conflict with a core property of iOS devices.

The same can be said, I suppose, about physical keyboards for iOS. Yet they have proven to be a popular peripheral. However, with keyboards, there is a direct translation of the actions taken: you can almost seamlessly switch back and forth between the two types of keyboard inputs without needing any significant relearning of how things work.

With most iOS games, especially ones that depend heavily on touch actions for game play, shifting to a game controller will likely require a significant amount of work, both for the game developer to modify the code and for the user to learn a different way to play.

In many cases, I expect such efforts will get “lost in translation.” One example of this is the mega-popular Angry Birds. There is a Mac version of the iOS game; you play it mainly using a trackpad or mouse as an input device. While not identical, this is similar to shifting to a game controller. No matter how many times I’ve tried, the Mac version never comes close to matching the simple intuitive experience of playing the game on an iOS device. To put it bluntly, Angry Birds on a Mac is a dud. As such, I do not look forward to a game controller version of Angry Birds.

On the other hand, the best candidates for conversion to a game controller are games that already work via a virtual version of such a controller, such as car racing games and many shooter games. Here, at least, I can see physical controllers having success. They may actually improve the game experience, as your fingers will not get in the way of seeing what’s on the screen.

Small vs. large

Even without the touch obstacle, there remains a second notable problem: size.

A typical game controller is at least the same size as an iPhone or iPod touch, usually larger. It strikes me as awkward to have a game display be significantly smaller than the controller you’re holding. There’s also the matter of convenience. Will iPod touch owners want to carry a game controller in their pocket, ready to pull out whenever they wish to play a game? I don’t think so. Doing so significantly lessens the appeal of the iPod touch as an on-the-go gaming device.

The iPad is a better match for a game controller here, but is not completely immune to these size problems.

Wait! There’s another iOS device…

Given these obstacles, it seemed to me that the potential market for iOS game controllers was a limited one at best. I’m confident that Apple is aware of all these considerations. Yet, they appear unconcerned. Why? With a bit more thought, the likely answer hit me…

There is another iOS device, beyond the iPhone, iPad, and iPod touch. It’s the Apple TV (ATV). Despite running on a variation of iOS, ATV doesn’t use a touch interface and it typically connects to large displays. In other words, ATV circumvents the very problems I’ve described here, making it a perfect candidate for working with a game controller.

Recall that earlier this year, Apple enabled Bluetooth keyboards to work with ATV. This dovetails nicely with forthcoming Bluetooth game controllers that would similarly work with ATV.

The final piece needed to make all of this fit together would be a separate Apple TV App Store, accessible from the ATV itself. From here, you could purchase games specifically designed to work with ATV and its non-touch interface. My Macworld colleague, Dan Frakes, came to a similar conclusion, as we tweeted a couple of weeks ago.

An Apple TV App Store might additionally include apps beyond games, such as TV network apps. This would allow users to add channels such as HBO GO without having to depend on Apple updating the ATV iOS to do so.

An Apple TV, combined with a game controller and an App Store, would quickly emerge as a serious contender for the top of the heap of game consoles. A recent article expanded on this theme, exactly predicting that “Apple TV will…dominate the console gaming market.” (Thanks to The Loop for pointing me to this article.)

I do see at least one obstacle for ATV to overcome: storage. Unlike iPhones, iPod touches, and iPads, there is no user-accessible internal storage in an Apple TV. So where will users save all the apps that they purchase and presumably download? Will Apple release a new ATV model, one that includes user-accessible space on an SSD? Will an ATV App Store only work with these latest devices? Or will Apple find some way, possibly via iCloud streaming, to make the system work with existing ATV’s?

I don’t know the answer. But I strongly suspect that Apple already has one. When iOS 7 gets released this fall, I predict that Apple will simultaneously announce a modified (either via hardware or software, or both) Apple TV as a primary target for game controller support.