Ask Slashdot: Objective C Vs. Swift For a New iOS Developer?

RegularDave writes: I'm a recent grad from a master's program in a potentially worthless social science field, and I've considered getting into iOS development. Several of my friends who were in similar situations after grad school have done so and are making a healthy living getting contract work. Although they had CS and Physics degrees going into iOS, neither had worked in objective C and both essentially went through a crash courses (either self-taught or through intensive classes) in order to get their first gigs. I have two questions. First, am I an idiot for thinking I can teach myself either objective C or Swift on my own without any academic CS background (I've tinkered in HTML, CSS, and C classes online with some success)? Second, if I'm not an idiot for attempting to learn either language, which should I concentrate on?

Comments

Further reading

[pushing-robot]

There's a site you may not know about which had a long discussion on this very subject not so very long ago. A lot of people weighed in and you may find it enlightening:

http://ask.slashdot.org/story/...

No idiot.Go with ObjC

[Henriok]

You are not an idiot for going for this. There's a vibrant market out there for products based on these languages, with a great community and it serves at least two plattforms which by all accounts won't be going away anytime soon. I would go for Objective C, since it's a more mature language, with lots of good documentation, learning materials, and all the frameworks in iOS and OSX is using this. Swift is still finding it's way.. so while you are learning ObjC, Swift will mature, and you will be established when the time comes for Swift. Let the bleeding edge developers work out the kinks first.

You should learn both of them

[caseih]

As far as I can tell, Swift is just a new front-end to the Objective-C object system. So knowing how Objective-C works will be beneficial to working in Swift.

Also most of the libraries and frameworks you will be working with are Objective-C and most of the current tutorials and online resources probably use Objective-C in their examples. That's not to say you need to start with ObjC, but be prepared as you use Swift to learn a bit about it, at least enough to read and translate example snippets you see.

If my understanding of Swift is accurate, one can intermingle Swing and ObjC libraries and modules. They should have the exact same calling convention and object semantics. Perhaps Swift is easier to remember without some of the more unusual aspects of ObjC's syntax.

Depends...

[dagamer34]

Depends on your goals, really. I think a big pitfall most people think is that the goal is to learn a language, when you really should be aiming to learn confidently learn as many as possible. You'll soon start to see how similar they are, and it becomes a lot easier to pick up.

The hard part actually isn't learning a language, but a framework. Frameworks are very platform specific, concepts are less reusable. And because Cocoa Touch is so intimately designed around Objective-C, even if you chose to learn Swift first, you'll need to know Objective-C anyway because of a) the amount of code/books/resources that exists on the internet in Obj-C vs Swift and b) a solution to your problem may only be written in Objective-C in a StackOverflow search result.

As for skipping academic CS, at some point you need to learn the stuff that almost every CS grad is expected to know at some level (data structures/algorithms, operating systems I & II, algorithm complexity (aka Big O notation), software design, etc...) not so much because they'll be explicitly required of you, but as you build larger and more complex apps, without them, code readability, maintainability, and performance are going to go to total shit. Granted, there are some, heck many, CS grads who somehow evade actually knowing this stuff, and things don't turn out so great for the code they write in the end.

My advice, tackle building an iOS app with a goal in mind, written in Objective-C due to the sheer number of resources out there, then expand from there.

Re:Objective-C

[ShanghaiBill]

Or Swift. But definitely one of the two.

Not necessarily. You can write some C++/Objective-C wrappers for Apple's APIs, and then write the other 95% of your app in pure C++. Objective-C is a preprocessor, not a real language, and can be mixed with either C or C++.

Anyway, good luck making money as an iOS developer. It isn't as easy as it used to be.

Re:Objective-C

[MouseR]

Definitely Objective-C, unless your intent are for small home projects no one else will ever have to deal with.

Here is a bunch of random notes I took when evaluating Swift...

- No header files confuscate passed-on intended usage by exposing ALL class details rather than the intended consumable APIs.

Q: Is there any private/public scoping in the language?
A: None! It's wide open. Apple promised at the WWDC to fix that. But it will probably take the form of private/protected keywords much like C++ in the class definition. They seem hard-bent on not having public header files.

- Access Control

In Xcode 6 beta 4, Swift adds support for access control. This gives you complete control over what part of the code is accessible within a single file, available across your project, or made public as API for anyone that imports your framework. The three access levels included in this release are:
private entities are available only from within the source file where they are defined.

Internal entities are available to the entire module that includes the definition (e.g. an app or framework target).
public entities are intended for use as API, and can be accessed by any file that imports the module, e.g. as a framework used in several of your projects.

Ie: public class ListItem { // Public properties. public var text: String public var isComplete: Bool
}

Problem with that is regardless of access control, you are still exposing your entire class code and layout to users of it, preventing any restriction on class access for "consumable non-internal" implementations.

- optional means object can be nil. But they're just a wrapper.

Real-world test code being written showed you end up peppering your code with ? and ! symbols.
Using ! unwraps a var to it's value. CHECK FOR NIL or use if let

Ig target.foo?() unwraps to if [target respondsToSelector(foo)] target.foo()

-weak reference need to be optional

-Swift "module" import uses the project group name; change a file from group and suddenly is out of the module

-AnyObject = id or Class type

Can't upcast AnyObject to a static type
wrong: var view: NSView = anyObject
need to upcast using as
var view: NSView = anyObject as NSView
or tested
var view: NSView = anyObject as? NSView

- Arrays upcast arrays: for item in myItems as NSButton[]

Your code end up having full of "as othertype" in it. So much for inferred type.

Random bridging nastiness:

-NSError** gets magically translated as NSErrorPointer
and you still need to pass by reference: &error
and then receiver must unroll pointer using !

- useless notations like optionals:

foo?.prop?.prop?.prop.ToInt()
vs foo.prop.prop.prop.intValue;

Saved nothing. Obj-C can already handling nil object dereferencing

- Integration with existing code: Obj-C require Swift mangled name

SWIFT_CLASS("_TC5MyApp10MyDocument")

-STL-style templates

@objc func myGeneric(x:T)-> (String,String) {} ensures
func can be expressed in Obj-C at compile type

Need I say more?

- Specify obj-c accessor:

var enabled : bool
{
@objc(isEnabled) get {...}
}

further obfuscate the .swift file (remember: NO HEADERS!)

- Swift does not fix the CF bridging issue

Unmanaged for manual memory management. ie

let color = CGColorGetRandomColor().takeUnretainedValue()

Force the memory convention by annotating the header

CF_IMPLICIT_BRIDGING_ENABLED() //header content
CF_IMPLICIT_BRIDGING_DISABLED()

- String-types enums are a major fubar

Given

enum Method : String
{
case GET = "GET"
case POST = "POST"
case DELETE = "DELETE"
case PUT = "PUT"
case PATCH

iOS is free to play with also

[SuperKendall]

one of the advantages of Android that I haven't seen anyone mention is that you don't need to know C or C++ or ObjectiveC/ObjectionableC. Just a subset of Java

I was a Java developer for around a decade. Now I've been doing iOS development full time for several years, most with ObjC and recently in Swift.

The thing is, from a language standpoint all of those are comparable in terms of effort to learn - so if he doesn't know Java it's no harder to pick up ObjC over Java, or Swift over Java (and Swift has the advantage of being a lot lees verbose than the Java or ObjC, while still maintaining the good descriptive aspects of ObjC [named arguments]).

The real effort is in learning the frameworks for whatever system you are developing for, Java was actually the first platform I know of where that mattered more than the language because the frameworks were extensive - but so are the iOS frameworks.

As a bonus, you can develop for free on any laptop.

You can with iOS/Swift also, the simulator is very good and you could realistically write an entire app ready to ship to the store then pay for a dev license only when you felt you had something worth using.

What you gloss over is that with Android development you often NEED to have a device to develop, because the Android simulators are so poor/slow. If he doesn't already have an Android device where is that $100 advantage? Gone, and more than gone because to buy a reasonable test device (or several test devices which is more realistic) is going to cost way more than $100... I have an Android device I bought when abroad for around 70 EU, that is utterly worthless for development or even running apps.

Maybe you'll decide that, until you get that sorted out, you want to take a (probably low-paying, but with your degree, who knows where that will lead) job at some humanitarian organization

Which will have even worse politics going on than in a normal company, and probably be very draining for the soul... those are the kinds of places you want to volunteer for, not work for. They will eat you up rather than giving you the uplifting you speak of. Have you really worked for one or does it just seem like a good idea?

you don't have to worry too much about this

iOS developers have not had to worry about THAT because we have THIS.

Which is Infinitely better than having to research the dreaded other thing because your app just locks up at times...

Seriously, have not had to look for leaks in years.

it will give you the basics of OOP

Swift will give you the basics of OOP *and* functional programming, which is far more valuable going forward. And it's much more interactive since you can use Playgrounds to explore.

The demand for Java developers is either for people who know the Android frameworks really well, or incredibly seasoned IT developers with years of service experience. A few weeks of learning Java will be of little use in finding a job anywhere.