Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
IOS Apple IT Technology

Developers Explain Why iOS Apps Are Getting Bulkier ( 140

Reader joshtops shares a report: Apps are getting bigger in size, in part because developers add new features, something many users obviously appreciate, developers say. "Apps are getting bigger because iOS devices are more powerful, and developers are building more and more complex things for them without considering the impact the size will have around the world," developer Stephen Troughton-Smith tells Gadgets 360. But in part, it is also happening because developers are being careless, and adding more than one instance of files, Troughton-Smith added. "So Facebook, Twitter, and other large companies have perhaps tens or hundreds of people building their iOS apps. A lot of the components for these apps are developed independently as components, or frameworks. For each additional component you glue together into an app, there is some overhead," he explained. "Some of the teams will duplicate functionality some other team wrote. Images and other resources end up being duplicated." The high-resolution image assets that developers are required to add also contributes to the size of an app, two India-based developers, and Peter Steinberger, founder and CEO of PSPDFKit, a dev kit that is used by several popular PDF apps, told Gadgets 360. Apple can itself take some blame, too. Developers using Apple's Swift language, which the company introduced in 2014, are required to add several components to their apps that make them heavier. "Apple's new Swift language, for example, requires a bunch of components to be embedded each time it's used, because it's not yet 'ABI stable,'" Troughton-Smith explained. This means developers need to embed the versions of libraries they've developed against, and not count on the one available on the system. Another developer who didn't want to be identified said a typical app built with Swift language requires as many as 30 Swift runtime libraries to be stuffed within the app. On top of this, he added, "you will be surprised at just how many apps use common code found at places like GitHub. Developers often don't care about removing the bits that wasn't relevant to their app," he added.
In a blog post published in June, marketing and research firm Sensor Tower wrote, "The total space required by the top 10 most installed US iPhone apps has grown from 164 MB in May 2013 to about 1.9 GB last month, a 12x or approximately 1,100 percent increase in just four years." The phones' storage capacity has not changed at anything close to the same rate, with the base iPhone version only recently going up from 16GB to 32GB of storage." [...] San Francisco-based developer Ben Sandofsky, who was part of the team that made Twitter's iOS app and has served as a consultant on HBO's Silicon Valley show, resonated our concerns and said often "employees at these [Western] companies live in an 'early adopter bubble.' They have LTE connections, fast Wi-Fi at home, and phones with 64 gigs of storage. This creates a huge blind spot around your average user." Sandofsky, who recently developed popular third-party Halidi camera app for iPhone, added, "another issue is advances that have made the lives of engineers and managers easier, without understanding the burden on users. It's gotten easier than ever to reuse code between iPhone apps. With a few keystrokes, an engineer can add thousands of lines of code to an app. In theory that's good, because engineers shouldn't reinvent the wheel. Unfortunately things have gotten crazy in the last few years, with engineers pulling gigantic libraries that add megabytes to their app's size, when they could build something much smaller to solve the task at hand in under an hour."
This discussion has been archived. No new comments can be posted.

Developers Explain Why iOS Apps Are Getting Bulkier

Comments Filter:
  • by Luthair ( 847766 ) on Wednesday August 09, 2017 @10:19AM (#54974131)
    Doesn't it prune unreachable code?
    • My thought too. If a function is never used, it should be elided from the final linked binary.

    • Re:Swift Compiler (Score:5, Interesting)

      by infolation ( 840436 ) on Wednesday August 09, 2017 @10:39AM (#54974383)
      I think the issue is redundant code through duplication, not code that isn't used.

      The Swift optimizer can perform high-level optimizations, but to use the high-level abstraction of built-in Swift data structures in Swift Intermediate Language, the developers need to understand how the Compiler performs those optimizations.

      My guess is that the developers lack that understanding of the Compiler's SIL optimization.
      • by Luthair ( 847766 )
        I dunno, while they do reter to duplication they also mentioned copying a crap from Github
      • TFS also claims that Swift programs can't count on stable libraries, so they have to include their own runtime libraries. That's perfectly reachable code that shouldn't have to be there.

    • In OO languages it is a bit difficult to see which code is truly unreachable, unless for obvious cases, of course.

      • by Dog-Cow ( 21281 )

        Actually, for pure Swift code, it's rather easy, as compiler optimizations go. The problem is the dynamism of Objective C.

      • by Luthair ( 847766 )
        OO languages are just as easy as anything else, you just need to know the entry point.
        • No, they are not.
          E.g. with overridden virtual methods, you usually have to link all of them as you can not statically decide which will be called in the end.

        • by dgatwood ( 11270 )

          OO languages are just as easy as anything else, you just need to know the entry point.

          Not even close. Not when programmers can do things like:

          id object = [[NSClassFromString(@"SomeOtherClass") alloc] init];
          id result = [object performSelector:NSSelectorFromString(@"someMethod")];

          It's theoretically possible to catch all of those tricks, but easy, it ain't.

    • by Anonymous Coward

      This is all about sloppy architecture - as in not having one - and shitty project management.

      It looks like they have a bunch of separate teams with their own direction and no one sitting down and really designing the things.

      it has nothing to do with the compiler or tools. Shit like this happens on poorly managed projects all the time regardless of language, tools, platforms, etc....

      See folks, good management does have its place.

    • Doesn't it prune unreachable code?

      If you have hundreds of megabytes of unreachable code, then you have bigger problems than your compiler.

    • Yes it does. It isn't Swift anyways. []

      Since we launched Halide, the most unexpected compliment we’ve heard is about its size. At 11 megs, we’ll push less data in one year than a social network pushes in a single update.

      “So you aren’t using Swift,” asked a friend. After all, Swift bundles its standard libraries into your app, bloating its size. Halide is almost entirely Swift.

  • Redirect (Score:2, Insightful)

    by Anonymous Coward

    No mention of the very real problem of analytics/trackers. Once you get Crashlytics and all the other trackers stuffed into there you're pushing 200MB without any real functionality.

    Contrast this with Signal; the most recent update was around 30MB, and it incorporates complex crypto and video calls. Not so many trackers.

  • by Anonymous Coward

    Developers are sloppy, lazy, NIH-prone sods who'll slap together as much crap as they can get away with because the prevailing wisdom is that developer time is more valuable than resources and time wasted by their millions of users. We knew this, we just hadn't realised the math is that flawed. Because, hey, who needs more than one app on their phone, right?

    • They are lazy, but they haven't been NIH people for quite some time - in fact, NIH is anathema to the truly lazy developer.

      The pinnacle of laziness for software development is finding some library or framework already on the Internet that does what you need to do in the particular situation you are in, and you import the whole bloody thing without so much as looking at all the other shit it brings along with it. Do this 30 or 40 times and glue it together with the flavor of the week language and ship it wi

  • by Anonymous Coward

    Dynamic link libraries.

    Tim Cook should talk to this guy named Bill Gates, he might know a bit about them.

    • The developers are lazy. The linking model isn't the problem. You can duplicate native code with dynamic linking or with static linking.

      Or are you suggesting moving more functionality into the platform's standard library?

    • Read the summary. The issue with Swift is that the libraries are not locked down yet. Each app has to static link - or include the libraries as part of the installation - as it can't rely on the different versions being compatible.

    • by thsths ( 31372 )

      The whole idea of mobile apps is that they are self contained. Using shared libraries (unless they are included in the OS) is the exact opposite of what people want. And if you think about Windows, it did start with shared DLLs, but nowadays it keeps a different version of the very same DLL available for each program, to prevent DLL hell.

      Shared libraries only work if you have a single source, such as a Linux distribution. Otherwise they are more hassle than it is worth.

  • Unexpected benefit (Score:4, Interesting)

    by Dixie_Flatline ( 5077 ) <> on Wednesday August 09, 2017 @10:26AM (#54974227) Homepage

    I have a 16GB iPhone 6. It was a mistake to go for the lowest tier of storage, and I regret it, but it DOES make me choosy about my apps. I have a 32GB 5th Gen iPad and just by the nature of what I do on my phone vs. my iPad, that's actually just fine. I install the big games on my iPad, aggressively delete anything I'm bored with, and that's great.

    On my iPhone, I'm now ultra vigilant about what I use, which means I don't have facebook installed, which is GREAT. (I still use it, just in the browser.) I've gotten rid of the apps that are huge and distracting, and while I'm still always toeing the line with regards to storage, I'm happier with this low-storage situation than I expected. And when I finally get a new phone with more storage, I think I'm going to TRY to keep the same mindset, and keep my phone's installed app base nice and lean.

    • I have a 16GB iPhone 6. It was a mistake to go for the lowest tier of storage, and I regret it

      It was also a mistake to choose a phone without expandable storage.

      • That is the larger mistake, in my opinion.

        Being able to use memory cards and being able to change the battery are two of my "won't buy if I can't" features when I'm shopping for a phone.

        • I don't need to swap batteries until my current one no longer keep its charge so I don't really care if the battery is "removable" as long as I can open the phone with tools and replace the battery.
          What I don't like is that it is sometimes hard to find original quality batteries 3-4 years after launch which aren't overpriced or sold by obscure ebay sellers.

          • I don't really care if the battery is "removable" as long as I can open the phone with tools and replace the battery.

            I count that as "removable". Just not conveniently so. But there are too many phones that don't even allow that, with batteries glued and/or soldered in.

            • at least on the Nexus 5, it was pretty easy to "unglue" the battery and replace it.

            • Last I looked, Apple would change the battery for eighty dollars, and there were lots of places charging less. The iPhone battery is removable, just not conveniently so.

              • If I can't remove it myself with, at worst, a commonly available screwdriver then it's not removable in my book. The idea is that if I drain or damage my battery, I can put a new one in without a lot of fuss.

                By the way -- $80?? That's simply insane.

      • by Anonymous Coward

        I think it's a mistake to pick Android because of the overall junkier experience. But see, I recognize this as an *opinion*, not a fact. You could adopt this attitude as well...

    • Same here with my very old iPhone 4S with its 16 GB of RAM. Also, have to conserve its original old battery and slowness. I also use it when I have to.

  • > The high-resolution image assets that developers are required to add also contributes to the size of an app. -- This. Having to provide icons at 57x57 and 58x58, just for two examples out of dozens, is asinine. Our app code is dwarfed by the image collection size just to provide the minimum number of icons and load screens required.
  • by ctilsie242 ( 4841247 ) on Wednesday August 09, 2017 @10:30AM (#54974279)

    Dynamic libraries have been one way to save space for programs. Have a standard library that is tossed into a special shared area of the filesystem, hard link it so the apps can see it in their jail, and call it done. Obviously, the library would be signed.

    Now comes the tough part. DLL hell. A WinSxS mechanism would be useful so apps that use different versions of a library would not conflict with each other.

    Of course, the best solution would be filesystem level deduplication. If apps are stored encrypted on the device, then move to a dynamic library system and deduplicate the .so files.

    This isn't the best solution, but it should significantly save space.

  • I'm pretty sure the app developers are just renting out storage space on the user's phone.
  • Transition period (Score:5, Interesting)

    by UnknowingFool ( 672806 ) on Wednesday August 09, 2017 @10:34AM (#54974335)
    I wonder how much of the code bloat is also due to multiple transitions happening at once. First Apple is moving to 64-bit for all iOS devices. Certainly there is some overhead maintaining both 32-bit and 64-bit frameworks. Second, Apple seems to be phasing out Objective C in favor of Swift. As the article noted, Swift requires more space but I wonder how much of the space is because both are used.
    • by Anonymous Coward

      It is mostly Swift that is a pig, as it forces your app to ship with the ever-changing Swift libraries while the ObjC ones are stable.

      This is hilarious, as Apple marketing is so powerful that in every WWDC presentation, the guy now have to say something good of swift (like : "you would not have this prolem in swift" when talking about optimizing ObjC), even if it makes little sense. Having such a big "swift apps are bloated" hanging all over the tech news is just too funny.

    • by AmiMoJo ( 196126 )

      It sounds like they created their own DLL hell by requiring every app to have a copy of the library for compatibility reasons.

      Of course, it wouldn't matter so much if they priced flash memory fairly and if they made the app download/install system clever enough to check if it already has a copy of that version of the library and use it.

      • Yes but if compatibility isn't as big an issue in the future, how much will the bloat go down? I'm not an expert enough in Apple's development to answer this question. For iOS 11 for sure, the 32-bit frameworks will be gone so we'll see how much that will change the bloat.
      • It sounds like they created their own DLL hell by requiring every app to have a copy of the library for compatibility reasons.

        Nope, they just wasted a lot of space. Probably the best way to solve it is with a filesystem with deduplication, because just bundling the libraries with the apps every time really does solve several problems. I've been playing with my Amiga 1200 lately and having to run around finding whatever.library is kind of annoying. It's orders of magnitude less annoying today than it was in the early days of the internet, but it's still a pain.

        Of course, the other reasonable way is to add dependencies to app stores

        • by Jeremi ( 14640 )

          Nope, they just wasted a lot of space. Probably the best way to solve it is with a filesystem with deduplication, because just bundling the libraries with the apps every time really does solve several problems.

          Agreed; in fact Apple could take the deduplication idea even further since they have full control of both the App Store and the iOS device's filesystem -- Apple could maintain a database of secure hashcodes/checksums for every file in every app that has ever been uploaded to the App Store, so it could replace its download-the-whole-bundle install process with one that only downloads the files that the phone doesn't already have have stored locally, and (of course) only stores exactly one copy of each file,

    • First Apple is moving to 64-bit for all iOS devices. Certainly there is some overhead maintaining both 32-bit and 64-bit frameworks.

      The frameworks on the computer and compiled code are larger because of that, but the final version that goes out to the users device only includes the architecture they need it for.

      Second, Apple seems to be phasing out Objective C in favor of Swift. As the article noted, Swift requires more space

      The reason it requires more space is not so much the language itself, but that e

      • by Dog-Cow ( 21281 )

        ...but the final version that goes out to the users device only includes the architecture they need it for.

        Did Apple ever figure out how this works with backup and restore? This feature was actually disabled shortly after its introduction. I am not aware that it has been reenabled.

    • I did wonder about the difference between iOS and Android on this. We only recently ran an article talking about Facebook being 388MB. On my Android phone it weighs in at 162MB, and 10 seconds of Google "research" showed that universally apps are far larger on iOS.

  • by Anonymous Coward on Wednesday August 09, 2017 @10:39AM (#54974389)

    developers are building more and more complex things for them without considering the impact the size will have around the world,"

    I cut my teeth programming computers with 1 KB of RAM (not 1 megabyte, not 1 gigabyte, but a mere 1024 bytes). On the plus side, you could lift it yourself.

    You took every possible step to save a byte here, and 3 bytes there. Once desktop computers became monsters with megabytes and then gigabytes of memory, the need for that was reduced. Which is good in a lot of ways, but it also led to a generation of programmers who had no exposure to highly limited devices. They'd never written anything in assembly language, and they had only a dim awareness of the time vs space tradeoffs of the huge library routines they were using. This led inevitably to bloat, since out of sight is out of mind. I've seen people using many megabytes for something I'd do in bytes or kilobytes, but their approach required less developer understanding. It was amiable to programmers who didn't grow up bit twiddling, it was easy, and it was faster (for them) than trying to understand my way (which was fast for me, but depended on skills honed in another time). Programmer time is expensive, and most programmers have little low level knowledge about how the machine works under all the layers they depend on, so their approach allows people to accomplish things they never could otherwise. Is that good? Is that bad? Probably both, I think, depending on how you look at it.

    The same thing is happening now with phones. Early phones were highly memory constrained devices, but now, that pressure is fading. Bloat is inevitable. It can't be stopped any more than the tide can be.

    • > On the plus side, you could lift it yourself.

      Not really an advantage... I can lift my smartphone just fine. :-) But I guess you mean an advantage compared to ENIAC and its kin... the 1/2k machines or the even heavier 1/4k machines. Come to think of it, the original bit must've really massive!
    • You say programmer's time is expensive, but I wonder how it compares to the full system-wide cost. I suspect that a massive amount of cost has been pushed to the unknowing consumer - possibly many times what the cost of better programming would be.

      Is the combined time saved by modern sloppy programming practices greater or less than the cost of all of the extra memory required in billions of devices and the extra distribution costs for all of those apps. We don't consider things like, what is the energy cos

      • I suspect that a massive amount of cost has been pushed to the unknowing consumer - possibly many times what the cost of better programming would be.

        Let's see...Swift takes more memory, users react by upgrading to iPhones w/more memory and more profit margins for Apple.

        Older versions of Windows get slow and bloated with extensive patching, users react by getting new computers, boosting OEM license sales.

        Conclusion: It cuts expense while simultaneously increasing sales. That's win-win!

    • It could be stopped if Apple stopped approving apps that were grossly oversized for what they were.
      • If users developed a preference for buying smaller apps, you'd see smaller apps. It's not Apple's job to decide what you should have in phone apps (although they do a fair amount of it anyway).

    • You can cut your teeth all you want. The problem isn't the size constraints, it's the functionality constraints. I too do a lot of work on very constrained microcontrollers, but that doesn't mean I don't reach for a generic video library when I am working with a device that has a touchscreen interface.

      If I re-invent the wheel every time I want to build a car all I'll ever end up with is a bunch of crappy wheels.

    • I'm optimistic about all of these retro implementations of legacy computing platforms. I think that any programming curriculum should involve some exposure to a modern implementation of an Apple //e, for example. That would teach frugality and perspective.
  • Isn't the role of architects to ensure independently developed components have access to shared resources? [sarcasm font]Oh wait, architects aren't needed when you can just hire more coders. [/sarcasm font] Seriously though, how many times you have heard we don't need architects?
  • by JohnFen ( 1641097 ) on Wednesday August 09, 2017 @10:57AM (#54974587)

    An awful lot of that sounds like the bloat is due to the same things that are making pretty much all other modern software so bloated: economics.

    Developer time has become much more expensive than hardware, so the entire industry has moved to development practices and tools intended to minimize the time required to create applications. But these productivity gains, almost universally, come at the cost of wasting bytes and machine cycles.

    So all software has, for many years now, been getting fatter and slower, relying on faster hardware to make things tolerable.

    • True. Plus, developpers are lazy, and being pushed to do so. They usually download these large librairies with hundreds of methods/functions , and maybe will use only a couple of these functions. But everything is bundled in, and they don't care about the total package size, until it becomes a concern...
      • I think we should stop calling such developers "lazy" and instead call them what they are: bad developers.

        • Hard to distinguish lazy from efficient in this context. If it only takes a couple moments to pull in a giant library but that saves writing three functions, the time tradeoff may be worth it. And if the devices are beefy enough that no one complains about your app? Win!
          • That would count as a conscious design decision, though, not laziness. Laziness is just taking the path of least resistance without considering the tradeoffs involved.

      • Plus, developpers are lazy,

        One of Larry Wall's Three Cardinal Virtues of programming. Lazy developers do things efficiently.

        they don't care about the total package size

        Programmers are adept at optimizing for what they're asked to optimize. As long as there's no money in reducing package size, developers will continue not to care about it.

    • by Anonymous Coward

      Economics, yes, but you overlook a key aspect of the economics: it's cost shifting. Software companies push the cost of their inefficient software onto the consumer who must keep purchasing new, more capable phones just to be able to run pretty much the same crap he could have run on the old phone if the software weren't so sloppy.

  • by SLi ( 132609 ) on Wednesday August 09, 2017 @11:02AM (#54974635)

    I used to work at a game company. Before that, and coming from the a Linux world, I had always wondered how people manage to get even the executables to reach hundreds of megabytes to gigabytes. Now I understand.

    For example, the game uses compression, so it embeds zlib. It also uses something like 50 externally or internally sourced libraries, many of which also embed zlib. Some of those embed other libraries, which again may embed zlib.

    I found more than 80 copies of zlib in the game engine source code and its embedded dependencies. There were also tens of png and jpeg libraries, zip libraries and Lua interpreters. For building and tooling purposes only, there were around ten Python interpreters. Also, there were some eight copies of different versions of the in-house developed container library (STL replacement). And that doesn't count the libraries we didn't have source code for.

    Nobody in our team even had the slightest idea that was the case. In the Windows world, that's standard and best practices. I believe this is largely due to the somewhat sorry state and limited benefits of dynamic linking on Windows.

    The Linux world proves properly versioned dynamic linking can be extremely beneficial when done rigorously. To fix a security vulnerability in zlib, you only need to update zlib, not every application. Memory is saved: Any executable pages in dynamic libraries are only mapped once. That means you have one copy of zlib in memory per system, instead of 80 per application.

    Statically embedding anything does have its benefits, though, which is why the commercial world likes it. It means you won't get to debug weird problems because of broken libraries on a system. Containerization is the trend also in devops, and that means explicitly duplicating stuff yo make it easier to maintain.

    • by starless ( 60879 )

      I'm just a humble amateur scientific programmer (I'm mainly a scientist), but I still have trouble understanding how "just" libraries can get anything into the GB range. In my humble number crunching code (linux based), it always seems to be large data arrays which end up eating up all the space. Could it be with phone apps that they're including lots of images which are what is principally eating up space?

    • This is a natural outcome of the "let's make methods and variables private to protect developers from each other" mindset.

  • A lot of developers develop their apps in a vacuum, e.g. they test their apps on a relatively clean device which doesn't have any other apps installed aside from the OS itself. It's easy to see why they don't really care how much space their apps occupy.
    • they test their apps on a relatively clean device

      If this is the only sort of testing you do, then you aren't actually testing your application.

      Which goes a long way to explaining why most apps are terrible.

      • While I was reading this I was thinking that the dev and testing environments should be hamstrung like a previous generation phone used by a teenager in terms of processing power and hard drive space. It would suck to develop under that, but it would mean that on a next generation phone the app would be small, fast, and responsive.

    • My wife had to argue with her boss for some time to get a limited account on her computer. She had found too many times in which she'd written something and it worked just fine, but required some admin privilege she missed, and so it wouldn't work for the users.

  • No one mentioned what is probably one of the biggest reasons for bloat from the apps of the big tech firms over the last 10 years: Machine Learning Models using Deep Learning. If machine learning models are included with the app as opposed to the cloud it will add up. Even the most compressed of these models comes in at 10-30 MB. Add one for photos, one for search, one for voice, and one for some other as application specific model. At this point you're already pushing up to ~100MB right there and you haven
    • I'm not aware of any apps I use that involve machine learning. Probably because I make sure that my machines cannot talk to the cloud.

  • by cyberfunkr ( 591238 ) on Wednesday August 09, 2017 @12:19PM (#54975463)

    As in nature, the more powerful grow bigger as to kill off the competition for food and space.

    By making my apps larger than required, it means there is less space for other apps on the phone. If room is at a premium, then you're less likely to load duplicate functionality (While it's nice to have two weather apps to get an average, if I don't have enough space, I'll just stick to the one).

    This can backfire as people may instead delete the one big app to make room for two smaller but possibly just as competent. However, since file sizes are not always quickly available, more likely people are too lazy to do the research.

  • by Waffle Iron ( 339739 ) on Wednesday August 09, 2017 @12:19PM (#54975467)

    Apps are getting bigger because iOS devices are more powerful

    The only explanation needed is the old adage, which I have never found to be untrue:

    "Software is a gas; it expands to fill its container."

    • It could be extended as a gas under pressure, the slightest leak lets it get into all kinds of trouble. Even if not under pressure, it could still diffuse. If under lower-than-ambient pressure, that's another problem... Disclaimer: I'm bad at making analogies.
  • If so, is it on Apple's end, or the developers' end?
  • A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

    - Antoine de Saint-Exupery

  • by p51d007 ( 656414 )
    No incentive to slim down the code. Same with PC's. With space NOT at a premium, why waste the time trying to slim down the code. Plus, people want/demand/expect more things from the application.
  • Apple could fix with with a "tax" on large apps. Larger apps have to have a higher price share with Apple. Free apps have to pay say a cent per every 10 MB over a certain size. That would make everyone's code tighter quickly!

  • This is a small illustration of what is happening in all things, not just technology, the continuous, unrelenting, addition of complexity. At some time there must be a "complexity collapse."
  • has 32gig of storage built in and supports a 2 terabyte SD card. This doesn't seem like a software problem, this seems more like an "Apple charges too much for storage" problem. When Sony tried this on the Vita it cost them a ton of sales.
  • The more things change, the more they stay the same.

  • Does anyone have any info on the amount of bloat the is actually embedded graphics information? I have no direct data but from the apps I see the big ones always has a lot of still-frame and full-motion video component embedded in it. Almost always games and entertainment, not business or utilities.

  • Android development has also suffered the same issues. Showing my age... In the old days I remember trying to optimise some code and data to fit into 1K of RAM. It wasn't an easy task but eventually you'd work out a better more reusable function to serve more than one purpose and nail it.

    <rant level="maybe"> Now days it seems that just getting something running is good enough to put into production. Agile projects run by PMs that think that teams working separately in little groups with no interac

  • Good news. ABI support coming to Swift in 2018 []
  • There's an app for that!
  • It's why I prefer header only libraries.
  • here is a memo that circulated in SGI in 1993, about how IRIX got bloated and unusable because of exact same reasons as mentioned in the original post: []

    This is mandatory reading for every new IT employee in my company.

From Sharp minds come... pointed heads. -- Bryan Sparrowhawk