Few Mac Dev Questions

1. Yes for public API, in particular if you want to publish on Appstore, you have to use public API.

2. Yes

3. No VM/Interpreter. That's why performance is high.

4. Plain Old C alone, no. But you can also use Swift.

1. Cocoa is a library/framework, it contains AppKit (a UI framework) and Foundation (a framework that contains a lot of useful data types). If you need to make an app with a graphical user interface you will probably have to use it.

2. Yes.

3. Swift is compiled. Swift can access all the Objective-C / C frameworks and libraries, so it can access Cocoa too.

4. No, you can use plain C or other languages, but it's a pain to do so with Cocoa. There are C or C++ UI frameworks like Qt or wxwidgets if you want to avoid Objective-C / Swift or make a cross platform UI, but it all depends on what are you trying to accomplish.

With respect to 1: Cocoa is the lowest-level API for GUI app programming, but there are lower APIs for some other kinds of programming. There's a whole BSD/POSIX layer. There are various C APIs like Core Foundation, Core Graphics, parts of AddressBook, Core Audio, etc.

With respect to 3: Swift is a language. System libraries and frameworks can be accessed by mulitple languages. Besides C, Objective-C, and Swift, there are Fortran, Go, Rust, C++, etc. That doesn't require interpretation or anything like that. The dynamic object-oriented frameworks require a language that supports such features. That includes Objective-C and Swift. C can only (easily) access traditional C-style libraries and frameworks.

1. No.

2. No.

3. Yes and no.

4. No and no.

To elaborate...

1. See Ken Thomases’ answer. The APIs are a mess.

2. Cocoa is a Mac framework. As such, it is (informally) deprecated. That means it is officially supported in every way except for when it isn’t. If you want to start developing Mac apps today, you need to think of how you would write them on iOS and do that on the Mac. Don’t use Catalyst. Ironically enough, that is a Mac API, and therefore, not well supported.

3. Swift is mostly a (highly successful) social experiment. Unless you can sit down at a keyboard and code Objective -C in a stream of programming concisiousness, you aren’t going to have a choice.

4. You are expected to use Swift now. You can do most things in Objective-C, but not all. In all fairness, you can’t do everything in Swift either.

#2. Surprised you state that Cocoa is not supported… and that it is (informally) deprecated.

#4. I'm convinced a lot of developers still use (exclusively) Objective-C ; I do prefer Swift, but this is just a personal preference.

Because it's not (informally) deprecated. And there is nothing wrong with Objective-C. Still running along well.

I agree with the sentiments of john daniel's answer. While "(informally) deprecated" might not be the most accurate description, it certainly gets at the feeling--and oftentimes reality--of the current state of objective C. None of the recent code samples (that I am aware of) are available in objective C. It's a shame that obj C has mostly been thrown to the wayside just when it became a mature lanugage. I am glad that I have enough experience with it that I don't need all the line by line code examples to figure things out. As john daniel said, "Swift is mostly a (highly successful) social experiment" to which I wholeheartly agree--that pretty much sums it up.

#2. Do your iOS or Catalyst apps work if you #import <Cocoa/Cocoa.h>?

#4. Many developers do still use Objective-C. Just as many developers still use C++, Perl, PHP, etc. They are usually unemployable and doing only maintenance at this point. Any such blanket statements are false, of course.

There are always niche projects and highly talented people using legacy languages. But it would not be advisable for someone just coming into the Mac ecosystem now to start learning Objective-C or Cocoa. I know of at least one new Apple API (RealityKit) that is Swift-only.

#2. Do your iOS or Catalyst apps looks like crap on macOS unless you write your own custom AppKit-like UI elements? Yup.

#4. I agree, but there isn't a single person in the world that knows only Objective-C and no other languages. Objective-C is such a simple language.

Sadly, Apple is really muddying the waters by constantly creating rival frameworks that are designed to solve the same problems (and problems that I think have already been solved). UIKit on Mac (Catalyst), Appkit, and now SwiftUI. Would rather see them fix bugs. I don't think we need another UI framework.

BTW I still do ObjC only. Just seems like a better language to me all around. It's no so complicated, doesn't have a bazillion keywords. Pretty sure the community is split 50-50 (just a guess). All Apple sample code is Swift now. Much of the sample code from recent years will no longer compile because of this. When Swift first came out, I remember reading a quote from a developer: "Every line of Objective-C code is now legacy code" (or something like that). It was kind of humorous to see all the changes made to Swift in the years since, breaking source code compatibility. These people were beta testers and they didn't even know it.

Apple started selling new $6000 laptops that run on an OS where 98% of all apps use Cocoa. So while it seems like they want to replace Cocoa, it's going to take a really long time I think. They kind of have to support Cocoa, even if they don't want to.

I sometimes dream in Objective C!

I do agree on your comment on SwiftUI. Funny enough, it is somewhat a return to "all in code and tools will show it graphical" instead of "design graphically and tools will turn it into code" (a new version of "human to learn computers vs computers have to learn human ; thought Apple had made a clear choice…)

Sure, Soryboard can still be improved (notably to manage constraints more easily to cope with Portrait / Landscape or different screen sizes…). But there is a huge value to see an app full storyboard in one shot.

My intent is to later use SwiftUI in the same way I'm using xib in a stroryboard word: to handle some specific cases, when really needed. But not as general purpose.Still have to see if SwiftUI makes more sense in MacOS environment (my apps there are not storyboard but xib, because a MacOS app logic is pretty different from an iOS one).

As for Swift and objective-C, I really feel they serve different audiences (for some may be it is a questionof where they come from: C culture or Pascal culture) and I agree, there is not much value to argue, only expecting Apple will continue supporting both equally (dream ?).