Translation of Swift to Objective-C possible? - objective-c

We started a new OS X project based on Swift, only to find out that the management doesn't really like that just through the use of Swift, we cannot sell the application to users before 10.9, even if 30% of the market still has older OS X versions.
Reimplementing the software in Objective-C seems to be the only solution. As Apple advertised Swift to be binary-compatible with Obj-C, I'm wondering if a translation of Swift source code to Obj-C source code is theoretically possible, and if so, if you know about any implementation of that idea.
Couldn't find anything about this topic on the web so far, everyone seems to be searching for the other direction at the moment.

Of course it's possible. But I am afraid there's no tools to do that. You should rewrite all the codes manually.
As you mentioned, Swift and Objective-C codes can work together perfectly. So I think rewrite the codes one class/file by one should be a good way.
Apple's document Using Swift with Cocoa and Objective-C https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/ should be help.

Related

How does Objective-C get updated? Are there versioned releases? What is the current 'version'?

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.

ObjC, Swift to WinObjC

I have an iOS app which includes both objective c and swift. Does the winobjc tool support converting the iOS apps which includes both objective c and swift code?
I work on the Windows Bridge for iOS at Microsoft. We're getting more and more questions about Swift support and it's clearly a top priority for the community. Now that Apple has open sourced large parts of Swift, we're considering our options and the technical implications of implementing it.
We regularly update our roadmap on our project wiki with our plans for the next month or two, so there is the best place to check for near-term plans. If you try out the bridge and have any questions, please don't hesitate to get in touch by filing an issue on Github. Thanks for checking out the bridge!
No, WinObjC only supports Objective-C but no Swift at this point.
It also doesn’t seem to be on their roadmap at this point.

What’s the difference between Xcode, Objective-C and Cocoa?

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).

CoffeScript'esque language for Objective-C?

Seeing what has been done for Java with Xtend and Mirah I can't help but think someone must be playing around with something similar for Objective-C or even C and C++ for that matter.
After some searching I've come up with nil. Is anyone aware of a CoffeeScript like Objective-C implementation?
Update:
Good input so far from the two that have submitted answers, however wouldn't it be superior (realizing that that's a little subjective) to have an intermediate language that compiled directly to Obj-C precisely as per how CoffeScript works? Now, I'm not asking for CoffeeScript mind you, but rather some language that doesn't compile directly, but rather gives you a more readable top layer syntactically a la Xtend.
Yes: Eero, which provides a somewhat Python-like syntax for Objective-C, implemented using a modified version of clang. (I haven't tried using it, though, so I can't comment on how useful it is!)
MacRuby and RubyMotion let you code Mac and iOS applications (respectively) in pure Ruby. CoffeeScript is very Ruby-inspired, so if you enjoy that language, i think you'll feel at home with Ruby :)
Also, it is my understanding that both MacRuby and RubyMotion integrate nicely with the native environment; they don't run on a separate Ruby VM on top of Mac/iOS, so there is no big performance penalty and the native things are not that far away. So in that sense i think they are more similar in sipirt to Mirah for the JVM than to JRuby or Jython for example.
This project actually compiles Ruby -> native code in the end, thus making it possible to write iOS apps via Ruby. It's called UnderOS (uOS - because it's all about "u" according to the author ;)) and is about the best solution I've found if you want to do iOS development with Ruby:
https://github.com/under-os/under-os
Example of building a calculate app:
http://vimeo.com/81919125

Documentation for Objective C and Cocoa APIs?

Super-newbie question!
I've been looking for a list of all the classes that come with Objective-C and Cocoa but can't seem to find one.
Hoping that it has matching methods and syntax(?) as well.
Be gentle with me!
Thanks,
Spencer.
I would start here: http://developer.apple.com/referencelibrary/Cocoa/index.html
The system is broken up into frameworks, so you will not find a single listing. It depends on which frameworks you include with your project. good luck.
If you're using XCode, there's a documentation browser (Help -> Documentation) that's searchable. If you want to browse by classes you can also do so here. You might need to subscribe or download the documentation first though.
I'm finding this very convenient for iPhone development at least, since I can just type in a class or method name and get its documentation very quickly. YMMV for Mac OS X documentation though since I haven't used that at all.