Hacker News Reader

Comment by donbronson | Hacker News Reader

Where is native support for iOS and Android? Why do we bother generating the same assets for different screen densities? Am I the only one who wants SVGs on mobile?

View on HN

One of the things I like about hybrid apps (Cordova, Ionic, etc) is that this is a solved problem since you basically develop on top of Chromium (Android) and WKWebView (iOS). I already do heavy use of SVGs on mobile apps for everything, including animations, and I'm quite happy with the results and the workflow. No more asset-hell, everything's a vector.

Design once in Illustrator (export SVGs) -> Code once -> Run everywhere

Everything supports SVG 1.1 these days (the end of the article talks about this).

http://caniuse.com/#feat=svg

I think the OP means in the native SDKs for those platforms.

Correct!

https://github.com/jmenter/JAMSVGImage

Android supports a sub-set of SVG in its VectorDrawable and AnimatedVectorDrawable classes. There is also tooling to convert SVG into VectorDrawables.

It is definitely a partial subset and creating VectorDrawables from any sort of design program is a giant PITA. The best strategy is making an SVG and then going through the XML by hand and turning it into a drawable (ugly I know).

Clearly this is the future direction of Android, but as of today it is still only half implemented.

As for why we didn't have SVG from day 1 on Android, I'm going to guess that is all a performance optimization. It's hard to overstate just how slow & weak early smart phones (iPhone & Android) were relative to today. We've expanded the scope of the apps to fill the available resources (as software engineers always do), but now there is enough head room to handle it all.

This is a fantastic point. Made me google around, seems this was added to Android Studio 1.4

https://www.youtube.com/watch?v=8e3I-PYJNHg

Even better, they get converted to PNG at build time for older SDK targets that can't display SVG.

Your move Apple.

Apple & Xcode support the same concept, but with PDFs. You can add a PDF to an "imageset", and at build time it will be rasterized into different resolutions for different devices.

Because you have to basically implement half a browser for SVG. You need to parse the XML into a DOM and apply CSS that you also need to parse (also javascript in case of animated SVGs that use JS)

SVG specification distinguishes two types of conforming SVG viewers: static and dynamic [1]. The static viewer does not have to support scripting, animations and user interaction.

A good example of a relatively small static SVG viewer/renderer is libRSVG which is used by GNOME project to render icons.

[1] https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewe...

[2] https://en.wikipedia.org/wiki/Librsvg

"relatively small"

The library takes half a megabyte under archlinux: https://www.archlinux.org/packages/extra/x86_64/librsvg/

It also requires a 1.2 megabyte css parsing library: https://www.archlinux.org/packages/extra/x86_64/libcroco/

And of course also a 8.8 MB xml parsing library: https://www.archlinux.org/packages/extra/x86_64/libxml2/

Now compare this with libpng:

https://www.archlinux.org/packages/extra/x86_64/libpng/

half a megabyte and the only real dependency is zlib, which is also in the dependency tree of librsvg

The main size is dealing with libxml, but that's readily handled by smaller xml libraries [http://pugixml.org]. I mean, maybe you don't want to do SVG on an arduino.

Directly comparing SVG and PNG libraries purely based on library size is misleading. PNG's aren't layered, don't contain semantic information, etc. For me librsvg is lightweight since its way better than installing phantomjs as I have been doing to generate embedable PNGs for documents.

Xcode supports PDF IIRC. I think it bakes them into PNGs, 'cause performance.

Reply on news.ycombinator.com