Hacker News new | comments | show | ask | jobs | submit login
App sizes are out of control (trevore.com)
729 points by trevor-e 77 days ago | hide | past | web | 442 comments | favorite



The situation is messy. Take Facebook.app. The reported size on the App Store is 377MB, the distributed .ipa is 241MB. But it is a universal app which includes fat binaries arm_v7 and arm64 and all the graphics 1x, 2x and 3x. App Thinning halves that size for end users. Yet the App Store reports the full size.

There's more. App Store also provides some sort of delta updates [1], which save a lot bandwidth, but failing to report it properly again [2].

App Thinning does not work for standalone image assets. It means you are forced to use Asset Catalogs where all PNG files are stored as LZFSE (previously zip) compressed BGRA bitmaps. It's good. But optimized PNG files can be 30-50% smaller on average. I'm fighting this [3] but not sure if there's a simple solution.

[1] https://developer.apple.com/library/content/qa/qa1779/_index...

[2] https://twitter.com/rjonesy/status/878051126704254976

[3] https://twitter.com/vmdanilov/status/892015508203216896


I was wondering why not use SVG (or any other vector file format) files and render all the graphic on the device, instead of including tons of PNG at various resolutions.


Fuzzy reasons abound, but you do occasionally see this. One major often-complete-blocker that I've seen though has been ungood rendering, so results aren't always identical on all devices. You can't really rely on the device's possibly-weird implementation (who knows what the OEM did to it)(except on iThings probably), so you're forced to bundle an svg renderer that works reliably on all devices and has consistent behavior, and good luck finding a high quality lib that does that[1]. And, to be friendly to the designers, it has to be reasonably full-featured.

[1]: but if you know of one, I'd love to use it!


Hand tweaking for specific resolutions is an art. You can't expect to just render SVG and get equivalent results.


I've made few apps and so far nobody cared about it. I thought that hand tweaking was about 16x16 icons, but now we are using 1024x1024 icons sometimes, there's no reason to tweak anything there, really. Actually it was the other way around: I wrote some scripts which rendered SVG into multiple PNGs and I think that almost everyone does the same.


even if you provide one svg for each range, you still gets massive size savings for 99.9% of icons


Well, the importance of red lining decreases as resolution increases. We still aren't there yet, however.


SVG stadnardisation and support is growing fast, notably because it is now part of HTML5 and has strong support in browsers, which are the most active software development needed for all kinds of apps. SVG includes many tests to assert the conformance and is one of the best graphic standard in terms of standardization with very precise requirements. It's in fact easy to get the expected results on wide ranges of devices, and implementations are now very performant. they are implemented as reusable opensource libraries or directly now in core services of most OS distributions, and even part of mobile platforms. The hardware is now optimized to support almost all SVG graphic primitives. The standard is not born from nowhere, it has inherited the best practices initiated earlier in PostScript then OpenGL, DirectX, X11 and similar APIs, and references other related technologies that are also standardized: Unicode, OpenType, IEC color spaces. There are still ways to extend it, but the SVG standard defines the requirements needed to support many devices, small or large. Only very old implementations will suffer from some quirks due to absence of support of newer features, but the graphic will still render correctly provided they followed the mandatory conformance rules for each version. Remeber that SVG extensions are widely upward compatible: newer renderers will support all graphics built for conforming renderers based on older versions. Note that SVG is not designed to get exactly equivalent results but results that are suitable for use on each device. This is absolutely not the case for bitmap graphics which are extremely hard to adapt, and waste lot of bandwidth. The next step for SVG will be to be a bit less verbose, suing another base syntax than XML: JSON seems to be the best candidate as it offers significant performance improvements to XML parsers: this will appear because now SVG is standardized primarily not for its syntax but for its DOM and API, just like HTML now and more recently as well with CSS (which is also used by SVG). And more impoprtantly the SVG standard is open, allowing all kinds of experimentations and implementations. No new feature appears in the standard before there's already been experimentations. The only few things that SVG do not support completely for now: * fine tuning fonts to handle more semantics and typographical effects * better support to render on non-additive color spaces (SVG still depends to much on sRVG which does not print very well, and new display technologies are now using more than 3 color planes to extend their gamut); colorspace transforms, and masks are still better supported in PostScript. * support for 3D rendering is still in alpha stage, but will come sooner or later. * support for splines may later add other curves than just quadratic or cubic Beziers, and elliptical arcs: hyperbolic, sinusoidal, and other parametric curves should appear, with their own rules for their subsampling decompositions to match the expected resolutions on target devices * lighting models are still too simple. But the OpenGL standard already drives what will appear. * support for texels should also come for 3D rendering, including mipmaps and synthetic/parametric mipmaps * integration of videos with SVG animations is still a challenge; given the neeed to also synchronize in time with audio, users events or scenarios for gameplay.

The HTML Canvas will drive the needs, as well as other W3C specifications related to accessibility, internationalization, matching user preferences. You cannot do the same thing with "stupid" bitmap graphics. In fact the birmap graphics will be internally converted to vector graphics for better rendering (this is already what printer drivers are doing to improve their results, you cannot do that only by subsampling, bicubic interpolations: you need geometric transforms, notably for adapting texts or symbolic designs such as maps): the individual "pixels" in bitmaps are really stupid objects that do not properly handle how they are geometrically linked to their surrounding pixels: there's a need to contextually hide or show some details, or improve some of them, vector fonts for Opentype are perfect examples of that need.


It definitely is improving, and it's fantastic to see the progress. I really enjoy SVG assets, and I'd love to see them mostly take over (obviously they'll never be 100%, nor should they).

But that still means it's years away from widespread support, because large companies can't rely on it for large user-bases, and feature-sets are still pretty widely varying in my experience. Some support animations, some complex gradients and masking, and huge variance in text rendering (which is absolutely essential to finely crafted images) cripples some of the most-valuable use-cases (internationalized images without making dozens or hundreds of near-duplicates).

It's just not there yet. I hope it gets there, but there are significant hurdles that don't seem to be getting a lot of attention.


Sure. So hand-tweak the SVG files per density that you need custom-handled. Like you already do for images / when exporting images. Same difference....

... except now you need to do it on the device too, to make sure it renders identically there. Otherwise the same problem!

---

For very small images it doesn't matter / png may be smaller, but small images with that quality don't typically add up to hundreds of megabytes.


You are lucky: I know one because I wrote it! Take a look at: http://www.amanithsvg.com


Raster images are still faster and often you can make your png images very small and do stretching.

OTOH, people do vector stuff for many things, it's just they typically don't use SVG but something more efficient. XML parsing is not lightweight compared to a binary format or some sort of vector -> code translator speed wise.


The XML parser is not much a problem: the time to parse it is insignificant compared to the waste of resources to store and transport bitmap graphics.

Bitmaps will also never be able to adapt their content gracefully to user preferences and constraints. Bitmaps have no intelligence; they are only suitable for photography, but even in this case they lack information for proper rendering, so you will nver same twice the same bitmap across devices and rendering supports

Just compare what we had in the past with bitmap fonts (now almost abandoned except for text consoles) and how we appreciate now to have scalable vector fonts.

Bitmaps are extremely complicate to adapt to any layout, whereas SVG graphics can be now self-adaptative, to render only what is needed.


You could ship SVGs and lazily generate PNGs for the specific device. Once it's generated, you keep it cached. Although it might be a little slower on the initial run. I guess it depends on your SVG's complexity.

Webkit does a fine job with SVGs. You could draw it on a <canvas> element to get a rasterized view of the SVG in the desired size, and save the resulting image.


I'm guessing but it seems logical that phones are not the place you want to do extra graphics rendering if you don't have to.


Modern smartphones have quite competent GPUs. They can run 3D games at 1080p/60fps. They could raymarch circles around an svg icon. And if it wasn't enough, the renderings could be cached for later use.


TBH not many people consider SVG format worth the effort unless the graphic is made from scratch. 1) an organization rarely rationalizes having a UI dev spend 6 something hours either transforming an existing PNG to an SVG, or spending 12 hours compleitly replicate an existing design in photoshop only for it to be exportable as an SVG. I could be far fe5ching things but sometimes business or upper management get short sighted on the small things. Probably there is no rationalizarion in spending extra effort in having these graphics all svg format, thus improving your application's load and bandwidth utilization, vs pumping more funds towards other easier quicker solutions.


>replicate an existing design in photoshop

AFAIK, the majority of designs are created in photoshop or illustrator. No conversion nessecary. In any case, I would consider it a liability if I didn't have my designs in an editable format. What if tommorow I realized I wanted a variant in a different color? Or I decided I wanted to use a different background? If all I had was a bitmap logo, I would consider it worthwhile to have someone change it into a scalable format anyways, even if I wanted to transfer them as PNGs.

Also, numerous free tool exist to convert bitmaps to SVG. Using one of these, plus some manual smoothing and correction, I'm sure the conversion would take no more than half an hour.


GPUs do not like SVGs. They don't handle them well at all. Most SVGs are CPU-rasterized as a result.


So you just CPU-rasterize out to a buffer, and blit it to the screen. After the initial render, it's equivalent to the PNG. The application essentially decompresses its assets on launch.


May be SVG is not the best vector format after all. May be we need something simpler, where every item directly maps to GPU graphics calls, also binary would help.


GPUs have graphic calls anymore. At best they have fragment and pixel shaders. Converting a vector graphic into a good shader is not trivial, compared to using the built in functions of texturing.

It gets even worse once you realize how limited older mobile GPUs are or what are the incompatible subsets of features supported at decent performance.


If you want something simpler that works with GPUs it needs to be exclusively built out of triangles and/or code that can operate on a single pixel independently of its neighbors.

Resolution independent formats are inherently anti-triangle and by the time you've hit triangles you already have a target resolution in mind.

Or put another way, GPUs really don't like vector graphics in general. That's not what they're built for or good at.


GPUs like vector graphics just fine; rasterizing vector graphics is literally what GPUs are designed to do. It's infinitely scalable vector graphics that they tend to dislike.

Once you've subdivided your curves and such into triangles/vertices/etc., the GPU ends up being a lot happier about its existence.


GPUs are not designed for vector graphics, they are designed for triangles and triangles only. Triangles are a subset of vector graphics, but are almost never the subset that people mean when they say "vector graphics."

Specifically vector graphics typically includes curves, which GPUs just don't do at all.

Once you've tessellated a curve into triangles you've already baked in a desired resolution. You can't have resolution independent vector graphics in a GPU friendly way.


Rendering svg icons sounds like a non issue for any "smartphone" made possibly ever.


Because the experience is subpar when that is done. It is impossible to create a vector image that will result in clean, unblurred strokes at arbitrary small pixel sizes. Don't even suggest using TrueType-style hinting, I don't think any designer would want to touch that with a 10 foot pole.


I would have said exactly the opposite: blurred strokes belong to bitmaps, you are still thinking that pixels are square over a regular area that can opnly be rotated by multiples of 90 degrees.

SVG graphics are clean, result in NO blur at all. They don't even need any Truetype-style hinting. You've probably looked only at early non-conforming implementations using bad approximations. But precise rendering algorithms for SVG are specified and fully tested (this is not the case for bitmaps whose support is much more problementic: see what happens to photos and videos when editing them! Never twice the same result, and lot of losses and artefacts everywhere, including bad undesired effects, and notably the moiré effects which are much worse and do not reproduce what natural scaling would do in your eyes, that are not fitted to a perfect rectangular grid).

So no, it's perfectly possible to create a vector image that results in unblurred strokes at arbitrary pixel sizes. What you want is a geometric transform to exhibit more some details: it is in fact impossible to do that with bitmaps except by sending variants tuned for multiple resolutions: you do that for a limited number of resolution and assume it is enough, but this is not the case, so you add more, and finally you have enormous images that are widely redundant with each other, and better represented by converting their 2D model to 3D and an adaptive 3D-to2D projection. you'll do that easily with vector graphics, not with bitmaps (or their extensions called "mipmaps" which are only approximations not really scalable because they're still all based on discretely sampled planes).


Truetype hinting serves to distort the curves beneficially (by being aware of the pixel grid) in order to produce more readable output at low resolutions. SVG graphics do not automagically scale down and stay readable.

The classic easiest to explain in words case is taking a capital letter O and turning it into more of an "elongated stop sign" shape at around 6 pixels of width. There is a tradeoff between remaining faithful to the original shape and creating high-contrast, readable shapes at low resolution. There is nothing impossible about scaling down the vector outlines of a TrueType font in a mathematically perfect way. You still need the hints to make the result more readable.

(I worked on the hinting software for 13 of Apple's System 7 font faces and about 3/4 of Windows 3.1 launch fonts.)


> SVG graphics are clean, result in NO blur at all. They don't even need any Truetype-style hinting. You've probably looked only at early non-conforming implementations using bad approximations.

This huge wall of text but apparently you don't understand the subject matter all that deeply. Why wouldn't SVG need hinting? Truetype needs hinting and it's a vector format as well.


(Philippe always posts walls of text, even on the SVG mailing list; seems to be their thing.)

Hinting as done in TrueType is probably overkill for most purposes. But icons are often not displayed in arbitrary sizes, but rather in one of a few known-in-advance sizes. It's not hard to tweak the paths and shapes to fit to the pixel grid for all those. Also, as you approach higher pixel densities, it becomes much less important; basically you may just have to make sure that the smallest sizes fit on whole pixels and that's it.

Long ago I've automated asset generation in different sizes from SVG for an Android app I worked on and even without caring (much¹) about a pixel grid the results were good enough not to need tweaking.

_______________

¹ When hand-writing SVGs I tend to care about integer coordinates simply to not lose my mind.


Wouldn't it make sense for the file format to just allow svg in addition to others?

eg png is fine, but if a developer wants to include svg then let them.

For developers who do care about the clean, unblurred stroked at arbitrary pixel sizes this wouldn't impact them at all.

For the developers who care more about the space taken up, this would give them a potential useful option.


For developers who do care about the clean, unblurred stroked at arbitrary pixel sizes this wouldn't impact them at all.

Ironically IMO I'm pretty sure this used to be one of the major selling points of vector graphics and svg :-)


I might agree that for very small icons (eg: targeting a ~VGA or 800x600 to maybe 1024x76 phone screen) hand painted bitmap graphics might be best... but shouldn't it be enough to ship 16x16 (or whatever) icons along with vector graphics for high-resolution screens? And if it's too slow to live-render the graphics, how about rendering custom icon sets (etc) on install - using the gpu, and then cache on the device?


SVGs are a problem because they don't have a "preferred size" parameter. On Xcode you can use PDF files for icons (which are much like SVG, but state "all my points are relative to the size WxH). Once you have that you can make pixel-perfect icons that are always rendered sharply.

The catch is that Xcode compiles all those PDFs to PNGs before bundling them into the .ipa, so in the end you have a bitmap either way...


Nobody said arbitrary sizes. It's still a limited set.


pcwalton's project Pathfinder (https://github.com/pcwalton/pathfinder) may eventually lead to an efficient GPU-based vector renderer, which would make this feasible.


I mean, it's feasible now; plenty of folks use vector rendering: Caching the result makes the CPU rendering much easier to deal with. The GPU would really help more with animations and dynamically constructed vectors.

In any case, I suspect something like lyon (https://github.com/nical/lyon) would be a better fit than pathfinder, which is both a) not super portable and b) very focused on rendering text, which it does very well.


Thanks for indicating lyon, that looks very nice. I mentioned Pathfinder because path rendering on GPU is important on mobile devices (battery and heat concerns).


Oh, it renders generic paths? I thought it only rendered vector fonts. Today I learned!


iOS vector asset catalogs (which use PDFs) actually don't support true vector rendering; any vector images are converted to PNGs at compile time.


As of iOS 11/Xcode 9 vector images are supported which is quite nice. It may still convert to PNG for backwards compatibility though, I’m not sure if App thinning discards the PNG for iOS 11 devices.


Pretty sure every trade off made at Apple is weighted heavily toward extending battery life.


Android starts to use it more and more. At least where it makes sense : icons and simple illustrations.

From discussions with iOS colleagues it seems that Android has seen a way stronger push for vector assets. Probably because from day one the OS and SDK has been designed for unknown displays at compile time.


I'm not sure about iOS, but on Android the reason is the cost penalty of rasterizing larger icons and images on the fly. There's also some fragmentation with differing levels of SVG support on different OS levels. As a result, SVG is limited.


"some fragmentation..." That's like calling the ocean a bit wet! The experience of learning to code on Android revolves a great deal around dealing with that fragmentation.


I was specifically referring to the level of SVG support, which is constant across given OS versions, not per device like the fragmentation in old camera hardware abstraction layer implementations.

In that sense, the only reason there would be more fragmentation in SVG support on Android than iOS is that it can be harder to upgrade Android devices that did not come from Google.


As someone who has spent a lot of time with SVG, I can assure you there are very wide discrepancies in how the same file renders even using different tools on the same platform, let alone cross platform.


For some things like icons and UI elements, the automated resizing gives worse (fuzzy) results than a human artist. It makes a difference.


Because different graphics are shown are different resolutions, rather than purely scaling a highly detailed 1024x1024 SVG down to 128x128.


SVG = scalable vector graphics

SVG files are vector based.


>1024x1024 SVG

Vectors don't have pixels.


But they do generally have a nominal size at which the artist considers the render to be optimal... no need to be so short.


The point is still valid. An SVG designed for a high DPI screen will most likely look bad on a low DPI screen.


However, they usually are designed around a target size. And it's quite possible that, scaled too small, much of the detail is lost. Hence why you'd still want different vector files for different resolutions.


Considering the topic of this post (apps), I would argue assets are usually designed around a physical size of the image; even when you have multiple target display sizes, it becomes a part of the requirements to design assets the way that looks decent on all phones. Moreover, I find this whole branch of discussion a bit funny because assets are already designed to be high res and later downscaled for target dimensions, so simply using vectors literally just pushes that task to phone instead of build server.


A simple solution to this would be for Apple (or the developer, via Apple) to distribute different builds based on the device installing the app.

That is, developers could compile a different copy of the IPA for all target devices. Using variables like CPU architecture, screen size, and other feature flags, a smart compiler could cut a lot of code and assets that never run or display on certain devices.

(Granted, this would be much simpler on iOS, which has a limited set of targeted devices compared to Android.)

In fact, it seems Apple has already taken steps in this direction with its cloud compilation (I'm not an iOS developer, so not sure of the specifics). What would worry me is if they started requiring all source code be uploaded to their servers for compilation. Going down that road is fraught with ideological pitfalls.


I think they already do that with bitcode. You upload the LLVM bitcode and it will generate the code for the appropriate architecture as needed. It's standard when you upload your app to iTunes. They don't use your source code for that.


Do you mean "bytecode" or is "bitcode" a thing?


bitcode is indeed a thing, its a file format for LLVM IR https://lowlevelbits.org/bitcode-demystified/

It's not really a bytecode as it's not interpreted, but that's debatable.


I continue to learn more.


Wild guess, but presumably file size was not Apple's only or primary consideration on image format. Rendering performance, app load times, and power conservation all likely rank higher in Apple's priority list that raw disk space used.


I don't think that's true. Having unused icons on the device has negligible effect, if any, on performance, load times, or power usage (they never are loaded into RAM)

App thinning, as they call it (https://developer.apple.com/library/content/documentation/ID...) almost solely is about two things: download time and disk space.


+1. Also, it's a plus for apple if people would buy 128gb version of iphones instead of 8gb ones...


This may be unrelated, but why do they push out updates every other day or so? No other app is like that. And sizes aren’t getting any smaller. They’re at version 137 right now...


Those numbers are mostly unfair. For some reason in the iOS 10 App Store, Apple started listing the complete fat (both 32-bit and 64-bit archs) submitted .ipa size. If you want to easily test that, clear your cellular data usage, update one of those apps (or install) and then go back to settings and see the actual bytes transferred.

Also, most everyone is using Swift in some small part, so that automatically includes the standard library. Then you have some companies who switched to Realm DB away from CoreData. Or then there's a whole subset of companies that have decided they want to go all in on Javascript and have brought in the whole React Native stack with it.

These apps in that list are also built by teams of 100s of engineers working at full speed. In reality, each one is its own little OS full of its own UI frameworks, testing frameworks, and nontrivial code.

Trust me when I say that everyone is plenty aware of how big their footprint is getting, and no one is happy about it. Apple won't even let you submit to the store if the actual single architecture binary is over 60MB.


It’s partly unfair and only a partial picture. Many apps post install proceed to download data.

Some limit that amount of data they download but a few are indiscriminate about it. I hated the Yelp app because it seemingly did not limit how much space it took up. The more reviews you viewed, the more space it took up. I never found a setting to limit it. If you go to Manage Storage you will discover that many apps take over 100mb in documents and data.


I'm curious, does anyone have the equivalent app sizes on Android? I'd love to see a comparison, to see if this is more of a platform issue as mentioned in a few comments, or a developer issue.

I guess we also should be looking at the actual data transferred rather than the number shown on the store page.


I'm 100% willing to believe this is a universal problem and is just as bad as Android. I'd be FLOORED if Android apps were significantly smaller.


I checked now.

LinkedIn: 20.36MB Facebook: 76.59MB Twitter: 25.71MB

That's about 1/8th the size of those apps on iOS. Those are just the first three apps in use article, I'm sure the rest are about the same.


Wow.

I wonder why it's so different.

Hopefully someone can chime in with the reason.


Java byte code is generally much smaller than equivalent machine code. If you use something like Multi-OS engine which statically compiles Java bytecode to native code for iOS it's fairly typical to see an order of magnitude difference in binary size.

This actually affects Android 5+ too (Multi-OS engine uses Android's AOT compiler) but since it happens on the device it doesn't affect download sizes.


Really? I've never heard that before. I'd guess it would be bigger if anything.

Any idea why that is?


It's true, Java bytecode was basically designed for small size. The goal was to transmit java apps quickly over the internet, a hope which mostly died off as JS took over, but which in some ways has been reborn with android (dalvik bytecode is somewhat different but is definitely small). The main tradeoff for the small size is a total lack of optimization until the JIT compilation stage.

But there's no way it's anything like a 10x difference. There's definitely something else going on here, like some quirk about how the app store is calculating the sizes of assets.


I'm talking about the binaries themselves as they are output from dex2oat. The 10x difference is I suspect a product of needing to compile parts of the standard library in addition to the app's code.


Many things that Java does with a single instruction take much more than that in the target architecture. For example, virtual calls (which are used almost everywhere in Java) take several instructions on x86 and ARM while only one in Java or Dalvik bytecode.


Bytecode is much closer to source code than machine code (there's a cool discussion about this in https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...)

and source code is generally smaller than machine code.


Its 174 MB installed with another 150 on Data which is a thing but I hardly use facebook once a day (just to see notifications not even the feed) which is quite big and no cleaner is going to delete the Data as it is not cache. Facebook app is a big one and I don't even know why.


Pretty sure some android versions or phones let you delete the documents and data, whereas on iOS you have no freedom to clear the cache manually. It only happens when you run low on storage.


I'm as far to mobile development as I can be but is there no shared libraries on those platforms ?

Other than the environment provided ones, isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps ? Makes absolutely no sense for each application to implement it's own web browser/runtime.

Can't believe we are constantly reinventing the wheel again.


For iOS, there are the shared libraries provided by the OS. UIKit, PhotoKit, etc...

Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility?

Most people don’t want to crack open their phone and set paths so that their app has a version of Python that works with it.

Also shared libraries can be giant security holes. See the bug in AFNetworking that affected many thousands of apps. Imagine an errant app shipping a backdoor into a shared networking library.


It's pretty telling that Linux distros are pretty much the only end-user platforms where binary distribution and packaging is built around shared libraries. Pretty much everyone else (Windows/OS X/iOS/Android/etc) generally expect binaries to include their own bundled versions of 3rd party libraries. Lots of people have looked at this problem and most have opted against the shared library approach.


That's because Linux distros are more centralized that the Apple's walled garden. They just lack the walls, but are as much a garden as you can get.

Unless those platforms start distributing a huge number of libraries your software may decide do depend on, shared libraries won't take off on them.


Not sure if "Linux distros" is the completely right term there. The various *BSD based "ports" systems do similar too.


The Global Assembly Cache for .NET was supposed to be a shared library storage with support for multiple versions of the same library + signed assembly/hash matching.

It just never really took off for some reason. It's where all the BCL assemblies existed.

Instead we have NuGet and the libraries exist wherever the application is installed. GAC be damned :(


If Apple (or Google) wanted to make this work, it wouldn't be that hard. An app could list the dependencies, with a name perhaps, but definitely a hash. The developer would have to upload the dependencies, too. If the hash matched, the server would also do a byte by byte comparison, and if that matched, mark the dependencies as sharable. When downloading an app with a sharable dependency, the phone would check if it already had installed it, otherwise download it and install it at the same time as the app. Refcount the sharable dependencies at install/remove/upgrade time and rove unused dependencies after a reasonable time.

You would only get a benefit if two or more apps you installed used the exact same version of the dependency, but that seems like it might happen enough; especially once it's expected to be in the ecosystem.


Sounds like you just invented https://nixos.org/nix/


Google is actually working on this for the support libraries. All the Android apps use them, so it is a good target (and of course it might be possible to extend it to other libs). I guess it makes the most sense in the markets where data is very costly. By itself the support lib is not really big but if each KB counts, let's not download it several times.


> Shared libraries beyond that would bring the hell of version incompatibility

This is more a general question but I've never understand why so many shared library systems have the restriction of "only one version of a library". What stops you from storing different versions of the same library for different apps?

(I understand the problem with transitive dependencies - e.g. if the same app transitively depends on two different versions of a library, that might spell trouble. Even for this there are solutions - e.g. different classloaders for the jvm - but even without, you could disallow this special case witout sacrifying much)


For Apple libraries, it is because the latest framework could be providing a completely different implementation and they both want and need everyone on that implementation. For instance, they reimplemented Photos, introducing a new interface, maintaining the old interface but deprecating it.

Edit: in other words, common data.


I guess they went as far as they could without a proper package manager.

> Shared libraries beyond that would bring the hell of version incompatibility. One need only look at Apple’s evolution of Swift where there still isn’t binary compatibility?

Since the source code is shared with Apple once it reaches the marketplace, wouldn't it be simpler for Apple to compile a specific version for whatever version of the Swift language is available on the target device ?

It wouldn't have any market value and wouldn't drive iOS devices sales but is would certainly slim them down a little.

> Also shared libraries can be giant security holes. See the bug in AFNetworking that affected many thousands of apps. Imagine an errant app shipping a backdoor into a shared networking library.

This sorta makes me like iOS a bit more. Memory gets cheaper but security doesn't get any cheaper when the dependencies grow.


Your source code isn’t shared with Apple. You ship Apple a binary or intermediate code.

Edit: Also doesn’t help if you have C or C++ code mixed in there.


> isn't it possible to bundle some dynamically loaded libraries that can be shared by multiple apps

Yes, there is one: the standard library, provided by Apple. However, many apps eschew this to use their own libraries and frameworks for whatever reason, be it ease of use or feature enhancements, and these cannot be shared.


The Facebook API library provided by Facebook is notoriously huge in source code at least, and they're pretty proud of the size of it, can't find the link right now, but they had a blog post talking about it a few years ago ago.


Here's a link to the oft-mocked slides from the talk where a Facebook engineer spoke about how iOS can't handle the scale of their app because they do the very logical thing of using over 18,000 classes: https://www.columbia.edu/~ng2573/zuggybuggy_is_2scale4ios.pd...


It would have to entirely app stored manage - it's not possible for iOS developers to currently share code between apps.

Everything that is shared between apps currently is stuff that's provided by the shared platform.


> In reality, each one is its own little OS full of its own UI frameworks, testing frameworks, and nontrivial code.

Are you talking about React Native apps here as well?


I am surprised at all of the app developer shaming in this thread. Is it really likely that every developer working on a popular BigCorp app is an idiot who imports 10MB libraries every time he/she faces the slightest challenge?

It's much more likely that app developers are optimizing for many things, including app size, but reducing app size has a bad cost/benefit ratio. Here are some decisions that may bloat your app:

  * Want your network calls to be fast and reliable?  Better use that cool new HTTP library rather than writing your own. 

  * Want to keep everything secure?  Rule #1 of hacker news is never roll your own crypto so better import the best lib out there.

  * Want to delight your users and their fancy QHD screens?  Time to include some high res images and animations.  Oh and you can't use vectors, they kill performance. 

  * Want to access new markets?  Time to translate your strings into 80 common languages.  Oh and some of these may require custom fonts to look right in your app. 

  * Want your Android game to have blazing fast graphics?  Import that native library, and don't forget multiple architectures. 

The biggest app I ever worked on was Google Santa Tracker. It was about 60MB. We spent a lot of time optimizing the app size in this year's version. We managed to drop 10MB while adding a few new games to the app. I'm proud of it, but if I didn't have the freedom to pursue app size I certainly would have taken the extra bloat to ship the new content.

https://android-developers.googleblog.com/2017/03/getting-sa...


Is it really likely that every developer working on a popular BigCorp app....

Not to mention, rarely does app size register to clients, PMs, bizdev in terms of a worthy task. Only when you end up at the top of the app sizes list is time given to optimize.

We work to keep down app sizes and offer line item tasks for app size optimization on updates, noone finds it needed until they start to risk being near the top of the app list on a users device when they want to delete some apps.

In games, many toolkits/engines like Unity and Unreal in mobile also add quite a large chunk. Building your own engine is rarely an option anymore in terms of competitive launch. Many games built with Unity/Unreal even with moderate assets can reach 200-300MB easily and easily creep up further on updates.


For some reason reducing APK size talks have been a constant presence in the last three Google IO and WWDC as well.

If you need to advocate this, it tells a lot about how much app devs care about the issue.


Every popular mobile OS has standard libraries for making HTTP requests and doing crypto.

I can forgive games for sacrificing size in favor of high-res animations and a blazing fast graphics stack, but I don't think LinkedIn, for example, is in need of particularly fast graphics.


If you've had to look at a pcap from what the android standard libraries do for https chunked upload, you would cry. One tls packet for the per chunk header, one for the chunk of data, and one for the carriage return newline. I've thankfully forgotten if these managed to also be separate tcp packets.

Given that, I don't think it's unreasonable to consider using a library to do it better, although you have to weigh the increase in apk size. The standard crypto libraries on the phone are great if the features you need were released 5 years ago, but if you want consistent behavior across Android versions and manufacturers, you need to include that yourself too.


Except the standard library will be updated if this actually became a problem, whereas you might choose that the cost/benefet ratio to updating your library is not worth it.


To a first approximation, the standard library on deployed Android phones is never updated.


Yet the installed size of my facebook app on android is 350MB and since the total phone memory is 2 GB I have a storage problem (less than ideal free space). While facebook lite is not a smooth experience compared to the full app.


"Installed size" as reported by iOS can be deceptive, since it includes a cache.

Unlike Android, end users can't clear it, though backing up and restoring your phone does that...


Mobile platforms should really do something about vector graphics. Shipping raster image which has much larger size than vector image is stupid. Shipping 3-5 raster images is beyound stupid. Surely there could be a way to render images on demand or roll some simple vector format which would be fast to render (it's not like decompressing PNG is that easy, it takes processor time as well).


Android offers VectorDrawable for this purpose, and Android Studio will automatically convert SVGs for you. It works great for icons and other "material" stuff, anything where flat colors and simple paths are sufficient. I believe there is also a support library to use it on older OS versions but have no experience with that since we're happy with 5.0+ for our app. I highly recommend it over making all those PNGs for different screen densities.


I have seen projects that did not cared about app size. Or rather, app size was priority "super low", because critical and important issues were still open.

It seems that most users don't really care nor use all that many apps.


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.

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...


It's a blog, the content doesn't have to be novel. That said, the author would improve the post by replicating your context links.


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.


It's pretty rich how these companies are well known for the rigor they apply to interviewing candidates on technical subjects, yet actually drop the ball in production with poor engineering like this. Where does that rigor go after the interviews are done?

Are there any examples of well-known apps from large organizations that aren't excessively large in size?


I work on Amazon Prime Photos iOS app. It's currently 60mb in size, and a good chunk of that is the Swift runtime.

Even the main Amazon shopping app is less than 100mb.


I'll bite. In what ways can you use up 100MByte with a fancy reimplementation of an online shop? That should be enough for a text to speech engine, or a 3d engine with quite a few assets.

I am being deliberately ignorant, having no idea what functionality one might add, but I'm actually genuinely curious. All that I see is a small databse and a lot of assets that are being downloaded on the fly.


I don't know the division of work between the app and server but don't forget that the app includes some level of voice recognition, and has not just a bar-code scanner but enough of a computer vision system that I can pretty reliably look up products simply by taking a picture of them.


I believe it does have a text to speech engine......the Android app has one.


>Even the main Amazon shopping app is less than 100mb.

109 on my device, not sure why it needs over 100 for a menu/search and checkout function that relies entirely on external data.

Also another commenter said Alexa was 78 when it's 124 for me and does even less than the shopping app.


Those apps are standouts but generally Amazon iOS apps are appalling. Alexa is 78MB of pure UX hell.


Wait. Do you have to include the runtime with the app? That seems backwards.


Because the customers are the ones who are paying for that inefficiency, not the company.

You can bet that those companies' infrastructure is optimized to hell and back.


> You can bet that those companies' infrastructure is optimized to hell and back.

You'd be surprised. (Source: I work at a unicorn.)


You know, I'm not currently an Uber customer because their app is too big and I don't have enough spare space on my phone.

There were a few times already that I thought about using them, but couldn't install it right at the time.


OK, so that's one. How many people even look? I have no idea what size the applications on my phone are.


I never really looked (not into Uber). I just tried installing it, and it failed due to lack of space... And, well, I can take a cab when I need it.


Do you have a lot of space on your phone, or just not use a lot of apps or media? People might not have the same situation as you.


I have a 64 GB phone with a fair amount of apps and media. I don't know if it's more or less than average.


64GB is huge. Many common phones only have 8gb. Inexpensive phones these days have 4GB. Super cheap phones for developing nations may try to sneak in with less. When your phone is full, you generally go to the installed app list, sort by size and kill the biggest thing you can't live without. Eventually you get to the point where you have to delete app A to run app B, and then delete B to run A. If your app is smaller, it'll stay installed longer.


I don't know much about developing markets, but I feel like most phones have for years come in 16, 32, 64, and 128 GB sizes. In any event, I'm not sure someone in a developing country with the absolute cheapest smart phone available is necessarily the kind of user Uber has in mind. I'd be skeptical of the idea that reducing app size is the most revenue-driving thing they could do to their app.


I have to imagine the vast majority either don't care, or have other reasons for not having the app on there (like the company itself, for one).


Not exactly large organisation, but the slack app is 80MB. For reference, discord is 17.


Please also count in server side data downloaded for identical functionality. It does not help if 80% of the app is downloaded after installation.


I'm on iOS, so checking the sizes in Storage. Slack is 74MB with 14MB extra downloaded. Discord is 18MB with 6MB extra downloaded.


> Are there any examples of well-known apps from large organizations that aren't excessively large in size?

This is nothing new. Look how much memory your typical Java desktop app, or worse, your average Java server app, uses. As soon as you have enterprises involved where it's regular occurrence for devs to be outfitted with the shiniest and beefiest (as perks or per standard company policy) developers won't care about resource usage until it's so excessive it either slows down their machines or accounting knocks on the door and asks who ordered dozens of x1.32xlarge machines...

Seriously, another huge problem is assets. In ye olde PC days, you included ONE version of an image and that was it (okay maybe a 16x16 favicon for the small start menu and a 32x32 one for desktop)... these days with loads of different combinations of resolution and DPI, and across multiple platforms (if you're doing a Cordova build and don't split the assets before packaging), stuff can and will grow.


It's not that Devs don't care. It's because every metric anyone has ever gathered says that users don't care.


It's not that users don't care, they just don't know it's an issue or who to blame. When they're out of space on their phone the blame whatever company logo appears on the phone, they don't blame the authors of a dozen bloated apps they installed.


This. People blamed Apple for them running out of space on a 16 GB phone. I agree photos, videos, and music take up space, but the first iPhone had 4 GB of storage. The iPod Shuffle had 500 MB. Not exactly apples to apples comparison, but Snapchat used to be about 5 MB, and now it’s over 100!


Could Snap have made the current app using only 6mb of space?

I'm sure they could, but i suspect the engineering effort would've been much greater. That's money down the drain if it turns out users don't care, or their competitors released earlier and grabbed more market share.


> It's because every metric anyone has ever gathered says that users don't care.

A lot of people go to wal-mart. Doesn't mean that it's a good thing overall for mankind


If you're looking for apps to be developed "for the good of mankind," without consideration of profitability, then you're going to have to have a different model than the pursuit of profit.


well of course, and I think there should be legal action in this direction. No reason to waste CPU cycles on the technologie du jour.


Adding onto this comment because people are latching onto the wrong part.

It's a greedy search. Just because you optimize for your local best interests, doesn't mean the COMMUNITY will benefit overall and the ecosystem itself suffers.

Look at how slow, ad-filled, and error-prone websites are these days.

So yeah, companies and people should be at least _concerned_ with the disparity between "best for me" and "best for all of us." Otherwise, we get things like rampant pollution. Well, this is app pollution.


I do not think you worked in Enterprise. Getting new tech approved is difficult, provisioning a VM takes weeks. Most enterprise lag at least 2 years behind everyone else.

Enterprise apps are slow because developers lack shiny new tech. You are forced to build yet another Spring App that takes minutes to start and gigabytes of memory. You also need to use MQ to interface with other systems and log/audit almost everything.


It's hard to move fast and have a well engineered product.


Then don't move fast. It's as simple as that. Move at the pace that you can sustain a reasonably engineered app.


At which point everyone who moves fast will beat you.


Will them?

Amazon differential is not the quality of their app. Unless they create something really impressive some day, they can only lose customers by moving faster there.

Besides, none of those are small startups anymore. All of them have something to lose.


> Amazon differential is not the quality of their app.

For my only real experience with amazon (audible) the quality of their app is a negative, I'd much prefer they made an API available. The same can be said of others, I'd much rather native apps connecting to a netflix API than use their awful web player.


There might be countless number of failed chat/social apps that failed due to their time spent engineering something like size reduction or code quality. You probably just never hear about them, since you know they failed to get traction.

So size being a problem seems only true for engineers. A normal user don't care as long as their device still works. And apple won't care since they can use this as an opportunity to up sell larger devices.


90% of the time, the organizations that say stuff like this just don't have any discipline. You can move plenty fast with a well engineered product.


Awesomely, this blog post of less than 200 words and one screenshot loads over 1.41 MB for me.

Software expands to fill all available resources.


For the few among us who haven't read "The Website Obesity Crisis", this is as good an excuse as any to link it again:

http://idlewords.com/talks/website_obesity.htm


The only issue I have with that site is that it's awful to look at.


Sorry for the extra bandwidth, forgot to optimize the images.


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.


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.


> 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]…

[1]: https://www.washingtonpost.com/news/the-switch/wp/2013/09/17...


I can agree that may be a bad example, but I think the point is fairly clear.

I do not, however, mean to imply a 4g connection. Many people don't even get 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, 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-

https://thenextweb.com/facebook/2015/10/27/facebook-starts-2...

They should be doing better than this.


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)


So which huge apps did you delete? Oh, none. Now you have your answer to why they don't optimize for app size.


For those who don't know, this is Parkinson's law :-)


yes! Do you remember where you learned of it by name?

(It came up for me in Ivan Illich's Deschooling Society :)


Worth pointing out: The author of this article works at Kayak, which has an iOS app of 176MB.

https://itunes.apple.com/us/app/kayak-flights-hotels-cars/id...

(As far as I can tell, the answer to "why is LinkedIn.app so large?" is not "because LinkedIn's iOS team sucks", but "because LinkedIn's iOS team works under a number of constraints, including app size, and app size is not a particularly powerful constraint to optimize for.")


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)


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.

[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


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.


These clocks did not have high fidelity long ringtones and billion of options. And especially no Google calendar support. ;)


PWAs? Public Welfare Assistance schemes?


Progressive Web Applications

It's the new name for a home screen bookmark.


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.


... without a huge install if you watch the weight of the initial page load and optimize for that. ;)


Pretty^W Progressive Web Apps (https://developers.google.com/web/progressive-web-apps/)

Essentially, apps on the web that feel and behave like a native app.



Progressive Web Apps


But those websites suck down enormous amounts of data each time they load.


Not if they use caching (whether service worker based or not) aggressively.


If an organization isn't taking the time and effort to make sure their app isn't bloated full of stuff, what makes you think they'll do that?


caching can be done reasonably well for straightforward cases with yet-another-library https://serviceworke.rs/

oh, the irony!


For the developers out there, here's one option for native applications that leverages the beauty of the web: http://jasonette.com/


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.


What exactly is the difference between a PWA and a mobile website?


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.


Sounds very diffuse. I can pin any mobile website to my homescreen but I presume that alone doesn't make it a PWA.


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).


Branding, obviously. :)


I have a cheap phone, and due to this I can only have like 6 apps installed at a time.

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.


There's also Facebook Lite https://play.google.com/store/apps/details?id=com.facebook.l...

And if Play Store won't let you install it then download & install manually from here http://www.apkmirror.com/apk/facebook-2/lite/


protip: switch to browser-based FB. it's perfectly reasonable.


And, you can still access messages by selecting "Request desktop version" from the Chrome menu.



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.


Didn't know about this one, thanks. That's an extra 300MB free on my phone from removing Messenger.


This no longer works for me, YMMV.


And the permissions aren't as nuts.


If you're on Android, you can try SlimSocial for Facebook + Notifications for Facebook, both available through FDroid. 223 KiB and 103 KiB respectively.


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.


What is it that keeps online web apps from turning into the bloated monsters that Electron apps are on the desktop?


They don't need to bundle their own copy of Chromium and Node, presumably.


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).

Also, relevant xkcd: https://xkcd.com/1367/


  > It works much better than you think
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.


"It works much better than you think"

It still doesn't work as well as a native app.


One of my first jobs was as a technician at a tech support call center. For a while around 1997-1998, a good 1/3 of our calls were customers who ordered a new system with a hard drive over 2.1GB, but Windows/DOS could only make partitions as large as 2.1GB. Customers wondered why they got a smaller hard disk than they ordered, not realizing the extra space was that Drive D under My Computer.

Fast forward to today, where my MacBook keeps nagging me that my "hard disk" (actually an SSD) is "full" because I only have 3GB of free space. In 20 years, what was once considered the maximum is now considered negligible.

Optimization is important, but regardless, software size is going to keep growing. Wringing hands over it doesn't help much.


This misses a large point of the article:

It's not the storage size that is problematic as much as the transfer size. Websites and developers really need to be aware how long it will take for someone to even get your product. If a website doesn't load in X seconds, you're losing Y customers. If your app takes an hour to download, your customer has probably already moved on in frustration.


Yes, this guy doesn't seem to care at all about it, beyond writing a blog post. If he did, he would remove those huge apps and find alternatives.


Perhaps the lament is that because nobody else cares, you can't actually find an app that is small to replace with!


There are lots of apps smaller and better than some of these. Consider the running app? Or using facebook in Safari.


OP is saying that what we think is large now could be considered negligible tomorrow. storage or transfer alike.


> my MacBook keeps nagging me that my "hard disk" (actually an SSD) is "full" because I only have 3GB of free space

That's because it will use that space for caches and swap, and you're preventing it from doing so and making the system slower.


Yes, I know. My point was that today's "practically none" was 20 years ago's "more than the OS can handle."


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.


Right? I just got a new phone that has 128 Gb of internal storage. 334 Mb app? no problem.


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.


When it only has the functionality of a 20Mb app... it's a problem.

When EVERY app does the same thing? It's a problem.


From that perspective, you have a very valid point.


It's really crazy. Overcast (my favorite podcast app) is under 10 MB because Marco cares about things like that.

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.


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!


But it also adds to their bandwidth and storage bills


It's probably a drop in an ocean compared to their other services.


Which they can easily price into the cost of the device, or into the cost of the app.


But if Android apps are smaller and faster, people will switch over to Android.


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.


The base for iPhones now is 32G not 16G.


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.


This absolutely.

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.


OT but not much, and JFYI, I started using an alternate unit of measure for web page sizes, the Doom:

https://twitter.com/xbs/status/626781529054834688

https://pbs.twimg.com/media/CLLGenwWgAAZAVv.png

Like: Hey, nice home page it is only 3 Dooms ...


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.


It's not just "lazy developers".

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.


The problem is it's not really in Apples interest to get app sizes smaller.

Larger apps means you have more "need" to upgrade your phone to the latest version with more space, power, speed etc.


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.


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.

And ALL of that effects apple's bottom line.


This is usually my thought when I see issues like this. If Apple wanted to fix the problem, they would fix the problem.


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.


most people here seem to agree more bloat = less users

I haven't seen any data in this thread to back that up. It certainly doesn't apprar true in my experience.


i think the disagreement is on what constitutes "bloat"


As someone with 16gb of space on my phone (before the OS), this has become really noticeable. It's a breath of fresh air when you install an app (like the habit tracker I installed the other day) and it's only 2mb...

It's worse knowing something like Facebook will cache a whole bunch of images, friend pictures and everything else.


Is anyone else worried about the massive amounts of bundled third-party libraries that come with each app from a security, rather than a size, perspective? What happens when such a library receives a security patch? AFAIK it's up to each developer to keep all bundled libraries up-to-date, which means that, realistically, everyone is shipping lots of vulnerable stuff and they don't even know it.

"This shirt is dry clean only, which means it's dirty."


Yes that's exactly what it means, React has 630 dependencies so 630ish separate libraries and components. You might even stop updating a component since the new versions change the interface and end up breaking sections of your codebase.

The idea is that because it's all open sourced, all the vulnerabilities will be found and patched. But more often than not you just end up missing the small notification from the maintainers telling you to update.


This is definitely getting to be a major problem. I've removed several apps for this reason as well.

Code bloat = lost users


I think the way it works in the real world unfortunately is:

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.


Yup, and also bulky apps that insist on a two week rolling release schedule...


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.


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.


Most people have small flash and can't fit many apps this size in the space that is left over from the OS and photos/media.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: