OT: The Size of iPhone’s Top Apps Has Increased by 1,000% in Four Years

JeffChasteen

@Pavel said:

@TheVimFuego said:

@Hmtx said:
Moral of the story:

These apps are now 10% function and 90% data mining?? (Anonymous, of course. Don't be evil, right?)

Or big companies have gotten sloppy with their code?

I hope there is a less depressing reason for this.

Generally people now code with "frameworks" that add a lot of bloat. And much extra stuff like differing resolutions, screen sizes probably doesn't help.

That and better performance of the devices means the devs don't have to count every machine cycle.

This is the real reason. Hardware is relatively cheap. And A9, A9X, and A10 chips are beasts. Cheap beasts when you compare value for money. Developing software is not cheap and testing new code is lengthy and expensive.

For the most part, developing today is built on layers and layers of abstraction, like lego bricks, where you focus on core logic for your function and don't worry about writing "bricks" that handle problems already solved by others, like memory management or user interface logic.

If you have used Audulus or Analog Kit modular synth you get the concept. Why rebuild from scratch an envelope when I can use one from the Audulus built in envelope? And if I edit an envelope control, I can see how complex it is. All that sublogic....

Differently from Audulus, however, these frameworks for app development are many and contain all of the different functions a developer might call on. They are vast, and very very useful to anyone programing their vision. It is not easy to tear the "bricks" apart without introducing the possibility of bugs, because they depend on and relate to each other.

There are three ways you can call on these "modules" :
1. call them over the Web : saves local space but your app won't work offline and is lower performance.
2. Pack them all in : application bloat and potentially performance problems : but just throw hardware at it
3. Ensure apps share the same modules : requires planning and coordination not only across development teams. Works for opensource, but not for Apple. Apple would have to approve the local shared library in their OS release. To a great extent they do, but not at the pace of iOS app innovation.

Once upon a recent time, companies would use the frameworks, and test their fat app, but then go through a code optimisation, recompilation, and retest before release. That's just not necessary when hardware is so powerful. People are expensive.

Option 2 is the rational choice in our decade. Most people have way more space than needed in their iPad and iPhone and only run into space problems when they have too many selfies.

I am sure, like me, when you show your iDevice to someone they are shocked by how many apps you have. Who would need that many apps? ;-)

But we are a rare minority, uninstalling one IAP or another to make room for that shiny new drum machine.

Companies market to the 99%, as well they should, and the careful choice to go to 128 or 256 as the standard storage size, but provide a 500 option for "lunatics" like us at a premium, well it's just good business

All of this still does not explain how @brambos packs so much goodness into so little space. Artist coder? 1970s code jockey? Zencoder? Who knows? Let's make music.

Thanks, that was very informative.

Littlewoodg

@JeffChasteen said:

@Pavel said:

@TheVimFuego said:

@Hmtx said:
Moral of the story:

These apps are now 10% function and 90% data mining?? (Anonymous, of course. Don't be evil, right?)

Or big companies have gotten sloppy with their code?

I hope there is a less depressing reason for this.

Generally people now code with "frameworks" that add a lot of bloat. And much extra stuff like differing resolutions, screen sizes probably doesn't help.

That and better performance of the devices means the devs don't have to count every machine cycle.

This is the real reason. Hardware is relatively cheap. And A9, A9X, and A10 chips are beasts. Cheap beasts when you compare value for money. Developing software is not cheap and testing new code is lengthy and expensive.

For the most part, developing today is built on layers and layers of abstraction, like lego bricks, where you focus on core logic for your function and don't worry about writing "bricks" that handle problems already solved by others, like memory management or user interface logic.

If you have used Audulus or Analog Kit modular synth you get the concept. Why rebuild from scratch an envelope when I can use one from the Audulus built in envelope? And if I edit an envelope control, I can see how complex it is. All that sublogic....

Differently from Audulus, however, these frameworks for app development are many and contain all of the different functions a developer might call on. They are vast, and very very useful to anyone programing their vision. It is not easy to tear the "bricks" apart without introducing the possibility of bugs, because they depend on and relate to each other.

There are three ways you can call on these "modules" :
1. call them over the Web : saves local space but your app won't work offline and is lower performance.
2. Pack them all in : application bloat and potentially performance problems : but just throw hardware at it
3. Ensure apps share the same modules : requires planning and coordination not only across development teams. Works for opensource, but not for Apple. Apple would have to approve the local shared library in their OS release. To a great extent they do, but not at the pace of iOS app innovation.

Once upon a recent time, companies would use the frameworks, and test their fat app, but then go through a code optimisation, recompilation, and retest before release. That's just not necessary when hardware is so powerful. People are expensive.

Option 2 is the rational choice in our decade. Most people have way more space than needed in their iPad and iPhone and only run into space problems when they have too many selfies.

I am sure, like me, when you show your iDevice to someone they are shocked by how many apps you have. Who would need that many apps? ;-)

But we are a rare minority, uninstalling one IAP or another to make room for that shiny new drum machine.

Companies market to the 99%, as well they should, and the careful choice to go to 128 or 256 as the standard storage size, but provide a 500 option for "lunatics" like us at a premium, well it's just good business

All of this still does not explain how @brambos packs so much goodness into so little space. Artist coder? 1970s code jockey? Zencoder? Who knows? Let's make music.

Thanks, that was very informative.

I learned a lot, thanks. And thanks @brambos for doing it the way you do...