Mobile development takes root; application analytics go mainstream

We’ve just finished up another survey tapping ~8,000 developers; mostly (although definitely not exclusively) of the .NET variety – and I think there’s little room for doubt; the rise of mobile and modern apps is having a profound impact on the way developers work and the tools they use.

What a difference a year makes

We did a similar survey in September 2012 (Who cares about application analytics? Lots of people for lots of reasons) and, even then, the interest in analytics was obvious – but interest had not yet translated into action. 

In Sept of 2012, we reported that 77% of development and their management had identified “insight into production application usage” as influential, important or essential to their work, and 71% identified “near real-time notification of unhandled, caught, and/or thrown exceptions” in the same way.

…BUT, at the same time, only 30% indicated that they were doing any kind of analytics in practice (exception reporting, feature tracking, etc.).

“More people believe that the world is flat than doubt the positive role of application analytics on development.”

Today, that 77% and 71% of developers who “got the value of analytics” is now a solid 100% and 99.5% respectively (for those that don’t do surveys, you have to appreciate that a 100% opinion is virtually impossible to find – you’d have a hard time getting a 100% consensus on the shape of the planet (round or flat) or even the role that aliens play in picking Super Bowl winners (are they pro AFC or pro NFC?).

Even more impressive is the rise of actual use of analytics. The 30% of development teams that claimed to use some sort of analytics has, in just one year, ballooned to 62%.

The rise of mobile development

Mobile devices have unique capabilities (accelerometer, augmented reality, gyroscope, camera/scanner, gesture recognition, GPS and navigation…) that drive unique development requirements which, in turn, spawn new development patterns and practices – and one of the most notable (in my opinion anyway) is the expectation that some form of application analytics always be included.

This is worth saying again; in traditional PC apps, adding analytics is the exception, not the rule – in mobile apps, the situation is reversed; embedding analytics is the norm.  

This is the other major shift in our year-over-year survey results. In 2012, only 25% of the development teams reported that they were developing mobile apps (iOS, Android, …) – in 2013, that number has more than doubled to 56%. Is it a coincidence that the rise of analytics use is proportionate to the rise in mobile development?

Analytics go mainstream

For analytics to “go mainstream,” mobile analytics development patterns need to be applied (and adapted) beyond narrow consumer-centric scenarios (as lucrative as those scenarios may be) to include line-of-business and “enterprise” apps (with all of the attendant infrastructure, IT governance, and data integration requirements that this implies).  …and we’re seeing evidence of this too.

94% of respondents are building mobile apps targeting consumers, BUT 40% are also deploying apps “used by employees” to “support a larger business,” e.g. enterprise apps!

65% of enterprise mobile app dev teams (essentially the same percentage as their consumer-centric counterparts) also report using (some form) of analytics.

Analytics: one size fits all?

Of course not – the specialization of application analytics technologies is another inevitable outcome of all of this change – and developers are on the front-lines trying to figure all of this out.

The following chart lists the analytics technologies our respondents have reported using – Google’s (and to a lesser degree, Flurry’s) prominence should come as no surprise. …but what’s the deal with the homegrown category?

Developers "doing it themselves" would strongly suggest that the reigning champions of consumer-centered mobile analytics are failing to meet a growing set of analytics requirements.

Is it a coincidence that the homegrown and PreEmptive analytics adoption rates map so closely to  the enterprise mobile app market share listed above? (40%)

These tools, they are a-changing

Analytics is not the only development tool category undergoing change and reinvention. When asked to enter specialized mobile development tools, responses included both “the familiar” and “the brand new.” (Note, this was not a multiple choice – this was an open text box where anything – or nothing – could be entered)

The familiar: Visual Studio was cited as a “specialized toolset” by 24.6% of those listing at least one specialized mobile app development tool – of the 49 unique tools that were cited, this was the #1 response – and should give the Visual Studio product team some satisfaction as they are clearly establishing Visual Studio as something more than just a .NET-centric dev environment.

The brand new: Xamarin, the cross platform mobile app development platform, was the most common new – and/or truly mobile-specific – toolset (they released a major refresh of their solution in 2013). Xamarin was cited by 9.5% of those listing at least one specialized mobile app development tool. 

(Are you using Xamarin? Contact me if you’d like to learn more about our soon to be released analytics integration with Xamarin – or visit the PreEmptive website if you’re reading this during or after Q4/2013)

The complete list of tools mentioned at least once include:

While Visual Studio was cited most often, relative newcomer, Xamarin, is already making its mark.

Game over? Are you kidding!? We haven’t even figured out the rules yet…

Have development organizations figured out how they’re going to tackle current and future mobile development requirements? (That, my friends, is what we call a rhetorical question)

The rise and assimilation of mobile devices is far, far from over and, sadly, I would suggest that picking new tools and expanding technical skillsets is the least of a development organizations’ worries – grappling with entirely new sets of operational, legal, social, security, and privacy obligations (that are themselves changing and often inconsistent) pose (in my view) the most serious risk (a.k.a. opportunity) for today’s development shop. 

…and those that lack a sense of urgency around these issues, that take the posture of waiting until these issues come to them, are in for a world of hurt.

For example, 

Personally Identifiable Information (PII)

• 15% of respondents that collect personally identifiable information (PII) do not offer their users a way to opt-out 
• 18% that collect PII do not offer a link to their privacy policy (there was only a 6% overlap between these two groups) 

To know that you’re collecting PII and to not provide these mechanisms is a serious omission (both from a development and an operations perspective) – and this is the easy stuff! This question also presumes that developers are using the most up-to-date and appropriate PII definition – a stretch to be sure.

Regulatory and Compliance

For those that indicated that their apps have “regulatory or compliance requirements” (29.9% of respondents) – their obligations are, by their very nature, more complex, ambiguous, and fluid.

• 36.6% of respondents whose apps are subject to compliance and/or regulatory oversight do not offer their users a way to opt-out 
• 16.7% of respondents whose apps are subject to compliance and/or regulatory oversight do not offer a link to their privacy policy.

…and what about collecting application usage information?

• 41.7% of respondents whose apps are subject to compliance and/or regulatory oversight use Google Analytics or Flurry – analytics providers whose business model is predicated on harvesting and monetizing usage telemetry! 

Have these development organizations reconciled their regulatory obligations with Google’s and Flurry’s usage terms or privacy policies? 

In confusion, there’s opportunity

…and I think everyone can agree – mobile application development is full of opportunity.

(Zinfandel + BBQ = $$$) - I told you so

Back in February of 2011, I posted Riddle me this! Where can French, Italians, and Germans all agree? focusing on how a collection of early Windows Phone developers were leveraging analytics; the 10 apps included games, media apps, and a foodie app that paired food and wine by VinoMatch. In this last example, our analytics tracked user behaviors (which foods users chose) and which wines they selected during the pairing.

Analysis of food selection by users' nationality showing Italians' special interest in BBQ

I was surprised to learn a) Italian interest in pairing wine with BBQ and b) the implied potential to market Zinfandel to Italians as an American wine for BBQ (because Zinfandel was bred from a cheap table-variety Italian grape, Italians have typically been a hard sell).

So… imagine my surprise now in 2013, as I see a series of targeted marketing campaigns with exactly this message (from multiple wineries). I wonder how many hundreds of thousands of dollars in market research these guys spent when all they had to do was instrument an app?!
  Cin Cin!

Your phone can be a very scary place

Mobile apps are changing our social, cultural, and economic landscapes – and, with the many opportunities and perks that these changes promise, come an equally impressive collection of risks and potential exploits.

This post is probably way overdue – it’s an update (supplement really) to an article I wrote for The ISSA Journal on Assessing and Managing Security Risks Unique to Java and .NET way back in 09’. The article laid out reverse engineering and tampering risks stemming from the use of managed code (Java and .NET).  The technical issues were really secondary – what needed to be emphasized was the importance of having a consistent and rational framework to assess the materiality (relative danger) of those risks (piracy, IP theft, data engineering…).

In other words, the simple fact that it’s easy to reverse engineer and tamper with a piece of managed code does not automatically lead to a conclusion that a development team should make any moves to prevent that from happening. The degree of danger (risk) should be the only motivation (justification) to invest in preventative or detective measures; and, by implication, risk mitigation investments should be in proportion to those risks (low risk, low investment).

Here’s a graphic I used in 09’ to show the progression from managed apps (.NET and Java) to the risks that stem naturally from their use.

Risks stemming from the use of Java and .NET circa 2009

Managed code risks in the mobile world

Of course, managed code is also playing a central role in the rise of mobile computing as well as the ubiquitous “app marketplace,” e.g. Android and, to a lesser degree, Windows Phone and WindowsRT – and, as one might predict, these apps are introducing their own unique cross-section of potential risks and exploits. 

Here is an updated “hierarchy of risks” for today’s mobile world:

Risks stemming from the use of Java and .NET in today’s mobile world

The graphic above highlights risks that have either evolved or emerged within the mobile ecosystem – and these are probably best illustrated with real world incidents and trends (also highlighted below):

Earlier this year, a mobile development company documented how to turn one of the most popular paid Android apps (SwiftKey Keyboard) into a keylogger (something that captures everything you do and sends it somewhere else).  

This little example illustrates all of the risks listed above:

• IP theft (this is a paid app that can now be side loaded for free)
• Content theft (branding, documentation, etc. are stolen)
• Counterfeiting (it is not a REAL SwiftKey instance – it’s a fake – more than a cracked instance)
• Service theft (if the SwiftKey app makes any web service calls that the true developers must pay for – then these users are driving up cloud expenses – and if any of these users write-in for support, then human resources are being burned here too)
• Data loss and privacy violations (obviously there is no “opt-in” to the keylogging and the passwords, etc. that are sent are clearly private data)
• Piracy (users should be paying the licensing fee normally charged)
• Malware (the keylogging is the malware in this case)

In this scenario, the “victim” would have needed to go looking for “free versions” of the app away from the sanctioned marketplace – but that’s not always the case.

Symantec recently reported finding counterfeit apps inside the Amazon Appstore (and Amazon has one of the most rigorous curating and analysis check-in processes). I, myself, have had my content stripped and look alike apps published across marketplaces too - see my earlier posts Hoisted by my own petard: or why my app is number two (for now) and Ryan is Lying – well, actually stealing, cheating and lying - again). 

Now these anecdotes are all too real, and sadly, they are also by no means unique. Trend Micro found that 1 in every 10 Android apps are malicious and that 22% of apps inappropriately leaked user data – that is crazy!

For a good overview of Android threats, checkout this free paper by Trend Micro, Android Under Siege: Popularity Comes at a Price).

To obfuscate (or not)?

As I’ve already written – you shouldn’t do anything simply to make reverse engineering and tampering more difficult – you should only take action if the associated risks are significant enough to you and said “steps” would reduce those risks to an acceptable level (your “appetite for risk.”)  

…but, seriously, who cares what I think? What do the owners of these platforms have to say?

Android “highly recommends” obfuscating all code and emphasizes this in a number of specific areas such as: “At a minimum, we recommend that you run an obfuscation tool” when developing billing logic. …and, they go so far as to include an open source obfuscator, Proguard – where again, Android “highly recommends” that all Android apps be obfuscated.

Microsoft also recommends that all modern apps be obfuscated (see Windows Phone policy) and they also offer a “community edition” obfuscator (our own Dotfuscator CE) as a part of Visual Studio. 

Tamper detection, exception monitoring, and usage profiling

Obfuscation “prevents” reverse engineering and tampering; but it does not actively detect when attackers are successful (and, with enough skill and time – all attackers can eventually succeed). Nor would obfuscation defend against attacks or include a notification mechanism – that’s what tamper defense, exception monitoring, and usage profiling do. If you care enough to prevent an attack, chances are you care enough to detect when one is underway or has succeeded. 

Application Hardening Options (representative – not exhaustive)

If you decide that you do agree with Android’s and Microsoft’s recommendation to obfuscate – then you have to decide which technology is most appropriate to meet your needs – again, a completely subjective process to be sure, but hopefully, the following table can serve as a comparative reference.

Learn more about PreEmptive Solutions can both secure and monitor you mobile applications.