It’s not resolution independence, but it has the potential to make asset production much less painful. I don’t know if this approach also work for app icons or only for things like button and toolbar images.
Of course it'd be better if this was done at run time on the device, and bitmap representations cached as required (eventually they probably wouldn't be, even if initially they are).
http://oleb.net/blog/2014/08/replacing-launch-images-with-st...
I seem to recall Marco Arment took a bit of pride in having 100% procedurally generated graphics with overcast, so that he didn't have to create/ship any bitmapped images whatsoever.
The tools are there by Apple, but I don't think the hardware until fairly recently could really justify the performance hit - instead choosing file size over performance. These days though, in the majority of cases, the performance hit is negligible (especially when compared to dev/design time of generating @3x assets years/months later)
That's interesting, I might try that for launch assets, though it can't be used for app icons, I'd love to just drop in an svg and let the OS scale my icon.
Unfortunately the default path (including many default assets like icons and launch screens) is to produce tens of raster files generated from the original vectors and bundle them with the app which is wasteful, painful and prone to break with new hardware.
The pixels of the screen are now so small they have almost disappeared, so I think there's an argument we have reached the place where going mostly vector makes sense.
Clearly some assets will always be bitmaps (photos), but so many others are not well represented as bitmaps (icons, text etc) - content is fine as bitmaps but controls and chrome are usually better as vector.
IMHO this is what Apple should have done a long time ago, certainly on ios. Yes it has issues, but those issues are mostly faced by the OS vendor once, and have been successfully dealt with in the case of font rendering for example with antialiasing, hinting etc. You don't hear anyone decrying fonts being vector formats and asking to go back to pixel fonts nowadays, and resolutions are only going to increase.
The OS should be handling rendering, hinting, caching, raster representations based on vector data. As you point out this is a hard problem and Apple are uniquely qualified to handle it. Instead Apple have punted on this and developers are actively encouraged to produce raster representations of each asset which break for every new device which comes out (as you point out this doesn't just apply to fonts).
Controls like buttons or custom ones should be drawn in code, not included as raster assets, and the iconography for things like buttons, launch screens, branding or other app-unique assets could be stored as the original vector, as it should be. If you want to put a raster image on a button, well, sometimes that's not going to look good.
On top of the problems caused by resamping, what Apple have done instead of choosing the vector route is create an ever-growing headache for developers and themselves by focussing on raster assets and requiring pre-rendered bitmap reprentations of assets like icons, which usually start as vector anyway. How many different pre-rendered sizes of ios icon are we up to now, 20? Where does it end? This is not practical or forward looking, it's a hack which imposes real costs on developers, customers and Apple - there is a huge amount of work in creating and maintaining all the different launch screen, icon and other assets now required to be rendered at 3 or more different sizes for Apple devices, and this is bloating every single ios app with multiple megabytes of assets which could be generated on the fly from their vector representation, over the entire app store that alone is a huge waste of bandwidth for Apple and customers.
So there are lots of reasons to aim for real resolution independence, and from the point of view of developers, Apple chose a quick hack (which has devolved into a hacky mess over time), over a more difficult, forward-looking solution which anticipates that screen sizes and formats are going to multiply until it is impossible to cater to all of them with raster designs.