I think it is unlikely that most people care and the improved analytics and development speed is probably worth it. My android is connected to wifi almost 24/7, so it doesn't matter how long it takes up update.
Yeah it is a problem, and so far the way most companies fixed this issue is by releasing a 'lite' version which of course is probably not feature complete but will be significantly faster to update and load.
If you are on a good network you probably won't ever notice such bloat until you run out of disk space or bust your download limit (Canada)
If I find an app to be too big for my taste I normally fall back to the web version if it exist at all but even then its hit or miss because sometimes the web app is pure complete garbage or worse than the app itself.
It's really amusing to me when "engineers" start talking about the "scale" of the UI. It's a client. Thin vs. Fat aside, if it's that fat it's almost certainly a bloated mess of redundancy and what is called "overengineering" (which is actually underengineering--that is, a deficiency of the application of engineering and architecture principles to the design of the application).
I had a friend who quit working for Facebook about a month before that slideshow was published, and it was hilarious to see her mock it so mercilessly. She estimated a good 40% was completely dead code, and another 20% was partially dead code (e.g. code for notifying people of "pokes" without any mechanism to view them). She also had some choice words for the engineer who published the slides, but those can mainly be pieced together from the general mockery on Reddit and hacker news.
It varies, but for most apps I'd wager it's library bloat, but in my experience doing iOS dev here are the common culprits:
- For games assets are a big issue. Some do not compress their assets, and unfortunately most image-authoring tools make it easy to output PNGs that are much larger than they can be. I think a lot of people by default assume bloat comes from images/icons/etc, but IMO this is a red herring for most non-game apps.
- Library bloat. Even simple apps pull in a large number of external dependencies, which contribute dramatically to app bloat. There's also a lot of code pulled in that replicate platform-provided functionality (see: the bajillions of layout libraries out there), which may be simpler to use than the stock Apple components, but add to your bundle size.
One of the common problems is that iOS open source dependencies are typically all-or-nothing - you end up pulling in a very large library even if you're only using a small slice of its functionality.
I think most disassemblies of iOS app bundles show that library bloat is typically a far larger problem than asset bloat.
In any case, I think the future will be something like Android Instant Apps - where apps are sliced up such that necessary bits can be downloaded on-demand. This gets users into apps faster, and saves space.
How so? The scenario being modeled here is a user who wants to use an app but does not already have it.
The status quo is that they must download a 150MB bundle before being able to proceed.
The proposed app slicing will allow them to download maybe 10-20MB before being able to proceed, with additional components (up to the 150MB total) downloaded on-demand.
If the user is on an intermittent or slow connection this is still a significant improvement over the status quo: the user gets into the app much more quickly.
Additionally, if the user only uses a small slice of the app's functionality (which is the 90% use case), additional downloading can be deferred until the user connects to wifi, at which point the rest of the app can be downloaded over a fast and reliable connection, all seamlessly without the user having to worry about it.
Apparently, Crosswalk [1] for Android adds "only" about 20MB.
I just compiled a Cordova-based Android-app without Crosswalk, but also without images. Just JavaScript, HTML and CSS and a few plugins and the APK is < 3MB. Was quite surprised by that.
I think a few more years and we can finally stop bundling browsers. It's not like anyone wants to bundle a browser inside their app for fun. That being said, Crosswalk really solved some serious issues for my product so cheers to them.
Yeah, I used it a year or two ago, and it was nice for making sure the experience was the same across all Android devices. Glad to see the built-in Webview is getting place.
There were a few articles with actual content on this topic covered on Daring Fireball in recent months. Not sure what this blog blurb is adding to the conversation.
Yea, I wasn't trying to think too hard about the subject, I know there are many excellent posts out there already (like those linked above) that go into detail. I only wanted to show some actual download numbers to demonstrate how absurd it has become. Linking those other articles is a great idea, thanks for the feedback!
That second link about the FB app is hilarious. As an example, there are 3 copies of a 3.6 MB binary file used as part of an optical flow algorithm (likely for 360-degree videos)
So it's not just that there's a bit of sloppy (or pragmatically careless) packaging, but there's just a lot of stuff in these apps.
Short a major customer outcry, Apple is largely incentivized to not fix this—
(1) They substantial profits from memory upsells on their product lines
(2) Larger apps take more horsepower to run— so older models become less effective sooner!
I highly doubt that. Few people actually know how big any given app is. Plus, there are more compelling things keeping people on their platform of choice, like iMessage or the sunken cost of apps that they've already purchased.
+1 for this. I think 16G iPhone6 exists to promote sales of models with larger memory. Now I have to uninstall an app to install a new one on my iPhone(16G), EVERY TIME, it's painful. Next time, I will definitely go for 64G.
Once upon a time I deleted music and videos from my phone to make room for newer music and videos but nowadays I catch myself removing apps. Not because of the space they are using but because of the app size itself. A once removed app is unlikely to be reinstalled.
I was comparison shopping something this week and wanted to check Best Buy, so I went to the app store. 100+ MB and needed to be on wifi to download. What in the Best Buy app could be over 100 MB?
On another note, I just went to check some of my apps and iOS 11 got rid of the size from that view. You now need to dive into each app to see the size.
This is faster than the app for me. My main problems with the app are a) it was pre installed so can't be moved to SD card, b) not only does the app include a snapchat clone I don't use, but it stores 100s MBs of user data too, c) it tells me I have messages, but that requires more 100s MBs to read in another app with another 100 features I don't use.
If you're on Android, you can try SlimSocial for Facebook + Notifications for Facebook, both available through FDroid. 223 KiB and 103 KiB respectively.
I never understand where this increasing size comes from. For videos or hi-res photographs, I understand.
There is however no reason that code, either compiled to a binary format or in a textual format, uses so much data. Heck, the memoirs of Casanova spans 3000 pages, and is 6,5 MB. People don't understand how incredibly large a megabyte is for simple code.
Surely the 275 MB isn't all useful data (I wonder what compression ratios you get on 'apps'), and it should be possible to cut it down to a few MB.
Could it be that whenever coders today need some fairly trivial functionality, they tend to go out and find a library that contains it. So you end up with lots and lots of libraries where only a tiny bits of them are used. Just a hypothesis though.
Leftpad is not an example of the issue mentioned. Leftpad is an example of a small module that was being used by a lot of projects. GPP is talking about pulling in larger libraries which contain code not actually used by the app.
(Also Electron bundles 'just the rendering library from Chromium' [1], not 'all of Chrome').
Well it wasn't that you weren't being specific, more that you were casually maligning the JS community unfairly, when the article isn't even about web/JS :)
(I also don't agree with 'don't need to'. The main takeaway from the leftpad debarcle was the fixes to the npm module deletion policy, and hopefully people learning they shouldn't rely on an 'npm install' for production deployments! Whether people should use small modules is still up for debate, there are trade-offs [1] [2]).
There are many reasons why apps are so big, but I think you are right about a major part of the problem. Development environments these days make it very easy to add in third party libraries for very little effort.
At a previous job we had a monolithic java server that ended up at over 350Mb of compiled code simply because each development team had imported whatever libraries they thought they needed. In some cases, 2 or 3 versions of the same library were included.
How did they get multiple versions of the same library to work together? Java loads things via the class path so I would have thought that would cause some sort of error.
Some libraries change the namespace (package names) between major versions, specifically to allow transition from one to another in a gradual manor, or to start following namespace guidelines better.
Most of it is actual code - not assets. For some types of apps (see: games) assets do take up a significant portion of total size, but for most everyday apps bloat by code over-inclusion is likely a bigger problem than asset-bloat.
I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality.
> I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality.
Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool like Webpack to throw away what isn't used.
I don't think that's the right solution to the problem. Nobody wants libleftpad.so, and as someone who works on a distribution the very concept is horrific (making distribution packages for every three-line package does not make anyone happy).
What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link time not build time -- otherwise you still have the same problem).
Young minds don't like it when someone questions the wisdom of how they reinvented the wheel, even when the question comes from confusion instead of malice.
Maybe you're not familiar with how it works. The idea is that you do, let's say, "import lodash" then your packaging system says "A-ha! But you're only using these 5 methods!" and only packages those.
Behind the scenes, lodash is built out of many modules, but you as a developer don't need to think about that.
Because tooling isn't perfect yet, you have the option of helping it out manually and being explicit about importing submodules. We were able to reduce our compressed JavaScript size by some 60% using a combination of automatic and manual tricks like that at my day job.
Right, but from what I've seen (though I'm not a JS developer, so I might be wrong) is that most projects are not designed like lodash. They are small, single-purpose libraries that would be much better served as part of a module of a larger library. That was the point I was trying to make with the whole "libstring" and "libleftpad" point.
I've seen people try to package JS projects inside a distribution. >800 nested dependencies is simply not sane nor sustainable. The fact that they're small is even less excusable because it means that there was an active decision to not consolidate them into a single dependency that is properly maintained.
JavaScript people do not create libleftpad.so, they create libleftpad.o (metaphorically speaking), which will not clutter up your distribution, it will just clutter up some apps. I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries.
But I agree with what you're saying in the second paragraph, which actually sounds just like what my GP meant by using "Webpack to throw away what isn't used". Having unused parts of larger libraries cut out would be a much cooler solution than just telling everyone to eschew kitchen sinks in favor of many tiny, bespoke items. Especially since finding the right small libraries is much harder than finding a kitchen sink that just works and has a sizable community behind it
> I'd rather see 50 little files like libleftpad.o than 5 gigantic libraries.
And then you'll have to use software written in 50 different styles, with 50 different type and error conventions, with pieces that couple together or not at random.
> And then you'll have to use software written in 50 different styles, with 50 different type and error conventions, with pieces that couple together or not at random.
All of which matters not one hoot to folks _using_ the software.
Right, and most people could have much more free space on their phones (or, more apps). I'd much rather write some glue code than ask my users to dedicate 275 MB to install my app, not even counting cached data or anything else. There's a reason many of my friends and I have deleted apps like LinkedIn - it's not that we don't like them, it's that the the apps were too big for the little value they gave us, especially when considering the web versions give us almost all the same capabilities, and only cost a couple KB of persistent storage (cookies + history + maybe some localStorage or whatever).
> which will not clutter up your distribution, it will just clutter up some apps.
Not necessarily. Distributions have to build everything, and in openSUSE we have an integrated build system[1] which has a lot of very useful features (rebuild when dependencies are updated, and automated QA runs before releases). Those features require you to have all of the dependencies of a project in an RPM package. Even if you don't end up shipping that package, the package is used for tracking security issues and backports and so on. You can't pull anything from the internet during a build, you have to depend on your BuildRequires.
Now take any average JS application that has over 800 dependencies. Ruby was already bad enough with ~80 dependencies, but adding another order of magnitude is just not maintainable. One of my colleagues gave a talk at LCA about this problem[2].
I had no idea about this - thank you for bringing it up! But we seem to be discussing different ideas. I was trying to argue about apps, specifically iOS apps, like the original article was about. iOS apps aren't distributed on openSUSE, so if some devs make some kind of libleftpad.o for Objective C developers making iOS apps, I'm saying that's fine, and I doubt it would clutter up your distro because Objective C isn't exactly known for it's cross-platform adoption :)
If we're going to talk about linux packages, aren't they often written in languages with amazing optimization skills? If I write some C99 code that uses a gigantic library but I only use like 2% of it, my compiler will cut out the 98% my code doesn't use, so libleftpad sounds like an awful idea. That's one reason why packages on linux distros aren't too big.
But I'm talking about iOS apps where, as others have pointed out, the available optimizations suck[0], and as such, I think that having libleftpad.o included in everyone's iOS apps isn't a big deal (note that iOS doesn't really have a nice way to create libleftpad.so anyway AFAICT because all code for your app is supposed to be sandboxed so no one else can mess with or use it). I agree that it would be really cool to just cut out the 98% of $GIGANTIC_LIBRARY that isn't used at compile time, but since Objective C doesn't seem to have that now, I think small things would be a really nice way to give users more space on their phones without removing features.
Ah okay, I was talking about things like electron applications or desktop/server javascript projects. If you want to use $latest_js_web_framework and package it in a distribution, you're going to be in a world of pain (the same applies for Rust because their package management was based on NPM).
If you want "just pull in the things I use" you can already get that by having a static library, and if you were going to be shipping a private copy of the .so file in your app then surely you would be better off with a static library -- you don't get any of the benefits of the DLL (sharing with other apps, can update the DLL without shipping a new copy of the whole app), so why pay the cost of it?
(If you link against the static library then the linker pulls in only the .o files that the app used, so assuming that the library was written in a sensibly modular way you pay only the binary size cost for more-or-less what you use. The linker can probably discard at a finer granularity than whole-object-file these days, but only-the-.o-you-use has been there for decades.)
Probably only widely used static C library with fine grained dependency tracking is glibc. The source code structure required for that is probably one of the major reasons for people to call glibc's source code unreadable and/or unmaintable.
Depending on how they are made, how the linker is configured, and the phase of the moon, static linking can help by just taking the required functions.
Also I think we, as programmers, have taken the "don't reinvent the wheel" principle too far. The idea is to use 3rd party code to (1) save time writing, (2) reduce the risk of bugs, and (3) lower the maintainance burden.
But this makes sense only if the benefits outweigh the corresponding costs of integration, which also (1) takes time, (2) might be done wrong (especially because you don't understand the part you added), and (3) creates a maintainance burden. Of these, only #1 is solved when your development environment makes adding new libs quick and easy.
Depends on the language. If you're using something like C++, you can probably remove a lot of dead code. But with more dynamic languages, like Objective-C or Ruby or JavaScript, it becomes difficult or impossible to prove that a given chunk of code is never used. In Objective-C (which I'm most familiar with), the linker will keep all Objective-C classes and methods because it has no idea if you might be looking things up by name at runtime and invoking them that way.
Even if you can throw away dead code, you can run into bloat because a library has a massive set of foundational APIs that the rest is built on, and using one little feature of the library ends up bringing in half the library code because it's used everywhere.
You could use static analysis to find out if anything calls objects dynamically by name at run time which could be a useful optimization. To be safe this would be one bool value for the entire code base, but with some care it would help. A larger issue is size is simply not considered a significant issue.
With Objective-C, that will always come back "true." Even if you never use dynamic lookups, Apple's frameworks do. I suspect the same is true of other languages.
Nibs and storyboards are full of this stuff. They instantiate classes by name, call methods by name, etc. Some example documentation if you're curious:
Objective-C's dispatch is built around looking up methods by their selector, which is effectively an interned name. Looking up the selector can be slow, but once you have one, invoking a method using a dynamic selector is as fast as invoking one with a selector that's known at compile time.
> Interesting, I find that surprising due to the overhead involved.
Due to the frequency of this, objc_msgSend (which handles dynamic method calls) is hand-written in assembly, with caching and "fast paths" to improve speed. The overhead can usually be brought down to that of a virtual function call in C++.
That's the thing about performance. If you do something a million times, it's usually OK if the first time takes a thousand times longer than the fast case, as long as subsequent times are fast.
Look at how much code is written in Ruby and Python. Their method dispatches are way slower. To put it in perspective, it takes CPython about an order of magnitude longer to add two numbers together than it takes Objective-C to do a dynamic method dispatch.
The interesting part of this is that all this dynamism and dependence on runtime actually improves performance in comparison to C++. For example it is perfectly possible to implement objc_msgSend in portable C such that it is on modern superscalar and heavily cache dependent CPUs on average faster than C++-style virtual method call.
Really? That seems highly unlikely, and doesn't match with any of the speed testing I've done.
When you get down to it, an ObjC message send performs a superset of the work of a C++ virtual call. A C++ virtual call gets the vtable pointer from the object, indexes into that table by a constant offset, loads the function pointer at that offset, and calls it. An ObjC message send gets the class pointer from the object, indexes into that table by a constant offset, loads the method cache information at that index, uses the selector to look up the entry in the cache's hash table, and then if all goes well, it loads the function pointer from the table and jumps to it.
Depends on if you're statically or dynamically linking. When statically linking the final binary shouldn't contained unused functions from external libraries.
This happens a lot, especially with dynamic linking. I have a project that uses Qt, OpenCV, CUDA, PCL and VTK - fairly standard stack for 3D imaging and visualisation.
Since you normally need to bundle dependencies to account for different versions, this adds up quite fast. Qt adds 20MB for OpenGL, 15MB for the VC++ redist, about 30MB for other core libraries. Some stuff in OpenCV requires Nvidia's performance primitives (NPP), so in goes nppi64_80.dll - that's 100MB alone. opencv_cudaarithm310.dll is 70MB and even opencv_imgproc310.dll weighs in at 30MB. And on and on.
So yes, one little call to cv::cuda::remap adds in a boatload of dependencies when all the algorithm is doing is using a lookup table to sample an image.
It's pretty ironic that dynamic linking's main motivation was to eliminate duplicate code and reduce code size. Deploy a DLL once, every software uses it and doesn't have to include it.
Now it has turned out exactly the opposite way. If we went back to linking object code together we would get smaller sizes. Instead we have to include huge DLLs.
> dynamic linking's main motivation was to eliminate duplicate code and reduce code size
I'm pretty sure the main motivation is/was to allow patching of dependencies independently from applications. Very popular shared libraries might save space overall, but that is a secondary effect.
I had a fun time with this once. The Jetbrains Toolbox app is written using Qt and is 150mb. I opend the .app package on mac, deleted the frameworks directory, and symlinked it to my system's Qt install.
They seem to build it against a reasonable version of Qt, I haven't updated it in a while (because it's just a launcher), and when I do I'll just re-symlink against whatever Qt is currently installed (which I do keep updated)
I understand your argument, but in this particular case things aren't volatile enough that it causes any problems, and if it does it's just as easy to solve.
As I understand it, when you link your binary, the linker will only include the used parts of the libraries. Linking to a 10M library but calling only one function will not increase your binary size by 10M, probably just a few bytes.
A huge chunk of that probably goes to, well, videos or hi-res photographs to be used in building the UI. Hi-res splash screens plus a bunch of hero images plus 2+ prerendered sizes of each display element for different pixel densities plus a dozen 30 second tutorial videos can easily add up to a couple hundred megs of assets alone.
I think a large factor is the ever increasing need to have different display sizes for different pixel densities, developers essentially have to create and package a couple versions of the same application into one package and that is alot of waste.
At least in the context of this article (iOS app bloat) this is no longer the case - developers upload all assets for all pixel densities, but Apple repackages for each specific device, so that each device only gets one set of assets. Same goes for binaries for multiple architectures - each device only gets the binary for its specific CPU architecture.
Also to the GP's point - Apple also now no longer supports splash screen images, so that element of bloat is no longer a factor (though some legacy apps have retained them pointlessly).
I think for non-game apps assets are not the primary driver of bloat.
The worst part is that they probably use huge PNGs to make sure the flat graphics are clean. You know, the kind that are perfectly suitable for vector graphics.
Unless your graphic designer provides you with vector graphics embedding a vector for each pixel of the rasterised image of the original vector graphic.
That's almost as bad as the autogenerated SVG I once was sent that used hundreds of thousands of think horizontal lines to fill an area. Instead of, you know, a filled polygon.
The sheer number of vectors could make any renderer I threw at it crash.
Lots of things. Most companies now have huge development teams and that means that you're going to get a lot of duplicate and triplicate media assets. Duplicate and triplicate static libraries and frameworks (which Apple is trying to address with it's new dyld improvements[1]). As you also can't forget all of the analytics and A/B testing frameworks that are put in place. Each one of these apps can actually probably run 100^2 permutations of the app.
>Surely the 275 MB isn't all useful data (I wonder what compression ratios you get on 'apps'), and it should be possible to cut it down to a few MB.
This is pretty tone def. The bulk of apps are audio and ui assets and the compression rates on those are quite good.
That said, the compression rate for iOS apps is horrible as Apple decides to encrypt and then compress the binaries, completely blowing apart the compression ratio of duplicate data.
When I was developing a few pet apps, the reason was pretty simple. I was pulling in entire libraries for one or two functions. They were good libraries and good functions. I think multiple examples were Google-provided app development libraries that you roll into your app. Like, appcompat. Nobody can get by without appcompat anymore it seems, but nobody needs all of its functionality either.
Anyway, probably millions of lines of code, 99.9% of which I didn't call. There is a tool for stripping code that will not be called, and I reduced my apk's from ~20MB to ~1MB, although I wound up turning it off in the end because it was not trivial to enable correctly. (I was linking 3rd party binary libraries into my app which complicated things)
Normal apps are around 10 to 20mb, which is still big. But the reason for this is support for different screen resolutions. Images of different sizes are bundled with the app, even though the phone only needs on of them.
Vector graphics will solve this, but is not mainstream yet.
The facebook android app is 88MB (zipped), i did check the APK of why its so big:
90mb of code
30mb of assetes (javascript, metadata, librtc, big json files (animations))
30mb of resources (images)
Yep, agree with the image bundling issues. We have tried to keep our footprint as small as possible in our own product (3D modeling application https://3dc.io) and are clocking in at 8mb on iOS. Out of that about 3MB are icons/splash images and other media. Regarding vector graphics, we couldn't use them, as they cause bugs and flickering with css animations in iOS Safari. But we do generate everything we can procedurally (primitives, colorpicker etc.) which saves a ton of space.
You're entirely right, but "it is difficult to get a man to understand something, when his salary depends on his not understanding it" certainly applies to the entire "tech" industry, and the app factory in particular.
I expect this realization will only become widespread when open-source folks actually fix their software's deep-seated usability problems. The way to do that is not by hiring UX designers or appifying it; it's by thinking deeply about how humans interact with computers and blowing away the conventions that make computers and software unforgiving, hard to explore, and opaque to the uninitiated.
Objective-C has fully dynamic dispatch. In a context like that, generics are just a type safety thing to ensure that you aren't sending messages to the wrong type — they don't make the executable any smaller.
They make code reuse possible. Watch this Sean Parent video https://www.youtube.com/watch?v=4moyKUHApq4 where he estimates that if Photoshop was rewritten using generics, the code size would go from 3,000,000 LOC to 30,000 LOC. You are right, during compilation, generics are specialized so you end up with code, however going all in on generics removes a lot of accidental complexity.
I think you've misunderstood my point. What code reuse is possible with generics that is not not possible in Objective-C without generics? I don't think there is very much, because Objective-C fundamentally doesn't care the types of objects.
The full answer would be kinda long but this is a rehash of the debate that has been had many times over.
You cannot just compare obj-c vs generics, you need to also account for the fact that when you are obj-c development, you might need some fast code and as a result drop to c. And code reuse is hard to impossible in C.
The fact that code reuse can be done without a performance hit is enough of a difference difference on it's own as it pushes down the level at which code reuse can be done. E.g. you can use generics for Graphics or Audio or general low level stuff.
Interesting talk. If he's right, then a Photoshop clone ought to be doable. 30k LOC is doable for a single person or a small team. I'm guessing that even with generics, it wouldn't help that much. Also, I think there are probably a lot more algorithm LOC in Photoshop than he thinks...
That has nothing to do with code size. You'll either get some sort of type erasure, which will create the types are compilation time anyway, or you'll have some sort of dynamic dispatch. Neither approach will make the generated code any smaller and may even make it bigger.
I remember when apps used to take less than 4k of memory, because 4k was all the RAM in your computer.
Then I remember downloading a 3 MB mp3 on my 9600 baud modem and being amazed at how much space was taken up by music that sounded realistic and not like just a bunch of beeps out of speakers that could only make beeps.
Then came the old joke about EMACS standing for "Eight Megs and Constantly Swapping".
Then I remember noticing that commercial software like games filled up a full CD's worth of space (back when software was distributed by physical CD's). After that it was common to ship software as multiple CD's, then multiple DVDs.
Now, is software even shipped on DVDs anymore? I just download everything, and, yeah, apps are still bloating, same as ever.
That's cool that you can afford $500+ for a phone.
But the rest of us just want to use a phone with a couple apps. We can't afford phones like that, and high market-share apps shouldn't be designed for the top 1% of phones owners.
If Facebook wants people to use their shit, they can't design it solely for early-adopters.
You're typing from a first world country where there are not huge cellular costs or speed limitations. If you go to other countries, even say, Botswana, the option to download over a gig in apps every (other) week isn't cheap. Bandwidth costs.
As a Canadian, to get 2.5 GB of data from a larger cell phone company costs me over $100 / month (there are smaller companies that will reduce that, but still, it's little data for quite a bit of money). I'm very happy I can force things to download only over WiFi.
It should definitely exist, but Apple's one-size-fits-all approach is pretty dumb. It ought to be configurable. The 100MB limit is way too big for someone on a really limited cellular plan, and way too small for someone on a high-end plan.
Folks: there's a built-in technology on your phone that allows you to load and run an app on-demand over the internet without dedicating any internal storage at all! It allows clean integration with many of the "native" features you expect like camera and notification and timers and stuff. And it's based on completely open standards with multiple, competing open source implementations.
No, seriously: uninstall that junk and just run stuff in the browser. It works much better than you think, the biggest annoyance being all the nag screens sites throw at you to get you to install their apps.
the biggest annoyance being that these are even less integrated and fine tuned to the environment than all those bloaty corporate apps. The best apps still are made by small indy developers, feeling right at home in their OS. Take for example Instapaper, Fantastical, Outbank, Due, Reeder.. You just can't make web apps so polished, so well integrated into the OS..
I'm afraid it's exactly as bad as I think. I use web sites instead of apps whenever I reasonably can, but most stuff I use frequently is much better as an app.
Facebook in particular likes to break their web apps to push you to use the native one. If you ever need to use Facebook in the browser try mbasic.facebook.com(it even includes their messenger).
Thanks, but we do have smartphones and we are aware of this thing called browser. We are also aware how it works.
Not "much better" for sure, if better at all.
Well that's your answer to your question. You forgot to optimize the images, because with your test environment, you don't notice it.
If you were testing over a dial-up connection, you would notice it.
Same with app writers. They forgot to optimize their app because they're testing it on the latest and greatest phones on their home network (or a corporate network which is blazing fast). If they tested on a low-end phone, and actually performed the update themselves over a slow cell network, they'd probably notice it.
Many common tools aren't set up for common-sense optimization. Ideally resizing images would be an automatic step, and you wouldn't have to remember. But that's not the case.
I'm sure that there are plenty of iPhone apps with 2 MB images from a camera, when a 256 KB image would do.
Sure, but the apps the blog talks about aren't two-man teams. And some of these firms were already touted as dogfooding their apps under resource constraints-
I used to work at a shop that ran a 1.5 mbps dsl line, and a ~5 year old, cheap, slow computer. If their code worked on that, it would work on any of our customer's machines.
I wish devs would still test like that. Sure, your app works fine in downtown SF on the newest phone, but try using it in Nowherseville, TN, on a phone that is more than a couple years old. I bet a lot of user frustration comes from dealing with that.
The Spotify app is dog slow on a Samsung S8+. Do you know how ridiculously overspecced this phone is and it can't load a Winamp clone with a terrible UI!
Hell, all of Android is far, far slower than it should be. I won't move to iOS but what Apple can do with a dual core phone is pretty amazing (and yes, I know that newer OS builds get slower).
I really wish android came with better tools to let you know what is bogging down the machine. If only they hadn't gutted the linux part of it, we could have much better tools at our fingertips....
Does anyone know of a good process-viewer/resource watcher for android?
Google killed all of the outside tooling by messing with their own variant of IntelliJ and build system. (Especially the latter. Eclipse plugin for gradle w/ android support is hopelessly incomplete, killing eclim which was the one reasonable code completion software.)
Apparently writing an IntelliJ plugin of a reasonable quality is much harder than a Python or other script. Who would have thought. And a glorified text editor takes GBs of RAM, likewise a glorified Makefile.
(The resource watcher is built into Android Studio, but ignores GPU memory. To do that you have to run GPU debugger, a separate memory hog.)
> Sure, your app works fine in downtown SF on the newest phone, but try using it in Nowherseville, TN
Granting that you heavily imply a 4G connection, the choice of "Nowherseville, TN" is extremely interesting: Chattanooga, TN — which as a Tennessean I feel is essentially "Nowheresville" to most non-Tennesseans — has Internet service multiple orders of magnitude better than most of the Bay Area[1]…
Images do not seem to be the biggest culprit (unless you already fixed them).
I see 200kB of images and 600kB of javascript (most of which comes from disqus)
I can see how high-res pictures embedded in the app can add dozens of megabytes, and maybe a different runtime that you have to bundle for compat reasons, but multiple hundreds of MB?
The lack of a stable ABI means that the Swift runtime libraries have to be bundled into the apps, which accounts for around 10MB of bloat. Unfortunately, 10MB is almost unnoticeable on the scale of bloated apps these days. Does Swift do anything else to make apps bigger?
There is a reference to django.css in the source, assuming you meant the style. As the blogging engine wouldn't necessarily dictate the cleanliness of the look.
The only real solution I can think of would be if apple actually incentivized app creators to reduce their size. They are actively harming the Apple ecosystem by preventing users from having a large number of apps which hurts Apple.
* Charge owners a fee for apps over a certain size "a processing fee" or whatnot
* Charge owners a fee based on the download costs. Under XMB and it is free. The more you cost apple to transfer your app to their customer the larger the fee.
* Penalize large apps in the app store search results or give bonus to smaller apps.
Or rather than straight up bonus's / penalize apps based on size go after specific things that cause bloat
* Apps that don't use pngcrush on their png's
* Shipping wav files and not acc
* ...
Maybe Apple doesn't even need to actually implement any of these, but just threaten to.
Most of the time it's the same reason why web pages are MBs in size today: lazy developers that uses a new library for every feature they need, without a deeper analysis of costs and benefits.
Not only, there is IMHO also a "technological supremacy" bias.
Quite obviously most developers will have:
1) VERY powerful hardware
2) VERY fast (and unlimited) internet connection
It's not like (they should do it as part of quality assurance or similar) they take a car, drive in some remote countryside, possibly in the middle of nowhere, stay there a couple days and try accessing their website (or running their app) on the lowest/cheaper entry level hardware on a metered connection.
It's easy when you have a T1 or faster connection on a recent top-hardware to forget how a lot of other people have slower devices, with less memory and limited bandwith and metered connection.
I wouldn't be surprised if half of the outrage about file sizes simply comes from the fact that there are people who remember what software was like before all of this "technological supremacy" was a thing. People joining the workforce today didn't grow up with the experience of installing something off of seven floppy disks, which would have been considered an emormous program before the CD-ROM drive was common. They also don't know how much better those programs run, because they had to do so with 8 MB of memory or less and nowhere near 1 GB of hard drive space.
I've watched entire episodes of anime in RM format in highschool that were smaller than the majority of apps these days. Not just smaller, but like... a 4X smaller or more.
The Phillips Sonicare Kids app, which is nothing more than a simple game for kids to track brushing their teeth, is 245MB.
I guess the good thing is that it gave me an opportunity to teach my kid about tradeoffs. "Ok, so if you really want this app, we're gonna have to delete 4 of your other games on the iPad." Even a 5 year old could reason his way out of that one.
this incentive analysis is so shallow it doesn't pass first muster. does fitting/selling more apps make Apple more money? are storage and bandwidth expenses? do users value performance? most people here seem to agree more bloat = less users.
Except they have been working on it, by repackaging apps to strip out unneeded assets.
And it is in Apple's interest to have smaller apps, because then people will be able to download more apps. They'll be willing to try more apps, because there will be less of a barrier between seeing the download button and being up and running.
Plus Apple likes shipping lower end/cheaper devices to people who won't buy the high end.
When your low end configuration is hard to use because Facebook takes up 29% of the storage... that's a problem. Customers get mad.
When they can't update Facebook because it wants more space and the device is full and now the user is locked out from their friends... customers get mad.
When updating a handful of apps uses up 70% of their monthly data... users get mad.
While that sounds like a clever trick that Apple could use, they really want to minimize production costs and maximize utility for consumers. Their profit margin comes from a share of that surplus utility.
I suppose it can help hide price increases of the next higher configurations, such as when the base configuration of the MacBook Pro decreased from 256GB to 128GB between 2016 and 2017, with the list price for 256GB configurations increasing by a couple hundred dollars. However, Apple has also gone as far as developing an entirely new filesystem to decrease storage use.
I have been replacing traditional apps with PWA's or mobile websites wherever possible (on Android). They hardly take up any space and also seem to behave well (drains less battery) compared to traditional apps.
I could replace the following with PWAs:
- Twitter
- Uber
- Lyft
- Google news
- Instagram
- Flipboard
- Shopping sites like Walmart, Wish
and many more.
Facebook and Amazon have no PWA's but have mobile websites. (Facebook mobile web works well with Opera. On other browsers it annoyingly redirects to play store to install messenger)
Progressive Web Apps - basically HTML5 web sites that work well on a phone, and take advantage of some newer browser features to make a web page more "app-like." Not sure if there's a distinction to be made between PWA and Single Page Applications (SPA), but in either case, you can use Service Workers, local storage, offline mode etc as well as "app" features like notifications and a homepage shortcut. The experience ends up being very much like that of an app, without a huge install.
So sounds like the promise of web-based "apps" from pre-app store iOS to WebOS to Firefox OS... finally about to be realized thanks to official Google backing. RIP to all the minor players who came before and failed.
I think that's a fine solution, but its looking at the wrong problem.
Consider an app like Discord [1], which is built using React Native and is thus a "native" app with some additional cruft like a JS runtime. It clocks in at a relatively small 30mb. Not bad.
Then consider Slack [2]. For nearly intents and purposes it does the same exact thing. Discord has far more functionality than Slack. Yet, it is 129mb.
Tweetbot [3]? 12mb. Twitter [4]? 204mb.
The issue has little to do with the technologies used. PWA, React Native, full native, it doesn't matter. The issue is truly that these large companies have horrible, bloated engineering teams and that bloat comes through in the size of the apps produced. It is Conway's Law in action.
I've been doing this too; but annoyingly I usually am in Private Browsing mode and when I go to launch one of these apps it doesn't work because I'm no longer logged in.
Well here is an application that defies your approach: the Android clock. 17Mb update to that just now, vanilla android. Plus Google do some diff. style updates so that is probably a lot more and for a clock. Presumably it has 17Mb of updated alarms in surround sound and presumably these are needed however I can't see any other obvious bloat potential as the clock should use Android UX.
How can a clock need the equivalent of a box of floppies? Windows 3 and 3.1 together comes to the same Mb and that comes with a clock.
I can say that I use it accidentally without realising(at first) it was a PWA website. So, Im just gonna tell it in layman term.
From what I can tell, its a website, but definitely felt more like an app rather than a website.
the best way to understand it is just to try it. Its just a website(PWA) pinned to your homescreen, so theres not much cost to try it.
PWA apps can run from home screen without address bar, with splashscreen and you can use things like ServiceWorkers (some things can run in background, better caching/storage, you can even run your app offline showing information/data/whatever from last time you synced with backend server).
453 comments
[ 3.5 ms ] story [ 285 ms ] threadCode bloat = lost users
code bloat => "your phone is full" => "oh, my phone is too old" => new iphone => free space => code bloat
That said, I also delete bulky apps before I start deleting media.
If you are on a good network you probably won't ever notice such bloat until you run out of disk space or bust your download limit (Canada)
If I find an app to be too big for my taste I normally fall back to the web version if it exist at all but even then its hit or miss because sometimes the web app is pure complete garbage or worse than the app itself.
It's really amusing to me when "engineers" start talking about the "scale" of the UI. It's a client. Thin vs. Fat aside, if it's that fat it's almost certainly a bloated mess of redundancy and what is called "overengineering" (which is actually underengineering--that is, a deficiency of the application of engineering and architecture principles to the design of the application).
You're not allowed to include your own browser, and can only use the platform's web view, which is not duplicated on a per-app basis.
There are many culprits for app bloat, but using a browser is most certainly not one of them.
- For games assets are a big issue. Some do not compress their assets, and unfortunately most image-authoring tools make it easy to output PNGs that are much larger than they can be. I think a lot of people by default assume bloat comes from images/icons/etc, but IMO this is a red herring for most non-game apps.
- Library bloat. Even simple apps pull in a large number of external dependencies, which contribute dramatically to app bloat. There's also a lot of code pulled in that replicate platform-provided functionality (see: the bajillions of layout libraries out there), which may be simpler to use than the stock Apple components, but add to your bundle size.
One of the common problems is that iOS open source dependencies are typically all-or-nothing - you end up pulling in a very large library even if you're only using a small slice of its functionality.
I think most disassemblies of iOS app bundles show that library bloat is typically a far larger problem than asset bloat.
In any case, I think the future will be something like Android Instant Apps - where apps are sliced up such that necessary bits can be downloaded on-demand. This gets users into apps faster, and saves space.
This "cure" is worse than the disease.
The status quo is that they must download a 150MB bundle before being able to proceed.
The proposed app slicing will allow them to download maybe 10-20MB before being able to proceed, with additional components (up to the 150MB total) downloaded on-demand.
If the user is on an intermittent or slow connection this is still a significant improvement over the status quo: the user gets into the app much more quickly.
Additionally, if the user only uses a small slice of the app's functionality (which is the 90% use case), additional downloading can be deferred until the user connects to wifi, at which point the rest of the app can be downloaded over a fast and reliable connection, all seamlessly without the user having to worry about it.
I just compiled a Cordova-based Android-app without Crosswalk, but also without images. Just JavaScript, HTML and CSS and a few plugins and the APK is < 3MB. Was quite surprised by that.
[1]: https://crosswalk-project.org/
Cordova uses the system WebView.
1. https://sensortower.com/blog/ios-app-size-growth
2. http://blog.timac.org/?p=1707
3. https://blog.halide.cam/one-weird-trick-to-lose-size-c0a4013...
So it's not just that there's a bit of sloppy (or pragmatically careless) packaging, but there's just a lot of stuff in these apps.
(1) They substantial profits from memory upsells on their product lines (2) Larger apps take more horsepower to run— so older models become less effective sooner!
On another note, I just went to check some of my apps and iOS 11 got rid of the size from that view. You now need to dive into each app to see the size.
I'm constantly removing Facebook/Messenger for situations like when I had to download Ticketmaster app for a concert ticket.
And with all these apps disallowing you from moving them to SD card, I can't even really use my 32GB SD card for them.
And if Play Store won't let you install it then download & install manually from here http://www.apkmirror.com/apk/facebook-2/lite/
There is however no reason that code, either compiled to a binary format or in a textual format, uses so much data. Heck, the memoirs of Casanova spans 3000 pages, and is 6,5 MB. People don't understand how incredibly large a megabyte is for simple code.
Surely the 275 MB isn't all useful data (I wonder what compression ratios you get on 'apps'), and it should be possible to cut it down to a few MB.
(Also Electron bundles 'just the rendering library from Chromium' [1], not 'all of Chrome').
[1] https://electron.atom.io/docs/tutorial/about/#core-philosoph...
(I also don't agree with 'don't need to'. The main takeaway from the leftpad debarcle was the fixes to the npm module deletion policy, and hopefully people learning they shouldn't rely on an 'npm install' for production deployments! Whether people should use small modules is still up for debate, there are trade-offs [1] [2]).
[1] https://github.com/sindresorhus/ama/issues/10#issuecomment-1... [2] https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...
At a previous job we had a monolithic java server that ended up at over 350Mb of compiled code simply because each development team had imported whatever libraries they thought they needed. In some cases, 2 or 3 versions of the same library were included.
http://blog.timac.org/?p=1707
Most of it is actual code - not assets. For some types of apps (see: games) assets do take up a significant portion of total size, but for most everyday apps bloat by code over-inclusion is likely a bigger problem than asset-bloat.
I wonder if it's possible to get major open-source libs to move towards more fine-grained build targets and internal dependency management, so that devs don't pull in a gigantic binary when they're only using a small slice of the functionality.
Fwiw, this is already a trend in JavaScript land. Libraries are moving towards many small packages so you can import only the parts you need either manually or using a tool like Webpack to throw away what isn't used.
What I think GP was arguing for is that you have libstring.so which you can strip down to just having leftpad or w/e with Kconfig or similar configurations (preferably at link time not build time -- otherwise you still have the same problem).
Behind the scenes, lodash is built out of many modules, but you as a developer don't need to think about that.
Because tooling isn't perfect yet, you have the option of helping it out manually and being explicit about importing submodules. We were able to reduce our compressed JavaScript size by some 60% using a combination of automatic and manual tricks like that at my day job.
I've seen people try to package JS projects inside a distribution. >800 nested dependencies is simply not sane nor sustainable. The fact that they're small is even less excusable because it means that there was an active decision to not consolidate them into a single dependency that is properly maintained.
But I agree with what you're saying in the second paragraph, which actually sounds just like what my GP meant by using "Webpack to throw away what isn't used". Having unused parts of larger libraries cut out would be a much cooler solution than just telling everyone to eschew kitchen sinks in favor of many tiny, bespoke items. Especially since finding the right small libraries is much harder than finding a kitchen sink that just works and has a sizable community behind it
And then you'll have to use software written in 50 different styles, with 50 different type and error conventions, with pieces that couple together or not at random.
All of which matters not one hoot to folks _using_ the software.
Not necessarily. Distributions have to build everything, and in openSUSE we have an integrated build system[1] which has a lot of very useful features (rebuild when dependencies are updated, and automated QA runs before releases). Those features require you to have all of the dependencies of a project in an RPM package. Even if you don't end up shipping that package, the package is used for tracking security issues and backports and so on. You can't pull anything from the internet during a build, you have to depend on your BuildRequires.
Now take any average JS application that has over 800 dependencies. Ruby was already bad enough with ~80 dependencies, but adding another order of magnitude is just not maintainable. One of my colleagues gave a talk at LCA about this problem[2].
[1]: https://build.opensuse.org/ [2]: https://www.youtube.com/watch?v=4ua5aeKKDzU
If we're going to talk about linux packages, aren't they often written in languages with amazing optimization skills? If I write some C99 code that uses a gigantic library but I only use like 2% of it, my compiler will cut out the 98% my code doesn't use, so libleftpad sounds like an awful idea. That's one reason why packages on linux distros aren't too big.
But I'm talking about iOS apps where, as others have pointed out, the available optimizations suck[0], and as such, I think that having libleftpad.o included in everyone's iOS apps isn't a big deal (note that iOS doesn't really have a nice way to create libleftpad.so anyway AFAICT because all code for your app is supposed to be sandboxed so no one else can mess with or use it). I agree that it would be really cool to just cut out the 98% of $GIGANTIC_LIBRARY that isn't used at compile time, but since Objective C doesn't seem to have that now, I think small things would be a really nice way to give users more space on their phones without removing features.
[0] https://news.ycombinator.com/item?id=14902174
(If you link against the static library then the linker pulls in only the .o files that the app used, so assuming that the library was written in a sensibly modular way you pay only the binary size cost for more-or-less what you use. The linker can probably discard at a finer granularity than whole-object-file these days, but only-the-.o-you-use has been there for decades.)
Also I think we, as programmers, have taken the "don't reinvent the wheel" principle too far. The idea is to use 3rd party code to (1) save time writing, (2) reduce the risk of bugs, and (3) lower the maintainance burden.
But this makes sense only if the benefits outweigh the corresponding costs of integration, which also (1) takes time, (2) might be done wrong (especially because you don't understand the part you added), and (3) creates a maintainance burden. Of these, only #1 is solved when your development environment makes adding new libs quick and easy.
There (usually) is no dead code elimination for libraries.
Even if you can throw away dead code, you can run into bloat because a library has a massive set of foundational APIs that the rest is built on, and using one little feature of the library ends up bringing in half the library code because it's used everywhere.
PS: Do you have an example?
https://developer.apple.com/library/content/documentation/Ge...
https://developer.apple.com/library/content/documentation/Co...
https://developer.apple.com/library/content/documentation/Co...
Objective-C's dispatch is built around looking up methods by their selector, which is effectively an interned name. Looking up the selector can be slow, but once you have one, invoking a method using a dynamic selector is as fast as invoking one with a selector that's known at compile time.
Due to the frequency of this, objc_msgSend (which handles dynamic method calls) is hand-written in assembly, with caching and "fast paths" to improve speed. The overhead can usually be brought down to that of a virtual function call in C++.
Look at how much code is written in Ruby and Python. Their method dispatches are way slower. To put it in perspective, it takes CPython about an order of magnitude longer to add two numbers together than it takes Objective-C to do a dynamic method dispatch.
When you get down to it, an ObjC message send performs a superset of the work of a C++ virtual call. A C++ virtual call gets the vtable pointer from the object, indexes into that table by a constant offset, loads the function pointer at that offset, and calls it. An ObjC message send gets the class pointer from the object, indexes into that table by a constant offset, loads the method cache information at that index, uses the selector to look up the entry in the cache's hash table, and then if all goes well, it loads the function pointer from the table and jumps to it.
Since you normally need to bundle dependencies to account for different versions, this adds up quite fast. Qt adds 20MB for OpenGL, 15MB for the VC++ redist, about 30MB for other core libraries. Some stuff in OpenCV requires Nvidia's performance primitives (NPP), so in goes nppi64_80.dll - that's 100MB alone. opencv_cudaarithm310.dll is 70MB and even opencv_imgproc310.dll weighs in at 30MB. And on and on.
So yes, one little call to cv::cuda::remap adds in a boatload of dependencies when all the algorithm is doing is using a lookup table to sample an image.
https://github.com/opencv/opencv/blob/master/modules/cudawar...
Now it has turned out exactly the opposite way. If we went back to linking object code together we would get smaller sizes. Instead we have to include huge DLLs.
I'm pretty sure the main motivation is/was to allow patching of dependencies independently from applications. Very popular shared libraries might save space overall, but that is a secondary effect.
It's now 6mb.
I understand your argument, but in this particular case things aren't volatile enough that it causes any problems, and if it does it's just as easy to solve.
Also to the GP's point - Apple also now no longer supports splash screen images, so that element of bloat is no longer a factor (though some legacy apps have retained them pointlessly).
I think for non-game apps assets are not the primary driver of bloat.
I didnt know this as the only mobile I have dabbled with has been game dev with android in which case assets are the main cause of bloat.
Sigh...
The sheer number of vectors could make any renderer I threw at it crash.
That's actually one of the positives from moving away from gradients and shadows everywhere, funnily enough.
[1] - https://developer.apple.com/videos/play/wwdc2017/413/
This is pretty tone def. The bulk of apps are audio and ui assets and the compression rates on those are quite good.
That said, the compression rate for iOS apps is horrible as Apple decides to encrypt and then compress the binaries, completely blowing apart the compression ratio of duplicate data.
Encrypt then compress makes no sense at all. Compress then encrypt, or don't compress at all.
Anyway, probably millions of lines of code, 99.9% of which I didn't call. There is a tool for stripping code that will not be called, and I reduced my apk's from ~20MB to ~1MB, although I wound up turning it off in the end because it was not trivial to enable correctly. (I was linking 3rd party binary libraries into my app which complicated things)
Vector graphics will solve this, but is not mainstream yet.
The facebook android app is 88MB (zipped), i did check the APK of why its so big:
90mb of code 30mb of assetes (javascript, metadata, librtc, big json files (animations)) 30mb of resources (images)
Then you're trading off battery life vs. space. Vector graphics can be far more expensive to render than bitmaps.
I guess it would add considerable overhead for a negligible improvement in size (compared to just shipping all images) for most devices.
EDIT: Too slow...
Doesn't do anything for size on disk, but should help network a lot.
https://medium.com/@miguelrochefort/the-application-paradigm...
I expect this realization will only become widespread when open-source folks actually fix their software's deep-seated usability problems. The way to do that is not by hiring UX designers or appifying it; it's by thinking deeply about how humans interact with computers and blowing away the conventions that make computers and software unforgiving, hard to explore, and opaque to the uninitiated.
You cannot just compare obj-c vs generics, you need to also account for the fact that when you are obj-c development, you might need some fast code and as a result drop to c. And code reuse is hard to impossible in C.
The fact that code reuse can be done without a performance hit is enough of a difference difference on it's own as it pushes down the level at which code reuse can be done. E.g. you can use generics for Graphics or Audio or general low level stuff.
Then I remember downloading a 3 MB mp3 on my 9600 baud modem and being amazed at how much space was taken up by music that sounded realistic and not like just a bunch of beeps out of speakers that could only make beeps.
Then came the old joke about EMACS standing for "Eight Megs and Constantly Swapping".
Then I remember noticing that commercial software like games filled up a full CD's worth of space (back when software was distributed by physical CD's). After that it was common to ship software as multiple CD's, then multiple DVDs.
Now, is software even shipped on DVDs anymore? I just download everything, and, yeah, apps are still bloating, same as ever.
When EVERY app does the same thing? It's a problem.
Here's some of what's listed in the update list on my iPhone:
Chipotle is 92. The kindle app is 171 (perhaps the fonts?). The Amazon app (which is mostly a web view anyway) is 127.
Robocall blocker? 22. Verizon app? 160. An app for tracking streaks of achieving task? 65.
Slack is 123.
Clips? The Apple app for making little movies that includes a fair bit of art? Only 55. That makes sense.
Authy? To show 2-factor codes? 65!
Outside of games (which have a lot of assets) app sizes seem to have absolutely no correlation to what they actually do.
But the rest of us just want to use a phone with a couple apps. We can't afford phones like that, and high market-share apps shouldn't be designed for the top 1% of phones owners.
If Facebook wants people to use their shit, they can't design it solely for early-adopters.
Something that I'm very happy about in 2017 :-) Data is expensive in many places, and wifi/broadband is typically cheaper.
No, seriously: uninstall that junk and just run stuff in the browser. It works much better than you think, the biggest annoyance being all the nag screens sites throw at you to get you to install their apps.
It still doesn't work as well as a native app.
Also, relevant xkcd: https://xkcd.com/1367/
Software expands to fill all available resources.
http://idlewords.com/talks/website_obesity.htm
If you were testing over a dial-up connection, you would notice it.
Same with app writers. They forgot to optimize their app because they're testing it on the latest and greatest phones on their home network (or a corporate network which is blazing fast). If they tested on a low-end phone, and actually performed the update themselves over a slow cell network, they'd probably notice it.
Many common tools aren't set up for common-sense optimization. Ideally resizing images would be an automatic step, and you wouldn't have to remember. But that's not the case.
I'm sure that there are plenty of iPhone apps with 2 MB images from a camera, when a 256 KB image would do.
https://thenextweb.com/facebook/2015/10/27/facebook-starts-2...
They should be doing better than this.
I wish devs would still test like that. Sure, your app works fine in downtown SF on the newest phone, but try using it in Nowherseville, TN, on a phone that is more than a couple years old. I bet a lot of user frustration comes from dealing with that.
Hell, all of Android is far, far slower than it should be. I won't move to iOS but what Apple can do with a dual core phone is pretty amazing (and yes, I know that newer OS builds get slower).
Does anyone know of a good process-viewer/resource watcher for android?
Apparently writing an IntelliJ plugin of a reasonable quality is much harder than a Python or other script. Who would have thought. And a glorified text editor takes GBs of RAM, likewise a glorified Makefile.
(The resource watcher is built into Android Studio, but ignores GPU memory. To do that you have to run GPU debugger, a separate memory hog.)
Granting that you heavily imply a 4G connection, the choice of "Nowherseville, TN" is extremely interesting: Chattanooga, TN — which as a Tennessean I feel is essentially "Nowheresville" to most non-Tennesseans — has Internet service multiple orders of magnitude better than most of the Bay Area[1]…
[1]: https://www.washingtonpost.com/news/the-switch/wp/2013/09/17...
I do not, however, mean to imply a 4g connection. Many people don't even get that.
(It came up for me in Ivan Illich's Deschooling Society :)
It's making app bundle sizes explode in size
I can see how high-res pictures embedded in the app can add dozens of megabytes, and maybe a different runtime that you have to bundle for compat reasons, but multiple hundreds of MB?
* Charge owners a fee for apps over a certain size "a processing fee" or whatnot
* Charge owners a fee based on the download costs. Under XMB and it is free. The more you cost apple to transfer your app to their customer the larger the fee.
* Penalize large apps in the app store search results or give bonus to smaller apps.
Or rather than straight up bonus's / penalize apps based on size go after specific things that cause bloat
* Apps that don't use pngcrush on their png's
* Shipping wav files and not acc
* ...
Maybe Apple doesn't even need to actually implement any of these, but just threaten to.
Quite obviously most developers will have:
1) VERY powerful hardware
2) VERY fast (and unlimited) internet connection
It's not like (they should do it as part of quality assurance or similar) they take a car, drive in some remote countryside, possibly in the middle of nowhere, stay there a couple days and try accessing their website (or running their app) on the lowest/cheaper entry level hardware on a metered connection.
It's easy when you have a T1 or faster connection on a recent top-hardware to forget how a lot of other people have slower devices, with less memory and limited bandwith and metered connection.
I wouldn't be surprised if half of the outrage about file sizes simply comes from the fact that there are people who remember what software was like before all of this "technological supremacy" was a thing. People joining the workforce today didn't grow up with the experience of installing something off of seven floppy disks, which would have been considered an emormous program before the CD-ROM drive was common. They also don't know how much better those programs run, because they had to do so with 8 MB of memory or less and nowhere near 1 GB of hard drive space.
It's pure decadence.
https://twitter.com/xbs/status/626781529054834688
https://pbs.twimg.com/media/CLLGenwWgAAZAVv.png
Like: Hey, nice home page it is only 3 Dooms ...
For most freelancers and contractors the economics of the market means most of the time you have to be lazy or you will lose the job to someone else.
I guess the good thing is that it gave me an opportunity to teach my kid about tradeoffs. "Ok, so if you really want this app, we're gonna have to delete 4 of your other games on the iPad." Even a 5 year old could reason his way out of that one.
Larger apps means you have more "need" to upgrade your phone to the latest version with more space, power, speed etc.
I haven't seen any data in this thread to back that up. It certainly doesn't apprar true in my experience.
And it is in Apple's interest to have smaller apps, because then people will be able to download more apps. They'll be willing to try more apps, because there will be less of a barrier between seeing the download button and being up and running.
When your low end configuration is hard to use because Facebook takes up 29% of the storage... that's a problem. Customers get mad.
When they can't update Facebook because it wants more space and the device is full and now the user is locked out from their friends... customers get mad.
When updating a handful of apps uses up 70% of their monthly data... users get mad.
And ALL of that effects apple's bottom line.
I suppose it can help hide price increases of the next higher configurations, such as when the base configuration of the MacBook Pro decreased from 256GB to 128GB between 2016 and 2017, with the list price for 256GB configurations increasing by a couple hundred dollars. However, Apple has also gone as far as developing an entirely new filesystem to decrease storage use.
I could replace the following with PWAs:
- Twitter
- Uber
- Lyft
- Google news
- Instagram
- Flipboard
- Shopping sites like Walmart, Wish
and many more.
Facebook and Amazon have no PWA's but have mobile websites. (Facebook mobile web works well with Opera. On other browsers it annoyingly redirects to play store to install messenger)
It's the new name for a home screen bookmark.
Essentially, apps on the web that feel and behave like a native app.
Consider an app like Discord [1], which is built using React Native and is thus a "native" app with some additional cruft like a JS runtime. It clocks in at a relatively small 30mb. Not bad.
Then consider Slack [2]. For nearly intents and purposes it does the same exact thing. Discord has far more functionality than Slack. Yet, it is 129mb.
Tweetbot [3]? 12mb. Twitter [4]? 204mb.
The issue has little to do with the technologies used. PWA, React Native, full native, it doesn't matter. The issue is truly that these large companies have horrible, bloated engineering teams and that bloat comes through in the size of the apps produced. It is Conway's Law in action.
[1] https://itunes.apple.com/us/app/discord-chat-for-gamers/id98...
[2] https://itunes.apple.com/us/app/slack-business-communication...
[3] https://itunes.apple.com/us/app/tweetbot-4-for-twitter/id101...
[4] https://itunes.apple.com/us/app/twitter/id333903271?mt=8
oh, the irony!
How can a clock need the equivalent of a box of floppies? Windows 3 and 3.1 together comes to the same Mb and that comes with a clock.
the best way to understand it is just to try it. Its just a website(PWA) pinned to your homescreen, so theres not much cost to try it.