Tag Archives: Cocoa

Future macOS Frameworks

Duct Tape, fixer of all things!I stumbled upon an interesting conversation between some well know Apple Ecosystem Developers this morning discussing, maybe lamenting, the lack of UIKit on macOS. I’m afraid I may have pushed these fellas to take their conversation private, I am sorry if that was the case.

Here’s the tweet that started the conversation:

https://twitter.com/stroughtonsmith/status/779726806727491584

I’m not known in any development communities. I’m what you’d call a nobody. But I’m a nobody with years of experience that has seen changes to my development ecosystem.

Having experienced a dramatic shift in Windows Development technologies I have opinions about what I would expect to see from Apple. These opinions and $10.00 should be enough to buy you any item on a Starbucks drink menu. Take if for what it is. An opinion of a nobody.

What I Expect

Given Apple’s love and focus on Swift I fully expect Apple to put their effort into moving their frameworks to focus on Swift while continuing to allow App developers to use Objective-C with anything new. I’ve written about the idea of Swift only Frameworks. I believe we will eventually arrive there. For now we have excellent UIKit support for three different devices; iOS, watchOS, and tvOS. Odd man out would be macOS. It doesn’t make sense, at least to me, for Apple to spend time back porting or adapting UIKit to the Mac. Their bread and butter is their  iOS based trio of the phone, watch, and cable like device. Since iPhone accounts for around 60% of revenue it makes sense for the iOS Platform to be their primary focus. That begs the question, will the Mac ever receive the attention we’d like it to receive? Probably not.

In the end I’d expect Apple to push iOS forward while keeping the Mac as a primary development system for iOS, watchOS, tvOS, and macOS developers with the latter receiving very little attention from a new Frameworks perspective.

A Brief History of Windows Development

Like I said above, I’m opinionated and I’ve been around the block a few times. I know Apple isn’t Microsoft and people tend to hate those comparisons. But I do see similarities between the Microsoft of the 90’s and the Apple of today. That’s a discussion for another time.

The discussions around Frameworks reminds me of Microsoft’s transition to .Net and C# as an easier way for developers to create Windows Apps. Apple is making such a big push with Swift a new framework targeting Swift developers feels like a natural progression.

It’s taken over 15-years to really push app development into a .Net world. I suppose some could argue it took less than 10 and I wouldn’t fight that. The point is Microsoft managed to push an entire development community to a new technology while allow old technologies to continue to not only function but grow. Look at the Microsoft Office Apps and Adobe Photoshop among others. They continue to be very relevant today and continue to add new features while the Windows API receives much less attention than does .Net and C#.

Ultimately the point is I know Apple could choose to push toward a Swift only framework and allow legacy Objective-C/Cocoa apps to continue to grow and thrive. Microsoft is a prime example of how a company could pull it off.

I think it’s kind of nice being a new developer to Apple’s platforms. I don’t have 20+ years of baggage like I do with Windows. It’s been so much easier to move from Objective-C to Swift because of it. Well, that and being most familiar with C++ made the transition to Swift feel more natural to me.

Whatever Apple has in store for us, be it the growth of Cocoa, a new Swift centered framework, or a Swift only framework, I’m ready for it and welcome it.

ARC

ARCMike Ash: “That, in essence, is what ARC is. The memory management rules are baked into the compiler, but instead of using them to help the programmer find mistakes, it simply inserts the necessary calls on its own.”

Reference counting is a pain in the keister, until you understand the rules. ARC is going to become an important tool in the quest to creating error free code. If you’ve ever written ref counted code you know how careful you need to be so you don’t leak memory or double-release something and cause a crash. It can be frustrating if you don’t pay attention.

This is a welcome change and one I’m looking forward to.

I think it’s time for an RxCalc refresh anyway. Plus some other nifty things I’ve been working on, that will definitely be ARC’d and Mac OS X Lion / iOS 5 only.

Yeah, what he said

Marco Arment: “But the biggest reason why there’s no iPhone SDK on Windows or Linux is that it doesn’t need to exist. The iPhone is the premier platform where the most money is being made. Developers will come to Apple — Apple doesn’t need to come to developers. (Google does, as the underdog.) It’s the same reason why there’s no OS X or Linux port of Microsoft Visual Studio, and you don’t see a lot of Mac owners yelling at Microsoft for not porting its sophisticated development environment to their chosen operating system.” – I really like this Marco guy. He’s about as blunt as can be, but he makes fine points. He’s also the creator of Instapaper, an application that’s quickly becoming my favorite little utility.

Mac Bits for Sale?

Matt Legend Gemmell: “I want to solicit some feedback on the idea of selling source code for the iPad/iPhone and/or Mac platforms. It’s something that’s commonplace (and popular) on other platforms like .NET and Java, but for whatever reason it’s never taken off on the Mac. I think that there’s potentially a reasonable market, particularly for iPhone/iPad, and I’d be interested in your thoughts.” – It’s odd there isn’t more of this in the Mac world. There’s definitely a whole lot of free, very well designed, Mac and iPhone source code floating around out there. Matt’s very own MGTwitterEngine or Gus Muller’s FMDB to name a couple.

I, for one, would welcome high-quality, supported, fully baked component bits for the Mac, iPhone, and iPad. It’ll make my life easier and allow me to focus on creating apps by not having to create as many foundation pieces.