Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Software Data Storage IOS Iphone Apple Hardware

Are App Sizes Out of Control? 386

In a blog post, Trevor Elkins points out the large sizes of common apps like LinkedIn and Facebook. "I went to update all my apps the other day when something caught my eye... since when does LinkedIn take up 275MB of space?!" Elkins wrote. "In fact, the six apps in this picture average roughly 230MB in size, 1387MB in total. That would take an 8Mbit internet connection 24 minutes to download, and I'd still be left with 27 additional apps to update! More and more companies are adopting shorter release cycles (two weeks or so) and it's becoming unsustainable as a consumer to update frequently."

Should Apple do something to solve this "systematic" problem? Elkins writes, "how does an app that occasionally sends me a connection request and recruiter spam take up 275MB?"

Further discussion via Hacker News.
This discussion has been archived. No new comments can be posted.

Are App Sizes Out of Control?

Comments Filter:
  • by Anonymous Coward

    I know you old perl grognards don't know anything about the size that graphical assets take up, but when you need a 2086x1080 image for every screen because iphone resolution is fuckhueg you get ballooning app sizes.

    • Re:lol know nothings (Score:5, Informative)

      by Anonymous Coward on Wednesday August 02, 2017 @09:11AM (#54924939)
      Image compression exists for a reason. If you neglect to optimize your images, the best compression in the world won't help. Check out PNGQuant; it can often achieve perceptually lossless compression through careful palette selection and dithering. Vector graphics are also a thing; you can create your bitmaps at runtime.
      • There's the basic problem of all Adobe software making bloated PNGs in the first place. Easily solved if you use a PNG optimization program as you say. Myself, I use ImageOptim when working on websites.

        The problem, however, is probably moron programmers who save everything in JPEG at 100% quality instead of using PNG.

    • by Anonymous Coward on Wednesday August 02, 2017 @09:18AM (#54924987)

      Bullshit. Image sizes for simplistic apps like that would never consume that much space. The actual reason these apps are ballooning is size is because developers nowadays are complete shit and don't understand code reuse, optimisation or assembly language.

      • by Anonymous Coward on Wednesday August 02, 2017 @09:24AM (#54925033)

        simplistic apps like that

        how is facebook simplistic? it needs to:

        track your location at all times
        record everything via the mic even when backgrounded
        send you push notifications when your gradeschool girlfriend makes a post about how men suck
        deliver you the quality ad content you deserve
        let your HR department creep on your comings and goings because they have nothing else to do
        support hashtaggings

      • by Daemonik ( 171801 ) on Wednesday August 02, 2017 @09:43AM (#54925151) Homepage
        Okay, no app developer is going to use assembly, because their app will be on a range of hardware from different manufacturers. Portability is mandatory in the app world.
        • Even within Apple's walled garden, app developers must write for an increasing array of different screen sizes, and to take advantage of optional hardware like Touch ID when available.

          • Bullshit. (Score:2, Informative)

            by Anonymous Coward

            Reaper, a highly sophisticated digital audio workstation for PC that is decades more advanced than any phone equivalent, weighs in at 10MB installed.

      • Re:lol know nothings (Score:5, Interesting)

        by Anonymous Coward on Wednesday August 02, 2017 @09:58AM (#54925255)

        Actually, they ARE re-using code. These days every schmoe has a library that is "built on" some other schmoe's library. You can't even flush the urinal without going through 99 million layers of schmoe software. It's schmoes all the way down.

        These clowns are worried about size -- frankly, it's a damn miracle that any of it even functions at all.

        • This. And in order to render HTML one library happens to be an entire browser. This is the case for Electron apps

        • by tatman ( 1076111 )
          this is it! no one can just write their own code any more. they gotta download a library. and as you stated, that has to download another library and cycle repeats.
      • by skids ( 119237 ) on Wednesday August 02, 2017 @10:55AM (#54925605) Homepage

        How code re-use works on a real linux distro:

        1) application A wants to perform operation B
        2) application A depends on libB
        3) A bug in libB is discovered that prevents Application C from using it
        4) Application C embeds a fixed version of libB
        5) libB eventually gets upgraded while maintaining ABI compatibility
        6) Application C drops its embedded version of libB and resumes sharing the system libB by depending on it with a version restriction in their next version

        How code re-use works on andriod:

        1) application A wants to perform operation B
        2) Luckily android happens to have libB preinstalled (for argument's sake) so application A just uses it
        3) A bug is discovered in the preinstalled libB that prevents Application C from using it
        4) Application C embeds a fixed version of libB
        5) nothing happens for a year or so until all major carriers upgrade the whole OS
        6) The whole OS gets upgraded and other things in the upgrade break both application A and C even while libB gets fixed
        7) The authors of application A and B say "screw this, that sucked" and embed their own copies of everything
                so they never have to deal with that kind of mess again.

        • by MachineShedFred ( 621896 ) on Wednesday August 02, 2017 @12:04PM (#54926181) Journal

          It's a good comparison, except that step 6 on the Android list very rarely happens at all.

        • It is much, much, much worse than that.

          Chrome for instance, has four separate copies of zlib. The copy used by most Chrome code, the copy in Skia, the copy in Pdfium, the copy used by libpng, and I might be forgetting some... They solve link time problem by prepending every copy with a separate prefix.. You know, you discover you are doing something retarded, and solves it by double down and making it more retarded.

          This is the future: Utter crap!!

    • How many of these images are really needed? And how many of the remaining images could be done with some simple vector graphics calculations?
      Back in the old days, the customer wanted a shadow effect on a table border to make it stick out. At the time CSS didn't have shadow ability. So I had 5 small png
      TopRight 5x5, Right 5x1, BottomRight 5x5, Bottom 1x5, BottomLeft 5x5. Then I just stretched the images in the right spot to create the effect. during this time people were still using dial-up modems, so we n

    • Re:lol know nothings (Score:5, Informative)

      by Timothy Hartman ( 2905293 ) on Wednesday August 02, 2017 @09:43AM (#54925153)
      Total bullshit. LinkedIn, for example, is 247 mb uncompressed of frameworks and 1.6 mb of images, 14.9 mb of language localizations for the 25 languages it supports.
      • by Zocalo ( 252965 )
        Those proportions seem sane enough, at least from looking at the contents of packages on Android, but unless iOS does things very differently I doubt that the frameworks are going to be entirely code either. The next step would be work out how much that 247MB is actual code, how much is images or other media resources, localizations, and even other frameworks (which may contain their own non-code resources and other frameworks...)?

        More importantly, and I suspect the main reason for the bloat, even when
      • by 93 Escort Wagon ( 326346 ) on Wednesday August 02, 2017 @12:06PM (#54926197)

        Here's something I really don't get.

        The blogger - and many of the responders here - are debating the size of LinkedIn's app. But, given the bad things we know that LinkedIn has tried to do with that app on more than one occasion... why does anyone even consider having that piece of malware on their phone at all?

  • by gillbates ( 106458 ) on Wednesday August 02, 2017 @09:05AM (#54924901) Homepage Journal

    This is the natural consequence of choosing languages based on their library support. These languages were chosen for their ease of creating deployable solutions, not for the size of their executables.

    Storage utilization is the user's problem, not the software engineer's.

    • by Anonymous Coward on Wednesday August 02, 2017 @09:12AM (#54924947)

      This is the natural consequence of choosing languages based on their library support. These languages were chosen for their ease of creating deployable solutions, not for the size of their executables.

      Storage utilization is the user's problem, not the software engineer's.

      Incorrect. Resource management is the software engineer's problem, not the user's. Using inappropriate amounts of resources is a sign of a poor software engineer who has no idea how to design, code and use resources properly, not a user with an old small phone.

      • by LordWabbit2 ( 2440804 ) on Wednesday August 02, 2017 @09:31AM (#54925073)
        Wrong, it's the software engineers problem. Most of these apps are huge because the decision was made to go with a framework which would make it easier to build for all relevant platforms without specifically catering for that platform (except maybe UI). Just before my last phone upgrade I was seriously hunting for space, and guess what apps got nuked first?
        The largest that I don't use often or can live without. {{{ That makes it a software engineers problem, not the users.

        If no one is using your application because they consider your flash light app that clocks in at 70mb too big to bother with, then you may as well not have written the software at all.
        Xamarin is a prime example of this, a hello world app is over 16mb (the last time I looked) the same app in native Java is a couple kb.
      • There are other reasons. In many large companies, bugs are assigned a priority, and something like "app size too large" would fall well below segfaults and operational bugs. While management and programmer alike may agree that resource utilization is a problem, it is often a difficult issue to resolve because it's an open-ended task, and it can be difficult to tell what "done" means - does it mean reduction of 50%? 90%?

        poor software engineer who has no idea how to design, code and use resources prope

        • The prioritisation of these bugs is indeed a problem, but I would argue that the problem is not with prioritising bugs, it's directly with how people think that these particular bugs should be prioritised.

          Significant size, performance, and power regressions should be considered right up their with the operational bugs, and severe ones should be considered more important. The only bugs that should beat them out should be security bugs (which I guess means most crashes too).

      • by Shotgun ( 30919 ) on Wednesday August 02, 2017 @10:45AM (#54925531)

        In this world, the software engineer's problem is getting paid.

        The software companies problem is adding candy to the app to get you to choose it over the other app, and installation size doesn't get considered. The Google PlayStore doesn't even tell you how large an app is until you decide to install it.

        So the situation is that the company gets judged on how fast "features" get gets judged on what and how quickly she adds features. The fastest way to add a feature is to add a library that supplies it. Eliminating cruft earns no points, so no one works for it, but learning a new library will make the engineer's resume look better, so he might choose to add one even if the library used in a different part of the code would do the job.

        The result is that what is rewarded get optimized.

    • by BasilBrush ( 643681 ) on Wednesday August 02, 2017 @09:13AM (#54924953)

      Large size app packages are invariably caused by sizes of assets, not code. In the case of games that's usually inevitable. But for most other apps, it usually means that no engineer has bothered to look at what assets are shipping, and get rid of the ones that aren't used, and think of ways to save space on those that are.

      • by beelsebob ( 529313 ) on Wednesday August 02, 2017 @10:38AM (#54925483)

        Actually, that's not true. Facebook for example is huge because of code size, not because of asset size.

        They have literally thousands of classes for a super simple application. In fact, their code is so large, unwieldy and complex that they wrote an entire IDE, because the traditional IDEs couldn't deal with the sheer amount of code they have.

        I don't know why it didn't occur to them to just write better code, but apparently it didn't.

    • Except:

      "As app developers, we should be more conscious of the space we use. Take some time to remove the cruft that builds up and push back against needless waste." []

      So no it's not natural consequences.
    • Storage utilization is the user's problem, not the software engineer's.

      The CEO from Bloatware, Inc. just called.

      He wants you to stop infringing on his legally protected slogan.

    • by jellomizer ( 103300 ) on Wednesday August 02, 2017 @09:56AM (#54925237)

      Most Apps are not really made by professional software developers. It reminds me back in the early desktop era, where most applications were made by people who had their own problem to solve. Without actual practice in coding, they wrote a program to do what was needed, but without much planning or for-site. Being these computers did one thing at a time, if it took 0.5 second vs 0.01 second wasn't a big deal, because it didn't affect other systems. So if you wanted a pause you can figure out the speed of your cpu and just loop x thousand of times. Moved to a multi-tasking system, that is great way to kill your jobs.

      Now companies are trying to race to Device Apps. But except for bringing in the old developers and get them to learn the new software, they hire flashy new App developers, who have Objective C and Swift and all the buzzword systems on their resumes, but not people with experience with coding, and for these new devices, which are relativity low powered, the talent to think about system resources.

    • From what I understand of the chaos at some of these companies (particularly FaceBook and Twitter), it's got more to do with the lack of engineering discipline, and a lack of good quality engineers.

      Facebook at one stage had 17,000 classes in their app. Most of them duplicated each other, but because the whole app is just a wild west of development, no one knows, or cares what their code duplicates.

      It's more important to throw in the new feature than to make sure the code is structured in a sensible way.

    • by ceoyoyo ( 59147 )

      Precisely. Only when users solve their storage utilization problem by deleting the bloated software will it become a problem for the engineers.

  • by El Cubano ( 631386 ) on Wednesday August 02, 2017 @09:07AM (#54924917)

    Good job, guys.

    On the one hand we have Bettridges law of headlines telling us that the answer is "no", and on the other the fact that it is rather obvious to pretty much anybody who owns a smart device that the answer is "yes".

    Since you're on a roll, why don't you just spread butter on the back of a cat and drop it from the ceiling to watch it float?

  • Yes. Probably. Maybe not, once your start ruling out the apps that you probably shouldn't be using in the first place.
    • Yeah, about a year ago I got fed up with the Facebook app using up hundreds of megabytes of space without really adding anything above and beyond the mobile web version. Still use Facebook, though - just through the web browser.

      • This is my big complaint with "apps". Why the hell do I need to sacrifice ANY space on my device (aside from maybe a few kb for cookies etc) to do something on my phone/tablet that I do from a browser on my desktop/laptop? Why can't I do it in the browser on the phjone?

        My storage is for my mp3s, pics of my kids, my ebooks, MY stuff.

  • Because node.js? (Score:5, Insightful)

    by mfearby ( 1653 ) on Wednesday August 02, 2017 @09:12AM (#54924949) Homepage

    Node.js apps are a dime a dozen these days, and they're all fat slugs of things. Sad.

    • Yep. Make the app great again!

    • As are packages and code snippets for other languages?

      The only "problem" with Nodejs is that it's very easy to use these packages. And then for the incompetent, it's very easy to forget them, not read and understand what those packages do and how they do it. But that can also be said for other languages.

      So I guess the true problem is that the entry-level expertise required to write JavaScript is too low for your high horse. You can't bitch about shitty developers then turn around and shun any aspiring ones.

    • by zifn4b ( 1040588 )

      Node.js apps are a dime a dozen these days, and they're all fat slugs of things. Sad.

      No way it's all those Python apps. They're all the fat slugs of things. Dime a dozen

    • Node.js apps are a dime a dozen these days, and they're all fat slugs of things. Sad.

      I'm genuinely confused. How does server side software cause mobile apps to become bloated? What difference does it make if the app is pulling from Node or Ruby or Python or anything else?

    • It's a JavaScript runtime. Is anyone using a JavaScript runtime for native client side apps that aren't just running in a browser? I'm not sure I see the point of complaining about server side apps. You trade performance and size for programmer hours.
  • by Snowhare ( 263311 ) on Wednesday August 02, 2017 @09:13AM (#54924957) []

    Technical Q&A QA1779
    Reducing Download Size for iOS App Updates

    Q: How can I reduce the downloaded size of my app update for users that already have the previous version installed?

    A: This document is specific to app updates. See Technical Q&A QA1795: Reducing the size of my App for a collection of techniques to reduce the size of an app when it is downloaded and installed for the first time.

    Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format.

    Note: The ability to create update packages is not currently available to developers who do not distribute their apps through the app store, such as those distributing enterprise apps.
    When used optimally, an update package is significantly smaller to download than the full package of the app and the update will install more quickly. Also, in many cases, this mechanism allows updates to large apps to be downloadable over cellular networks where app downloads are subject to a size limit.

    In addition to new content, the update package contains instructions on how to transform the prior version of the app into the new version of the app. New files will be added, modified files will be replaced with their updated counterpart, and deleted files will be removed as part of this transformation. As far as the developer and user are concerned, this process is entirely transparent and the resulting updated app will be indistinguishable from a full download of the corresponding updated version of their app.

    To optimize the size of your app updates, you should consider two tips:

    Do not make unnecessary modifications to files. Compare the contents of the prior and new versions of your app with diff or another directory comparison tool and verify that you've only changed what you expect within your app bundle.
    Content that you expect to change in an update should be stored in separate files from content that you don't expect to change. This reduces the size of the update package and increases its install speed.
    For devices running iOS 6.x and iOS 7.0, the update package will include any file, in its entirety, that has changed in the new version of the app. For example, if you have a 10 MB file in your app and only change 1 KB of content within that file in the new version of the app, the update package for that new version will contain the full 10 MB file.

    For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device. For this reason, the two tips above are still important even for updates on iOS 7.1 and later. Minimizing changed content and localizing it to many smaller files instead of one larger monolithic file will reduce the download size in all cases and will speed up installation on devices running iOS 7.1 and later.

    • Damnit I would mod you up, but I have already left several comments. Thank you for this information, it's nice to know that at least some attempt is being made to reduce upgrade sizes. Does this also hold true for Android?
    • "App Update Size is not the same as App Size"

      Tends to get reduced to bullshit semantics outside of bandwidth concerns. At the end of the day, even "optimized" updates are feeding bloated appware that's consuming precious device storage.

      And I find Apples give-a-shit level quite low when they are in the highly profitable business of selling soldered-memory upgrades for app-enabled hardware. Hell, their default bloatware says volumes about that. Garageband and iMovie apps consume over 2GB? Fucking seriously...

  • UI Overkill (Score:5, Insightful)

    by randomErr ( 172078 ) <ervin,kosch&gmail,com> on Wednesday August 02, 2017 @09:14AM (#54924963) Journal

    This is just plain overkill on UI components. ost companies are more worried about bells and whistles then functionality right now. That's why tablets and phone apps became so popular. Everything was light, small, simple which desktops and laptops really aren't. That's also my Facebook offers a slim version of their application in countries that has slow network connections.

    My guess is that the pendulum will switch away from native apps to something like Progressive Web Apps (God I hate that marketing term.) Light static websites that pull from RESTful service will become popular again. The base site will be 1 meg at most in size. Until thos ebecome as bloated as native apps. Then a new disruptive technology will come along and start the process all over again.

    • Re:UI Overkill (Score:4, Insightful)

      by nine-times ( 778537 ) <> on Wednesday August 02, 2017 @09:28AM (#54925055) Homepage

      Then a new disruptive technology will come along and start the process all over again.

      Not likely. If the past few decades have been any indication, storage capacities will grow and available bandwidth will increase, and people's idea of "small" will grow. Mobile apps will be 2 GB, and people will be saying, "Man, these app sizes are growing out of control. Remember the good old days when an app like this would only be 1 GB?"

  • by Chris Katko ( 2923353 ) on Wednesday August 02, 2017 @09:16AM (#54924977)

    ...on my Android phone. Except my phone is full, so every update... I have to delete another app, or clear the cache for it to download.

    It's !#@$!ing pathetic.

    I've got maybe 4 apps that aren't stock on my phone. It runs slow as piss compared to the two years ago when I bought it used. A freakin Samsung S5. You know... an "enterprise model / top-of-the-line" phone when it came out. No Facebook. Nothing. Just Google's, T-Mobile and Samsung's defaults.

    "Maybe you just need to upgrade."

    Bull. Shit. It's got a quad-core CPU and a GPU that would make my netbook cry, and yet... somehow... my Linux laptop sits there, every day, just as fast. And my phone keeps getting slower. Same websites. Same hardware (from purchase date). And yet... mysteriously... it keeps getting slower.

    I would not be surprised at all if there's some planned obsolescence at play. I've seen countless stories of people "reseting to factory default" their phone or tablet, and then once it installed all the normal updates... it's slow as mud again. It shouldn't take me 7+ seconds to load my bloody GMAIL app on a quadcore ghz CPU. It's _e-mail_. It's practically a word processor without the word processing.

    Then again, it's probably just a conspiracy theory. It's not like large corporations have ever colluded to bypass things like environmental regulations to increase profit.

    • by DNS-and-BIND ( 461968 ) on Wednesday August 02, 2017 @09:33AM (#54925085) Homepage
      Developers develop their apps on emulators, not on the phones themselves. When they do use phones, they are the latest high-performance ones. They never see the slowness, or if they ever do, it is handwaved away with "upgrade your damn phone, Luddite."
      • by Wycliffe ( 116160 ) on Wednesday August 02, 2017 @09:48AM (#54925193) Homepage

        Developers develop their apps on emulators, not on the phones themselves. When they do use phones, they are the latest high-performance ones. They never see the slowness, or if they ever do, it is handwaved away with "upgrade your damn phone, Luddite."

        Why is this modded down? This is absolutely the truth. Most apps are developed for the newest version of the phone and most developers tend to have the latest phones anyways. My company's solution to this was to send our developers to the store and have them each buy several $20 prepaid devices. Even this though isn't a perfect solution because developers still tend to do most of their testing and development on the higher end devices first and only switch to the crap phones during final testing or when there is a problem.

    • by enjar ( 249223 )

      Nothing. Just Google's, T-Mobile and Samsung's defaults.

      This is why when my Samsung Galaxy S4 needed replacement, I went with a (used, unlocked, GSM) Nexus 6P with 128 GB of storage. No crap Samsung apps, no carrier apps. There were the Google apps (which can be removed) but otherwise it was clean. Plus if my provider decides to be a jerk, I can take my business elsewhere.

    • I had similar things happen with other Android phones (I've also seen it happen with older iPhones/iPods each time you apply a new iOS version), which is why I decided to go with an unlocked Nexus 5. So far everything is still working great except for certain sites on Chrome, and those sites seem to be the ones that try to cram too much crap (that no one wants) into their mobile pages.

      Take as an example. Don't give me an app with alerts that drains battery life and CPU performance 24/7. Just l
      • by enjar ( 249223 )

        Take as an example. Don't give me an app with alerts that drains battery life and CPU performance 24/7. Just let me bookmark two pages for hourly and 10-day (maybe a third page for the current weather radar), show me the freaking temperature, tell me when it might rain, and include some static ads if you have to. Get rid of the fancy JavaScript, options to add/save 10 locations, high-res videos and animated ads, and the rest of the crap that makes it so painful that I gave up on visiting that web site on my cell phone.

        I just say "ok google, what's the weather" and it does exactly what you want. After you ask it enough times it notes the habit and then starts displaying it as a notification. Kind of equal parts creepy and awesome.

      • by tepples ( 727027 )

        Don't give me an app with alerts that drains battery life and CPU performance 24/7. Just let me bookmark two pages for hourly and 10-day (maybe a third page for the current weather radar)

        When got all bloated, I switched to

  • ... doesn't Apple use delta updates? Or is my phone somehow magically updating faster than my brand-new $1800 PC can download through a wired ethernet connection? Also: [] So yea, the initial download is huge, but the updates, specifically for Apple, are much, much smaller - depending on how much was changed in the update.
  • Absolutely (Score:5, Insightful)

    by Dan East ( 318230 ) on Wednesday August 02, 2017 @09:19AM (#54924997) Journal

    Yes, absolutely. I was just complaining to a fellow developer about this recently. As an "old school" software developer, who compiled code on an Amiga with two floppy disk drives (one for the compiler and libraries, and the other for my workspace), I am greatly annoyed by the bloat I see in apps. In my opinion, for an app to be 300 MB, it either is comprised of at least 1 trillion lines of source code, or contain a 298 MB video showing how to use the app. The latter of course being totally unnecessary. The FB app is over 300 MB. The images and icons it contains are most certainly not taking up the bulk of that space. Does it contain its own build of Linux or something? Does it contain translations for every known human language? Really, there is no reason for applications of that kind to be nearly that large.

    Two things I know for sure are that iOS apps do not need to be that large - there are some really good games that are only around 5 MB. Second, and I haven't used Android in years so maybe it has changed, but a given Android app always seemed to be smaller than the iOS version.

  • by enjar ( 249223 ) on Wednesday August 02, 2017 @09:25AM (#54925035) Homepage
    AND WE LIKED IT THAT WAY. Sometimes you had to swap a floppy, then people got 10 MB hard drives and everybody started throwing around memory like it was free.
    • Sorry to break it to you.
      Yes we did our best to fit as much data as possible on one floppy disk (664 blocks in use anyone?).
      But no we did not like it (boot - switch floppy - wp51/wp51 - switch floppy - load document - switch floppy again ...)
      And don't get me started on disk dupe and stacker from the times you could easily fill a hard drive a few times over with software alone..

      So, yes it's agreeable to go down the memory lane but longing back to floppies? Really?

      • by swb ( 14022 ) on Wednesday August 02, 2017 @11:21AM (#54925791)

        I don't miss the size constraint nature of floppies, but I do miss the portable environment nature of floppies.

        It was awesome to have my own little box of 5.25 floppies that I could bring from home and then in computer class, boot the Apple ][ with my own disks and utilities.

        I kind of wish it was more practical to do this with Windows. Of course there are close workalikes, (RDP, web based environments, Windows to go, etc) but nothing with the elegant simplicity of just booting the dumb thing from a 128 GB USB stick and using it as normal, and then carting it off.

  • For LinkedIn, I don't even see the point in having a dedicated app, it provides no added value compared to the web site as seen in a browser.
  • Why would you install a LinkedIn App? Is your browser retarded?

    • Because you're the sort of coked-up monkey that's addicted to push notifications interrupting every waking moment and keeping you up at night. It blows my mind how pavlovian some people are.

    • The OP kinda covered this in his original post when they mentioned "recruiter spam". Microsoft needs the app to collect as much personal information that it can to provide to job placement sites and job recruiters. That's how the app pays for itself, and it another good reason why you should just use the web site instead.

  • >> I went to update all my apps the other day when something caught my eye... since when does LinkedIn take up 275MB of space?!

    Use the mobile web site instead. (Closed - Solved)
    • by acroyear ( 5882 )

      oh, but then you're asking Apple users to run Javascript.

      As we saw from the post on PWAs last week, that's like asking Disney to give up its Copyrights.

      • >> (REOPENED) then you're asking Apple users to run Javascript.

        Toss Apple-branded Chinese cell phone, replace with Google-branded Chinese cell phone. (Re-Closed, Solved)
  • I've noticed this recently as well. Usually I have a 64GB sdcard in my phone, and it has 32GB internally so I normally don't notice/care. However recently the sdcard failed, and I had to make some room on my phone for music and things. So I actually spent the time to go through my apps, I was a bit appalled. I mean I got rid of a bunch that I never use, but there were a lot of apps that are very bloated for what they are. Many of which were a couple hundred MB, some of which are glorified mobile webpages.


  • Should the Farmer's Market do something to solve the inadequate quantity or quality of the produce of its vendors?
  • It's the same thing that people said years ago about programs installed on your computer. Reason why? Why should a software company, worry about the size of the code for their program, when storage space is not at a premium? People routinely have 64gb or more space on their phones, so why spend the time to tighten the code, when the space is there? Lazy coders, and or bottom line pencil pushers don't care about the size of the program.
    • Devs of desktop apps didn't care because you could always just install a larger Hard Drive. It's not always so easy with a phone.
  • The play store used to show you the app size before you installed it, now it doesn't. I would frequently look at an app and find the smallest one. Especially if it was something like a basic utility like a compass, specialized calculator. No need for an app like that to be more than 1 or 2 MB unless they've packed it full of junk.
  • I have a phone that's a year or two old which I don't really need more than 1-2 apps on because it's not my main personal phone. This phone has 4GB of total flash storage, of which 2.25GB is the Android system. What's very interesting is that when I set up this phone and my Google account, the built-in apps auto-updated and they have to use the remaining free space to do so.

    It ran out of space halfway through.

    What I had to do is turn off auto-updating, remove all the app updates for apps I didn't use,
  • On my Android phone LinkedIn is only 108MB. Twitter - 81MB., Chrome - 131MB, Facebook - 397MB.

  • It's like the super-highway effect. The larger you make the highways, the more drivers it attracts, causing drivers to change their driving patterns until it gets over-congested. Expand it again? It attracts even more. If you build it, they will come.

    In this case, the more storage space the average phone has, the less app developers will care about size. When it comes to games, the artists will go nuts adding more and higher-res images/video/music/sound effects. I worked with a company on a few iPhone/And
  • by ledow ( 319597 )

    There is zero need for that size.

    There's no way that a Facebook app contains 200+Mbytes of code that are required to render a Facebook interface. It makes me wonder what ELSE it's doing.

    Also, Facebook doesn't even contain messenger functionality, that's a separate app. A copy of Chromium, branded with the Facebook logo, with the titlebar removed, and locked to only accessing Facebook URL's, would be smaller and more featureful.

    Facebook is the one app that I have had to advice my girlfriend to remove. Bef

  • by Lumpy ( 12016 )

    Linked in and Facebook apps are complete crap written by no talent hacks. When the Mobile version of the site is significantly faster and has a better UI than your app? you fire your entire app developer team and hire some that understand efficient and fast.

  • Many apps are built with tools like Xamarin or Appcelerator which require a large run-time library. This is downloaded for each app and not shared.

    I would be concerned if native apps were of this size.

  • A lot of apps don't even need to be apps. They worked fine as a website, but the company wants you to use their app instead so they can better track you. Now multiply that by the 20-50 sites you frequently visit. One web browser with 20-50 bookmarks, vs. 20-50 apps at 5-300 MB each.

    LinkedIn is a great example. Push content (notification of contact request) worked fine over email, and could even be sent as a SMS. Pull content works fine via their web portal. Web forums which try to get you to instal
  • by l3v1 ( 787564 ) on Wednesday August 02, 2017 @11:12AM (#54925727)
    This is not a new phenomenon, it's been going on in the desktop PC world since the beginnings, and it's been going on in the mobile world since day one. I absolutely hate the trend but there's not much one person can do about it. As I see it, especially in the mobile world, there are lots of coders who use and link large libraries even for small tasks, usually don't even try to implement it themselves, and usually don't even search for other solutions or smaller libs providing the same functionality, they just stick with the first they find, and never care for the size of the apps. This applies for average junk apps as well as for large company apps like linkedin or spotify or here maps, and I could just go on. Gone are the days when efficient and small coding was the norm. And most of young coders don't even, or can't even think about writing small and efficient code. Just a couple of months ago I was given a code to use for some task, handling images, at a speed of ~14s/image, which was unacceptable for the specific task. After a complete rewrite in about two weeks I got it to run at ~1s/image, which was still slow, but at least was good enough for a proof-of-concept. And everyone was looking at me like I was some alien.

    Lots of coders prefer fast prototyping and quickly throwing together some app and spending very little time on making it small or as efficient as possible - upgrade your device/hw/PC is their mantra. Well, f*k that.
  • by omibus ( 116064 ) on Wednesday August 02, 2017 @11:13AM (#54925733) Homepage Journal

    OK, the numbers are "real" in that "that is how much space the app is taking on Apple's server". It is not real in that "this is not the size of the files being moved to your device."

    What those numbers include: Multiple assemblies for different architecture platforms. The whole 32/64 bit thing is rearing its ugly head. There are also shared assemblies, not all of which get sent to your device (because they might already be there).

    Source: I'm an app developer who has had to explain this a few times as well.

  • by ilsaloving ( 1534307 ) on Wednesday August 02, 2017 @01:03PM (#54926621)

    What exactly would you have Apple or Google or any other app distributor do?

    The fact of the matter is modern day applications are *shit*. Todays average "developer" is a glorified script kiddy that slaps a bunch of components together, adds some glue, and calls it done. And the bits that developers write themselves are so shockingly bad, that bloat is inevitable.

    I mean, seriously..... Look at Facebook for example. The Facebook App + the Messenger app takes a whopping 3/4 GIGABYTE on iOS. The Slack desktop application, as good as it is, takes up a stupid amount of resources.

    This is what happens when you lower the bar to programming to the point where any John Doe can slap some crap together and think that they are now a professional developer. This is what happens, when you push a culture of "You don't need a degree to write code!", of "young and new is always better than old and previous".

    The focus is now on slapping some crap together and shoving it out the door, than doing things properly. As long as it runs, everyone is happy. The end result is low quality, ridiculously bloated apps that are replete with security issues. This has been a steady hole that everyone has been reveling in digging deeper and deeper, and that's exacerbated by the attitude that people who have learned from their previous mistakes should be fired to make room for young people who are still deep in dunning-kruger territory.

    App sizes are just a symptom of a much larger issue: Computing in general have gone to shit, and the tech industry is happily dancing a jig in their own filth because they've so completely drank the koolaid of their own marketing that they think that filth is full of rainbow sparkles, and they ostracize anyone willing to lift their head up and go, "Wait a sec here...."

Karl's version of Parkinson's Law: Work expands to exceed the time alloted it.