Apple already has “universal apps” that run on both iPhones and iPads, from a single binary. The user only has to buy an app once, and it will run on any iOS device they have. (Note that not all companies provide their apps this way, and I believe companies like Omni Group and others that sell their apps separately for the iPhone and iPad are desperately clinging to the past, but that’s the subject of another post.)

But why not take this a step further? Why not have apps that run on iPhones and iPads also run on Macs? Why bother having 2 App Stores, one for iOS and one for OS X? Microsoft is going down this route with their (future) plans to merge their Windows and Windows Phone stores. But how can Apple do something similar without running into the same problem Windows 8 has, which is making the desktop experience catered too much to a touch interface? How can Apple leverage their thousands of iOS developers and get them to be OS X developers?

There are several ways that  Apple can do this, including Storyboards for OS X, iWatch, Apple TV, and CarPlay.

First, a little background. iOS is actually very similar to OS X, when you strip off the user interface–they both use the same “engine”, namely the Foundation libraries. This is similar to how VWs and Audis look and drive differently, but both share many of the same engines, such as the 2.0L turbo 4 cylinder.

So developers (or is that “Developers! Developers! Developers!”?) can, even now, create shared libraries for the “back end” parts of their apps. This includes things like networking, using web services, file management, encryption, XML and JSON processing, etc.

But writing the user interface for iOS apps uses libraries called Cocoa Touch, while writing the UI for OS X apps uses libraries called Cocoa. There are several important things to note about the similarities and differences between Cocoa and Cocoa Touch:

1. To the user, they look somewhat different. The buttons and controls tend to be much taller in Cocoa Touch because a user needs to be able to easily touch a button without touching the button next to it or above it.
2. They share many of the same types of controls: buttons, labels, images, text input fields, etc.
3. Cocoa has more, and more complex, controls. For example, you can create spreadsheet-like grids in an OS X app by using a built-in control, whereas on iOS you’d have to create your own custom control from scratch.
4. Cocoa controls are optimized for mouse and keyboard input (you can Tab between input fields, for example, and use the Home and End keys to move the cursor around), while Cocoa Touch controls are optimized for touch input (gestures, swipes, etc.).
5. The way a developer draws onto the screen is inverted in the two systems: In Cocoa Touch, you start at the upper left and higher numbers go down. In Cocoa, you start at the lower left and higher numbers go up.
6. There are other major differences, where generally Cocoa is more complex, robust, and mature than Cocoa Touch. For example, Cocoa Touch only has one “window” which is essentially the entire iPhone or iPad screen. In Cocoa, your Mac apps can have multiple, overlapping windows that you can move around on the screen.

These differences are why Apple has not (and probably never will) completely merge iOS and OS X, the way Microsoft is doing with Windows 8. But I think there is an opportunity for Apple to move some or all of Cocoa Touch to OS X.

If they do, it means developers might have a Storyboard (for layout out their apps) not only for iPhone and iPad, but also for Macs. It means it could be much, much easier for the hundreds of thousands of iOS developers to release apps that also work on a Mac (but aren’t just iPad or iPhone apps stretched to fill a 24-inch monitor).

How could Apple do this? One way would be to port the existing Cocoa Touch controls over to OS X, but add more keyboard and mouse interactivity to them. (As I mentioned in an article a couple days ago, Apple will be introducing OS X 10.10 with a decidedly iOS 7-y look and feel, and potentially taller controls that may be more tap-friendly.) iOS developers would then simply create a new storyboard for a Mac, in addition to iPhones and iPads. There might be some compromises here. Developers may not be able to use multiple windows–their apps might have to be full-screen–and they may not be able to use the more complex controls available on the Mac, such as the grid control I spoke about earlier.

But it could be a quick way to leverage all those iOS developers and build a huge porfolio of native Mac apps which would then give desktop and laptop Mac users a much richer array of apps to choose from.

And if Apple were serious about its A7 (and coming A8) 64-bit “desktop class” ARM processors, they could even port the keyboard-and-mouse-optimized controls back to iOS, and produce an ARM-based laptop for much cheaper than an Intel laptop would cost.

Now I’m not saying all of this (or, actually, any of this) will happen next week at WWDC 2014. But I do think Apple has to at least be thinking about this. Creating a much larger market for Macs (even ARM-based Macs) by porting iOS controls intelligently over to OS X would be a great way to increase their PC market share.