App sizes are out of control

Swift induces large binary sizes through the language itself. You'd be surprised what a simple optional if let creates in assembly, or how it uses template specialization with pretty much every typed collection interaction or some other standard library interaction. That plus the 10-20+MB that the swift standard lib adds contributes a good chunk. Once ABI stability comes in and a bunch of in progress size optimizations come in, binary sizes will decrease quite a bit for swift using apps.

Apple also encrypts then compresses, which means the binaries you download in the app store are incompressible.

If apple wants to decrease IPA download size worldwide, they would let developers not encrypt their app and just sign them. That would be very relevant for developers of popular free apps. I'm guessing they encrypt then compress so they wont have to re-encrypt the binaries on the users phones once they uncompress an app.

Also all the SV big-co have A/B testing practices with weekly release cycles that induces large line counts in their apps.

I think everyone copied the facebook mobile dev style, which simulates what you can do in webdev. In webdev there is no cost to adding another team for another feature that lives in some section of the greater app, since it's just another webpage. You can create many a/b tests and rollback things nearly instantly. With the weekly cycle everything is under a feature flag and you'll see a bunch of half developed features sitting in the delivered binary turned off via feature flag. This induces code size and creates these kinds of issues you see today.

Also large apps start requiring management structures that I call hallways and elevators. A single indie app can make a equivalent of a 1 room hut of an app, which doesn't require any hallways, elevators, floors, boiler rooms, parking structures or stairs. If you look at the layout plan of a highrise, you'll start to realize a lot of the floor space is taken up by the elevator and hallways.

Once apps become as large as a highrise, then they start requiring code structures that help manage the chaos, such as reporting systems, rollback systems, well defined tree structures and so on. That and the shear amount of rooms they have create apps larger than they look.

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

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

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.

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.