3 ms·

MP3 hasn't changed as a standard or probably as a codebase for decades. Your apps are changing every week, and apps tend to grow in size as more and more code

MP3 hasn't changed as a standard or probably as a codebase for decades. Your apps are changing every week, and apps tend to grow in size as more and more code & features are added to them. It's a natural consequence of most software projects. The binary size of swift projects doesn't catch most people, only large projects with > 400k lines of code as they go over the cellular download limit. It's the new hotness, so many projects are adding swift even if the app is old. Adding swift to a project adds ~20MB alone for the standard libraries that get included with each app, and each line of swift creates that much more binary bloat. The autogenerated interface between swift and objective C creates even more bloat.

52-6F-62 9y ago
That's an interesting problem. Do you find it's that bad for a new project as well? I've otherwise heard nothing but good things about working with Swift, and it's the only macOS/iOS-specific language I've actually worked with a little bit for its rather quick learning curve. So I guess the problem is pretty simple, if not immediately obvious for the details of it. I sigh and guess that means I just have to upgrade soon...
- mahyarm 9y ago
  The swift scalability problems start coming up around 70k lines of code, so for the typical case of 1 or 2 developers it doesn't come up. But if you start getting a large codebase: * indexing will take forever * xcode will beachball continuously * the debugger will crash because the codebase is too much to handle * build times will be 4-5x more than the equivalent obj-c codebase * startup times will balloon significantly if you have many separate libraries, since using swift forces you to use dylibs. 60-100 libraries will mean 3-5 seconds being added to your app startup time They are all solvable problems, but it will take several years before they are fixed. But I don't think swift will be better than C++ development, since they are both similar languages as far as compiler tradeoffs go. I notice some lag even in small swift projects compared to objective-c, but it isn't major enough to worry about.

52-6F-62 9y ago

That's an interesting problem. Do you find it's that bad for a new project as well? I've otherwise heard nothing but good things about working with Swift, and it's the only macOS/iOS-specific language I've actually worked with a little bit for its rather quick learning curve. So I guess the problem is pretty simple, if not immediately obvious for the details of it. I sigh and guess that means I just have to upgrade soon...

mahyarm 9y ago
The swift scalability problems start coming up around 70k lines of code, so for the typical case of 1 or 2 developers it doesn't come up. But if you start getting a large codebase: * indexing will take forever * xcode will beachball continuously * the debugger will crash because the codebase is too much to handle * build times will be 4-5x more than the equivalent obj-c codebase * startup times will balloon significantly if you have many separate libraries, since using swift forces you to use dylibs. 60-100 libraries will mean 3-5 seconds being added to your app startup time They are all solvable problems, but it will take several years before they are fixed. But I don't think swift will be better than C++ development, since they are both similar languages as far as compiler tradeoffs go. I notice some lag even in small swift projects compared to objective-c, but it isn't major enough to worry about.