Android why developers cant produce lean applications (smaller size)

Status
Not open for further replies.
M

mymatl

Contributor
my experience with htc explorer

earlier days i used to have 6-7 apps installed on my mobile

now i cant install more than 1 app other than playstore :mad:

in my opinion developers should create leaner applications, i mean of lesser size which saves data and further time and further environment :p
 
First of all, you're talking about a 3 year old phone that too a crappy one with 90MB internal memory(better phones were available in that price then). And do you have any idea how app development takes place? And as new API's are added, apps tend to be heavier.
 
Last edited:
not only mine
my colleagues galaxy grand with 1gb ram also struggling with space issue

may be i am also at mistake here
so while buying phone which memory should be consider for installing large apps....internal memory or ram?
 
Yeah my galaxy y too has the same problem . use link2sd . still a portion of the app will occupy internal memory . better to upgrade .
 
This was the reason why Google stopped SD card support entirely in early builds of Kitkat. Most OEMs had to add own code to bring it back. Google had to later add the support back due to demand.
Still 90MB is too low. HTC has the habit of making useless low-end phones.
 
  • Like
Reactions: Phan7om and ayanavish
AFAIK majority of the size of an app will be taken up by the resources (i.e the images you see within the app, icons and so on). Since android supports different screen resolutions, I think the same image have to be re-sized multiple times and put in different folders for different resolutions. Next thing that adds to the size is some of the libraries bundled with the app to make it work evenly across different versions and also added functionality. In most cases, the app developers use readily available ones and dont have much control over its size. The actual code of the app will be in kilobytes.
 
  • Like
Reactions: pauldmps and nishthecooldude
pauldmps said:
First of all, you're talking about a 3 year old phone that too a crappy one with 90MB internal memory(better phones were available in that price then). And do you have any idea how app development takes place? And as new API's are added, apps tend to be heavier.
Click to expand...
Wrong argument.

As new APIs are added, apps does not need to be heavier. New APIs doesn't mean you replace old ones. So devs use old API s and still make it work.

It all depends on how OS, APIs and Devs are doing it.
 
  • Like
Reactions: thrift
With higher resolution screens coming out & apps moving to material design, the embedded resources are getting heavier. Also support for both old and new APIs has to be there:
Code: 
if(build.version.sdk_int = build.version_codes.kitkat)
{
code for new api............
}
else
{
code for old api...........
}
 
  • Like
Reactions: nishthecooldude
Similarly, a simple if block can remove all the unnecessary assets/media files/material crap. All this embedded sources can be removed.

And that if there is really an if block, which checks for version every time, God bless the devs.
 
^^ That is how support for APIs are implemented for every app.
Blame fragmentation. Most devs need to support from 2.3 to 5.0. There are plenty of necessary API missing from 2.3-3.0. Plus the apps need to adhere to design guidelines which varies for different versions of Android.
After the introduction of Lollipop, now the runtime has changed from Dalvik to ART so now the apk has to have two different format of binary executables in it.
Multiple apks are supported by the Play Store but its more hassle than its worth.
 
pauldmps said:
^^ That is how support for APIs are implemented for every app.
Blame fragmentation. Most devs need to support from 2.3 to 5.0. There are plenty of necessary API missing from 2.3-3.0. Plus the apps need to adhere to design guidelines which varies for different versions of Android.
After the introduction of Lollipop, now the runtime has changed from Dalvik to ART so now the apk has to have two different format of binary executables in it.
Multiple apks are supported by the Play Store but its more hassle than its worth.
Click to expand...
Then that's a bad implementation. So NO, I won't blame fragmentation, I would blame implementation And also devs shouldn't worry about runtime, Dalvik or Something else, OS/APIs should handle that. If you are worrying about underlying tech, what's the point of APIs?

Here's one more example, Nokia N79 running latest version of Whatsapp, has all support of new features. N79 has 50MB of RAM, runs Whatsapp pretty nice, lol:
image.jpg
image.jpg


My point is, just cos a device is shitty, doesn't mean it cannot run apps. I would blame Android than on devs:
1. The way APIs are exposed
2. How OS/API work with each new version
3. Poor optimisation
 
I agree on the poor optimisation part. But you cannot expect better for an OS that works on a wide range of devices to be optimized for each and every one of them. As time passes, newer software would require more powerful hardware. Whatsapp may run on Symbian but the main reason Symbian failed was that it couldn't evolve. The same WhatsApp takes 40-50MB RAM on a Android device.
I am not worried about the underlying tech but wanted to give you an idea on what factors contribute to the app sizes are increasing day-by-day.

And people have to upgrade. Just the way you need to upgrade your GPU or add more RAM when a every few years for the latest game to work on your PC.
 
There are several reasons for the increasing size of the apps and no, its not always about developers being lazy. As far as laziness is concerned, the primary type of laziness from developers that I see is cutting corners by building packaged web/hybrid apps instead of native apps and they tend to be bulky and poorly optimized for all of the platforms they run on. Apart form that, there are several other reasons many of which are not really the developers fault.

Some platforms like especially iOS have hard line restrictions that each app should be completely standalone. So for example if you use a popular framework that weighs 10 MB and you develop 10 apps using it and some other developer makes 5 apps, over the framework size, if the end user is installing all 15 apps, the framework size would be duplicated that many times. lets say that the application code is just 2 MB for each app, so instead of 2 x 15 + 10 = 40MB, they will take 12 x 15 = 180 MB.

Furthermore, majority of the bulk of mobile applications is the various assets packaged in the app.

Despite the small size, you have Full HD and Quad HD displays on phones and in next few months, we will be have 4k displays on phones and tablets. Think about how much high resolution assets add to the weight of the app. Further more, you have to cater for multiple resolutions. so in all probability, same assets in multiple resolutions would be included in the package and used as per the device specs. Developers cannot make separate packages for each combination of specs and assets cannot be selectively installed by app stores.

As an example, I was working on a Windows Phone app till recently. The code is spread across 80 assemblies that were written in C#. The app bundle that we were producing was about 4.2 MB in size, the 80 code assemblies combined together constituted just about 1.2 MB. 3MB was the compressed images, audio and font assets. This was with assets for 800 x 480. When the 720p assets were added, the app size was nearly doubled. Imagine adding 1080p and 1440p assets to that bundle. The code size was still 1.2 MB.
 
Status
Not open for further replies.
Top Bottom