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.
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.
lol know nothings (Score:2, Funny)
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)
Re: (Score:3)
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.
Re: (Score:3)
I work as a front-end and back-end Web developer. You have no idea how many times users, clients and even developers do this mistake. Somewhere, there's a tutorial about file formats, teachers, FAQs or something that teaches things the wrong way.
I call it the "JPEG for everything" syndrome. I once taught a lesson to a friend who kept doing this. One day he asked for an Excel file and I sent it a screen capture of the data, saved in JPEG at 1% quality.
Re:lol know nothings (Score:4, Insightful)
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.
Re:lol know nothings (Score:5, Funny)
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
Re: (Score:2)
Re:lol know nothings (Score:5, Insightful)
Re: (Score:3)
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)
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)
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.
Re: lol know nothings (Score:3)
This. And in order to render HTML one library happens to be an entire browser. This is the case for Electron apps
Re: (Score:2)
Re:lol know nothings (Score:5, Insightful)
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.
Re:lol know nothings (Score:5, Insightful)
It's a good comparison, except that step 6 on the Android list very rarely happens at all.
Re: (Score:3)
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!!
Re: (Score:3)
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)
Re: (Score:2)
More importantly, and I suspect the main reason for the bloat, even when
Re:lol know nothings (Score:5, Insightful)
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?
Natural consequence (Score:5, Insightful)
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.
Re:Natural consequence (Score:4, Insightful)
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.
Re:Natural consequence (Score:5, Informative)
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.
Re: (Score:2)
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
Re: (Score:2)
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).
Re:Natural consequence (Score:5, Insightful)
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 added...engineer 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.
Re:Natural consequence (Score:5, Interesting)
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.
Re:Natural consequence (Score:5, Interesting)
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.
Re: (Score:2)
"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." https://trevore.com/blog/posts... [trevore.com]
So no it's not natural consequences.
Re:Natural consequence (Score:5, Interesting)
The writers of the Halide app also went into this:-
One Weird Trick to Lose Size [halide.cam].
Re: (Score:3)
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.
Re:Natural consequence (Score:4, Interesting)
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.
Re: (Score:3)
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.
Re: (Score:2)
Precisely. Only when users solve their storage utilization problem by deleting the bloated software will it become a problem for the engineers.
Re:Natural consequence (Score:4, Insightful)
Maybe their logic is that if you are going to uninstall some apps for space you pick the one that is less useful, I don't know. It annoys the crap out of me though because if the only reason you have the app is for messaging, being able to order a pizza through one is fucking useless to me.
And while I'm on a rant, I hate the fact that more and more websites keep popping up with "It's better in the app!" and nagging you to install their retarded, badly designed, cookie cutter application when all you are trying to do is follow a link on your phone that someone sent to you from their PC.
Also, why does a torchlight application require access to my contacts? Camera sure, but contacts WTF? It's getting almost as bad as blackberry was before it died.
The laws of nature are confounded (Score:3)
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?
Are App Sizes Out of Control? (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
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)
Node.js apps are a dime a dozen these days, and they're all fat slugs of things. Sad.
Re: (Score:3)
Yep. Make the app great again!
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:3)
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?
Isn't Node.js server side? (Score:3)
App Update Size is not the same as App Size (Score:5, Informative)
https://developer.apple.com/li... [apple.com]
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.
Re: (Score:2)
Re: (Score:2)
"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)
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)
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?"
Re: (Score:2)
I remember when the good old days was a large app on a 1.4Mb floppy disk.
Same thing just happened... (Score:5, Interesting)
...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.
Re:Same thing just happened... (Score:5, Insightful)
Re:Same thing just happened... (Score:4, Interesting)
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.
Re: (Score:2)
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.
Re: (Score:3)
Take weather.com as an example. Don't give me an app with alerts that drains battery life and CPU performance 24/7. Just l
Re: (Score:2)
Take weather.com 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.
Re: (Score:3)
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 Weather.com got all bloated, I switched to Weather.gov.
Having not read the article.. (Score:2)
Absolutely (Score:5, Insightful)
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.
BACK IN MY DAY WE FIT THINGS ON FLOPPIES (Score:3)
Re: (Score:2)
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?
Re:BACK IN MY DAY WE FIT THINGS ON FLOPPIES (Score:5, Interesting)
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.
Why an app ? (Score:2)
But why? (Score:2)
Why would you install a LinkedIn App? Is your browser retarded?
Re: (Score:2)
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.
Re: (Score:2)
My browser already supports push notifications if I'm not mistaken.
Re: (Score:2)
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.
Use the mobile web site instead. (Closed - Solved) (Score:2)
Use the mobile web site instead. (Closed - Solved)
Re: (Score:2)
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.
Re: (Score:2)
Toss Apple-branded Chinese cell phone, replace with Google-branded Chinese cell phone. (Re-Closed, Solved)
Bloat (Score:2)
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.
Ho
Farmer's Market (Score:2)
Same song, different verse (Score:2)
Re: (Score:2)
Can't even tell before installing (Score:2)
Low-capacity phones get hammered out of the box (Score:2)
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,
Must be an iOS problem (Score:2)
On my Android phone LinkedIn is only 108MB. Twitter - 81MB., Chrome - 131MB, Facebook - 397MB.
Super-Highway Effect (Score:2)
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
Apps (Score:2)
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
Yep (Score:2)
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.
Runtime Libraries (Score:2)
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 these apps shouldn't even exist (Score:2)
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
fat apps (Score:3)
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.
Those numbers aren't real (but not a lie either) (Score:5, Interesting)
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.
Suck it up (Score:3)
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...."
Re:Microsoft updates / apple updates - No proxy ca (Score:5, Informative)
There is a solution for Microsoft, and it's built in to Windows server. It's called Windows Server Update Services, and it does exactly what you're talking about for Windows.
Mac OS also has exactly the same thing, called Software Update services and it's included with Mac OS Server.
Neither of these are Unix based, but if you've already invested in 1000 clients, it's pretty likely you have at least one Windows/Mac OS server for all the other ancillary things they provide.
Re: (Score:2)
And Mac OS X Server costs only $20. It's worth it for the update server and the ability to host remote Time Machine backups, even if you use nothing else.
Re: (Score:2)
Except that Apple don't provide any server hardware to run it on, so you'd end up having to buy a mac mini and some kind of stand so you could mount it in the rack, and it still has no lights out remote management capability.
For time machine all kinds of remote shares will work for hosting backups, most NAS devices include support.
It's also annoying having to buy a windows server license just to cache updates, but at least you can run that in any hypervisor.
If the updates were downloaded in a standard way,
Re: (Score:2)
The presumption would be that you have an existing Mac to run it on. For a large operation, the cost of buying hardware for this function is 'in the noise.' For a smaller operation that already has an investment in Macs, taking an older Mac, adding an external hard drive (if necessary) and running OS X Server on it for Software Updates is a wise use of existing resources.
As far as lights-out, Server comes with a remote manager that you can run on other machines (although you might have to pay $20 to get i
I dont run Microsoft I run a network (Score:2)
I run a network I dont run any Mac or windows machines they are clients of that network...
there are plenty of education facilities in the same boat, we pay for bandwidth and frankly the amount that updates take downloading the same thing is incredible
I cant run a WSUS server as the clients are not owned by us
doesnt anyone measure this ?
Re: (Score:2)
You have a choice:
- Block Windows Update
- Provide a WSUS server and insist they use it (e.g. by blocking Windows Update), or even insist they use a proxy server of your choice (Windows Update will respect the one specified in Internet Settings, for instance).
- Don't block Windows Update, and charge for your services appropriately.
To be honest, things like Apple Caching would be much more of a concern on my networks as I have no idea how they operate, how much they are transmitting, or what they are doing, w
Re: (Score:2)
Re: (Score:2)
There are and you can (at least for Apple). I once wrote my own Apple update server since we moved away from Apple hardware for servers. All you do is download an XML, parse it and download the URL's that it's telling you to download. Then make them available with Apache or nginx.
Not sure about Windows, from what I understand you need Windows Server ($500-6000) and then set up WSUS and then have an Active Directory. Ever seen the WSUS interface? It's absolutely horrid and the organization of updates makes n
Re: (Score:2)
> why are their no unix/proxy/gateway solutions ?
The Open Edge Content Distribution Network, TOECDN, has been developed for exactly this.
The whole purpose of TOECDN is that you, as a end user, can setup a cache server at your home, to be able to cache software updates like this. And its not just for software updates. Its for all static content.
The thing is, nobody care about this solution.
Re: (Score:2)
Re: (Score:2)
Why would we need the source? The app is a folder of files. app code separate from libraries and assets. We can see from that what's taking up space. We can't see if from looking at the source.
Re: (Score:2)
Yep, I will dedicate years of my life analysis the source code before I use the app. I might as well write it myself.
Re: (Score:3)
I'll give you the source code to systemd. You tell me what it's doing.
The "open" system is an absolute myth anyway. You have no idea what your computer is actually doing, no matter what it is or where it was bought from. Even the "open" / "coreboot" laptops do things like apply closed-source Intel microcode updates to the processors on boot or they wouldn't work properly at all,
Re: (Score:3)
how one achieves being a parent without a child?
People can die before their parents.