Swift.org – Core Libraries: “The Swift.org version of Foundation makes use of many of the same underlying libraries (e.g. ICU and CoreFoundation) as Apple’s implementation, but has been built to be completely independent of the Objective-C runtime. Because of this, it is a substantial reimplementation of the same API, using pure Swift code layered on top of these common underlying libraries.”

This is the beginning of the radical departure from Cocoa I’m hoping for. A day when all Framework code for building Mac and iOS applications is void of Objective-C, or mostly void of it. Not that Objective-C and Cocoa are bad, they’re not. It’s just time to move on.

Yes, it will take years and years and I doubt Apple will pull the rug out from under us any time soon. Look how long they supported Carbon, about 12-years. Think of Objective-C and Cocoa on that same, or similar, path.

Eat your own dog food.Come to think of it, Apple will probably support Cocoa and Objective-C much in the way Microsoft continues to support the Windows API. It’s still around, you can still write apps using it — the Office Apps still use it as well as most awesome legacy apps (like Photoshop) — but Microsoft is now pushing their Universal App platform. A platform that is based on .Net. I see Swift, the new runtime, and whatever new Swift only Frameworks as Apple’s .Net effort.

Will there be pain? Absolutely. Is it possible to overcome it? Of course it is. It will take a lot of work and planning for companies to move to Swift and Framework X, but it will take years for Apple to get there, so we all have quite a bit of time.

I know our little group of developers at Agrian is writing 100% Swift today. We have a substantial investment in Objective-C and Cocoa (obviously), but all new code is written in Swift and we’re slowly refactoring areas of code that are easy to isolate into Swift. It’s been a fairly smooth transition.

From planning to chaos (“We’re screwed”) to literal tears of joy, Photoshop team members talk about the single toughest cycle in the app’s long history. – John Nack on Adobe, March, 2011

Large companies like Adobe and Microsoft have a considerable investment in C and C++ over the years to make their applications portable. Their move to Swift may — in many ways — be easier than the transition to Swift and Framework X for small shops that are 100% reliant on direct access to Cocoa.

With a common C++ core, a thin native UX layer and evolving PALs, Microsoft is building its Office apps so they work on different OSes with fairly little tweaking required. Zaika cited PowerPoint as an example, noting that only four percent of its tens of millions of lines are unique to the WinRT/Universal version of Office (the touch-first Office release some of us have been calling “Gemini” ). If the XAML code is excluded, the amount of shared code is 98.6 percent he said. The PowerPoint for Android code base includes 95 percent shared code, Zaika said. – All about Microsoft, October, 2014

Microsoft has a complete architecture of shared code in Office that is C++ and abstracts the app from the OS layer, I’d imagine Adobe’s layer is very similar. I’ve called this the “Grilled Cheese” approach.

Here’s hoping we see a fresh approach to building on iOS, tvOS, and OS X.

P.S. – If you ever feel down about a development cycle visit John Nack’s old Adobe blog and watch the video about the transition from Carbon to Cocoa. It’s very inspirational. These folks really went through the ringer to ship a Cocoa using Photoshop. Smart, smart, people.