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 j…
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.
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!
+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.
I have a limited understanding of how this works, but could it be that app devs are leaving debug stuff in the builds, and not removing that when it gets pushed to production? Please, educate me. I'm all ears. :)
Often, it's really bad design. For instance, Facebook's app has 18k classes. In other cases, it's a lot of big 3rd party libraries.
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.
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.
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 element to get a rasterized view of the SVG in the desired size, and save the resulting image.
Not sure that Apple has any interest into reporting smaller sizes.. They have interested in having lower download sizes (less strain on their servers) and users buying the bigger and better memory storage.. Along with the iCloud subscription of course..
They're working at making smaller apps on people's iPhones. They strip out all the graphics that don't apply to the given phone that's downloading on, plus bitcode is compiled for the specific architecture, so you don't have multiple architectures installed that you don't need.
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 failin…
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.
+1. Also, it's a plus for apple if people would buy 128gb version of iphones instead of 8gb ones...
> which will not clutter up your distribution, it will just clutter up some apps. Not necessarily. Distributions have to build everything, and in openSUSE we have an integrated build system[1] which has a lot of very useful features (rebuild when dependencies are updated, and automated QA runs before releases). Those features require you to have all of the dependencies of a project in an RPM package. Even if you don'…
I had no idea about this - thank you for bringing it up! But we seem to be discussing different ideas. I was trying to argue about apps, specifically iOS apps, like the original article was about. iOS apps aren't distributed on openSUSE, so if some devs make some kind of libleftpad.o for Objective C developers making iOS apps, I'm saying that's fine, and I doubt it would clutter up your distro because Objective C isn…
Ah okay, I was talking about things like electron applications or desktop/server javascript projects. If you want to use $latest_js_web_framework and package it in a distribution, you're going to be in a world of pain (the same applies for Rust because their package management was based on NPM).
> 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.
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.
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 bu…
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.