Someone here suggested that I use an Apple DTS incident to ask about Cocoa's future, so I filed one Nov 19th. Still no reply. Ditto for a dev forum post, and an email to Aaron Hillegass.
Meanwhile, we've been thinking about what to say to Apple that might help make our future app development easier. Keeping Cocoa is vital for that, but it would be nice to see it improved also. There's one detail that could use feedback. So here's another long post, then I promise to STFU. Right now, Swift and Objective-C are about equally popular. TIOBE index and Stack Overflow have Swift slightly ahead, while PYPL and GitHub say it's slightly behind. Both languages increased rapidly during the iPhone Gold Rush, then declined somewhat. There's a cute animation of PYPL ratings here: https://www.youtube.com/watch?v=7EifKIFk60U (best viewed at 2x speed). Despite their equal footing, Apple has Objective-C and Cocoa way on the back burner. That may be because Apple's business model is based on innovation. Swift and SwiftUI are new and shiny. NextStep/Cocoa is 30 years old. Objective-C is 35. That's a PR problem. Will their lack of glamour turn them into the next Carbon? Currently unknown, but it sure doesn't help. Unfortunately for Apple, SwiftUI probably won't work well as the sole API for Macintosh. Microsoft and Adobe are already moving away from desktop apps. Force them into another, even bigger rewrite, and they may abandon the Mac entirely. Based on poll results here, it's even more so for smaller developers. Their loss will affect hardware sales to business, academia, and anyone else using specialized apps. Of course, Apple could fix that with robust, easy-to-use bridges between SwiftUI and Obj-C, Cocoa, and/or C++. However, it's more work for them, and still a difficult jump for developers. It risks making SwiftUI more complicated for pure-Swift work. And worst, it will vex the Swift purists who created the language and UI. It's like putting a gas tank on a Tesla. Better to target SwiftUI as a clean, easy development tool, great for small devices and small apps on Mac. Don't muck it up just to get Cocoa developers on board. Where does that leave Cocoa and Obj-C? To survive, they probably need to become as sexy as SwiftUI. So, I'd say rename them, and improve them enough to deserve a new name. Since SwiftUI is optimized for small apps, Cocoa 2.0 should become an amazing new tool for building big apps. Go head to head with WinUI 3. There are major GUI differences between MacOS and iOS, so it's reasonable to give them different frameworks with a common core. What would make Cocoa 2.0 more attractive to developers of large, specialty and cross-platform apps? Stability, for one thing. A promise to respect large investments in existing code, and make future transitions easier. Faster development- which could happen quickly by turning chunks of existing Apple apps into new API classes. We really could use an NSSpreadsheet. All the little stuff like good documentation and up-to-date sample apps. And most of all, language agnosticism. Allow developers to program in their favorites, or easily integrate existing code written in whatever. Here's how I think language agnosticism can happen. First of all, any Cocoa language change can't break existing Obj-C code, nor change its basic design. The goal is to improve connections to other languages without affecting existing apps. A slightly expanded header syntax could accomplish that, maybe like this: @interface HybridClass : NSObject - (void) objCMethod : (int) value; @language C++ public void cPlusPlusMethod (int &value) const; @language Python @end It defines a hybrid class which inherits from Objective-C, but is accessible from other languages. Obj-C callers only see Obj-C methods, C++ callers only see C++, etc. In source files, Obj-C and C++ functions have Obj-C++ contents same as now. For Python functions, it's a mix of Python and Obj-C, etc. Create a hybrid object from C++ and its lifetime is managed with constructor/destructor. Do it from Obj-C and it's alloc and ARC. Create in Python and it lives by their ref count. Allowing multi-object and multi-language inheritance would be a plus, but optional. Open source would be a big plus. Cocoa 2.0 could start with just C++ header support, since Obj-C++ is already half-way there. Add Python and it competes well with WinUI 3. After that, minor-language enthusiasts would probably do the work to link their own in: just give them a API for the connection sugar. I have no fondness for the original Mac Toolbox. But it was innovative for its time: enough to spawn Excel, MS Word, Photoshop, and other great apps that started Mac-only. Apple could use another spurt of software innovation. Users too. Apple likes big gestures, and this solves a looming problem for them. That makes it more likely the idea can be more than a pipe dream. Thoughts? Casey McDermott TurtleSoft.com _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
