Hacker News Reader

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?

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

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.

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.

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.

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.

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

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.