6 ms·

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 an

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.
valuearb 9y ago
Restart XCode 9 every 2 hours. SourceKitService is eating up your available memory.
kevan 9y ago
The safety we get from Swift in our app is worth the problems with the dev tooling, but barely.
swi_982747502 9y ago
This is an asinine comment. Just because YOU can’t figure out how to reduce build times for XCode and enjoy swift doesn’t mean that no one else can’t. Swift is very much here to stay. Don’t let this dissuade anybody or any company from using swift.
bartvk 9y ago
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?
- steeve 9y ago
  I'm kind of sad this flag exists to be honest....
- dep_b 9y ago
  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.
- andrewmcwatters 9y ago
  1. Sounds pretty sane. 2. is tragic.
- kobeya 9y ago
  400ms is about a billion clock cycles. If it takes a billion clock cycles to type check an expression, something is very very wrong.
fit2rule 9y ago
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.
- vertex-four 9y ago
  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?
  - fit2rule 9y ago
    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.
    - vertex-four 9y ago
      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.
    - _pmf_ 9y ago
      > then I don't want to work with you, period. Are you one of those adorable persons who think search and replace is a suitable replacement for refactoring support?
      - 9y ago
AnthonBerg 9y ago
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/ https://www.jetbrains.com/objc/
- AsyncAwait 9y ago
  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.
  - coldtea 9y ago
    >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.
    - Synaesthesia 9y ago
      I think not only the language features but the new features of iOS and idevices and Macs, which xcode usually supports on day 1.
      - LeoNatan25 9y ago
        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.
  - AnthonBerg 9y ago
    Thank you!
jgalt212 9y ago
> 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.
- Grustaf 9y ago
  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.
- kobeya 9y ago
  Very few apps I use are thin clients. Those that are (without an unavoidable need to be) I usually uninstall.

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.

valuearb 9y ago

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

kevan 9y ago

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

swi_982747502 9y ago

This is an asinine comment. Just because YOU can’t figure out how to reduce build times for XCode and enjoy swift doesn’t mean that no one else can’t. Swift is very much here to stay. Don’t let this dissuade anybody or any company from using swift.

bartvk 9y ago

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?

steeve 9y ago
I'm kind of sad this flag exists to be honest....
dep_b 9y ago
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.
andrewmcwatters 9y ago
1. Sounds pretty sane. 2. is tragic.
kobeya 9y ago
400ms is about a billion clock cycles. If it takes a billion clock cycles to type check an expression, something is very very wrong.

fit2rule 9y ago

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.

vertex-four 9y ago
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?
- fit2rule 9y ago
  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.
  - vertex-four 9y ago
    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.
  - _pmf_ 9y ago
    > then I don't want to work with you, period. Are you one of those adorable persons who think search and replace is a suitable replacement for refactoring support?
    - 9y ago

AnthonBerg 9y ago

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/ https://www.jetbrains.com/objc/

AsyncAwait 9y ago
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.
- coldtea 9y ago
  >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.
  - Synaesthesia 9y ago
    I think not only the language features but the new features of iOS and idevices and Macs, which xcode usually supports on day 1.
    - LeoNatan25 9y ago
      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.
- AnthonBerg 9y ago
  Thank you!

jgalt212 9y ago

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

Grustaf 9y ago
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.
kobeya 9y ago
Very few apps I use are thin clients. Those that are (without an unavoidable need to be) I usually uninstall.