[woolvalley]

I wouldn't really say those are the reasons why.

The app store and code signing have been fairly bureaucratic to deal with from day one. It's actually improved compared to the initial years from turn around times measuring in a day or two vs a week or two. I remember doing such tricks such as resubmitting the same binary and it getting passed. It really is a dice roll.

Compile times comes from swift and promoting it too early because it was too immature. If you write your code in objective-c, your fast compile times will come back. Swift compile times have been improving as time goes on.

They also don't pay as well compared to google or facebook. But even then I think it's more a management thing, since they determine the priorities in software dev.

[fooker]

>Swift compile times have been improving as time goes on.

Swift compile times will never be close to ObjC or C compile times, no matter how much engineering goes into it. This is because of how the language is designed, it requires a typechecker which solves an NP hard constraint solving problem.

[woolvalley]

There is a whole bunch of low hanging fruit in the swift compiler as far as compile speed goes.

What swift compiler devs complain most about is about how operator overloading causes some sort of O(n^k) or worse check, because things like the '+' operator has dozens of implementers.

If your really worried about type inference slowing you down, you can write out all of your types like you didn't have type inference. You could even do it in an automated fashion like your source code was some sort of cache.

[14113]

Unlike C compilers which have no NP-hard problems to solve /s

[fooker]

You can write a C compiler without solving NP hard problems. You can even have pretty good optimizations.