If you're in any doubt about what I mean (as if!), the screenshots above should remind you, somewhat forcibly. Back in the 1990s, my Psion palmtop computers ran a full multitasking operating system on a processor as low as 8MHz, several hundred times slower than today's multi-GigaHertz systems and with 500k of RAM, well over a thousand times less dynamic memory than today's Lumias. And I could switch between applications instantly, each popped up on screen with zero delay or wait time.
Most of today's top Android handsets, with modern specifications, at least live up to the same promise - with all your favourite applications shortcutted on your home screen, a tap on each and you're instantly 'there' and instantly productive. As you damn well should be, with such monster resources under the hood.
So how come we have multi-GHz, 1GB or 2GB RAM Lumias leaving you and I hanging around for one or two seconds, maybe fifty times a day? Not only does this all add up, the biggest factor is the frustration at seeing something which should be instant take its own sweet time. While you grind your teeth and wait.
The 8.0 issue
You may have noticed that not all third party applications behave this way - some leap up immediately, as if turbo-boosted. The problem is that most current applications are compiled for Windows Phone 8.0 and its UI guidelines. As a result, many don't work well with the current Windows Phone 8.1's expectation for full support for 'fast resume'. Under 8.1, it's assumed that everything will play nicely with being 'suspended' and then immediately resumed - even if activated from the Start screen or applications list (remember that the 'old' behaviour here was to start a new instance of the app) - and this isn't currently the case.
I looked at 20 or so top current Windows Phone applications, by Microsoft itself and by third parties, and tested* to see which ones were optimised for Windows Phone 8.0 and which for 8.1. (Obviously, 8.0-compiled apps work under 8.1, but not the other way around.**)
Note that I'm simplifying the situation slightly, since there are several ways of building apps for WP 8.1, but these should be transparent to the user.
* in part through the simple expedient of going into the application, then pressing 'back' and seeing if the app is listed in the multitasking carousel - 8.1-optimised applications should be (if coded properly), 8.0-compiled apps are immediately tombstoned and shouldn't.
** developers get round this apparent break in compatibility by using a feature of the Windows Phone Store wherein different builds/versions can be offered to users, depending on OS version.
|Apps||By||Optimised for WP 8.0||...and for WP 8.1|
|Tubecast PRO||3rd party||Yes|
|Nextgen Reader||3rd party||Yes|
|Aerize Explorer||3rd party||Yes|
|(Bing) Weather etc.||Microsoft||Yes|
|Video Editor 8.1||3rd party||Yes|
As you can see, roughly half the top applications are still on '8.0' and/or have yet to be recompiled and optimised for Windows Phone 8.1. Third party developers are either/both:
- waiting for more users to be on 8.1 after the Lumia Cyan and similar over-the-air rollouts (we're surely getting up to around 50% right now and will be at 75% within a month or two?)
- putting off the recompilation/optimisation, as it will also usually mean maintaining two binaries, one for the older 8.0 and one for 8.1
The end result is that, even with a Lumia Cyan smartphone, pop back to Twitter or Skype or similar, either having pressed 'back' to switch away from them or simply having not used them for a few hours, and there's often the usual annoying 'resuming'-style wait while the OS struggles to resurrect the 8.0-compiled application to full operation. What I'm hoping is that we'll see a rush of updates throughout September and that revisiting a table like this will see far more 'Yes' marks in the right hand table. Along with a faster user experience when jumping from application to application.
All applications should support 'fast app resume', all should work with 8.1's expectation that this mode is enabled and available.
It's also worth noting that the faster, newer phones (e.g. Lumia 1520, 930, HTC One (M8)) reduce the existing delays somewhat, even for 8.0-compiled applications. As does (the Developer Preview of) 8.1 Update 1. In summary, it all helps, and the newer the better.
Developers, it's over to you!
PS. If there are other particular good or bad examples, in terms of applications, then feel free to name and shame in the comments below.
UPDATE: Following some comments (partly justified), we've clarified a few of these concepts in an interview with a knowledgeable developer here.