Showing posts with label App OS choice. Show all posts
Showing posts with label App OS choice. Show all posts

Wednesday, 15 October 2014

iOS8 apps GPS Always privacy battery concern

Why do the majority iOS8 apps access GPS all the time and is this killing battery life.

The short answer must be yes. A parallel example and some context can be found is the now growing by day popularity smart watch scene. The latest 920XT from Garmin battery lasts only 24 hours with GPS on all the time, and this almost doubles to 40 hours when using the GPS in a limited mode every minute rather than constantly. However, if we turn GPS off, but still leave the Bluetooth, WiFi (yes I am also bored of hearing misguided people turning Bluetooth off on their smartphone to save battery, ok it helps, but relativity is important...) and other smart features on, we get months of battery from the 920xt.
Smartwatch battery life varies between hours with GPS enabled, to months with GPS off, but still Bluetooth, etc on.... 
So go to Settings, Privacy, Location Services and prepare to be surprised, and then quite annoyed.

Surprised is first because you notice that pretty much all your apps are using location services always. Indeed I found this from the iOS alert to this very fact.
iOS8 alerts to the fact that all these apps are using GPS in the background
And then you look at the list and see responsible app developers either having "while using" only by default or allowing the option to be only using GPS when needed, the "While Using" option, like the amazing 645Pro camera app and Apple's own App Store by default: as it should be.

Responsible Apps are only using GPS while Using by Default.
So then you look at the long list of apps and see that from, yes admittedly I have a lot of apps on my devices at any given time. Surprise then shifts to annoyance as you try to make the Avis and Addison Lee (taxi) apps only use data when they need to, i.e when using: Why does Avis Car hire and Addison Lee, obviously now on their second app developer and fell out with their first (prey tell why two apps if not???) need to know my position all the time? in Case they want to surprise me with an unsolicited car? I don't think so!

Why do all these apps need constant GPS access?

And it is not just Avis, ist pretty much all except 5 of 55 apps.
Page 2

Page 3

Page 4

Page 5
After going through them all (and one iOS8 crash... #notwhenJobswasabout) I have managed to turn all that I can back (some apps have changed, sorry).

The Good are British Airways, Chrome and the Apple apps.
 I am very bored with clicking through apps now...
Facebook and Google leading the way
 About here is when iOS 8.02 crashed, nice... look for the whole section again...

Instagram, the amazing Manual and the great Netatmo, as well as other FB propoertises and Apple apps: good
 Nice to see Netatmo being responsible, and you can see that "Manual" is a showcase Apple app right here!

Speedtest the only one here other than native apple apps
 No surprise Ryanair not following British Airways's great example... I wonder if they plan to charge me extra for not being close enough to the airport when checking in?

Vivino and Twitter the only responsible app developers here in this last list
So why is this? Well a key part of the problem is that apps, and indeed mobile, are still "something we should do" for most big companies and brands, and they do not have anyone representing good UX reporting all the way up, which is just not a good plan in todays "mobile first" environment where Facebbook clearly does. The next question that comes along after battery life is; are these companies using / processing this info off the app? We all still remember the contacts scandal apps privacy of a few years back I am sure...

Friday, 18 May 2012

New G+ App for iPhone

So Google+ finally gets some love and gets and update that brings it into killer app territory.... and it has made it into the iPhone killer apps list as well as the Android killer apps list this was much needed, as in a report on my MVNO blog on Facebook activity being mainly mobile and the Mobile App store blog on even low end phones now getting Facebook integration: mobile social is now big business, in case you still had not heard!

So, without a decent app, Google+ may have been missing a trick for a while. yes, the tech savvy will create a shortcut to their homescreen, but this does not give you notifications (see my native vs. html5 debate for more on this) and for many people you still need "an app for that".

So what is all the fuss about?

Well firstly, it looks good. There is no denying, clean simple design is what Path, Flipboard and pulse have been soaring in popularity on, and this app now has it...

Secondly, it gets it... for a while I have seen posts on the point that Facebook photo implementation on the web is awful: Its true, while Facebook generally have great UE, the images are handled in a very "we installed this 3rd party tool" way; and the mobile app (with the exception of the windows Facebook app version with its panoramic view) did not show off photos as well as they could either. Even The Sun newspaper caught onto this a few decades ago: many people just look at pictures, especially if the content was written mostly by chimps, a point which both Facebook and The Sun newspaper largely share (sorry, could not resist, but at least Facebook has the excuse that its UGC (User Generated Content))

So yes, boys and girls, if you got pictures, show 'em off, and that is what Google+ app has done very well.

People living in UK will be able to pinpoint which day this was in the whole year :)
Here is my colleague Keith getting some inspiration, on one of the few days when a) there was sunshine and b) the lawn was actually mowed :) In fact, Google+ got it so right, that a certain other social network soon followed:
I wonder where Facebook got the inspiration for this "wide photo" update???
It would not be fair at this point if I did not point out that the Google+ app widescreen images, with subset picture of the poster, does not have influences from timeline on the web, its just amazing that these days, with articles like at the top of the page showing mobile has surpassed the web in terms of interface to all things social, that the apps are so neglected - but then I have always argued, that nothing makes a business take its eyes off the ball like having to pander to (still potential) investors...

if you want notifying when more articles like this come out, my Google+ and my company, Virtuser's Google+ or like Virtuser on Facebook for updates

Monday, 27 February 2012

Updated iPhone killer apps list

I have just updated the iPhone Killer apps list with a why-so for Pinterest, and why, like Path and Pulse (all beginning with "p"???) is not only important, but may replace Facebook as a benchmark app for an app store. Pinterest has the editorially defined quality of new, post-digital publications, like wired, wonderland and wallpaper (all beginning with "w"???) except its crowd sourced and allows instant interaction, its now not hard to see why pinterest already the top social network on global page impressions behind stalwarts Facebook and LinkedIn.

read more

Monday, 6 February 2012

Killer Apps Ecosystem

I have just updated the section on killer apps in general, as a) I read a good quote that gelled some thoughts on it, and b) had a discussion with a colleague in the industry that got me thinking, as well as the fact that I have as much more work in 2011 on SMS and HTML5 than on apps in 2009 and 2010... http://www.mobilekillerapp.com/p/killer-apps-in-general.html

Friday, 3 February 2012

HTML5 vs. Native app development

The HTML 5 vs Native debate was raging yesterday in the Mobile Monday London event (see my digest on this blog) and will continue to for a long time, just as the java vs. native did and the widget vs. native did, and just as much as the "which OS choice/debate" I discuss here in my blog as well

The reality is blurring with recent announcements of high profile games on HTML5 like cut the rope however the issues that I found when heading up the iPhone porting for Voda 360, the first major W3C HTML with APIs if not HTML5 still remain even with these successes.

Then I go out into the market and hear some game developers doing cross platform, some adopting HTML and other focusing on the multiple approach of iOS and Android, looking at HTML5 to cover the rest. That is with games at least, and will be the case of many apps with access to low level functions and APIs (beyond GPS, audio, video, etc).

With certain apps it is much clearer:  I spoke to a developer of a major social network that was launched recently who said they would never have gone native if they did it over again: the user experience is just two fragmented between the web, tablets and the main app OSs and then mobile web. I also know users who have ditched native apps for social networks in favour of the HTML5 experience: quicker, closer to the web, the same on tablet as smartphone and the closet to their web experience... and as a result I specified a social network for a client recently in html5 with native in potential roadmap...

Then there are the mobile operator clients considering portals and app store, more relevant to my portal blog, but still very interesting for the case in hand: Its important to maintain flexibility in these situations, and fix your roadmap (in scope) only for one or at most two quarters ahead. Just recently, for example, a mobile operator client was faced with a situation where their development on an app store/portal was lead natively on two platforms with another two following and another two in roadmap... when Microsoft announced that W7 was going to be a closed environment, symbian split, meego was sidelined and RIM became evidently more fragmented (bb5 vs bb6 vs bb7, etc) then the option was very clearly android plus... native or java or HTML5. It was still a little early then, but the answer would be much clearer today.

So, with so much depending on what you are doing where and with whom... and so much social, regional and international fragmentation, however there are some key considerations to take into account:
  1. what device is it running on? which will affect many things, but in short, running in  a sandbox without native extensions will be slower on things like
  2. refresh rate: while low end Java devices and even proprietary runtimes like Offscreen Media's were running 50-100 frames per second, the first web runtimes were at 3-5, with the best developers on best devices eeking out 10-15. Even if you get this much higher, its still a limiting factor over native, and those pushing the boundaries will always prefer native
  3. how many platforms are you going to distribute on. Its all very very well having a cross platform app and cross platform intentions, but do you have the time and resources to update APIs across 20 stores, check 100's devices, upload across many platforms, have the project management and roadmap skills to manage the process, etc, etc.
  4. What is your target audience now and later. if you are going after advanced users and then mass market then native first, html5 later maybe an option, if revered, then reversed, obviously. if you have a product like Sonos, why go to the extra effort of making the platform universal when all your customers will have at least one android or iOS phone or tablet at their disposal?
  5. What regions are you looking at? HTML5 will play better to strong growths in ever cheaper smartphones, like Africa, vs those with a solid smartphone base (Nokia in parts of Asia and Latam, others varied in US, Europe and ROW)
  6. Do the stores you are planning to roll-out on have the features and APIs you want? There is no point creating your freemium app that requires in-app upgrades or subscriptions in HTML5 for flexibility if it would have been quicker to do it natively in the two stores that support what you want to do, and the ad serving and other APIs are completely different in each deployment
  7. Do you want to be off-line?
  8. Do you want to obfuscate and/or only have certain functionality using server based algorithms for extra security.
Its interesting times, I shall be updating this article as more interactions with clients and colleagues provide more scenarios, and will announce those changes here at my Google+ and my company, Virtuser's Google+


Tuesday, 24 January 2012

Mobile App OS choices

When deciding what OS to go out on there on are a number of factors to take into account, unfortunately, as with most things apps, all most people is see is numbers. Numbers are important, if you want distribution, but it is also important to look at the product, who uses it and its fit.

Bloomberg, for example, an app I have helped port to different OSs, is a great fit for Blackberry, Nokia and iPhone as the key business phones in the key Bloomberg markets: finance. While it may be good to be everywhere, you have to ask the cost of that and the incremental gains. Moreover is managing all these versions - they may be within budget to build, but as new services are rolled out, managing a roadmap across lots of mobile OS and their subsets (BB6, BB7, ipad, 3G and 4G screen sizes, etc) can become costly and difficult to manage.

Spotify is on Meego and the Nokia N9, as well as iOS and Android, but not on windows market; why - well the N9 has hit a sweetspot and will ship around the world to the kind of audience who will pay for a premium service, and the are relatively few apps on the device. Sonos is just on iOS and Android, probably based on the premise that while its users have other devices, if you have a premium music device, you will have either a tablet with the aforementioned OSs or a dedicated controller.

Social networks want to be pervasive, however with each OS version comes fragmentation, then there is the issue of prioritising the versions when you update an API and risk offending part of your base: the only option is to update all at the same time or plan very, very carefully and risk backlash! An developer from a social network recently told me that if they did it all again they would do probably just one or two native apps (no prize for guessing which ones) and the rest in HTML5 - he then corrected and said - no, I would do them all in HTML5 and have done: after all you get the most important APIs: location, audio and video, working out of the box, across all devices, in one go. How important is this, well very;
  1. one it means you can stay on or ahead of the curve - rolling out new services on mobile almost or even in parallel
  2. it means you avoid embarrassing issues like the iOS facebook app that recently had everybody in London posting from Walton Abbey for a while
  3. moreover, fragmentation is minimal: another developer recently expressed that his users have upto four different experiences of their product: one on a tablet at home, another on a PC at work, and then another one or two on their work and personal mobiles
A weather app, like accuweather for example will have different priorities, from bums on seats to strategic deals, which will see them having everything from bespoke versions just for the Nokia N97 and Voda 360 homescreens (yep I did that, it seems to be everywhere now, from samsung in store ads to tablet online promos - which is great) to then being on maybe android more than iOS now (how many weather apps must there be on the App store!).

So, in short there are many things to consider:
  1. What APIs if any you need and which support them and which handsets. Apple is still all inclusive (all devices have a compass, gps, etc, etc) however other devices / OS have all sorts of fragmentation 
  2. how easy is it to integrate the service you want on that platform and which platform(s) Android is not too far from Java J2ME, you may want to focus on this from the beginning
  3. How much is your app, how important are ads vs. revenue, freemium support
  4. do you have the need for fancy functionality such as in app subscription, upgrade, etc.. your mileage WILL vary by OS
  5. How important is design and brand. Apple are very aware of the style, UX, fonts, etc and encourage homogeneity with the OS, a clean experience, etc. This means not only is the experience generally more "pleasing" for want of a better word, the apps around it are generally of a high, homogeneous quality as well: no negative association. Android are now starting to do this as well, as per this new announcement of a few days ago of a style guide. Believe it or not, Vodafone were doing this in 2009 with Vodafone 360 and Nokia did it with their own beta apps but that is it.
  6. Your target audience: How many people use and will pay for your service: you may get 500,000 downloads for free on one platform vs 50,000 paid for on another... quality is generally better than quantity.. (unless you are targeted on quantity, of course!)
  7. The submission, update and approval process
  8. The stats, settlement, promotion, how easy will you be to find on the store, etc
  9. what phones your analysts have (if you are quoted :))
  10. can you do it in HTML5, get the usage and adoption stats, build on what you know, not what you think... so much time, so many wasted features have been built over the years on assumption: just get it out there!
Hope this helps...