3 ms·
Your argument is more or less a critique of Swift itself, which is a far more full-featured and "safe" language than Objective-C, at the expense substantially h
by kerbs 5y ago
Your argument is more or less a critique of Swift itself, which is a far more full-featured and "safe" language than Objective-C, at the expense substantially higher compilation times given otherwise like-for-like programs.
You're not necessarily wrong, but that ship has sailed for iOS development long ago and isn't necessarily the fault of teams like Doordash who have probably (like others) already squeezed as much build-time performance out of their given app size and feature set.
Mobile apps are inherently monoliths, and there is unfortunately no real way around some code changes triggering full rebuilds of millions of LoC.
- tarentel 5y agoDefinitely will echo this. The app I work on is probably a lot of bloat which the op is complaining about but compared to the last app I worked on it's quite a bit less and compiles at least 5 times more slowly due to using swift where as the last project was 100% obj-c. Even if we could somehow manage to convince management to let us clean up the app we'd still be at the mercy of however long the swift compiler takes.
- sixstringtheory 5y agoDon't use type inference, and modularize the codebase into separate static libraries. That should reduce the amount of full rebuilds, and should make builds faster. (ETA: also try to avoid generics.) Ofc, probably a lot harder to go back and redo a huge legacy codebase where you still have new deadlines to meet, but for folks just starting out, these should be guiding principles in a Swift codebase if you care about compilation time.