Future of Cocoa #2
Future of Cocoa #2
- Subject: Future of Cocoa #2
- From: Turtle Creek Software via Cocoa-dev <email@hidden>
- Date: Tue, 10 Dec 2019 12:55:36 -0500
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@hidden)
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:
This email sent to email@hidden