15 ms·

Why many developers still prefer Objective-C to Swift

212 points by Udo_Schmitz 9y ago

iOSGuy 9y ago
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 9y ago
  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 9y ago
    As a newcomer to Swift, finding "old" blog posts and tutorials that are written in Swift 2 is utterly maddening.
    - melling 9y ago
      Try finding new blog posts in Objective C. Most are in Swift.
      - snerbles 9y ago
        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 9y ago
        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-3-refactor-list/ https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-swift-...
      - nicky0 9y ago
        Yeah but at least the old ObjC ones are still relevant. And there are a lot of them.
        melling 9y ago
        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.
      - orbitur 9y ago
        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.
    - magnetic 9y ago
      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.
  - nnd 9y ago
    How did you work around Obj-C inference issues when migrating to Swift 4?
- valuearb 9y ago
  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.
  - Koshkin 9y ago
    Not sure about that. The same has been said (many times) about Java vs. C and C++. All three keep chugging along quite nicely...
    - dikaiosune 9y ago
      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.
      - fit2rule 9y ago
        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".
        klibertp 9y ago
        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.
        fit2rule 9y ago
        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.
- AsyncAwait 9y ago
  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.
nickgrosvenor 9y ago
Because they're more comfortable with it
- neonhomer 9y ago
  Exactly. I haven't had any problems switching to Swift for newer projects.
dev1n 9y ago
Because the app size is an order of magnitude less than it would be with swift.
- valuearb 9y ago
  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.
lisper 9y ago
Because I can seamlessly call ObjC from Clozure Common Lisp through the ObjC Bridge/FFI.
askafriend 9y ago
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 9y ago
  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.
  - tambourine_man 9y ago
    It was nearly ready, then canned on the last minute. Hard times. Oh yes, and Java bridge.
  - agildehaus 9y ago
    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.
    - zbowling 9y ago
      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-10-4/ https://www.macrumors.com/2015/06/30/apple-releases-os-x-10-...
    - makecheck 9y ago
      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.
blunte 9y ago
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 9y ago
  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 9y ago
    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...
- apple4ever 9y ago
  Ugliness. That’s a primary reason too. Difficult ness in a bad syntax. Also a primary reason.
  - abritinthebay 9y ago
    Compared to Obj-C?? Unless you’re a Java or ASP developer I can’t see an uglier syntax in common usage.
    - astrange 9y ago
      ObjC/SmallTalk syntax has been working great for 30 years now. It’s the second best language with named method parameters besides AVISynth.
3chelon 9y ago
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.
coldcode 9y ago
I don't know any, at my employer are all trying to replace years of ObjC no matter the cost.
- programmarchy 9y ago
  I'm curious... Is this driven by management, or developers who want to learn Swift?
  - coldcode 9y ago
    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.
coin 9y ago
> 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.
- deleted 9y ago
  [deleted]
- pjmlp 9y ago
  Apple already rewrote launchd, Dock and a few other parts in Swift. Surely others will follow.
Apocryphon 9y ago
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.
CHANCECHANEL 9y ago
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 9y ago
  What similarities does Swift have to JS at all? There are some with Python, though not many.
  - texuf 9y ago
    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 9y ago
      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 :-)
sheeshkebab 9y ago
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.
- javabean22 9y ago
  It's simple. Swift is a million times better. It's just that people are lazy.
- valuearb 9y ago
  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.
- agildehaus 9y ago
  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.
crispinb 9y ago
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
orbitur 9y ago
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.
- iOSGuy 9y ago
  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.
  - htormey 9y ago
    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.
    - zoul 9y ago
      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.
Koshkin 9y ago
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/
- yodon 9y ago
  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?)
  - programmarchy 9y ago
    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`.
  - Koshkin 9y ago
    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?
  - pivo 9y ago
    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.
dreta 9y ago
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.
Koshkin 9y ago
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.
okdana 9y ago
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.
aplummer 9y ago
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 9y ago
  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 9y ago
    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.
xirdstl 9y ago
Does anyone use AppCode? How does it stack up to Xcode for Swift development?
- matt2000 9y ago
  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.
- mmargerum 9y ago
  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.
Abishek_Muthian 9y ago
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 9y ago
  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 9y ago
    Coders produce bugs, not the language they use.
    - pjmlp 9y ago
      The language they use has high impact on how what errors they write.
- CodeWriter23 9y ago
  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.
- 9y ago
madrox 9y ago
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.
- madrox 9y ago
  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.
- danso 9y ago
  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?
- microtherion 9y ago
  > 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 9y ago
    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 9y ago
      >> 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.
jordansmithnz 9y ago
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.
greensamuelm 9y ago
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.
- slrz 9y ago
  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.
- melloclello 9y ago
  A pox on people that make me add closed source binaries to my apps! Adtech companies are the worst for this.
- gok 9y ago
  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 9y ago
    Rust takes a lot of flak for it as well, some to the point of suggesting it's illegitimate until it has one.
- grav 9y ago
  How's the story with source code obfuscation in Swift-land? Wouldn't that be an option for you?
let_var 9y ago
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 9y ago
  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.
betadreamer 9y ago
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 9y ago
  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 9y ago
    Block syntax ?
    - ivm 9y ago
      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).
whipoodle 9y ago
I think Marco has the most reasonable posture here. Though I must admit I personally wouldn't want to use PHP.
- CodeWriter23 9y ago
  I’ve only looked and not actually coded with it, but Laravel makes it look as though coding in PHP might be livable.
mattschmulen 9y ago
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.
cm2187 9y ago
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 9y ago
  Just to clarify a bit: you only need to pay if you want to distribute your app on the iTunes Store.
  - cm2187 9y ago
    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 9y ago
      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 9y ago
        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/installation/device_provisioning/free-provisioning/ https://developer.xamarin.com/guides/ios/getting_started/ins...
aryehof 9y ago
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".
bitmapbrother 9y ago
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.
Razengan 9y ago
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.
- pjmlp 9y ago
  And Metal with its Swift/C++14 shaders is an actual modern graphics API, not stuck on C like Vulkan.
  - dep_b 9y ago
    Interesting, where can I read more about that comparison?
    - pjmlp 9y ago
      You can read the documentation in https://developer.apple.com/metal/ 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/ https://www.khronos.org/registry/vulkan/ There is a C++ wrapper, originally designed by NVidia, https://github.com/KhronosGroup/Vulkan-Hpp 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.
- cableshaft 9y ago
  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.
s_kilk 9y ago
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 9y ago
  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.
currymj 9y ago
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#.
jasonwelk 9y ago
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.
frusciante29 9y ago
A: Because they can't let go of the past
cageface 9y ago
My apps stopped crashing when I started writing them in swift. That alone is worth any hassles with an immature language or tooling.
applecorruption 9y ago
Very right. Swift development is been lately only rewritting , language change every 6 month and all apps do not compile anymore.
- alexasmyths 9y ago
  +!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 9y ago
    Which bank account should they transfer the money to in order to get these problems magically solved?
    - alexasmyths 9y ago
      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.
Grustaf 9y ago
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.
- jasonwelk 9y ago
  Agreed. Willingness to break backwards compatibility is good in pursuit of a better language. wish C++ did this!
- kazagistar 9y ago
  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 9y ago
    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.
gok 9y ago
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.

212 points by Udo_Schmitz 9y ago

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 9y ago
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 9y ago
  As a newcomer to Swift, finding "old" blog posts and tutorials that are written in Swift 2 is utterly maddening.
  - melling 9y ago
    Try finding new blog posts in Objective C. Most are in Swift.
    - snerbles 9y ago
      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 9y ago
        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-3-refactor-list/ https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-swift-...
    - nicky0 9y ago
      Yeah but at least the old ObjC ones are still relevant. And there are a lot of them.
      - melling 9y ago
        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.
    - orbitur 9y ago
      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.
  - magnetic 9y ago
    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.
- nnd 9y ago
  How did you work around Obj-C inference issues when migrating to Swift 4?
valuearb 9y ago
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.
- Koshkin 9y ago
  Not sure about that. The same has been said (many times) about Java vs. C and C++. All three keep chugging along quite nicely...
  - dikaiosune 9y ago
    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.
    - fit2rule 9y ago
      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".
      - klibertp 9y ago
        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.
        fit2rule 9y ago
        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.
AsyncAwait 9y ago
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.

nickgrosvenor 9y ago

Because they're more comfortable with it

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

dev1n 9y ago

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

valuearb 9y ago
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.

lisper 9y ago

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

askafriend 9y ago

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 9y ago
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.
- tambourine_man 9y ago
  It was nearly ready, then canned on the last minute. Hard times. Oh yes, and Java bridge.
- agildehaus 9y ago
  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.
  - zbowling 9y ago
    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-10-4/ https://www.macrumors.com/2015/06/30/apple-releases-os-x-10-...
  - makecheck 9y ago
    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.

blunte 9y ago

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 9y ago
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 9y ago
  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...
apple4ever 9y ago
Ugliness. That’s a primary reason too. Difficult ness in a bad syntax. Also a primary reason.
- abritinthebay 9y ago
  Compared to Obj-C?? Unless you’re a Java or ASP developer I can’t see an uglier syntax in common usage.
  - astrange 9y ago
    ObjC/SmallTalk syntax has been working great for 30 years now. It’s the second best language with named method parameters besides AVISynth.

3chelon 9y ago

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.

coldcode 9y ago

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

programmarchy 9y ago
I'm curious... Is this driven by management, or developers who want to learn Swift?
- coldcode 9y ago
  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.

coin 9y ago

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

deleted 9y ago
[deleted]
pjmlp 9y ago
Apple already rewrote launchd, Dock and a few other parts in Swift. Surely others will follow.

Apocryphon 9y ago

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.

CHANCECHANEL 9y ago

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 9y ago
What similarities does Swift have to JS at all? There are some with Python, though not many.
- texuf 9y ago
  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 9y ago
    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 :-)

sheeshkebab 9y ago

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.

javabean22 9y ago
It's simple. Swift is a million times better. It's just that people are lazy.
valuearb 9y ago
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.
agildehaus 9y ago
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.

crispinb 9y ago

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

orbitur 9y ago

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.

iOSGuy 9y ago
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.
- htormey 9y ago
  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.
  - zoul 9y ago
    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.

Koshkin 9y ago

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/

yodon 9y ago
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?)
- programmarchy 9y ago
  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`.
- Koshkin 9y ago
  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?
- pivo 9y ago
  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.

dreta 9y ago

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.

Koshkin 9y ago

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.

okdana 9y ago

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.

aplummer 9y ago

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 9y ago
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 9y ago
  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.

xirdstl 9y ago

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

matt2000 9y ago
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.
mmargerum 9y ago
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.

Abishek_Muthian 9y ago

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 9y ago
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 9y ago
  Coders produce bugs, not the language they use.
  - pjmlp 9y ago
    The language they use has high impact on how what errors they write.
CodeWriter23 9y ago
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.
9y ago

madrox 9y ago

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.

madrox 9y ago
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.
danso 9y ago
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?
microtherion 9y ago
> 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 9y ago
  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 9y ago
    >> 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.

jordansmithnz 9y ago

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.

greensamuelm 9y ago

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.

slrz 9y ago
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.
melloclello 9y ago
A pox on people that make me add closed source binaries to my apps! Adtech companies are the worst for this.
gok 9y ago
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 9y ago
  Rust takes a lot of flak for it as well, some to the point of suggesting it's illegitimate until it has one.
grav 9y ago
How's the story with source code obfuscation in Swift-land? Wouldn't that be an option for you?

let_var 9y ago

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 9y ago
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.

betadreamer 9y ago

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 9y ago
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 9y ago
  Block syntax ?
  - ivm 9y ago
    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).

whipoodle 9y ago

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

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

mattschmulen 9y ago

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.

cm2187 9y ago

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 9y ago
Just to clarify a bit: you only need to pay if you want to distribute your app on the iTunes Store.
- cm2187 9y ago
  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 9y ago
    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 9y ago
      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/installation/device_provisioning/free-provisioning/ https://developer.xamarin.com/guides/ios/getting_started/ins...

aryehof 9y ago

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

bitmapbrother 9y ago

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.

Razengan 9y ago

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.

pjmlp 9y ago
And Metal with its Swift/C++14 shaders is an actual modern graphics API, not stuck on C like Vulkan.
- dep_b 9y ago
  Interesting, where can I read more about that comparison?
  - pjmlp 9y ago
    You can read the documentation in https://developer.apple.com/metal/ 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/ https://www.khronos.org/registry/vulkan/ There is a C++ wrapper, originally designed by NVidia, https://github.com/KhronosGroup/Vulkan-Hpp 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.
cableshaft 9y ago
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.

s_kilk 9y ago

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 9y ago
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.

currymj 9y ago

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

jasonwelk 9y ago

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.

frusciante29 9y ago

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

cageface 9y ago

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

applecorruption 9y ago

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

alexasmyths 9y ago
+!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 9y ago
  Which bank account should they transfer the money to in order to get these problems magically solved?
  - alexasmyths 9y ago
    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.

Grustaf 9y ago

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.

jasonwelk 9y ago
Agreed. Willingness to break backwards compatibility is good in pursuit of a better language. wish C++ did this!
kazagistar 9y ago
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 9y ago
  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.

gok 9y ago

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.