Do I need to learn and convert my entire codebase to the new Swift language if I want to support ios 8?
No. The APIs available from Swift are exactly the same as the APIs available from Objective-C; you can code against any iOS 8 APIs from either language.
To start writing in Swift, there's an option called Migration. It will convert your existing code into swift code
Migration provides an opportunity to revisit an existing Objective-C
app and improve its architecture, logic, and performance by replacing
pieces of it in Swift. For a straightforward, incremental migration of
an app, you’ll be using the tools learned earlier—mix and match plus
interoperability. Mix-and-match functionality makes it easy to choose
which features and functionality to implement in Swift, and which to
leave in Objective-C.
NO.
Your Swift code can be run alongside your Objective-C code because Swift is built with the same compiler, ARC management and runtime as Objective-C.
Related
I'm looking to make an app which allows you to use Swift code within the app - similar to other Swift-based learning education apps to help you learn the language.
Is there a way to use the open source Swift code, for example, in any way to understand the syntax and possibly run the code for typed-in Swift code?
An example of an app I found on the App Store which can do this is called Sedona.
From GitHub apple/swift/.../Syntax there looks to be Swift syntax APIs, presumably for use by IDEs.
Am I looking in the wrong place?
Do these types of apps make their own Swift translator?
Is there some other way this is done?
Efficiency & optimization is not a priority, however would be a benefit.
It in no way needs to include very complex Swift.
Note: This is for an iOS app only, so Terminal commands would not work.
I work with an App that's 100% Objective-C and I'd like to start transitioning over to include Swift. Due to the size of the codebase, it's unrealistic that I'll have a 100% Swift app anytime soon.
As soon as a swift file is added, I noticed that the app size increases because now, the app needs to the include Swift run-time.
How else does things change? As soon as you include a Swift file, what is the process that the compiler and linker undergoes to ship a binary that is now multiple language & related frameworks?
Are there any other caveats in transitioning into a mixed language world in a somewhat large codebase?
In my experience, it works surprisingly well. It is advisable however, to wait to Xcode 7 / Swift 2.0 / Objective-C with generics support as that will eliminate a round of updates, allow you to interop from Objective-C with more elegant Swift code, and eliminate the Swift RT linking concern now that they have stabilized the runtime.
Aside from that, both compilers need to run, Swift first, Objective-C second, the swiftc compiler can be pretty fast or really really slow, depending on what innocent and otherwise legal Swift code that you write (this is also true of a Swift-only app of course).
Getting started, you need to read the interop guide, learn how the bridging header works, and are then mostly on your way. I would say that having a mixed app is actually a blessing as you are not pressed to learn and do everything at once. Opinions will vary of course, but this is mine.
Just a few questions which I can't find answers to anywhere:
To code games for IOS using Sprite Kit, do you also need to know Objective-C or Swift?
Can you code high quality games without knowing Objective-C or Swift?
Thanks!
SpriteKit is an Apple framework developed for Objective-C / Swift application. So, yes you'll need at least some code basics notions.
"Yes". You might be able to develop game with Unity2D for example, but that would include using another language to write your scripts.
I'll try to expand a little bit previous answer.
SpriteKit is an Apple framework developed for 2D/3D games. It uses Swift or Objective-C. Advantage of using this is that you can be 100% sure that this game will work flawlessly on iOS devices. Disadvantage is that you are locked only to iOS devices. If you have 0 knowledge of Swift or Objective-C, and you wish only to develop for iOS, I would choose Objective-C. It seems a little harder to learn and understand, but compared to Swift to it seems that Objective-C is still (and will be for long time) superior to Swift. Although, it just be my personal preference, because I truly hate Swift. (You can achieve same things in both languages) :)
I started this way, I do not regret.
You can develop games and apps for iOS without knowledge of Objective-C or Swift. You can use programs like Unity, Unreal engine, Corona, Cocos2D/3D. However these programs require learning another language to write your game (c++ or something else). You can also use GameSalad for 2D games. It requires 0 coding, many things are drag and drop, but you do need to understand logic behind it. For example, it wouldn't be programming but it would be coding :)
GameSalad is easy to learn, fun as well, but forget that you will be able to create any serious game logic or more advanced game than 2D platform one. I tried it, but very soon changed to Objective C and XCode.
If you decide to go with learning actual language (which I would strongly suggest), I would recommend either Objective-C or to learn Ionic software. Ionic uses javascript, but when you learn how to make games/apps you can easily distribute it to ANY platform: iOS, Windows mobile, Android...XCode is better software, but learning Ionic has huge advantage, and that is single click to deploy app on any platform.
Good luck.
I want to start developing for Mac and iPhone. I'm familiar with Objective-C a little and found it pretty complicated. Besides, I'm not sure that it would be worthwhile to learn it.
So it is possible to develop for Mac/iOS without knowing Objective-C, what programming languages do I have to use then? C++, C?
I like Scala, Java, by the way.
You can use c and c++ but you can't make any application without using objective - c. Since you need to use native app controllers and libraries.
Also in starting you find it difficult to learn obj-c because of it's syntaxes but after using them you are going to love it. So don't be scared and learn obj-c.
You can use some frameworks (e.g aapcelerator, phone gap)
but they are unable to give result like native app.
There are many frameworks you can use, like Mono where you can use C# (http://xamarin.com/monotouch) or some frameworks with HTML5 (see Creating native iOS/Android apps from HTML5)
But at the end basic understanding of objective-c and it's architecture will help you.
Why not? !!
But for iOS Native Development, you should learn objective C.
And if you want to develop using any other languages, you should use some other frameworks.
Haven't you heard about Sencha, jqueryMobile ,monotouch etc?
Once you get the hang of it Objective-c is actually quite fun.
Download some iOS samples and step through the code, that will greatly help you.
Or just create an empty project like a "Master/Detail" tableview app and see how it works.
I know RubyMotion is relatively new, but I'd like to find out if it's possible/easy to use OpenGL ES with it before I buy a license to make an iOS game I've been planning for a while.
The reason I'm wondering is that I understand RubyMotion wraps all the Cocoa/Objective-C stuff but OpenGL on iOS is a set of C functions (glBegin(), glEnd(), etc.)
If anyone that purchased RubyMotion could help me out in finding out or point me to a piece of documentation, I'd be extremely grateful. Thank you.
Yes.
They have a working demo in the RubyMotionSample project https://github.com/HipByte/RubyMotionSamples/tree/master/HelloGL
Yes, it is. The official site says so.
Interfacing with C
You do not need to be a C programmer in order to use RubyMotion, however some basic notions, explained in this section, will be required.
Objective-C is a superset of the C language. Objective-C methods can therefore accept and return C types.
Also, while Objective-C is the main programming language used in the iOS SDK, some frameworks are only available in C APIs.
RubyMotion comes with an interface that allows Ruby to deal with the C part of APIs.