By not having Android support for a start, which chews up insane amounts of RAM On top of that, significant amounts of hard work, and some interesting smoke and mirrors tricks. I don't remember everything clearly so much later but here's some (from the application side, which is where I was focused): Dropping OpenGL contexts and using software rendering of applications when they moved to the background (something which SFOS adopted sometime during 2014 to some extent, windows drop contexts when they move to the background) Dropping caches in applications when they move to the background on a similar basis Low memory notification (this is something that the upstream Linux kernel itself *still* lacks, Android has this capability to some extent) to drop caches/etc Ironically enough, RAM was (in my opinion) a very big problem there, even if you don't think so. Some parts of the software were rather huge in complexity/requirements, and slimming it down was never really a possibility due to the need to push the thing out the door (and then, well, keep it going out the door as much as possible). This showed as particularly painful in application startup time, and this is why most of the software on the N9 (that is built in) is pre-started, and just shown when the icon is clicked. Mercifully, this was avoided for most of the UI on SFOS with the exception of Phone (which, for responsiveness reasons, it does make some sense to keep running) and Messages (which was kept running due to architectural reasons; maybe some day that'll be fixed if it hasn't been already). I would have to say that the biggest problem SFOS faces in this regard is resourcing. Nokia had significant engineering resources to throw at this (and many other problems), Jolla not so much. For instance, significant performance improvements have been made to QML's JavaScript engine since its introduction in Qt 5.2, but taking that into use is a very large work project, so I don't see it happening anytime soon.