
Why many developers still prefer Objective-C to Swift - Udo_Schmitz
https://www.hackingwithswift.com/articles/27/why-many-developers-still-prefer-objective-c-to-swift
======
orbitur
I work for a company that writes iOS apps, large and small. When Swift 2 came
out, any new projects we started were in Swift. We still maintain several
large and small ObjC apps.

If I had my way while were planning out a "big" app, it would be ObjC.

\- ObjC isn't going anywhere, and it continues to receive improvements

\- Xcode 9 can still barely handle large Swift apps; I consistently lose
syntax highlighting and autocompletion

\- Equivalently sized ObjC apps clean build in approximately 1/3 of the time

Swift as a language is fine. There were some neat new concepts it forced me to
learn, and I look forward to writing it. But the tools make me want to work on
anything else.

edit: Also I was really, really looking forward to Swift 4 & Xcode 9. I hoped
there would be improvements in build time and less IDE problems, but I see no
noticeable change in build time, and Xcode routinely leaves me unable to
quickly make changes to Swift code, either because indexing failed and
autocomplete is suggesting random shit or because autocomplete isn't there at
all. Then I switch tabs and for a moment I'm looking at syntax highlighting
until it just... disappears. Maybe changing a line will fix it, maybe it
won't. Xcode 9 might actually be worse in this respect.

~~~
bartvk
Tip to reduce compile times:

1\. Use modules.

2\. In Xcode, go to your target, go to Build Settings, and at Other Swift
Flags, add the following flags: -Xfrontend -warn-long-expression-type-
checking=400

This will issue a warning when the Swift compiler takes more than 400ms when
deducing the type for a particular expression. If you get no warnings, lower
to 300, and if necessary to 200.

Anyone have other tips?

~~~
dep_b
Type all of your more complex statements and block parameters, especially when
you're chaining complex stuff. It's much easier to verify that the types
you've stated are correct than to calculate all the possibilities that a type
might have.

------
aplummer
I think a lot of these comments are directed at Xcode and tooling, not Swift
specifically. This is unfortunately just the trend with where we are at with
new desktop mac software, hopefully High Sierra's focus on improvements over
features will be a turning point, Xcode 9 does seem to be on the right track.

When I was out of the office this week, two server side java developers helped
a Swift junior step through some code - they both were really surprised and
impressed at just how approachable Swift is. As well, I notice daily how few
runtime errors and issues we have with Swift code-bases comparatively.

I think a lot of these comments are straw-manning the language. Yeah, people
don't like being beta testers, or using immature and changing software vs very
mature and stable software - that's not comparing two languages themselves
though.

~~~
megaman22
Has XCode ever been good? I've tried using it from time to time, over the past
ten years, and it's always just felt like banging rocks together compared to
the Microsoft or Jetbrains tooling.

~~~
aplummer
Like anything it has it's pros and cons. For some thing it's the best IDE out
there and for others not so great. Xcode 9's speed improvements to the editor
are fantastic, but stability has been an issue for me at least.

------
iOSGuy
Swift is great for a small app, with a handful of developers. For a platform,
which interops with multiple languages, being worked on by a large team of
engineers, switching to Swift would just be silly.

Oh yeah, let me increase my compile times, the size of my SDK, add
complications for my publishers, see zero performance benefit, build a ton of
scaffolding code, add yearly tech debt until Swift is actually a mature stable
language. Terrible idea!

It might be the gold standard some day, but for now it's just a kid compared
to ObjC, and everything that comes with being a C based language. If you're
learning to make apps, by all means, you should learn Swift, but it will be
quite a long time before ObjC is dead and gone, so be prepared to learn both
young padawan.

Not to mention, the hype train/bandwagon is really muddying the waters. It's
probably a bad idea to take advice on how performant/powerful Swift is from a
Zealot, or someone that's betting everything on it.

~~~
orbitur
I'm not so concerned about "yearly debt" anymore. Swift 2->3 was baaaad, but
Swift 3->4 was painless. I don't expect it will be worse next year.

~~~
snerbles
As a newcomer to Swift, finding "old" blog posts and tutorials that are
written in Swift 2 is utterly maddening.

~~~
melling
Try finding new blog posts in Objective C. Most are in Swift.

~~~
snerbles
At least one can tell those two apart. To someone learning the language, Swift
2 and 3 are almost indistinguishable.

Lots of fun compiler errors and deprecation warnings were had.

~~~
melling
You can run them through the Xcode converter. I made a list of the code that I
converted. It’s really not that hard to deal with small examples:

[https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-
swift-...](https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-
swift-3-refactor-list/)

------
jordansmithnz
I’ve developed primarily with ObjC for about 4 years, and when Swift was
released, primarily with that - so roughly an even amount of time with each.

The article has a lot of very opinionated comments, some of them not true
(e.g. ObjC development has not completely stopped). There are definitely some
truths in there too, like how fluid the language has been so far (last year’s
Swift code probably won’t just compile this year).

In general, I think it’s fair enough to say that Swift hasn’t matured yet.
It’s not so stable, and tooling isn’t great. Large projects might suffer from
that. ObjC on the other hand is rock solid, but lacks some of the more modern
language features of Swift.

Personally, I’m all for Swift, because it’s the future. Tooling issues and
stability can (will?) change. Turning ObjC into a modern, next generation
language just isn’t something that seems feasible.

Aside from that, Swift is a really neat language - tooling aside, I find that
Swift is (mostly) a great language to write in, with features that I’d sorely
miss going back to ObjC. That’s purely opinion though, I’m sure there’s others
that might say the same from an ObjC standpoint.

------
dreta
We started using Swift on new projects. I don't hate it per-se, but as with
most new languages like Rust, or Kotlin, they have some neat, modern ideas,
but mostly they help solving none of the problems you have on a day-to-day
basis, and instead make common coding tasks harder.

Using Swift feels like i'm back in college writing C++ code while following
all the newest design patterns, and best practices, thinking about whether i
should make two classes friends or not, instead of solving actual problems.

------
okdana
I think the Swift language is great, but the tool chain (specifically
`/usr/bin/swift` and `/usr/bin/swiftc`) is absolute garbage. The documentation
is almost non-existent, its preferred method of 'handling' errors is to just
segfault, when it _does_ give you an actual error message it's completely
nonsensical, and as mentioned it's very very slow.

I think i'm a version or two behind the latest, so maybe it's better now, but
that's been my experience so far.

Anyway, in spite of the above i still prefer it to ObjC.

------
Koshkin
For people coming from C/C++/ObjC, certain things in Swift can take some time
to get used to, e.g.

    
    
      if case .Success(let person) = personResult { ... } 
    

My first thought when I saw this was, "only a mother could love this syntax",
but later you come to appreciate and enjoy it.

Link: [https://www.natashatherobot.com/swift-guard-better-than-
if/](https://www.natashatherobot.com/swift-guard-better-than-if/)

~~~
apple4ever
That’s the biggest reason I don’t like Swift- it’s terrible syntax.

I hate let, var, func. I hate the backwards variable definitions. I hate the
crazy punctionation symbols (dots, question marks).

I agree with a lot of what Smith says about Objective-C. But my biggest
personal reason is the above. I find Objective-C beautiful and Swift ugly.

~~~
AsyncAwait
Very subjective, I for one like practically everything you listed as not
liking about the syntax:

> I hate let, var, func

For me it increases readability, for example when I see let, I can make
assumptions about it not being mutated, which is a huge win in a large
codebase.

> I hate the backwards variable definitions.

To me it says, "this is a variable called x of type String", which seems to
make sense to me, definitely more so that the C way.

I hate the crazy punctionation symbols (dots, question marks).

Question marks denoting optionals seems very clear, like "is String? really
there?"

> I find Objective-C beautiful and Swift ugly.

See, I am the other way, I don't really find [[]] all that beautiful.

~~~
fauigerzigerk
_> when I see let, I can make assumptions about it not being mutated, which is
a huge win in a large codebase._

What we know is that this won't work:

    
    
      let p = Person("one")
      p = Person("two")
    

But we don't know whether this will work:

    
    
      p.name = "three"
    

It depends on whether Person is a struct or a class, but that information is
not available locally. let/var is fine, but in terms of information content it
is strictly worse than what const can do in C.

~~~
AsyncAwait
You're right, if reference types are involved, it becomes tricky, however to
the extent that Swift encourages value types, it still provides value.

> in terms of information content it is strictly worse than what const can do
> in C.

True, however the Swift community largely adopted a "use let first, only use
var if absolutely necessary" approach, which is strictly better in terms of
mutability-related bugs than what it was in ObjC/C, as mutability there is
used much more liberally than in Swift.

------
madrox
All the junior mobile engineers I’m interviewing now are learning iOS
development on Swift. Junior engineers are probably the most pragmatic
programmers on the planet. When they’re choosing to learn Swift vs ObjC, none
of them are saying “...but ABI stability!” They’re learning Swift because
they’ve found they can make apps faster with it.

Tells you all you need to know about the future right there.

~~~
microtherion
> Junior engineers are probably the most pragmatic programmers on the planet

As a cranky senior engineer (and Swift fan), I'd say that junior engineers
tend to overvalue novelty and undervalue stability.

~~~
xeromal
As a dev forced into web development, you're not kidding. Frameworks and
tooling are a dime a dozen. I learn this and in 6 weeks it's old and busted
and not cool. You can't really become an expert at anything, but plain old
javascript.

~~~
dozzie
>> As a cranky senior engineer (and Swift fan),

> As a dev forced into web development, you're not kidding.

But he's not web programmer, he's mobile programmer.

------
Koshkin
The nice thing about Objective-C is that it combines two excellent distinct
languages - C and Smalltalk. Swift, on the other hand, introduces a completely
new universe. Which many swear is a good thing.

------
askafriend
No one said the future would be painless to adopt. What's obvious is that
Swift most definitely _is_ the future. Apple has made their commitments clear.
There's no stopping that train so might as well get on-board.

That's my view.

~~~
makecheck
Careful though, Apple has changed its mind plenty of times. A huge portion of
the stuff developed near the tail end of Carbon for example was presented as
the future, until it wasn’t. Heck, Forstall got on stage claiming Carbon was
becoming 64-bit “top to bottom” (never even shipped). Companies can have the
best of intentions but it still doesn’t take much for the next manager to come
in and torpedo all the promises.

~~~
agildehaus
Not sure how Apple deprecating a transitional tech is a valid comparison to
Swift. You might as well say APFS is a passing fad that some manager might
cancel and we'll all be back on HFS+ soon.

~~~
makecheck
It was not presented as a “transitional tech” at the time, it was presented as
an equally valid/supported way to build even new apps. Also, for a _very_ long
time there were things you could only do in Carbon, and arguably that was
still true at the time it was deprecated. Apple just makes bold moves that
aren’t always clean breaks.

~~~
agildehaus
It was always a way to get Classic apps running on OS X and Cocoa was the
preferred. No idea where you get that it was on equal footing to Cocoa.

------
aryehof
For better or worse, Swift will become the only choice known by a new
generation of programmers.

Merit and past lessons learned, are not really how concepts, practices and
techniques become popular in computing. Alan Kay had it so right when when he
said that computing is a "pop culture".

------
greensamuelm
The real point that I think this article misses is framework development.
Swift _still_ has not achieved ABI compatibility. If you are using an iOS
device, very likely framework code I have written in the past few years is
running inside one of the many apps you have installed.

This is simply _not feasible_ to do unless you are willing to open source your
code base. I have been shipping closed source binary frameworks written in
Objective-C for seven years. None of the companies I work for are willing to
maintain binary releases for each version of Swift AND Xcode. It's simply too
much.

I'd love to use Swift, but at this point it would only be a maintenance
nightmare for my team and I to maintain.

~~~
gok
I find it interesting how much flack Swift takes for not having a stable ABI.
Many contemporary but older languages (Go, Rust) haven't even attempted it. Go
binaries aren't even really safe to use across macOS releases, since they get
hardcoded to make syscalls directly.

~~~
steveklabnik
Rust takes a lot of flak for it as well, some to the point of suggesting it's
illegitimate until it has one.

------
nickgrosvenor
Because they're more comfortable with it

~~~
neonhomer
Exactly. I haven't had any problems switching to Swift for newer projects.

------
cageface
My apps stopped crashing when I started writing them in swift. That alone is
worth any hassles with an immature language or tooling.

------
blunte
Legacy code. That's the primary reason some people haven't jumped the Swift
bandwagon.

Newness (which includes rapid, breaking changes in language and still-to-be-
improved tooling) would be number two.

~~~
ioquatix
I've got apps that were originally Objective-C and I've migrated parts of the
app to Swift and it's been a great experience in almost every respect. I'm
honestly surprised at how seamless the experience has been, given that the app
is 10 years old and had a pile of very Objective-C specific things (e.g.
NSClassFromName or whatever that API is called).

~~~
kalleboo
On the contrary I've had a lot of problems with the ObjC-Swift interop, to the
point where I've mostly given up on integrating Swift into existing ObjC
projects. Like most of the other problems with Swift, this comes down to
tooling issues. Xcode's "jump to definition" taking me to auto-generated
interop header files, "AppName-Swift.h missing" errors, the debugger losing
track of a stacktrace in the transition between languages...

------
let_var
Here's something from the point of view of a Swift engineer who had multiple
conversations with experienced Objective-C developers.

1st. Don't look at it from the language perspective. Look at it from the point
of view of the platform and dozens of SDKs that comes with it. It's lot easier
to use those SDKs in an environment you are already comfortable with.

2nd. There's no financial incentive for an existing app to be ported to Swift
or train experienced developers to this new language. In my manager's own
words, "...you have to give me a business justification to port our app to
Swift..."

3rd. I'm afraid to say that incredibly high inertia about learning and
embracing a new language, and letting go of your stronghold.

Swift is an amazing language, and it's quite easy for you to switch between
Swift and other C-style language e.g. ECMAScript. Objective-C has somewhat
obfuscating syntax that makes it intimidating for beginners.

~~~
3chelon
Valid points except the last one: Objective-C is a strict superset of C, Swift
is not. If you're going to learn another C-style language, I'd start from
Obj-C not Swift.

------
cm2187
Is Apple really pushing for swift to be adopted in schools and colleges? Given
that it only runs on iOS and MacOS (expensive platforms) and that you need to
pay some fees just for the privilege to create your own iOS app, it's not an
obvious candidate in my mind, irrespective of the language's own merit.

~~~
magnetic
Just to clarify a bit: you only need to pay if you want to distribute your app
on the iTunes Store.

~~~
cm2187
Last time I checked (but perhaps it changed), if I wanted to install my own
app on my own iPhone I would have not only to pay for a developer license, but
also a special enterprise deployment fee (for non public apps).

I am not a professional developer and I like to tinker, create my own tools.
But it is uneconomical for me to pay all these fees just to run my own app on
my own hardware. I ended up going the web app route.

~~~
dangero
That has never been true. The enterprise deployment fee is only needed if you
want to deploy it to OTHER phones besides your own and even then it would have
to be a lot of them before it mattered.

The developer license is all you need to put it on your own phone. Source:
Started developing iOS apps in 2008.

~~~
cm2187
Are you referring to free provisioning? My understanding [1] is that it is
only for temporary testing an app on the device, you can't leave the app
permanently, you have to reinstall it regularly.

And you still have to pay a yearly fee, which creates a high barrier to entry
for non professionals.

[1]
[https://developer.xamarin.com/guides/ios/getting_started/ins...](https://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/free-
provisioning/)

~~~
saurik
There are three levels: $300/yr for "enterprise" allows you to deploy your app
on a large number of devices within your organization (and the terms of
service are very explicit that the devices must be under your control: not
even for testing by a customer at an off-site location unless you are
overseeing), $100/yr for an individual or company normal developer license
that lets you install your app for testing purposes on up to 100 of your
devices for one year (after which point the apps expire and you have to
reinstall them), or $0 for truly "free" provisioning (no yearly fee) which
lets you install up to three apps (total; not per account: across all free
accounts any device can have only three such apps) on a device using a
slightly limited set of APIs (for example: no VPN support) which expire every
seven days.

Clearly the free tier is pretty worthless in the grand scheme of things, and
being able to write software for you but not being able to legitimately give
it to anyone else not also paying the $100/yr "please let me own the piece of
hardware you sold me instead of renting it" tax is not really acceptable for
people trying to learn to write software as a big part of software is being
able to give it to other people. In practice, though, a lot of people are
seriously only learning to develop so that one day they can pay the full Apple
developer tax and deploy their apps to the App Store under the Apple software
approval process, and so it works out: like, to them, software development is
all about writing software for Apple hardware under Apple's rules, and that's
what Apple wants anyway. The entire scenario makes me feel a little sick: this
shouldn't even be legal as far as I'm concerned.

------
Apocryphon
It's pretty awful- there's not a lot more beginner material for Objective-C
anymore. Even if you think it's for legacy work only (Facebook and  itself
have a word with you), it's still needed to learn. Many many apps are too big
to rewrite in Swift. Don't discount your roots.

------
s_kilk
I haven’t touched macOS/iOS development in a while, but I feel Objective-C has
a certain graceless charm which just isn’t there in Swift.

~~~
gkya
Yeah it's a beautiful language in its own peculiar way. For many years I was
very intrigued with it and thought of getting into Macs to just use it.

------
3chelon
Wow, that was quite a whining article. I mean, I doubt I'll ever forget Obj-C
but Swift is now my goto language for iOS projects. Reminds me of when I was
reluctant to abandon assembler for C. Get over it.

------
Grustaf
I wonder how long we will keep hearing the complaint that Swift keeps
changing. I never saw that as a problem at all, 99% of the changes have been
for the better, and most of the time it's exactly the things I have wanted
them to change, or add.

For the first few days after the announcement I couldn't see the point of
Swift, why did Apple feel they needed a new language? It's not like there was
a dearth of developers in objc. I started reading the Swift book from Apple
though, and when I finished it a few days later I was hooked. Since then I
haven't voluntarily written a single line of objc.

Of course circumstances may vary but for us migrations between Swift versions,
even the biggest ones, have never taken more than 2 hours. Learning the new
syntax as a developer I see exclusively as a positive, it's exciting to see
how it develops. WWDC is Swift Christmas.

Again, each project and each developer is different but I can't shake the
feeling that at least some of the objections raised by obj c diehards sound
like pretexts, especially the talk about the language being in flux. It's not
like you're forced to adopt the new version immediately, and in any case APIs
also change. It's just part of the job. And Swift can't improve if it's not
allowed to evolve.

~~~
kazagistar
I thought they were pretry clear about why churn was bad:

\- Many examples are older, and don't compile anymore.

\- Code maintenence costs increase for long term "write it and forget it"
code.

I don't have a hrose in this race, but when I heard Swift was making breaking
changes, I had an immediate negative reaction.

~~~
Grustaf
How else could it be improved? The alternative would be to work on it in house
for a few more years and only then release it to the world. I think it’s much
better to let it be used by millions of developers in real apps and learn from
that experience.

Migrating code to newer versions is seldom a big problem, and it’s even
smoother now when you can run several versions in the same app.

------
xirdstl
Does anyone use AppCode? How does it stack up to Xcode for Swift development?

~~~
matt2000
It’s much much better than Xcode for autocomplete, code highlighting and
refactoring. It’s just a better swift editor than Xcode basically.

Disclaimer: I’m a long time IntelliJ user so I find the environment more
comfortable in general, not sure if that’s the case for long time Xcode users.

------
Razengan
I'll just add my 0.02 and say that for writing games, at least, I cannot
imagine a better language than Swift, unless it's a slightly better version of
Swift.

Combined with SpriteKit/SceneKit/GameplayKit/Metal, it's a decades-long dream
come true.

~~~
cableshaft
If you're only wanting to make games for iOS, sure. The moment you want to
make games for any other platform in addition to iOS, you have to look to
other options (or be willing to work on multiple codebases, which I have less
and less time for nowadays).

I've got a game half done in Swift with SpriteKit that I did as a learning
exercise, and it was a smooth experience, but I'm having a hard time
justifying putting more time into it when I would rather spend it working on
something that I could make a build for PC, Android, and consoles as well.
Hence why my efforts are more in Unity now.

~~~
Razengan
> If you're only wanting to make games for iOS

Not just iOS, but macOS, tvOS and watchOS as well. You can easily reuse like
90% of the code, save for the platform-specific windowing/views and player
input subsystems. Xcode even comes with a cross-platform game template.

Although I do want to be able to develop for the Nintendo Switch as well, I
don't mind being limited to the Apple ecosystem for now; it's the more
lucrative market, and I get faster access to the latest tech, but most
important of all, is that I know my potential users will have access to that
latest tech (see Android fragmentation and adoption rate).

Sometimes, I don't even have to rewrite or do _anything_ to have my games use
the latest tech; when Metal was introduced, SpriteKit and SceneKit were
updated to use it under the hood instead of OpenGL, giving a performance and
efficiency boost to all existing games for free, without even recompiling!

------
gok
Swift is a really cool, but in many ways more complementary to ObjC than a
particularly great replacement for it. A lot of the things uniquely
interesting about ObjC (truly seamless C/C++ interop, tiny lightweight
runtime, learnable in an afternoon for C users) are explicit non-goals of
Swift. So it’s not surprising that developers who found ObjC to be a good fit
for their problems aren’t always finding Swift to be the right tool.

------
betadreamer
Swift is a good language. Especially if you are new to Apple ecosystem. Objc
looks ugly and scary. But after 5 years of objc, I actually like the bad
things about it lol

What I don’t like about Swift is that it evolves every year. I already need to
maintain new OS updates and new devices. I don’t want to have another thing
that I need to maintain... especially the language itself.

~~~
ivm
It's weird how so many people bash Obj-C for the syntax. Behind the square
brackets, it's just another OOP language.

The real problem is getting puzzling regressions because of an accidental
message to nil.

~~~
bsaul
Block syntax ?

~~~
ivm
Snippets to the rescue. I don't remember their syntax but also don't type it
(same for many other verbose parts of Obj-C).

------
applecorruption
Very right. Swift development is been lately only rewritting , language change
every 6 month and all apps do not compile anymore.

~~~
alexasmyths
+!0.

It's a shame that they have made so many changes that are not reverse
compatible. They have $100 Billion in the bank - can they not sort this out?

~~~
simonh
Which bank account should they transfer the money to in order to get these
problems magically solved?

~~~
alexasmyths
Well, they can put it into the 'bank accounts' of a few dozen decent
developers and managers who are allocated with the task of solving this
problem.

It's a double shame that my comment is down-voted - I can't think of another
bit of tech which has had so many backwards-breaking changes over the years.
Not Node, not Java, not Javascript for example.

------
mattschmulen
While legacy iOS developers are justifying objective-c over swift. Swift is
“eating the world” of iOS and macOS app ( and some server side ) development,
avoid it at your own peril. The Xcode issues are undeniable but it does not
change the situation. swift lang is superior and it is the overwhelming choice
for new apps and new developers.

------
Abishek_Muthian
Say a fund constrained startup, with single iOS developer who is experienced
in Objective C. There’s no reason to go for Swift if building MVP is priority;
as it should be for any startup. If compile times are longer in Swift, it
increases cost on new hardware as well.

So cost plays an important role in the adoption of Swift as well.

~~~
valuearb
Compile times, while aggravating, have dick to do with time to market. Time to
find and fix bugs dominates time to compile, and the language that produces
far fewer bugs (Swift) is the time to market and low cost champ.

~~~
CodeWriter23
Coders produce bugs, not the language they use.

~~~
pjmlp
The language they use has high impact on how what errors they write.

------
jasonwelk
I primarily develop iOS apps in C++ so using Objective-C for the platform
stuff is a no brainer thanks to mixing that language with C++ in the same
source files.

I really like Swift though and hope tooling improves so I can start doing more
with it. I love its approach to type safety and offerings like ADTs.

------
lisper
Because I can seamlessly call ObjC from Clozure Common Lisp through the ObjC
Bridge/FFI.

------
currymj
in some ways these complaints remind me of trying to pick up Haskell or Rust
-- tooling isn't quite there, breaking changes all the time, outdated
resources online. funny that Swift, another "weird" type-heavy language, has
the same problems.

i wonder if part of the IDE problem isn't to do with having the elaborate type
system. it might make certain things easier but having to do inference could
slow things down a lot.

my dream is that someday Swift will be a mature, well-funded, "enterprisey"
language that is also weird and functional. Something to join the ranks of F#.

------
coldcode
I don't know any, at my employer are all trying to replace years of ObjC no
matter the cost.

~~~
programmarchy
I'm curious... Is this driven by management, or developers who want to learn
Swift?

~~~
coldcode
Both. Basically we leveraged a fear in management that Apple would leave us
behind if we didn't switch. Who says managing management isn't an art form.

------
dev1n
Because the app size is an order of magnitude less than it would be with
swift.

~~~
valuearb
Not close to true. Swift apps are only slightly larger, and no one cares how
big your apps code is when media is 90% of most commercial apps sizes.

------
whipoodle
I think Marco has the most reasonable posture here. Though I must admit I
personally wouldn't want to use PHP.

~~~
CodeWriter23
I’ve only looked and not actually coded with it, but Laravel makes it look as
though coding in PHP might be livable.

------
frusciante29
A: Because they can't let go of the past

------
sheeshkebab
Swift is nice although it doesn’t have any advantages for someone who knows
objc. Plus for interoperability you still need to know c/objective c anyway,
and then why bother.

I guess Swift is popular with JavaScript developers, coming from web dev.

~~~
valuearb
Swift is the exact opposite of Javascript and if used correctly created much
higher quality code than a Objective C. But the toolchain is weak and XCode 9
is a big step backwards.

------
crispinb
I shall add this to my HN thread generation algorithm:

\- article queries developers of category X: why do you do Y?

\- 1000 replies appear as variations on the theme 'no, it's just because Z!',
clearly implying category X either lacks the ability to introspect on their
own reasons for their choices, or are perhaps knaves or fools

------
coin
> Steve Troughton-Smith: Fully excluded; a Swift-only conference is one that
> has nothing for me. I don't want to have to care about Swift best practices
> or design patterns now before the language is fully formed and before Apple
> is using it at scale. I don't want to collate a dozen community-led design
> patterns, I want to do what Apple does.

So if it's not endorsed and spoon fed by Apple, he wants nothing to do with
it.

~~~
pjmlp
Apple already rewrote launchd, Dock and a few other parts in Swift.

Surely others will follow.

------
bitmapbrother
I'm surprised by the resistance of some of these iOS developers. You would
think that after years of developing in a language that looks like diarrhea
they would have gleefully switched over to Swift.

------
CHANCECHANEL
Uhh because Swift threatens their job? Objective-C is an abomination, which
has kept Python/Ruby/JS developers away. Swift on the other hand greatly
simplifies switching between, JS,Python,Swift. From employers perspective this
opens up a huge talent pool, for employees especially the Objective-C hipsters
its a bad news, since their privileged status in the app economy is now under
threat.

I don't see any sane new startup/projects using Obj-C, other than bullying by
Obj-C devs.

~~~
lghh
What similarities does Swift have to JS at all? There are some with Python,
though not many.

~~~
texuf
from [https://www.tutorialspoint.com](https://www.tutorialspoint.com) (high
seo, I do not personally endorse)

Objective-C:

    
    
        - (return_type) method_name:( argumentType1 )argumentName1   
        joiningArgument2:( argumentType2 )argumentName2 ...  
        joiningArgumentn:( argumentTypen )argumentNamen  
        {  
           body of the function  
        }
    

Swift:

    
    
        func funcname(Parameters) -> returntype {  
           Statement1  
           Statement2  
           ---  
           Statement N  
           return parameters  
        }
    

Javascript:

    
    
        function functionname(parameter-list)  
        {  
            statements  
        }
    

I know people downvoted op, but when I first learned it, reading Objective-C
made me angry. The second two examples are much closer in syntax and style and
require much less context switching.

And it wasn't mentioned, but the if let myVar = optionalVar { ... } is a
godsend for writing maintainable, crash-free code.

If you want to get a good idea of what good swift looks like, check out
[https://github.com/raywenderlich/swift-style-
guide](https://github.com/raywenderlich/swift-style-guide)

~~~
ajeet_dhaliwal
This is just a visual and fairly shallow similarity. I think the context
switch is huge and the same as Objective C.

Anyway the future isn’t Swift, it’s JavaScript for everyone :-)

~~~
kalleboo
Altho TBH most of the objections I've heard against ObjC from non-ObjC
developers usually are just as shallow and revolve around how weird or ugly
the bracket syntax for messages is.

~~~
valuearb
my objections to obj C are code quality, pointers and crash rates.

