Six Things Developers Want In Mac OS 11

We’re betting that OS 11 is the syncretic end of separate Mac OS and iOS systems. Here’s what we hope developer frameworks for a unified Apple OS might look like.

Six Things Developers Want In Mac OS 11

We’re just as excited as anyone else for iOS 7 and Mac OS 10.9. But based on the features we saw at WWDC, we can’t help but think that the two OSes will eventually converge. When the unification happens between Apple’s Mac OS and iOS, here are the developer frameworks we hope come along with it. (Check out our sister site Co.Design for their design-related Mac OS wishlist.)


Internet of things frameworks for dumb household devices.

Mac developers are going to want to integrate all sorts of simple, UI-less devices into the Apple ecosystem. For that, they’ll need an expanded Passkit framework, the library that allows developers to integrate their apps with Apple’s Passbook app. A more robust Passkit would allow developers to pass the metadata of digital “passes” into programmable things, which in our opinion can be more convenient than having all the info tucked away in an app. Also, it would be nice to allow these smart objects to do out-of-the-box peer-to-peer communication and voice-over-Bonjour the way games built with Apple’s GameKit framework can.

More webhooks APIs for native app integration

The new versions of Mac OS and iOS allow notifications to be generated by webhooks coming from websites like ours. As a web development shop, this lets us experiment with new interactions: One annoying example might be pushing out a desktop notification to subscribers when new articles publish online. But that’s just the beginning of what we need for real web integration with Apple’s OSes. For one thing, how about allowing web apps to occupy space in the Mac OS dock, as they can on iOS? Or giving web developers access to some of the APIs that power native apps, so they can create native-web hybrid apps where appropriate?

Robust desktop widget-building kit.

Yes, the file system is a total mess–we’ll get to that–but the problem of the desktop deserves separate discussion. Right now, the onus is on app-makers to help users manage files across devices, and always within deeply nested hierarchies in the file system of the device. How about allowing users to bring their files-of-the-moment to the surface? Make the Mac and iOS desktops accessible from the cloud so that developers can build apps that live solely on top of the desktop, with access to only the content there? Mac OS has had “widgets” in the dashboard for ages, but without file system access, these tiny Web apps are impotent.


A revamped file system and icloud. with no rampant file duplication and with better backup schemes.

Today, managing files across Mac OS and iOS means using at least one third-party cloud provider like Dropbox–not very user-friendly, Apple. ICloud only handles certain types of documents and data, making it an incomplete solution for developers and users alike. But those are just quibbles. Worse yet, precious space on our SSDs is wasted to all the duplication going on. Opening files in several iOS apps means duping the file to be stored separately in each app–a real pain if you work with a lot of PDFs on a low-end iPad or iPhone. On Mac OS, keeping things in Dropbox or Box still means you need them living on your hard drive, when in reality, less-used stuff should naturally drift towards being stored in the cloud only (to save space.) Capping off this whole can of worms is the lack of a comprehensive and customizable backup system. Time Machine is great, except when it has forgotten to back itself up or has run out of space on your backup drive without adequately letting you know. Letting developers build on top of a Time Machine framework would help ensure even niche backup cases can be accounted for.

Easier and wider ranging hardware integration. Right now, Apple leaves it to manufacturers to set protocols, and iOS developers must deal with manufacturers. It would be great if Apple took a more active role, allowing for easier hardware development. Apple’s developer docs leave us feeling somewhat cold on the topic:

Manufacturers must build explicit support into their accessory hardware for communicating with iOS. As part of this support, an accessory must support at least one command protocol, which is a custom scheme for sending data back and forth between the accessory and an attached app. Apple does not maintain a registry of protocols; it is up to the manufacturer to decide which protocols to support and whether to use custom protocols or standard protocols supported by other manufacturers.

Deeper open social network connectivity with integrated contact management.

We all have too many friends, Cupertino, and it’s too difficult to merge them all into one place. Hurry up and combine AddressBook and Social framework so users and app developers keep everyone organized. (Below, the sum total of the powers of iOS Social framework today:

  • Create a network session.
  • Get the activity feed for a user.
  • Make a new post.
  • Set properties on a post, add attachments, etc.
  • Publish a post to an activity feed.

Right now, Apple’s Social framework only supports Facebook and Twitter, and only a few different types of actions are supported out of the box (see above). We’d like to see integration for, say, the top 50 social networks at home and abroad–far beyond the rumored LinkedIn integration–and make Apple’s validation of a social network the gold standard it’s become in other partnerships.


H3: Read our design wishlist for Mac OS 11 here from our sister site, FastCo.Design.

Have suggestions for Apple developer resources for future versions of Mac OS and iOS? Think our ideas are dumb? Let’s hear yours on Twitter.

[Genie Lamp: Daniel Wiedemann via Shutterstock]


About the author

I've written about innovation, design, and technology for Fast Company since 2007. I was the co-founding editor of FastCoLabs