For an iOS app that will eventually be ported to Android/Winphone, I would love to be able to write some re-usable libraries in c#, but author the iOS UI in traditional Obj-C and reference the library written in c# from Xcode and consume it from Obj-C.
I've found lots of docs that talk about going the other way via bindings (Obj-C -> C#), but not much pertaining to my question. Also, a similar question was asked 4 years ago here, but a lot has changed in the ecosystem, the info seems out of date, and some of the links in the answers now redirect elsewhere:
Is there a way to mix MonoTouch and Objective-C?
So, is this possible? If so how, and what's the best way to achieve it today? (Or alternately, is this a bad idea and should be abandoned?)
No, it is not currently possible to consume a C# library from Objective-C.
Note that it is usually possible to do it the other way with some ingenuity - the only real requirement is that the app must be a Xamarin.iOS app and the entry point the managed Main method. In your Main method you can call into native (C/Objective-C) code and have all your logic there.
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).
I'm building an application in C, which is a client/server sharing app. This application is command line based which uses TCP sockets, libcurl and some fork(). It should run in an infinite loop without any input.
My professor at the university said that we have to implement a GUI, and because I'm on Mac, I learned Object-C and I have done it in cocoa.
Now I'm asking myself if could be possible to merge the two applications, the cocoa GUI and the real application written in C. Of course I need the two "apps" to run in parallel.
Can I add it to my cocoa app? Where I have to put the code in order to have it always running? Not in awakeFromNib right?
I know that the question is kind of vague.
Thanks.
You could run the command line app as an NSTask and write the appropriate code so that they can commnicate via pipes. This way they will run asynchronously.
Alternatively you could definitely 'merge' them as c code will run just fine in an ObjC progam. The infinite loop could live in a different thread. Although this solution may require more re-writing than the previous solution.
Is it possible to make a Cocoa app scriptable using Ruby instead of AppleScript? Any reasons why I shouldn't?
Even if one has to use AppleScript, there are still the following alternatives:
The AppleScript dictionary only contains one "function": "sendRubyScriptToApp". What this "function" (not sure what they're called in AppleScript) does is to simply pass a string containing the entire Ruby script that the app accepts.
Use AppleScript in the regular way.
What would be some advantages and drawbacks?
I think there are many disadvantages of going against the grain with AppleScript. Mainly because you have to then embed a ruby runtime in your application to get your idea to work. I suggest using AppleScript the regular way and then using rb-appscript to script your app. Rb-Appscript will allow you to create ruby code that interfaces with your application via AppleScript.
I'm about to write code for Windows that has somewhat similar functionality to the one existing in already written application for iPhone. I'm thinking of separating common functionality to form a component and compile it to both to iPhone and to Windows. This code is written in Objective C and uses RestKit and Core Data (and probably sqlite). Is compiling it for Windows a viable task? As I understand it GCC could compile Objective C on Windows but I'm unsure about the RestKit and Core Data api availability on Windows. I have seen two names that could be of use: GNUStep and Cocotron but I don't know if they will play well together with RestKit.
Note: I have no idea about iOS development so I might be confusing things. Any help is appreciated.
You will not easily be able to share this functionality between your applications. CoreData uses a custom opaque (not documented) format for the sql store. You would be hard pressed to reverse engineer this.
You will probably save a lot of time by rewriting that part for windows, rather than trying to get it working. There really isn't much iOS code that can be reused under windows, unless you have written pure C or C++.