
Ask HN: If learning to develop for iOS- start with Obj C or Swift? - austenallred
It seems like it&#x27;s an awkward time when Swift will definitely take over, but the environment around it may not be mature. My ios friends seem split on the matter.
======
mpweiher
Anecdotal evidence in favor of Objective-C (Swift wasn't around back then): at
an early WWDC, a dev. who was completely unfamiliar with Objective-C finished
his first Cocoa application during the "Intro to Cocoa" session, and spoke
about his amazement during the feedback.

Swift is way more complicated than Objective-C, even if the syntax may seem a
lot more familiar if you're used to certain other languages.

The reasons for this complexity are manifold: static type-systems of the
sophistication that Swift is attempting are complex. Even if Swift were stand-
alone, had an all new class-library (or non-class library as it may be), there
is quite a bit of complexity there.

However, Swift is not stand-alone. It has to interoperate with the existing
Objective-C class libraries. That alone would also not be a problem, had
Swift's designers not chosen to go in a completely different direction from
Objective-C, both syntactically and semantically. So while they did an OK job
in wrapping the libraries, there just is quite a bit of fundamental mismatch
that's just waiting to bite you. A small example are force-unwrapped optionals
that you get out of a lot of the library calls (because nil ptrs. are OK in
ObjC and Cocoa), which will blow up when you use them, without the compiler
warning you! (So much for safety).

As other posters have pointed out, you will need to learn Objective-C to make
sense of things.

On the other hand, Apple will push on Swift hard, and with the faddishness of
the industry being what it is, you might find Swift skills in much greater
demand, even if it doesn't actually make sense from an objective standpoint.

Finally, while Swift currently is completely proprietary, Objective-C actually
does have non-Apple implementations and users on Linux and Windows.

~~~
kgreenek
Idk if I agree that objective-c is simpler to learn. I have been working as a
full-time ios developer for almost 2 years now and I still have to consult
fuckingblocksyntax.com on a weekly basis. And fully understanding
objective-c's "message passing" idea is hard because it's so radically
different from other languages.

And sure you can whip together a simple app using all the documentation and
tutorials out there for objective-c. But objective-c has a lot of gotchas that
make it easy to do bad things as you start to build a larger app. Like
retaining self implicitly because of an ivar in a block... Can't tell you how
many times that is bitten us.

That being said, have you tried to use Swift with the core foundation
framework? Yikes. I spent hours yesterday trying to understand how to simply
pass a pointer to a function. The type was something like
CMutablePointer<Unmanaged<SecKey>?>. Hopefully it'll get easier as the
documentation improves though :)

~~~
potatolicious
Yeah, this is one of the reasons why Swift exists. The base Obj-C that we
started with was pretty simple and reasonably elegant, but over the years
we've been grafted pieces onto it in decidedly inelegant ways.

Block syntax, a ludicrous proliferation of __keywords and @keywords, the
verbosity of GCD calls, all of it makes modern, complex Obj-C apps harder and
harder to write.

In a lot of ways Swift is a reset. It offers a lot of the things we want from
Obj-C/Cocoa (e.g., more block-based everything) in a clean syntax that was
designed from the get-go to support it.

One of the complex bits of Swift right now is that the APIs haven't been
ported. UIButton still expects targets and selectors (ugh), and an innumerable
number of API calls still rely on the only C-style way of passing error
pointers into calls to see if they get filled (and necessitating the idiotic
NSErrorPointer class). A lot of the complexity of building in Swift right now
is shoehorning Obj-C style APIs into Swift code.

~~~
mpweiher
Yes, definitely. Objective-C was a lot more elegant before the odd grafting
started, with everything hard-baked into the compiler and special cases added
on top of special cases after the first special cases were found to be too
special.

So I'd agree that a reset is a good idea. However, Swift pretty much
represents the grafting-on approach. Even now, at the start, Swift is already
more complex, with more special cases, than even grafted-upon-grafted
Objective-C, let alone Objective-C as it started out.

That doesn't mean that there aren't a few things that are handled nicely, but
overall it's a bit of a mess already, because of the insistence of stuffing
everything into the language and compiler and having everything checked
statically (except that it only pretends...).

"If you focus on just messaging - and realize that a good metasystem can late
bind the various 2nd level architectures used in objects - then much of the
language-, UI-, and OS based discussions on this thread are really quite
moot."

\-- Alan Kay ([http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-...](http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-October/017019.html))

This is not to say that it's correct because "Alan Kay", but to show a very
different approach to language design that is, IMHO, much more powerful and
durable than special-casing all the language-fads-du-jour into the compiler.

If you go back a bit and see where Objective-C came from, it was the desire to
have Smalltalk, but with better performance and better C interoperability. So
an obvious reboot of Objective-C would have been Smalltalk based, with C
interop moved out of the base and better support for architectural
interconnect. A real "Objective-C without the C", unlike Swift, which is more
"Objective-C without the Objective-".

This is such an obvious thing to do that there have been several community
projects, including, but not limited to StepTalk, FScript, Pragmatic Smalltalk
and my own Objective-Smalltalk ([http://objective.st](http://objective.st)).

In fact, Objective-Smalltalk was in part inspired by Alan Kay's work as
expressed in that message: focus on the big things, get the right meta-system
in-place, the rest will take care of itself. (here's my response:
[http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-...](http://lists.squeakfoundation.org/pipermail/squeak-
dev/1998-October/004106.html) ) As such, it Objective-Smalltalk isn't trying
to be yet another Smalltalk implementation, but rather a new approach in the
spirit of Smalltalk: identify the next bigger thing to handle (we now have the
Web, for example) and then scale that down so it can handle everything else as
well. I think I'm on a good road of achieving this, Higher Order Messaging and
Polymorphic Identifiers in combination already handle a lot of what you need,
in a user-extensible, late-bound fashion, governed by a very simple and
powerful metasystem.

Starting with any of these Smalltalks (or a separate development along similar
lines) would have been an easy road towards the goals that Swift aspires to,
even considered by itself. When you add interop with the current class
libraries, which are simply _at odds_ with the Swift approach, it becomes a
no-brainer.

------
austinz
I would suggest going with Swift, but learning enough about Objective-C
concepts to use the Cocoa APIs. There is a guide to interoperability between
the two languages on the developer site.

For example, some sample code to call a method (here, one named 'upCommand')
whenever the user swipes in the 'up' direction looks like this:

    
    
      let upSwipe = UISwipeGestureRecognizer(target: self, action: Selector("upCommand"))
      upSwipe.numberOfTouchesRequired = 1
      upSwipe.direction = UISwipeGestureRecognizerDirection.Up
      self.addGestureRecognizer(upSwipe)
    

A more idiomatic way in Swift to create a gesture recognizer might be to
assign a closure to execute whenever the swipe is recognized.

However, because of the way Objective-C and Cocoa works, you need to define
the target of the action as a string literal describing the method name,
encapsulated in a 'Selector' object. This is a fundamental Objective-C feature
that shows up as a common idiom in the Cocoa APIs. If you didn't know what a
selector was, you might have trouble translating this API into working Swift
code, since Swift has no real equivalent construct (except the 'Selector()'
class described above, there only for backwards compatibility).

------
gdubs
I've been writing Objective-C for a long time now, and have shipped a fair
number of iOS apps. It's a beautiful language in my opinion, if you can get
passed the syntax (harder for those who lack a "beginners mind" and are used
to a certain way of doing things.)

To answer your question, it really depends on your goals. If you're looking to
write your own apps, and you're not under any time pressure, I'd say start
with swift. Apple will push the adoption curve _hard_, they always do.

If you're looking to get a job as an iOS developer in the next year or so,
Objective-C isn't going anywhere. Big organizations in particular will not be
rewriting their apps from the ground up, and there will be legacy code to
maintain for years to come. I know of some big projects that were still
avoiding ARC for quite a long time...

No matter what, I'd learn Swift _now_, but if you can spare the time I'd say
do yourself a favor and learn both. Objective-C has a lot of great concepts,
and they're totally worth learning. And it will make understanding the Cocoa
and UIKit frameworks a bit easier as well.

Good luck!

------
wisty
Objective C. When you need to figure something out, and Google returns 1,000
tutorials on how to do it on Objective C and nothing for Swift, you'll know
why.

Sure, Swift might be better. One day you'll probably learn it. But 99% of the
effort in learning Objective C is learning all the frameworks and libraries,
and the support to do that is much better in Objective C (at present).

If you already know Objective C, and a looking at starting a new project,
Swift might be better. The lack of Swift-specific resources won't hurt,
because you should be able to easily translate them from one to the other. But
if you don't know either, I'd start with Obj-C.

~~~
blisterpeanuts
Yes, I've just started down the iOS road and of course I'm sticking with ObjC
for now; all the Stack Overflow questions and tutorials are for ObjC at
present and I can't just adopt a brand new language. Eventually, I will,
though; Swift looks pretty cool!

------
jonhmchan
I used to help teach the iOS Development class at NYU - I was having this
conversation with the professor who's teaching it again next year and we
talked about this specifically for new students.

I think that you should learn Swift because it is where most app development
will be heading in the future and far easier to pick up than Objective-C. The
main disadvantage currently is that the whole corpus of knowledge about iOS
development is steeped in Objective-C. My advice is to learn Swift and develop
in Swift, but know enough Objective-C to be able to translate it to Swift and
read documentation written for Objective-C.

Eventually as the corpus of knowledge in iOS development grows for Swift, this
won't be as much of an issue.

------
potatolicious
Objective-C, though approach knowing that you'll switch to Swift.

The Swift tools aren't mature yet - on Friday I managed to get llvm to
segfault on multiple parts of my codebase. Rewriting the same thing in
slightly different syntax fixed it.

The code highlight/autocompletion service also crashes frequently, as does
Xcode in response to certain pieces of valid code.

Not only that, the amount of Googling you can do with regards to any kind of
problem is roughly zero right now. People are still figuring things out, so
the amount of help you can get is very, very limited.

Once Google/Stackoverflow fills up more, and llvm stops fucking crashing on
perfectly valid syntax, you can switch to Swift.

------
josephlord
Several questions to consider in deciding:

Can you wait 6 months to start? How comfortable are you with functional
programming and type theory? How comfortable are you with C/C++? How tolerant
are you of buggy/constantly crashing software?

In 6 months time the answer will be Swift in my view. It is a better language
and has nice strongly typed features to help make robust code.

However at the moment you have to put up with a buggy implementation and a
development environment that is likely to crash every 30 minutes or so taking
unsaved edits with it (this is not a complaint it is an Alpha/Beta release and
the first release). It does make developing more of a chore. Plus the fact
that the language may change itself in the coming months (and in places like
the arrays I hope it does). Given all that I suggest waiting and doing
something else in the meantime.

If you are familiar with C/C++ I would dive in with Obj-C and start getting to
know the libraries you will need for your project and you can start adopting
Swift when you are ready.

If you don't currently program or are used to dynamically/duck typed languages
like Ruby and Python I would try some stuff in something like Haskell, ML or
another strongly typed language that will get you used to type theory and how
to programme in that sort of strongly typed environment within a stable
environment. I think that would make it easy to pick up Swift when it is a
little more stable.

If you already have a good background in functional programming but not so
much in C/C++ it might be worth braving the instability to use Swift to learn
the Cocoa touch libraries and explore. The Playgrounds are very cool but VERY
unstable at the moment, maybe there will be a better release tomorrow.

------
kabdib
I learned Objective C in about a week (two days of reading, then three more
days of trying stuff out).

I'm not an expert ObjC hacker, but if you already know C++ and have done a
little UI work in something before then you shouldn't have much trouble.

Once I got over the hump (mostly weirdness with terminology and window
manipulation), the XCode environment feels quite nice, comparable to Visual
Studio with the Whole Tomato plugins.

Next up: Android. Hmmm.

~~~
nkozyra
Boy, I considered myself pretty well-versed in C++ (and pretty good at C
proper) and looked at Objective C like it was Delphi or something the first
time.

I wouldn't say it's a simple transition, even if it is a superset. You can get
away with writing a great deal of an iOS app without doing much in C proper at
all.

~~~
craigching
Curious what you found difficult? Maybe memory management and synthesize? The
dynamic nature of Obj-C?

Coming from a C/C++ background myself (and Java) I found it pretty straight-
forward to learn. It wasn't free, but not too bad either. And I'd argue
they've fixed most of the annoying things these days (synthesize was my
biggest annoyance, never could understand why that couldn't be automated as it
is now).

------
ricardobeat
I can offer anecdotal evidence in favor of Swift: I attempted to learn Obj-C
in the past and gave up more than once, whereas this week I downloaded the
XCode 6 beta and in an hour had my first app running.

The documentation on Cocoa is still sparse, and you have to use a lot of Obj-C
interfaces, so it feels like you're a level up too high; it's backwards, but
better than not learning it at all.

On the other hand, if you are looking into doing it professionally, it doesn't
seem possible to build complex iOS/OSX apps right now without knowledge of
Objective-C.

------
dirtyaura
A +10 times WWDC veteran said to me that it usually makes sense to really
start using new dev tools and APIs 1 year after their announcement in WWDC.
Dev tools have matured enough and the latest OS version has had enough
installs to make it worthwhile.

~~~
josephlord
There is probably quite a lot of truth in this if the new features aren't
things your product needs. I've only been doing iOS development for 3 years
and while I haven't been to WWDC yet I have followed the videos. I've been
bitten by things each year having gotten excited.

3 years ago: Core data ordered sets looked perfect for my use case and then
proved buggy. The kicker was a year later when iCloud managed document
integration came along ordered sets were not supported (and they still
aren't).

2 years ago: The above iCloud support was introduced and I was probably saved
by the lack of support of ordered sets and their use in my code because for
the first year iCloud was very buggy and problematic (see numerous blog
posts). The major iCloud announcement at WWDC the following year was basically
"no new features but we've fixed the bugs and added some testing tools" and
they got a big round of applause. Autolayout was introduced (I think) which
again excited me but I think my experiments with it in interface builder
basically failed so it didn't make it into my app.

1 year ago: iOS7 being introduced encouraged me to adopt Autolayout. At least
up until the release of iOS7 and Xcode 5 there were some pretty major problems
building Autolayout designs which caused me issues. Even the current release
Xcode has some issues that I recently needed to hack the XML file to work
around[0].

This year it remains to be seen what level of stability is reached by the
release time. At least there is no need to release product with a new design
like there was last year so maybe I should be waiting for a more final release
before trying Swift but I'm giving it a go. I might even try to release some
Swift code in my product before the final release (by creating a framework and
including it from Xcode 5) but I'll have to test it well.

[0] [http://blog.human-friendly.com/hacking-constraints-in-
storyb...](http://blog.human-friendly.com/hacking-constraints-in-storyboard-
files)

------
craigching
Both. Swift should be your focus, but you need to know enough Obj-C to
translate doc (hopefully a short-term problem) and you need to interop with
Obj-C. Swift will be the more productive language, but will have a bigger
learning curve (it is a bigger language, more concepts). Obj-C is not that
hard to learn these days, a lot of the annoyances are taken care of for you
(ARC, synthesize, etc.)

Good luck and have fun!

------
polskibus
I know you asked a closed question, but would you consider Xamarin? This way
you would earn more transferable skills (C#, multi-platform toolkit, etc.) and
not lock yourself in one platform. You could also develop in raw C++ and have
only a thin ObjC wrapper over it.

------
nkozyra
You know how a good beer tastes even better after a really long, arduous,
confusing, painful, muddled, wonky day of hard labor?

That's what it'll feel like when you try Swift after learning Objective C.

------
davidrupp
Short answer: Both.

Longer answer: Swift is the future, so if you have to pick exactly one of the
two, pick Swift only. But Swift is, along some axes, an evolution of ObjC, and
you will learn much by getting what you can from the wealth of
ObjC/Cocoa/CocoaTouch material that's already out there, then applying it to
Swift.

------
adamnemecek
I don't think that it really matters that much, they are not THAT different.
The harder part about learning Cocoa is learning the how to structure the
application and the APIs. You might have an easier time starting with Obj-C
since there will be more learning material and more sample code that you can
learn from.

------
LeicaLatte
Learning, Swift for sure.

For shipping, prototyping or production work, you cannot live without some of
the stuff from the community. Cocoapods, testing frameworks, AFnetworking,
Reveal there's a lot. All those are obj-c and it will take some time for Swift
to catch up.

------
wsc981
I think you do have to learn a bit of the basics of Objective-C. The sole
reason being that most of Apple's frameworks are currently written in
Objective-C, as well as most tutorials and example material. You'd have an
easier time converting Objective-C code to Swift code if you understand the
basics of Objective-C. You'd also have an easier time finding solutions to
problems on sites like StackOverflow, which already has a wealth of Obj-C
questions and answers.

But in the end you don't have to become an Objective-C pro. Once you feel
comfortable using the language, you could start focusing on Swift.

------
ajarmst
I, having been burned many times, have developed an allergy to the latest new
shiny thing, especially if heavily promoted. The number of such things that
have been successful are lost in the mass of those that have not. For every
C#, there's a hundred Microsoft Bobs.

Investing scant resources (and your time and mind-share are among the most
precious you have) in a technology before it has developed a following, third-
party support (tools and libraries), a viable user base, and the resources to
educate yourself and others is a significant gamble. Sure, you might win. But
you probably won't.

------
chriseidhof
Swift. All the code will move to Swift eventually, I predict that new APIs
won't even be callable anymore from Objective-C in the future. I'm going to
write all my code in Swift from now on.

~~~
zbowling
I highly doubt that actually. Swift is not a replacement. There will always be
glue between Swift and platform and system APIs. Swift only interoperates with
Objective-C and (to a limited extent) C and not C++ (and a lot of APIs in
Apple world are exposed as C++ especially on the Mac). Swift uses ObjC blocks
and can't even handle function pointers. Unless there is a dramatic shift in
the design of Swift, I don't see the writing on the wall that Swift is out to
kill Objective-C, only complement it.

------
bdcravens
Learning a language is more than learning the official syntax. It's solving
real problems, finding a community, looking up answers on blogs and Stack
Overflow. To that end, I think the answer is definitely Obj-C, but it's not
mutually exclusive. I think Swift is where C# was circa 2002 - it might be the
language of the future, but back then there was still plenty of VB being
written, and ditto for Obj-C.

I personally think starting with one of the WebView wrappers is a better place
to start, as it gets you used to the toolchain.

------
jerluc
I'd agree with some of the other commentors' sentiments voicing that you
should start out with Objective-C, but less so because of immature tooling.

For me personally, I'd be more concerned about someone in your position trying
to learn Swift now because it's an incredibly immature language. Core
language-level changes IMO are the hardest to cope with, as they can have a
severe impact on code written in a previous version of the language, not to
forget how much of a mental cluster-f!#@ it can cause.

------
Chetane
I've just started looking at swift since it was launched, and making really
good progress so far. Having coded in Ruby, C#, C++, and C, I really enjoy and
"get" swift as it's leveraging the strength from all these languages.

I also find it pretty easy to convert Objective C code (from
tutorials/StackOverflow) to swift, in particular with the help of auto-
completion. So in my opinion (from someone who just started, so take with a
grain of salt), I would definitely suggest Swift

------
runjake
It doesn't really matter, in my opinion, because the major learning hurdle
generally isn't the languages, it's the Cocoa frameworks. Experienced
programmers can pick up Swift or Obj-C in 2-3 days. The frameworks will take
you considerably longer to feel comfortable with.

That said, Swift isn't production-ready yet, and there's not a wealth of books
and documentation, but it's very, very likely the future of iOS and OS X
application development.

------
alpsavrum
Actually you don't have to learn Objective-C or
Swift.([http://www.smartface.io/ios8/](http://www.smartface.io/ios8/)) With
"Cross-Platform tools" you can develop cross-platform apps only using one
code. The Studio Which i use is Smartface App Studio. It uses %100 JavaScript
and lets you build %100 native applications. In my opinion you should take a
look.

------
purringmeow
I am not an iOS dev, so I apologize if the answer is too obvious, but why did
Apple introduce Swift? What's wrong with Objective-C?

~~~
gress
Swift is designed to:

* be safer and reduce bugs * be more concise to increase productivity * be easier for the compiler to optimize * introduce functional programming constructs to make algorithm development easier

Objective-C is weak in all of these areas.

------
loumf
Most of what you need to learn is Cocoa Touch and whatever other frameworks
you want to use. If you need to start today, use the production Xcode and
Objective-C -- it will be far less frustrating.

Give the Swift book a quick read in a month or so, so you are familiar with
the differences. Perhaps start thinking of Swift in August.

------
threeseed
If you plan to work in the industry in the next few years. Then definitely
Objective-C. No serious company is going to rewrite an existing app in Swift
just because it's a cool language.

------
sumitiscreative
Definitely Swift, i have mentioned and curated content here, about why and
how. [http://goo.gl/8X9H2u](http://goo.gl/8X9H2u)

------
CmonDev
Learn C# instead:

0) easily very cross-platform (but you will have to pay), mainstream in mobile
games via Unity3D;

1) not locked to one company: .NET by Microsoft, Mono by Xamarin;

2) open-source and welcoming feedback;

3) modern and innovative (not like Swift, but for real - introducing stuff
like async/await, mixed dynamic/static typing etc.);

4) allows building mobile, web, desktop, butt software today;

5) first-class IDE, that will get an extensible compiler-as-a-service in 2015;

6) best in class automated refactoring via ReSharper.

------
Arcanum-XIII
Pragmatic : Objective C. Swift is too "young" and unproven - there's still lot
of rough edge, it's a beta. But start learning Swift in the same time. Future
looking : Objective C, to be able to understand the interop still needed for
Swift... but using Swift right now for most stuff.

------
ianstallings
This is a tough one. Swift is going to be the future of iOS development and
very important. But at the same time I think Obj-C will allow you to explore
all the existing source code that is out there without any problems. I'd say
go with Obj-C and learn Swift in the future.

~~~
ianstallings
I see the dick riding down voter is here again. Ah go fuck yourself.

~~~
ianstallings
So the story is buried and I still get a downvote. Dick rider confirmed.

~~~
ianstallings
Idiots.

------
jayd16
Not knowing either, I would say Objective-C. Way more tutorials, SO answers
and you don't want to be dealing with compiler bugs when you're trying to
learn. In a year the answer will be Swift.

------
legohead
as a C programmer, _anything_ but Objective-C

