It seems that Cocoa seems to be the main platform for Objective-C. GCC (which Xcode uses) supports Objective-C so it must be available on a wide range of platforms.
Are there any notable cross-platform projects that use Objective-C but not Cocoa (or its open source cousin GNUStep)? Is it really used outside the Apple ecosystem?
Objective-C has also been popular in the scientific and financial services communities. There are still many Objective-C based applications deployed in banking, mostly on the trading analysis front. A friend works on a nearly million line of code Objective-C based analysis and trading engine for which they have written their own class hierarchy from scratch.
At one point, one of the more popular Linux window managers was written in Objective-C. That was a few years ago and may no longer be the case.
The LLVM compiler also compiles Objective-C, including having full support for Blocks. It is quite portable, too.
There is also David Stes's Portable Object Compiler. It compiles Objective-C to C and uses a class hierarchy that is based quite directly upon the original ICPak class hierarchy from StepStone.
It seems what you're asking is if Objective-C is ever used without Cocoa, or GNUstep, or Cocotron, or any API like them.
The answer is basically no. Without an API like Cocoa (or GNUstep, etc.), Objective-C isn't very useful. For example, without NSObject, retain and release wouldn't even exist. A ton of very important features are built into these APIs, so it's somewhat pointless to use Obj-C without one of them.
Yep, there sure are. The one I can think of from the top of my head is Cocotron. An effort to port AppKit to Windows.
http://www.cocotron.org/
Aside from that, Objective-C can be used on any platform that gcc will run on. You won't have the wealth of frameworks that are available in Cocoa on OS X or the iPhone, although as you mentioned, GNUStep does a pretty good effort.
Related
I have been trying to answer this question and looking at google/wikipedia etc but have not been able to determine this. On wikipedia I see a reference to Objective-C 2.0 but thats about it. I am curious for example in Xcode 7 there were some new features available for Objective-C like lightweight generics and __kindof. Did these exist before and they were just made available via Xcode in v7? Or did the language change? I tried to find a version history or information on releases but so far have come up with nothing. Swift is clearer on versions/releases and I keep asking myself if I am missing something related to Objective-C since I can't find this information. Does Objective-C update with Xcode releases or can the language evolve on its own?
in Xcode 7 there were some new features available for Objective-C like lightweight generics and __kindof. Did these exist before and they were just made available via Xcode in v7? Or did the language change?
To that extent, yes, the language did change.
The best way to research this sort of feature is by going through the Release Notes for Xcode. Thus, the features you are talking about appear here:
https://developer.apple.com/library/content/documentation/Xcode/Conceptual/RN-Xcode-Archive/Chapters/xc7_release_notes.html#//apple_ref/doc/uid/TP40016994-CH5-SW1
There is actually an Objective-C section with a subsection "Objective-C Language Changes". That pretty much tells you this was a change in the language!
Changes since then are listed here:
https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html
Of those, the most significant is probably the advent of class properties.
All these changes took place primarily to enhance Swift compatibility, and I think we may expect that all changes in Objective-C going forward will be for that purpose.
Objective-C is a very simple language. It's just a very thin layer on top of the C language. It's very important to realize that if C changes, Objective-C also changes. You can actually select which C dialect will be used for your Obj-C compiler. In that sense Objective-C changes all the time.
If we are speaking only about the object layer, there is no official specification, no discussion groups (e.g. as we have for Swift). It's not open-source. Practically speaking, current Obj-C features are exactly what the Apple's version of LLVM-Clang compiler has implemented (that is, what is shipped with Xcode). And LLVM documentation is where you can find the most interesting pieces of information about Obj-C features.
Obj-C changes a bit with every Xcode release although nowadays new features usually mean more attributes/annotations that can improve code analysis and provide more information to Swift. There is no official version number.
Objective-C has reached a state when it can't be really improved any more. It needs to support everything in C, it has to be backward compatible and its dynamicity makes it very hard to check types. That's exactly the reason why Apple has introduced a new language.
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
Having recently read up a on Objective-C it strikes me as a fairly neat language with plenty of cool features.
I have no intention of doing any iPhone development, however I understand that GCC is able to compile Objective-C code and so I wanted to know - Is Objective-C a viable alternative language to C99 for Windows development?
In particular:
Is anyone currently doing Windows development using Objective-C?
Are there any runtime components that would need to be distributed with my applications?
I understand that Objective-C is a superset of C, does this mean that it is possible to use any C-compatible library? (for example the Windows API)
Would I get garbage collection in my applications?
I've found Cocotron and GNUstep which are often mentioned when talking about using Objective-C on other platforms, however as GCC can already be used to compile Objective-C I don't really understand why I would need these.
Are there any other pitfalls or traps I might run in attempting Windows development using Objective-C?
With respect to your first question, I don't know if anyone is seriously doing development on windows with Objective-C, but there may be, though those numbers would probably be less than those doing serious work with a language like whitespace.
Secondly, you would need, at a minimum the objective-c runtime. There are two runtimes, NeXT's (now Apple's) runtime, and the GNU Objective-C runtime. They are not compatible. If you are on a non-NeXT and non-Apple platform, such as windows, you have no choice, GNU runtime only.
Objective-C is a superset of C, and yes you can use the Win32 API if you so desire directly in your objective-c code. As well, you would only get garbage collection if you use a conservative collector, and it ties in with the libraries you're using. In short: No.
What GCC has is support for the objective-c language, and runtime, no standard library. What the GNU objc runtime provides you with in terms of a standard library, is two objects: Object, and NXConstantString class, which is needed to support the #"" syntax. Object is merely a base class. Not very useful, eh? This is why frameworks like Cocotron and GNUstep exist — to give you access to an implementation of OPENSTEP/Cocoa.
Regarding pitfalls or traps, yeah: Your application, even using Cocotron or GNUstep may never be portable to the Mac for instance, or you may get bit by things like typed selectors in the GNU objc runtime, or a plethora of other problems. Let me finish answering this by posing another question: What pitfalls or traps might you run into targeting .NET? I'm sure some if not most of those apply in this case too. Standard pitfalls and traps apply.
I hope this helps.
There is no mature solution yet. If you develop the solution itself, you can do it anyway. But if you're not, it's not the time.
For compiler tools, there is LLVM/Clang which are open-source under BSD license.
The compiler is sponsored by Apple, so it compiles Objective-C completely, and is becoming primary compiler for Apple. So compiler is no problem anymore.
Problem is runtime environment library. Objective-C language is depends it's runtime to execute. The runtime defines all behavior of object system and some more. Runtime environment library is core system and different with framework library like Cocoa or Quartz. in .NET, it's CRE, not .NET framework class library.
Without runtime, program cannot be executed like .NET program executed on Windows without .NET runtime.
For more details, check this conversation:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html
I am trying to test Objective-C on Linux (Ubuntu 10.04), mainly to decide if it's worth it to get a Mac and XCode. I have to like a language before I seriously consider programming in it (even more so when I have to pay a lot for it)
I am using gcc (with gobjc++). But this of course does not include the Foundation Kit and the rest of the Cocoa API (not overly concerned about this one).
Short of GNUStep, what is the best way for me to get into Obj-C programming in Linux or Windows? I want to get at least class in the FoundationKit.
You have two options:
GNUstep, which is focused on Linux
Cocotron, which is focused on Windows
Those are the only freely available implementations of Foundation that I'm aware of.
Honestly, the language is hardly ever used outside of the Apple ecosystem, so you're not going to get a first-class experience here. Not knocking those groups' efforts, but if you're looking for something comparable to what you get on OS X, it just isn't there.
Is there any other scripting language that can be used to embed scripts inside applications, which can access Mac OS X, or application classes with the same features, or most of the features seen in F-script?
The scripting language with the best support on the Mac is still AppleScript. But unlike F-Script, it cannot directly access the Objective-C level, it can only use what the target application chooses to expose for scripting.
There are Objective-C bridges for Perl, Python, and Ruby. I suppose those can embedded to provide scripting to your application.
Nu is an interesting option, although it isn't very popular yet.
A lot of people seem to like JSTalk.
But probably Applescript is your best bet: integrated into the system and all that.
I would say F-Script for many reasons. It has many unique features and is extremely tightly integrated with Cocoa and the Objective-C runtime. You can for example inspect various Finder classes (windows, icons, coverflow view...) and it's very easy (one or two lines of code) to start or control other processes. I don't think there is any good reason to prefer AppleScript. It's good for very short scripts, but will probably drive you crazy if you want to do something more complex.
Also, MacRuby is going to rock when it's a bit more stable, and some serious stuff has been accomplished using PyObjC as well, although I don't think it's very actively maintained anymore.
If you don't need F-Script graphical introspection tools, which are quite unique, there are some decent scripting languages that you can embed in applications. See in Particular RubyCocoa (for Ruby), PyObjC (for Python), JSTalk (for JavaScript) and CamelBones (for Perl). They are based on bridges between Cocoa and a foreign object model, which leads to some complexities. This is different from F-Script, which is directly built for the Cocoa object model. When ready, MacRuby might be an option too, but the syntax for manipulating Objective-C objects is not very nice (it improves on RubyCocoa, though). Nu is also an option: directly built for Cocoa like F-Script, but with a strong Lisp flavor.
MacRuby is an implementation of Ruby 1.9 that uses the Objective-C runtime and garbage collector. It can be embedded in a Objective-C application.
Even if the last available version is only 0.6, it is reported to be stable enough to be used in applications.