Hacker News new | comments | show | ask | jobs | submit login
Why many developers still prefer Objective-C to Swift (hackingwithswift.com)
212 points by Udo_Schmitz 46 days ago | hide | past | web | 212 comments | favorite



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.


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?


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.


I'm kind of sad this flag exists to be honest....


1. Sounds pretty sane. 2. is tragic.


400ms is about a billion clock cycles. If it takes a billion clock cycles to type check an expression, something is very very wrong.


The safety we get from Swift in our app is worth the problems with the dev tooling, but barely.


Restart XCode 9 every 2 hours. SourceKitService is eating up your available memory.


This is my thought exactly. I've written a few open source Swift components to learn the language, but it's just not ready to work on the scale that mobile software is reaching.

Mobile software development isn't about a developer or two building "apps" anymore, it's grown much bigger than that.


Is this still the case with Swift 4? Swift had lots of issues as of the 2016 wwdc (language changes breaking third party libraries, barely working tools) however swift 4 seems to be not nearly as bad. I’d be interested in hearing your thoughts.


Swift 4 as a language is marvellous. It’s the tooling that’s still very annoying to work with – autocomplete not working, SourceKit burning CPU time, crashes, that kind of thing.


I haven’t tried Swift, but I never use XCode and always use Jetbrains IDEs - there is one for Swift: https://www.jetbrains.com/objc/


AppCode is good, but can't quite keep up with the changes Apple makes on a timely basis, (for obvious reasons). It also doesn't have a great way to work with storyboards and thus is more of a companion than a direct replacement for XCode.


>but can't quite keep up with the changes Apple makes on a timely basis, (for obvious reasons)

I don't see what the obvious reasons would be. Swift is developed and discussed in the open for one.


I think not only the language features but the new features of iOS and idevices and Macs, which xcode usually supports on day 1.


Huh? Those are features of the SDK. Simulators can be controlled using simctl.

There really is no excuse for an IDE developer not to support the latest swift syntax and runtime from day 1, given how there are nightly and weekly swift toolchain releases.


Thank you!


> I work for a company that writes iOS apps, large and small.

But aren't most iOS apps just thin clients? and if they are thickish isn't most of the code related to UI?

If the above is true, Swift and its currently un-robust tooling should be the solution for most/all projects.


I don't have any statistics on how many iOS apps are just "thin clients" but I wouldn't think it's more than half.


Very few apps I use are thin clients. Those that are (without an unavoidable need to be) I usually uninstall.


This is why I consider IDE-dependence to be a programmer-smell. If you have to have an IDE to function, you're really more of a team liability than an asset. Same goes with the language - if it has to have an IDE or else you get into some sort of hellish mess, then its really not designed as a language to make you productive - more, just to sell tools.


Would you consider an engineer who is significantly more productive with CAD software than manual drafting to be a liability? Sure, you want your engineers to know the basics of what they're doing, but why would you choose to throw away that productivity?


Its never acceptable as a developer to say "I can't do it, because the IDE is broken" - this is a programmer-smell.

Re: CAD software, I would consider them more productive, but only if they actually knew what the basics were and didn't just depend on the GUI doing all the work. If you can't get underneath the tooling and fix it, then I don't want to work with you, period.


No, but it's plenty acceptable to say "I'll be less productive because the IDE is broken". Even the diehard Java enterprise developers I know can jot down code with a pen and paper if they were absolutely forced to - that doesn't make it a good idea to tell them not to use an IDE in their day-to-day job, nor a language without good IDE support.


[flagged]


If you can't refactor with just search and replace, you don't really know the depths of your project, and yes - I would be uncomfortable working with you.


That just means you've never worked on a big project, where the component you are responsible for is used by >10 different other components. One very quickly reaches a limit where manual refactoring is an option.


Oh, I've worked on plenty of big projects - in fact, your life is probably being protected by my software right now.

Its just that I don't believe in succumbing to the crutch of tools. If the IDE is getting in the way, get the IDE out of the way - too many projects are incapable of doing this.


>Oh, I've worked on plenty of big projects - in fact, your life is probably being protected by my software right now.

Those two are orthogonal concepts. There is e.g. car or medical embedded software that's tiny in scope compared to a big enterprise project.


Just a remark on the topic. Been working in vehicle software business for 12+ years now and renaming variables is almost never done. In fact I don't remember someone ever renaming a system (global) variable. There tens of thousands such variables in a system, plus about the same number of calibratable constants. We have renamed our drivers variables only when we switched to a newer architecture (multicore ready, AUTOSAR compliant).

The entire code base running a modern car goes well within millions of code lines. Our IDE changed in time from Blue River X32 v5 to internally modified Eclipse plugin. The only major use for us are X32 type contractions. [1]

[1]http://tinypic.com/r/20qhq4y/9


Yeah, try taking a train in any one of 38 different countries around the world .. that big enough for you?

No, you really don't need the IDE to make big software.


You don't need computers to ride trains either.

Programming, as most technologies, is not about what you basically need. We are not cavemen.

It's about what enhances what you can do.


If you actually really know the "depths of your project" then you haven't worked in any really big project, and yes, I would be uncomfortable working with you.


Textual search and replace is blind to the syntax and semantics of the programming language, of the software itself. Why should we use stone tools?


You, yourself, should not let your control over the project be 'usurped by complexity'. If you can't handle the complexity such that you need an IDE to do refactoring, you should definitely not promote this fact far and wide - its far better to promote the style of thinking where IDE is not a requirement, but rather a luxury.


I'm sorry, but I fail to see the anything but superstition in the refusal to do search and replace through a language parser.


It means there are parts of the project you really don't have an embracive grip over, and that does not make you a great developer. It makes you a weaker one.


No, it means that I consider there to be a difference between language constructs, variable names, strings, comments, etc. - in other words what a parser does. String/based find-replace muddles these together. An IDE is but a collection of similar tools. I’m not strong if I choose to walk and weak if I choose to use motorised transport.


You're weak if, after using motorized transport to get around most of your life, you're suddenly asked to walk - and can't do it.

Look, there's no point arguing about this any further - but I urge you to look at this alternative point of view in your professional career. Without fail, those whose proficiency depends on the features of an IDE are, in my experience, more glib about their work and problem solving, and less likely to actually push to solve common programming problems on their own. Maybe you'll start to notice this too.


If you think that search and replace is an appropriate way to refactor, when there are better options, then I'm not sure I'd be comfortable working with you...


On the other hand, not knowing and not using the tools for your language is also a problem, assuming that such tools are improving productivity (which many of them do). You should be able to get by without them if necessary, but you should also strive to use the most powerful tools you can whenever possible. Powerful tools also have non-trivial learning curves, so you should train to become proficient with them too.

Being tied to a single effective tool is not always bad. If the tool is indeed powerful, the need for other tools may not arise. Emacs and Vim users use their editors to work on a lot of different things, for example, and have enormous libraries of plugins and features at their disposal, ready to use no matter the language.

If someone asked me whether to learn an IDE for a specific language or Emacs, I'd say both. The larger your selection of tools, the better - with more tools the number of things you can do faster/better also increases, which leads to higher productivity.

In other words - don't try to code in Notepad forever and be prepared to spend some time on learning new tools.


"On the other hand, not knowing and not using the tools for your language is also a problem,"

To be fair - XCode is a problem.

iPhone Apps are not rocket science.

There is no reason for the massive bureaucracy and confusion of XCode - or even Swift.

Not only does Swift try to do too much as a language - dealing with XCode is like dealing with the California DMV.

My god, man the compiler options. Pages and pages of options.

As far as I'm concerned, the biggest failure of the 'Swift' decision, was to be so tied to the old language standard, and to XCode.

The only possible advantage of XCode from a developer perspective is maybe the UI designer, but even then.

Obviously there's a huge investment in Xcode

But ...

Has anyone tried VSCode lately, or Atom? I mean it's possibly to have a 'light' editor and basic compile chain in which we can do powerful things. Or none at all.

I personally loathe using Android Studio or XCode - it feels like working for the government, on a team of 3000 people building a web-site for the local library that never gets into production. Anyhow, I jest.

I think there is rationality in wanting to be able to have a language work without an IDE.


Arguably, using Xcode for Swift is akin to coding in Notepad.

I basically have to have the documentation open in a separate window at all times, because Command-Click hardly works, and syntax highlighting/completion is never long for this world.

At least Notepad doesn't have pretensions to being a programmer tool.


I obviously know what I'm doing, the IDE isn't going to write the code itself.

But if I can "write" an 80 character line of code by pressing around 10 keys, I think that's pretty useful. If I can write a method, a class, faster than I would by manually typing and referring to docs all the time, why wouldn't I?

And clearly I'm still getting the work done. I'm complaining about the dissonance of trying to type a method name while the autocomplete dialog wants me to finish the name of a random C macro or an image name. It's frustrating and worth complaining about. Syntax highlighting is useful, the reason it exists is to help you differentiate tokens quickly.


Suppose we have a datatype called "User" and it has an attribute called "username". How do you distinguish between User and username with a text only search for just "user"?

Also nobody is saying that the tool is required to make you productive. The entire point is that it makes you more productive. I consider things like "What file is this datatype defined in?" to be menial work. It's merely a waste of time that requires no skills.


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.


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.


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.


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.


A larger team benefits more from the ability to write higher quality code with Swift. Fewer or no crashes is s better customer benefit than some hypothetical minor performance benefit. The toolchain does suck though, if Apple (or done one else) fixes the toolchain Objective C is done as a viable language.


Not sure about that. The same has been said (many times) about Java vs. C and C++. All three keep chugging along quite nicely...


From one perspective, this just means that the market for software quality is not very tight and that our industry is not empirical in assessing it.


What it really means is that the market for software language is being exploited and usurped in order to maintain developer mindshare. The only really good reason to learn Swift is "because everyone else is learning it".


The most important, and sufficient, reason to learn Swift - or anything else, for that matter - is curiosity. I don't like working with people who are not curious about their craft.


Its really unnecessary to learn Swift -there are a plethora of other, better ways to build apps.

But if you want to keep up with the joneses - while delivering Apple a perfect 'big stick' to keep developer mindshare locked into their platforms - Swift is a pretty sweet deal .. for Apple.


Swift is the best way to develop IOS apps, that’s a pretty good reason.


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.


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


I always set a filter in my Swift google search so I only get recent content. It generally weeds out a lot of old Swift code/tutorials.


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


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.


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


Yeah but at least the old ObjC ones are still relevant. And there are a lot of them.


The are lots of new API’s and some old code has been deprecated. There haven’t been many Objective C tutorials or books in 3 years.


Well. If you just want to confirm the order you should be calling methods, you should be able to figure out how to use any of those APIs based on Swift examples.

If anything, Swift examples are more necessary because there's tricky things you can do with closures, manp, flatMap, etc.

ObjC is very straightforward.


How did you work around Obj-C inference issues when migrating to Swift 4?


I find it it strange that you complains seem to be about tooling, yet you start the comment as if Swift - the language - is the problem.

In my experience, Swift has been great, I vastly prefer it to ObjC. What I don't prefer is SourceKit constantly crashing on me for example, but I wouldn't attribute that to Swift.


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.


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.


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.


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/


This is my personal gripe with Swift. Theres just so many different ways to form expressions and do control flow. It just feels like code golf to me.

  for case let (title?, kind) in mediaList.map({ ($0.title, $0.kind) }) where title.hasPrefix("Harry Potter") {
     print(" - [\(kind)] \(title)")
  }
http://alisoftware.github.io/swift/pattern-matching/2016/05/...


I don't know Swift much, but can tell at first glance that you're mapping items from `mediaList` into (title, kind) tuples, filtering for missing titles and "Harry Potter". I guess it's more about being comfortable with functional programming patterns in general, than its syntax.


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.


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.


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


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.


Definitely subjective. It's easy to argue that it's actually the C family of languages that have a backwards declaration syntax - in case of complex declarations, not just backwards but completely crazy inside-out zigzag [1]. Yes, there's a logic in it, but it's definitely not intuitive. On the other hand, the "type-on-the-right" syntax is quite popular outside the C family. Pascal, Ada, Go, Scala, Rust...

[1] http://www.unixwiz.net/techtips/reading-cdecl.html


I find this fascinating because the main reason I never did iOS development at all (as a hobby) is that I found Obj-C just so goddamn ugly and awful (java level ugly) that I avoided it.

Swift changed that completely. I finally find native iOS readable.


If you use it for more than a few hours you just wont think of it anymore.


I write in both ObjC and Swift. It takes more than a few hours to get used to both languages but it’s also true that you get used to both. I prefer the relative terseness of Swift and also find the language more elegant and safer than ObjC.


Tried that. Obj-C was just constant nails-on-a-chalkboard annoying. Too verbose, overly clunky syntax, etc.

So I’m afraid that wasn’t the case.


Objective-C has verbosity that's very expressive and serves a purpose.


While true, I find I can do just as much in other languages that done have such an ugly verbose syntax.

It’s ugly for a reason but that still means it’s ugly.


Eh, I'd argue that its verbosity is less ugly than say Java.

I can see why people might thing square brackets are ugly, though I prefer it to the double-colon and angle bracket fest that is C++, but what else do you find uniquely ugly about Objective-C? Infix operators are nifty and promote clarity.


I guess hours was an understatement. The point is that I guess most people hate the style on first sight, I definitely hated it. But it's been a while and now I like it a lot, the verboseness makes the code and intentions clear (you just have to read a bit).


If it was the only open on iOS then yes, I could live with it.

It’s not - thank god - so I don’t have to. So I won’t.


> Objective-C beautiful and Swift ugly

That's subjective. Unusual - yes, but ugly? Why? I'd say, it is quite beautiful, in its incomprehensibility (to the untrained eye).


Not sure why this is (was?) being downvoted.

Yes it expresses a subjective opinion.

Programmer preferences on languages, tooling and other things involve subjective opinion. We are all humans, not purely rational automatons.

There is nothing wrong with a purely subjective, and taste driven argument. How much weight you choose to give it is another matter.


try it for a bit. you'll never look back, pinky wear.


its


Please - tell me that's not something one might actually encounter in practice (and yes I know, it'll feel clever to respond with up votes and down votes but please don't as I'll not have any idea what they mean: good point! Or stupid comment! Or you would totally see this! Or you wouldn't! And for the last two which vote is which?)


You would totally see this in the code I've been writing. I've been taking advantage of enums with associated values for things like state machines. Usually, you'll see associated values like this in a switch statement, but if you need to handle a specific case, then you'll see the `if case`.


Not only is this not unusual it is completely normal and even banal when using Swift enumerations with associated values. It might look strange to someone who doesn't know the language, but a few minutes reading about Swift's enumerations will clarify what this code is doing and it will become totally mundane.

    struct Person {
      var name: String
    }

    enum Result<T> {
      case success(T)
      case error(NSError)
    }

    func printName(personResult: Result<Person>) {
      if case .success(let person) = personResult {
        print(person.name)
      }
    }
In the example above, Result is an enumeration that can be either success or error. If it's success it has an associated value that is the result of whatever operation was successful. If it's error the associated value contains the error information.

In the case of printName() the success case contains a Person value. The if-case is simply saying that if the enumeration represents the success case then extract the associated Person value from the enumeration. The "let person" means make person a constant because you're not intending to modify it. If you wanted to modify it you'd use "var person" instead.

Hopefully this is pretty clear even to people not familiar with Swift style enumerations.


Ah, it's an ugly, verbose syntax for pattern matching. Got it :-)


You may find it ugly, that's subjective - I personally find it weird and unintuitive. But you can't really say it's verbose, there is no redundant information there.


Well, it's very similar to Scala's pattern matching. Not as elegant as Erlang or Haskell's. Objective-C, which is what Swift is being compared to here, doesn't have pattern matching. An attempt to write something similar in Objective-C would be much more verbose, unsafe and almost certainly uglier.


You'll be surprised how soon after you start writing Swift you'll be doing this yourself - and enjoy it. Exploring new features and learning new ways of doing things is fun. Otherwise, what's the point in learning a new language? Seeing more of the same?


This is really the one construction in Swift that I find hard to understand and hence remember, it's not a very fair example.


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.


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


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.


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


That seems like a narrow definition of "pragmatic". Are they choosing Swift out of experience, or from lack of it? If they are junior engineers, how much experience have they had in building, and then iterating and maintaining apps with a significant userbase?


Yes, it tells me juniors still don't have any experience maintaining systems. And that in turn tells me I won't be out of work any time soon.


That said, I should follow up by saying...we recently did an assessment and determined it wasn’t yet worth the time to refactor our ObjC apps into Swift apps. We’ll probably wait for Swift 5 and reevaluate.


Or, you know, it's an objectively better language, clearly the future of the platform, and ABI stability doesn't usually affect the day-to-day life of an iOS developer.


How does one “make apps faster with it” when the compiler takes 3x as long?


You don't spend days tracking down memory corruption issues caused by C underpinnings.


Not bashing Swift, but I can't remember the last time I had a memory issue when using ARC in ObjC.


ARC in Objective-C only applies to classes following Cocoa retain/release patterns.

Anything else is not under ARC support and thus fails under the same memory allocation patterns as C.

Additionally there are the C pointer manipulation, strings and arrays.


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.


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.


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.


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.


I agree mostly with this sentiment but this did actually happen with discoveryd in MacOS. https://www.macrumors.com/2015/06/30/apple-releases-os-x-10-...


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.


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.


It was nearly ready, then canned on the last minute. Hard times.

Oh yes, and Java bridge.


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


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.


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.


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


Just ship the source code, the experience is going to be so much better, no matter the language. Programming against binary-only libraries is a PITA.

If you don't want to open source your code, at least give it to your paying customers under a proprietary no-redistribution license.


How's the story with source code obfuscation in Swift-land? Wouldn't that be an option for you?


A pox on people that make me add closed source binaries to my apps! Adtech companies are the worst for this.


Because they're more comfortable with it


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


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


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.


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


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


Ugliness. That’s a primary reason too.

Difficult ness in a bad syntax. Also a primary reason.


Compared to Obj-C?? Unless you’re a Java or ASP developer I can’t see an uglier syntax in common usage.


ObjC/SmallTalk syntax has been working great for 30 years now. It’s the second best language with named method parameters besides AVISynth.


So has Forth. This is not a good argument.


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.


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.


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.


Apple released an implementation of Swift on Linux since the first day they open-sourced it. IBM is behind it with their web framework, and some people are porting it to windows as well.


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


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.


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.


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


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.


There is no yearly fee when using free provisioning.


Swift is open-source, and has Linux implementations


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.


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.


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.


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.


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.


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.


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.


Agreed. Willingness to break backwards compatibility is good in pursuit of a better language. wish C++ did this!


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


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.


Just started using it out of frustration with XCode stability, works really well. I too have been using a few of the Jetbrains products through the years.


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.


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.


> 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!


And Metal with its Swift/C++14 shaders is an actual modern graphics API, not stuck on C like Vulkan.


Interesting, where can I read more about that comparison?


You can read the documentation in https://developer.apple.com/metal/ , which includes a link to all WWDC videos.

Vulkan is basically a C API, defined at https://www.khronos.org/registry/vulkan/

There is a C++ wrapper, originally designed by NVidia, https://github.com/KhronosGroup/Vulkan-Hpp, but it isn't part of the specification as such.

Likewise the shading languages are either GLSL or HLSL, although in theory others could be created for SPIR-V.

Of course, Vulkan has the benefit of GNU/Linux, Desktop Windows (not on UWP) and about 14% Android devices (optional in 7+ versions), but middleware engines make it kind of irrelevant.


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.


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.


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.


Block syntax ?


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


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


+!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?


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


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.


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.


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.


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.


Coders produce bugs, not the language they use.


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


I used the same logic in implementing my latest app, that taking a 3 month or longer learning curve with Swift would delay my time to market. That turned out to be true, but then again, with 15 years of ObjC under my belt, I’m cranking out more working code than bugs, so I don’t need language features to keep me from making stupid mistakes.

However, what I learned is, if you want to leverage MIT or BSD licensed widgets, libraries and etc, Swift is where it is at. Way too many of the ObjC code available has gone fallow with iOS 8 or 9, so you can still use it now. But the writing is on the walls, sooner or later iOS 12 or 15 is going to break that code and then the ObjC choice turns into technical debt. It runs the gamut from code that isn’t AutoLayout aware, to using deprecated but still available methods. I’ve steered clear of any code that hasn’t seen an update in 18 months.


If it's a startup knocking up an MVP, I hardly see compile times being an issue. It's only when there's a massive, usually legacy, and therefore largely Objective-C based codebase that compile times start to hurt.

It shouldn't be a factor in the decision about using Swift or not.


When choosing a language, framework or “platform” there are only three things that matter:

(1) Time to market: how fast can you implement a “ship-able” feature, app

(2) Resource cost/availability: can you find delivery resources easily and cost effectively. Sometimes this resource is you, metric appropriately.

(3) Scalability: as you grow and features change, how do the other two things change. Do they change for the better or the worse.

The weighting of these depends on longitivtiy expectations. If your short sighted for immediate reward weigh (1) and (2) higher if your confidence is high on the outcome of what your doing then weigh (2) and (3) higher.

For this discussion Swift wins on almost all fronts. The exception might be legacy maintenance , and even then it might be a knife fight of when and how.


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.


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


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


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


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


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


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


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.


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


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.


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


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.


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.


No advantages? Conciseness, null safety, no header files, cleaner syntax, no @property (readonly, getter=blah) nonsense.

Why bother? Swift is the blessed language on Apple platforms going forward and ObjC is not.


It's simple. Swift is a million times better. It's just that people are lazy.


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


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


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

Surely others will follow.


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.


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.


Objective C never kept me away and I love JavaScript, I really don’t think Swift makes things that much better, it’s just different.


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


from 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


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


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.


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


Visual affects reading which affects comprehension.

Don’t dismiss visual similarities so out of hand.


It matters yes, I’ve never been completely comfortable with Python and Lua because of their style but in the example above how is the Swift better than the Objective-C? Sure the params syntax is cleaner here but then you have the return type (with the ugly arrow) at the end instead of the start of the line which is unusual compared to many other c style syntax languages and you also lose the -/+ instance/class method syntax i always liked in Objective-C. JavaScript of course doesn’t have to supply a return type at all, I just don’t see how any of this helps someone coming from JS/Python/Ruby combined with the deeper understand required around nullables and types.


> reading Objective-C made me angry

Yet, many programmers love Smalltalk, which is where this "new" syntax came from.


It's just getting used to []][[][]] and having brackets and @property and lots of things a little different that most first languages people learn nowadays. If you're coming from C, then moving to Objective-C might feel different than coming from languages people tend to learn first nowadays. As someone coming from C++ (and others) when I started programming 4ish years ago, it definitely felt unnatural, but learned to appreciated it a lot and found it pretty sensible. Except for blocks...

It has made me really want to look into learning Smalltalk as a throwback hobby.


You're totally right, after a while you get used to it.


i agree with all your points , but despite the superficial syntax similarity, Swift’s strong typing, optionals and slow compilation make it the anti-javascript.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: