Nokia To Be a Smartphone Vendor Again

nokiaThis site was born 10 years ago in the era when Nokia was the top smartphone vendor and the iPhone and Android didn’t exist. February 2011 was turning point for me when I said that Nokia were heading off in the wrong direction and shortly after that I went ‘Android only’ from working on all mobile platforms at that time. Microsoft ended up taking over the Nokia handset division and more recently, according to Wired, Microsoft finally gets that it won’t win the smartphone war and Stephen Elop is leaving the company.

However, there’s a twist to the story. Tomi Ahonen is quoting Nokia CEO Rajeev Suri telling German periodical, Manager Magazin that Nokia will return as a brand to smartphones in 2016 as the exclusivity period out of the Microsoft deal ends. Tomi says “Obviously these will be Android based”. I’d like to think so. However, as the past has shown, companies don’t always follow what might seem like the obvious path.

Samsung Keyboard Vulnerability Learnings

nowsecureThere has been lots of press about the recent Samsung keyboard vulnerability. The vulnerability comes about because a new language can be downloaded under a privileged context which can be network hijacked to run arbitrary code.

Many articles mentioning this vulnerability are over sensational because it’s very unlikely that the user/app would download a new language pack AND be on a hijacked network taking advantage of the vulnerability. However, I think it’s more useful to pull apart the vulnerability and look for simple learnings to apply to other existing and new apps.

There are three main problems…

Supply and Demand for Enterprise App Development

Gartner has a new press release on how the demand for enterprise mobile apps will outstrip available development capacity five to one. Their survey on mobile app development conducted in 2014 found that the majority of organisations have released fewer than 10 apps. A significant number of respondents haven’t released any apps. Gartner says…

“This is an indication of the nascent state of mobility in most organizations, with many organizations questioning how to start app development in terms of tools, vendors, architectures or platforms, let alone being able to scale up to releasing 100 apps or more,”

There’s an increasing pressure on IT departments to develop a larger variety of mobile apps in shorter time frames. Gartner suggests some best practices in their press release that includes prioritisation, process, use of RAD tools and mixed-sourcing.

My thoughts on this are that while RAD (cross-platform) tools might be ok for internal use where users are more forgiving, their use on customer/consumer facing applications usually results in too many lowest common denominator tradeoffs in terms of functionality, performance and look and feel. I think that lack of productivity in the enterprise has a lot to do with how app development is being done and using RAD tools is trying to fix the symptoms rather than the cause – which then causes new undesirable side-affects.

The companies I come across tend to be of two types. The first, as Gartner identifies, have been internally arguing over who and how mobile development should be performed within the organisation and such cases usually result in separate parts of the company going it alone with separate outsourced work. This causes many internal and external problems, one external manifestation being multiple app publishers from one company.

The second type of company I have seen is those trying to do it all in house and running up against productivity barriers. There is often a common theme of building things from scratch rather than re-using open source libraries due to not knowing what libraries are worth using. There are also other common problems such as using non-iterative processes, no tracking tools, not creating domain specific libraries for re-use and lack of knowing what to test. Experience how to best go about things and productivity are related.

In many cases enterprises just need a little extra help via consultancy or a single, experienced ‘head of mobile’ who has seen and experienced most of the problems.

New Android ‘enjarify’ Decompile Tool

It’s very easy to reverse engineer most Android apps using dex2jar, JEB or Dare and there are even online tools that can reverse engineer an app without having to install any tools.

Each tool has its own limitations and those limitations are often used by other obfuscation tools to make reverse engineering more difficult. However, to make things even easier, a new tool enjarify has been ‘unofficially’ released (presumably means there’s no support) by Google that claims to resolve many of the limitations of dex2jar such as support for unicode class names, constants used as multiple types, implicit casts, exception handlers jumping into normal control flow, classes that reference too many constants, very long methods, exception handlers after a catchall handler, and static initial values of the wrong type.

I can’t see why Google would want to release such a tool other than it’s the result of a Googler’s 20% ‘free’ time. It will probably encourage more copied apps, ip theft and thwarting of in-app purchasing.

However, it does serve to emphasise how much more sophisticated and easier decompilation has become over time. You shouldn’t rely on the fact it’s difficult to do nor assume what might have protected your app in the past will protect it now or into the future.

New Mobile Marketing Market Map

firstpartnerFirstPartner has a new free (registration required) Mobile Marketing Market Map that clarifies the mobile advertising ecosystem. It covers areas such as  audience, contextual data, cross-screen targeting, analytics, attribution, acquisition, monetisation, proximity marketing, permission based messaging, loyalty and couponing.


Protecting Android Java Source Code

A common question I am getting from clients at the moment is “How do I protect the (Java) source code” in a shipping app. The short answer is you can’t. No matter what you do, a very determined hacker can recover something that resembles your code. However, you can make it much more difficult. I have written a lot about obfuscation and re-packaging on my Android Security site. You might also like to read about using the NDK and tamper prevention as it’s also possible the recover the code from optimised dex/oat files and even from memory.

The thing with this and many other aspects (e.g. UI design, testing) of mobile development is that the chosen strategy should usually depend on the actual project. Some developers tend to be dogmatic and mandate ‘this’ and ‘that’ approach but do no listening, questioning or assessment. There are many ways to do things and some might be better than others for a particular project or might indeed not be worth doing at all.

Android M Permissions

googleio15Of all the changes coming out of Google I/O 15, the new permissions model will have the greatest longer term impact on developers. I say ‘longer term’ because for existing apps on existing phones, users will see no difference. Existing apps on phones running ‘M’ can have their permissions taken away by the user which will, no doubt, cause them to malfunction and possibly cause confusion for the user (and people supporting the app).

The real power and possibilities come when an app is built for ‘M’ (or in the future ‘M or later’). Developers and designers now really have to think hard about their messages to users. There’s an article on Medium about the Cluster app, on iOS, that covers similar issues and the complications.

The good thing is that (‘M’ built) apps will no longer sit around, as now, waiting for the user to upgrade when they need more permissions. The down side is that the user disallowing a permission can seriously bazooka your app and you need to really try your hardest to explain to the user why a permission is needed.

Obviously, more transparent permissions is good for everyone – in theory. In practice, I find many clients and some designers already have trouble agreeing/deciding how screens and messages should look and feel. Adding permissions screens/dialogs into the mix is bound to lead to protracted mobile development, more testing of permissions-based scenarios and more support needed when apps don’t work due to revoked permissions.

New 2015 KPCB Internet Trends Report

kpcbKPCB’s Mary Meeker has a new free 197 page 2015 Internet Trends report. It provides some useful numbers on how the use of the Internet is moving to mobile…


A new insight is the increased use of vertical viewing brought on by the use of smartphones. This has implications for those of us designing and creating content for mobile and perhaps whether we should support both horizontal and vertical screen orientations.


Of interest to mobile developers, the report also has lots of charts and information on enterprise, messaging platforms, user generated content, just in time products and services, commerce, freelancers, regulation, China and India.

Finally, it also includes a useful chart on the ‘big’ smartphone markets…