More than just their UI, fundamental parts of Apple's OSes are written in ObjC, including very new components like ARKit, CoreML, and the Metal API . Apple continues to write tons of new Objective-C code every day. Of course Swift is making inroads inside Apple, but Objective-C has to be well supported for a very long time to come.
I've been writing Objective-C for 15 years, and continue to do about 60-70% of my work in ObjC (the rest is mostly Swift). I'm not particularly worried about my code being unusable anytime soon. When Apple starts making a real effort to wholesale migrate away from ObjC, I will too.
I think being so heavily pushed by Apple is actually a downside for ObjC here. I really enjoyed programming ObjC when I was programming for iOS and Mac. That was mostly because of the very rich API shipped with Apple products.
Can you point me to a list of libraries written in ObjC that work without Apple specific code? (E.g. without using anything starting with 'NS')
objective-c has a particular set of strengths that is well-suited to gui development. if you count its beginnings at next, it has been in use in this environment for over 20 years. there is no way in hell apple would abandon it now.
Apple hasn't really consistenly stuck by Objective-C; they tried to push people in the Java direction for OS X "Cocoa" development maybe about 10 years ago. Never really caught on, though.
Learning objc isn't too bad but it introduced a lot of (in my mind) unnecessary complexity because now you have two code paths (message passing vs. ordinary functions). It's quite a verbose language so you have to declare member variables several times, and ARC has drawbacks over garbage collection so it's not always clear when something should be declared strong or weak, making it nearly impossible to prove that an app is free of leaks in low memory conditions. Apple's iOS frameworks have a lot of trouble with inheritance, so you might have code that works with regular buttons but can't work with toolbar buttons for example, because they don't share a root class. So I generally find iOS development to be remarkably complex and tedious for even the simplest GUI elements, especially if you are trying to do something beyond the vanilla layouts that Apple has in mind. You also really can't develop for iOS without Stack Overflow, which to me is a red flag for any API. Xcode has numerous bugs, especially with XML, so you may find that some change you made to a .xib file is not revertible because of a caching issue, and when you examine the XML you see that something was named slightly differently, so you have to be diligent with your version control and snapshots. Apple is unable or unwilling to acknowledge many of these problems, much less solve them, so I constantly fight against issues that I thought would have been fixed by iOS 6. I think out of every API I've learned, iOS is the hardest, not because of conceptual problems (their threading system is actually fairly good) but because of poor implementation choices where Apple omitted something for political reasons so you have to reinvent the wheel. What we really need is a cross platform middleware that provides a consistent event system and API like win32 for all platforms, and then someone could write language hooks for that in javascript, lua, ruby, whatever. Without that middle layer, it's too constraining to work with pure html5 IMHO. I've only touched the tip of the iceberg here - there are so many hurdles to even getting an app published natively that I think making a cross platform app is still an open problem.
I actually hope Apple won't abandon Objective C and continue to improve it. I'd like to have languages from both sides of the spectrum (dynamic ObjC vs strongly typed Swift).
The main reason is that Apple has effectively deprecated Objective-C for ios/macos development going forward. It's not going away for probably another decade+, but all documentation is now in Swift, new APIs are written with Swift in mind, etc.
Think of it this way: in 5-10 years, ObjC will be the python2 of Apple development.
I do some contract work for a company I sold an app to awhile ago, and the codebase is mixed Objective-C/Swift. Anything new I do in Swift, but there's a few rare new view controllers and the like where Objective-C is used because it's just easier/faster to copy/paste infrastructure.
Some crypto code is also still Objective-C due to easier linking, but that'll probably change soon enough.
I don't consider ObjC to be a bad language in the slightest; in fact, I'll offer the (probably contrarian) opinion that it's one of the greatest languages of the past few decades.
Obj-C survives b/c it is the only real way to write iPhone and iPad apps, plain and simple (ignoring Appcelerator and PhoneGap for the moment). If people had options, it is likely they would use the alternatives.
Look at Linux. The "official" language will always be C, but there are toolkits for building GTK apps in Python, Vala, Mono and other even more obscure languages. Some pretty big apps have been written in each and people will continue to use those as long as they are viable options. If, however, someone big enough and with enough clout basically said "only native C/GTK apps will be accepted on our platform", you would see people migrate to that toolchain. It is simple economics.
Apple has the clout (imo, unfortunately) to do that and have done it with Obj-C. They basically killed Java, which was an option up until I think 2 years ago. I can see Apple's perspective, supporting two toolkits is expensive and takes time, resource, energy and focus. In their mind, what benefit to they gain from supporting multiple toolkits? Developers? They know they are popular enough that the developers will take up Obj-C when Java was dropped. Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT DEVELOPERS except that they make apps to attract the users.
I'm not saying what Apple did is right or wrong, but it does make sense from a strategic point of view. However, there is practically no merit to Obj-c on it's own. There are more compelling alternatives at nearly every turn, but NOT if you want to play in the iphone and ipad ecosystem.
I'm an iPhone developer who knows ObjC inside-and-out and I stand to profit (and in fact already am profiting) from Apple's decision to shut down cross-platform frameworks.
That said, there's no direct connection between a great user experience and specifically using ObjC, not even in theory. There are many frameworks (MonoTouch comes to mind) which explicitly bind Cocoa/Touch to C#. The only difference is, instead of writing your logic in ObjC, you're doing it in a language you're more familiar with. This type of framework/cross-compiler leads to high-quality, reliable code that still provides a nice Apple-ey user experience.
On the flipside, you have plenty of app store apps (games, mostly, but others like convertbot) that totally eschew Apple's UI controls. These apps are written in 100% ObjC with all of Apple's tools, but simply prefer rolling their own because they think the user experience is better. Up to now (and as far as I can tell from my talks with them, still) Apple has no problem with this.
So I think your logic that using Apple's tools magically leads to a better user experience is flawed. True, some cross-platform environments lead to a subpar experience (potentially Adobe's CS5). But Unity3D and MonoTouch clearly contribute to the platform from a user experience standpoint.
A much better argument is that Apple is planning to make lots of changes going forward and they don't want to have to worry about waiting for the Unity people to update their compiler in order for developers to be able to implement [whatever] for their apps. For instance, the multitasking change is pretty big under the hood--who knows how long it will be before MonoTouch binds to it? That's much more likely to be Apple's concern.
TUAW made a similar argument to mine, but it's flawed in a couple of places because they don't understand OSX. There's nothing about cross-platform frameworks that makes multitasking hard per se, but making it more difficult to update existing code is going to be hard if Apple ever decides to break backwards compatibility, which clearly they're indicating they're going to do.
Of course, from Apple's POV this has the nice "side" benefit of locking developers in to ObjC going forward. Better for the platform or not, I think that's what has developers most upset--we've just gotten out of two decades of vendor lock-in under Microsoft. We were headed for the web, and we're about to miss it.
So much negativity in this thread. I, for one, absolutely loved working with ObjC. I no longer do any macOS programming, but when I did, it was magical.
Is the syntax weird and crazy? No doubt. It is, however, an extremely pragmatic approach. It's completely unique in that it offers a dynamic, very-high-level OO language on top of C, giving you a way to work on both levels. C (or C++) for the performance-sensitive parts and integration with C libraries, and ObjC for the glue that orchestrates the application. ObjC isn't without its faults, and if was starting to show its age, so it makes sense for Apple to develop Swift, though between the two languages, I think ObjC is the more innovative one.
It's a lot like having a scripting language around a C core, though ObjC has stronger static typing. Dynamic dispatch, late binding, and interfaces (protocols) results in a super rich, dynamic ecosystem of objects all interacting with each other, fulfilling the promise of Smalltalk better — in the sense of being the basis for real, mainstream products, including macOS itself — than any implementation of Smalltalk ever did.
Despite the verbosity of the NS/Cocoa/etc APIs, Objective-C is a small, flexible, and unambiguous language. It performs very well at runtime, and is amazingly quick to compile. With version 2.0 and ARC, it became productive in addition to everything else.
I get it, it was long in the tooth, and the C legacy was both a blessing and a heavy weight holding the language back, but we lost a lot of the simplicity in the move to Swift.
As someone who has done a minimal amount of Objective-C programming in the past, I have to agree. That being said, I've also heard a lot of hackers rave about it. I'm confused over why there's such a love/hate relationship with this language. Whats the story with Apple's dev environment being so Obj-C heavy? What's the chance they'll spring for it's replacement?
The only reason Objective-C is not a relic of the past is that Apple are stuck with it. Some people mistake this relationship and think ObjC isn't a piece of shit. Poor fools.
I'm an iOS developer at my 9-5, so it certainly could be a case of disliking the thing I am most familiar with.
You seem to be disputing my claim that "people don't like obj-c and wouldn't use it if they didn't have to" on the grounds that it is capable and getting better. I don't think that is enough. It's all just my opinion, I don't think C# has a bright future either.
As for my "No and No".
## My First No - "No it is not popular" - Purely anecdotal
I interpreted popular as "well liked". Those I have met and worked with all seem to view Objective-C as "what we use" not, "language of choice". I know those who have grown to appreciate and even like it, but not a soul who says "Obj-C is my favorite" outside of the context that it makes them the most money. I'm sure objective-c fans exist, but to qualify as "popular" to me, that would have to be the overwhelming majority. I've never met an objective-c person who talks about it with the same grin that a Ruby person wears when they tell you about "unless".
## Second No - "No, I don't think anyone would use it by choice" (stupid internet assumption, anyone == people who think exactly like me)
The reason for this, I think, has more to do with its lack of popularity than anything else (yup, some circular logic, I know). The fact that every mac developer I know already knows at least one other language that they can use everywhere else is I think why they aren't putting forth any effort into developing the community to use Obj-C for other jobs. Why bother? There's already overwhelming support other languages of similar merit, so why opt for the unpopular one?
## My own experience
ARC has been wonderful, and I think it greatly improves the process of getting things from idea to application. However, I still feel like I am writing - or rather tab-completing - too much code to accomplish trivial tasks. There is so much ritual that could be done away with completely. If the most common case is to @synthesize an @property, why am I forced to @type @it @out every time? I understand there are sound, logical, historical origins to many of my frustrations (like separate .h and .m files and having to wear out my 'n' and 's' keys). To be honest, much of my complaining is nothing more than trivial syntax whining, but to me, that is all friction. Here I must also admit that I am probably seeing Obj-C in a negative light because I have to interact with it through XCode. I've tried JetBrains AppCode, but there is so much switching back and forth to XCode for CoreData and Interface stuff that I now just keep it around for a few specific tasks. With Obj-C it's really hard for me to separate the language from the Apple APIs, XCode and the iOS development community, all of which I would consider "take it or leave it" quality. Every once in a while Apple throws you a bone like NSOperationQueue, which is a joy to work with, but again, that's conceptual, not syntactic, it's still a million characters to do anything with it.
I can't think of a reason I would pick it over C for low-level serious business or over $yourSciprtingLanguageOfChoice / (((your-functional-language-of-choice))) for everything else. It's got some cool features, but nothing that overpowers its awkwardness for me.
I've been writing Objective-C for 15 years, and continue to do about 60-70% of my work in ObjC (the rest is mostly Swift). I'm not particularly worried about my code being unusable anytime soon. When Apple starts making a real effort to wholesale migrate away from ObjC, I will too.
reply