Tag: android

Categories
Languages

Infographic: Programming languages adoption trends 2020

What do developers value in open source?

Languages are a beloved subject of debate and the kernels of some of the strongest developer communities. The choice of programming language matters deeply to developers because they want to keep their skills up to date and marketable. They matter to toolmakers too, because they want to make sure they provide the most useful SDKs. So which programming languages had notable changes in adoption trends in the last 3 years? Find the answers in our infographic with key findings from our Developer Economics 19th edition survey, which ran in June-August 2020 and reached 17,000 developers in 159 countries. 

JavaScript is the most popular programming language

As of Q3 2020, 12.4M developers globally were using JavaScript. We also estimate that in mid-2020 there were 21.3M active software developers in the world. So, 58% of all developers use JavaScript. Notably, the JavaScript community has been growing in size consistently for the past three years. Between Q2 2017 and Q3 2020, nearly 5M developers joined the community – by far the highest growth in absolute terms across all languages. Even in software sectors where JavaScript is least popular, like data science or AR/VR, over a fifth of developers use it in their projects. 

It’s a good idea to learn Python

For the second half-year period in a row, Python is the most widely adopted language behind JavaScript. Python now counts 9M users, after adding 2.2M net new developers in the past year alone, outranking Java at the beginning of 2020. The rise of data science and machine learning (ML) is a clear factor in its popularity. An impressive 77% of ML developers and data scientists currently use Python. For perspective, only 22% use R, the other language often associated with data science.

What’s new with Java and other well- established programming languages?

Java, with over 8M active users worldwide, is the cornerstone of the mobile app ecosystem – Android – as well as one of the most important general-purpose languages. It’s adoption may have remained stable in the past six months but, in the overall picture, the Java community has gained 1.6M developers since mid-2017, which corresponds to a 24% growth.

The group of major, well-established languages is completed with C/C++ (6.3M), PHP (6.1M) and C# (6M). The fact that C# lost three places in the ranking of language communities during the last three years is mostly explained by its slower growth compared to C/C++ and PHP. C and C++ remain core languages in IoT projects (for both on-device and application-level coding), whereas PHP is still the second most commonly used language in web applications, after JavaScript. On the other hand, C# may be sustaining its dominance in the game and AR/VR developer ecosystems, but it seems to be losing its edge in desktop development – possibly due to the emergence of cross-platform tools based on web technologies.

Android developers behind Kotlin growth

Kotlin is one of the fastest growing language communities, having increased more than two-fold in size since the end of 2017, from 1.1M in Q4 2017 to 2.3M in Q3 2020. This is also very evident from Kotlin’s ranking, where it moved from 11th to ninth place during that period – a trend that’s largely attributed to Google’s decision to make Kotlin its preferred language for Android development. 

Swift surpassed Kotlin in popularity this year, after attracting slightly more net new developers in the first half of 2020 (400k vs 300k). Since Swift became the default language for development across all Apple platforms, the adoption of Objective C has been decreasing steadily. This phase-out from the Apple app ecosystem is also matched by a significant drop in the rank of Objective C, from ninth to 12th place. 

Finally, the more niche languages – Go, Ruby, Rust, and Lua – are still much smaller, with up to 1.5M active software developers each. Ruby and Lua have been around for more than two decades now, but their communities have essentially stopped growing in the last three years. On the contrary, Go and Rust appear to be actively adding developers, although it is still unclear whether the two languages will climb the programming language ranking in the coming period.

What’s your favourite programming language? Take our Developer Economics 20th edition survey to support your choice!

Infographic: Programming languages adoption trends 2020
Categories
Business Interviews Tools

Dev Evolution: Meet Vasil from AndroidPal

android, app development, developer tips, developer economics, developer blog, developer community, app community, android community
AndroidPal

How do tech startups win the hearts of developers with their products? What does it take to create value and get developers to use their tools? Our guest Vasil from AndroidPal talked to us about these challenges and shared a few tips on Android development.

Who?

I’m Vasil, owner and CEO of AndroidPal Ltd. and other businesses like Belvek Ltd. I have been into computer technologies most of my life, during the last 10 years — professionally.

My interest in technology and computers started when I was very young, probably at the age of 7. Back then people did not have computers at home. My brother and I had the chance to land in an after-school activity to learn programming. It was only once per week and we couldn’t wait for it to start. We were taught BASIC back then on computers called Pravetz.

We’ve initially worked with 8-bit but later 16-bit computers which were mostly identical with the Apple II computer. It seemed I had a knack for programming, maybe because I was good at Maths.

Additionally I’ve studied and worked with other popular at the time programming languages and technologies like VBScript (yes, it was a thing), Visual Basic, Delphi, OpenGL, PHP, ASP (prior to .NET) and of course HTML.

Fast forward 15 years and I started my own IT company. We’re based in Sofia, Bulgaria and have been providing software development and related services for more than 6 years now.

Most of our clients are from USA, Germany, Austria and Italy. We also have our own products and services in different fields – education, travel, gaming and entertainment.

How did you get into app & Android development?

We’ve been developing one way or another for Android for almost exactly 9 years now. I can still remember the first Android phone I got – HTC Desire. I think it must have been mid March 2010 when I’ve heard of the phone. I really liked it, but said to myself that I can buy it only after I’ve created a simple app for Android and learn more about Android development.

Back then developing for Android was not easy, the current Android version at the time was Android 1.5 but I remember that writing Android apps I had to support Android 1.1 too.

Developing for Android was done with Eclipse. Eclipse is an open source IDE and back then, at least developing for Android with it was not easy. There were too many issues with the IDE – it required too much memory, freezed often, needed restarts and obscure workarounds to make it stable.

So, that first app that I built used Android NDK and had C and C++ code to allow fast image manipulation. And fast it was – probably 3 to 5 times faster than manipulating the image data directly in Java. Of course a year later the Dalvik VM got JIT which would make a Java implementation comparable in terms of speed.

Ever since that first app I and later the people I work with are developing more and more for Android working on big or small projects for various industries.

And yes, I bought that HTC Desire phone on May 21st 2010 (I know the date because I bragged to a friend over email).

Tell us a bit more about AndroidPal.

AndroidPal started because of a problem. We were working on an Android app with a particularly complex graphical user interface. We’ve inherited the code of another company and struggled making certain views (the interface) work. To such extent that we had to create a tool to inspect the layout better. This is how our own View Hierarchy Inspector tool was born.

We thought it would be very useful to developers like ourselves and it would be great if we created other helpful tools.

With more than 2.7 billion active users undoubtedly Android OS is the most popular OS. There constantly are new technologies and frameworks and SDK updates and languages coming out. We know how overwhelming it can be for developers, and it is.

So we thought we start an online community centered around Android Development — this is what AndroidPal is all about. It’s a website where you can find useful information, chat with peers and learn. The site has different sections like – Questions, Libraries, Knowledge Base and Chat.

ap-studio-wide-screenshot

We’ve built all of these as only the foundation onto which we can implement all our other ideas. AP Studio is part of AndroidPal and the name is just a short version of “Android Pal Studio”.

What pain points are you solving for developers? Why should developers use your IDE?

AP Studio offers tools which Android Studio does not. One example would be the Icon Creator, probably the most popular AndroidPal Studio tool among existing users. Then there is the Shape Drawable creator and other tools. Say you want to create a Shape drawable resource file, you might need to check the docs to recall the exact specs and write XML text code. Our tool works visually. It has controls based strictly on the specs so you can’t go wrong.

Among other things this saves time. The tools are built into the IDE and there are quick actions to streamline the process. For example when you create an icon for your app AP Studio can immediately and automatically set it as your app’s launcher icon.

Then there is the snappiness of AP Studio. It does not have the heavy requirements of Android Studio and feels much quicker. In our work we sometimes need to make a small change and see the result right away, no need to spin another instance of Android Studio in such cases. We’re dedicated to increase the snappiness factor even further.

Our best ideas are yet to be implemented. One such idea is how to organize and reuse resources and experience from different projects. One way is to have a library of resources, for example a library of icons or library of layouts. Something that you can navigate easily. A public as well as developer’s very own private library. Our Shape Drawable Creator tool does have a public library with 8 free items, we’ll add more and accept submissions by developers and improve and categorize things a lot in the next iterations of the software.

Indeed everything in AP Studio is ad hoc. Android Studio is based on IntelliJ Idea which is a great software, but has been built as a generic purpose IDE. Google had to create a plugin for it. At some point we wanted to create our own plugins for Android Studio, but the IntelliJ Idea plugins documentation and the effort required to do so seemed overwhelming. Simple things would require a lot of work.

Therefore being ad-hoc and using modern technologies allows us to have a special touch in everything and to quickly respond and implement user suggested features.

To summarize, I would recommend developers use our IDE because it offers new tools and ultimately saves time and leads to less errors.

How was your experience of building the IDE? What challenges did you face in developing this?

Building an IDE is not a trivial task, it was much more effort than we’ve initially imagined.

Entering an unknown territory was very challenging. It’s a different kind of software than what we’ve done before. Also the sheer amount of technologies involved, the research of how things work and why, reading and understanding the (sometimes lacking) documentations – it’s a very big effort.
But it’s fun and rewarding to see things work. To get to a stage where we can start paying more attention to UX as functionality is already fine.

Martin, one of the main developers of the project had this to say:

“Having only been working on web sites and web apps I found using Angular for a Desktop app was something completely new to me. In my work on the project I’ve encountered things which were different from my usual Web development work. It was a tough but interesting work and certain tasks seemed overwhelming, but I did not give up and as a result became a better developer overall.”

Even though it’s well featured IDE now and offers everything you need to develop for Android we’re long way of having all our ideas implemented.

What’s next for AndroidPal? How do you see it progressing in the next two years?

On the whole we want to improve the online part and include interactive guides for beginners, different tools. To name but a few things coming:

  • Android Update tool where developers learn from a very well presented data what they need to do in order to update / upgrade from version X to version Y.
  • Git repos with Android specific web tools (e.g. preview specific android resources, display android specific info about the project).
  • Knowledge base – we have great ideas there and want to develop them.
  • Most importantly – more work on AP Studio IDE – to ultimately have low-code / no-code solutions for a wider audience (not just professional software developers).
  • Some sort of PM tool (todo lists — we have been using our own tool for it and are thinking of integrating it with AP Studio).

One other non-technical aspect of the project is AP Academy where we would apply our experience in teaching and explaining Android topics to a wider audience and in ways that would make the whole learning process better.

What’s your best piece of advice for developers today?

Software development is not an easy thing. Being a professional software developer means you have to keep up with all technologies as much as you can. Learning and improving is a lifelong process. Becoming good takes years. The best piece of advice would be to not give up when there’s a tough problem to solve. So, keep calm and don’t give up.

For most developers there would always be someone who is better in a particular aspect of programming. We should be humble and strive to learn.
As software developers we should always try to solve problems. Not to learn the syntax of a programming language as best as you can. Or learn the most number of programming patterns. What brings value is solving problems. Being creative when solving problems is equally important.

But this is just some developer with 10 years experience talking. There are far more experienced developers who have been into technology from much earlier days. There are great books out there every developer should read. The list might be long and depend on what kind of programming you do, but I would always recommend the books of Uncle Bob (Robert C. Martin) — for example one of his best known books “Clean Code”. Another book I’d recommend is “The Pragmatic Programmer” by Andrew Hunt and Dave Thomas.

What technologies do you invest in the most, and why?

One way or another we use the following technologies across AndroidPal and in AP Studio in particular:

– Java
– Kotlin
– Gradle DSL
– Python
– Javascript
– Typescript
– Angular
– NodeJS
– PostgreSQL
– MongoDB
– SQLite
– Firebase
– Electron
– HTML5 / CSS3 / SCSS

Most of the codebase of the IDE is Javascript / Typescript, however many of the important (albeit much smaller) parts are written in Java.

Then there are libraries and frameworks within those technologies which are too many to list.

Using HTML5 for the interface made so many things so much easier than in other platforms (comparing for example using existing Java GUI frameworks or creating our own). The freedom and ease such a mature technology offers is something we’ve really learnt to appreciate.

HTML5 and Angular made the big difference. Can’t even begin to imagine how much more effort it would require to do this with traditional technologies.

Categories
News and Resources

Google planning hybrid Android/Chrome OS tablets

razer fund gaming startups

Welcome to DeveloperEconomics’ weekly news roundup. In this edition Google is reportedly planning hybrid devices that run both Android and Chrome, game developers boycott Oculus due to its founder’s support for Donald Trump and Google takes its Daydream SDK out of beta. Read on for the full news rundown.

 

Google planning hybrid Android/Chrome OS tablets

Google is reportedly planning hybrid devices that run both Android and Chrome, according to 9to5Google. The Andromeda project bakes Chrome OS features into Android and is reportedly being released on a Nexus-branded tablet and a convertible laptop. Rumours suggests the laptop device will launch in Q3 2017.

 

IBM releases IBM Bluemix Runtime for Swift

IBM has introduced a production-ready Swift runtime on the IBM Cloud. The release allows enterprises to take advantage of the server-side capabilities in Apple’s programming language, for building microservice APIs on its cloud platform. IBM says by unlocking Swift for enterprises it’s “reached another milestone” in its “shared journey with Apple.”

 

Microsoft announces 400m Windows 10 users

Microsoft says Windows 10 now has over 400 million active users. The last update on user growth was in July, when the OS hit 350, just before it ended its free upgrade period. Microsoft’s original goal was to have one billion devices running Windows 10 by 2018, but the company has since backtracked and is not specifying when it will hit the one billion milestone.

 

Oracle announces new products for cloud platform

Oracle unveiled 20 new products and services for its Oracle Cloud Platform at the annual OpenWorld conference last week. New products include the cloud-based Oracle Database 12c Release 2, along with an SaaS offering, which combines third party data with real-time analytics for “adaptive” app development. During the announcements, Oracle’s CTO Larry Ellison said Amazon now has “serious competition going forward.”

 

SoundCloud devs must submit application for API access

SoundCloud has announced changes to its API policy, requiring devs to apply for access. The application form asks devs what categories their app falls under, how it makes money and whether the app plays content from the SoundCloud API. SoundCloud says the changes were made to stop apps from using content without the permission of creators.

 

Mopub modular ad SDK reduces app sizes

Twitter’s MoPub ad network has announced a new SDK that lets devs cut out the ad formats they don’t use. The modular SDK means devs can save up to 60% on disk space for Android apps and up to 35% for iOS apps, without losing any functionality. MoPub says the space savings will be particularly useful for Asia-Pacific devs, where expensive data plans can impact bigger apps.

 

Google takes Daydream VR tools out of beta

Google has released a new VR SDK, allowing devs to build VR experiences for Daydream-ready phones and headsets. The Daydream VR SDK 1.0 supports “integrated asynchronous reprojection, high fidelity spatialized audio and interactions using the Daydream controller.” The release also supports native integration in both Unity and Unreal Engine 4.

 

Facebook rolls-out Profile Expression Kit SDK

Developers can now integrate Facebook’s Profile Expression media into the apps. The Profile Expression Kit lets users turn media – such as Vine videos, Bommerang GIFs and Lollicam stickers – into profile pictures. Facebook says profiles are the second most visited surface on Facebook, allowing Expression Kit apps to generate a lot of exposure.

 

Onsen UI 2.0 now available

The Onsen UI team has released version 2.0 of its UI framework, which helps developers create native mobile apps with HTML5. While Onsen 1.x was based on Angular JS, the new version has no library dependencies, as well as new Material Design components. The team has also released new and improved documentation to make it easier for devs to get to grips with the framework.

 

Developers boycott Oculus over Trump-supporting founder

A number of Oculus developers are boycotting the VR platform due to the political views of its founder, Palmer Luckey. According to a Daily Beast report, Luckey funded a pro-Trump activist group, which posted anti-Hilary Clinton ads. Developer Scruta Games said it will “cancel Oculus support” unless Luckey steps down from his position at Oculus.

Categories
Platforms

Facebook Messenger: All your numbers are belong to us

Facebook started 2016 with the bold claim that it intends to eradicate phone numbers and replace web browsing, but the Social Network has a mountain to climb before Facebook Messenger becomes the centre of our online world.

New-Report_Final

That’s the stated intention of the Zuckerberg empire – to replace all our myriad internet communication systems with one interface.

Facebook claims that its Messenger app has been installed 800 million times, but at VisionMobile our latest research shows that those installations are very much concentrated into the lower end of the market.

If Facebook is going to recruit the shops, taxi companies and airlines it needs to make Messenger a one-stop internet shop it will need to get the app installed across the demographics before Microsoft (with Skype) steps in to take the cream.

[tweetable]Facebook has long known that the days of pokes and personal walls are fast disappearing[/tweetable], and has quite a history in struggling to adapt to whatever the future might bring. Facebook Gifts/Credits/Deals/Questions/Beacon haven’t lit up the future, so now the company is betting on messaging, and value-added messaging platforms.

Such platforms are proliferating in business. The bots that proliferate across Slack and Yahoo Messenger have turned those platforms into much more than messaging, but taking that functionality into the consumer sphere is much harder.

The medium is the Messenger

With that in mind, Facebook Messenger was forked from the main Facebook mobile app back in 2011, but messaging remained possible in the main app until 2014. These days, the Facebook app will notify you that a message has been received, but if you want to read that message then you’ll have to download and install Facebook’s new Trojan Horse.

That analogy isn’t perfect: the horse of Troy was disguised while Facebook has made no secret of its plan to migrate key internet functionality into the Messaging client. If Facebook can’t own the interface to your phone (it tried that), then it will own the interface to the internet, which the company believes will be Facebook Messenger.

The inspiration behind this idea isn’t hard to see. In China, where Facebook/Google/Twitter fears to tread, the competitive market created in their absence has driven huge innovation as companies strive to differentiate themselves with new features and functionality. Every month, 600 million Chinese are using Weixen, Tencent’s WeChat client, to book taxis, check into flights, play games, buy cinema tickets, make doctors’ appointments, and even manage bank accounts, all without touching the web browser.

[tweetable]In China, messaging has become the platform of choice for accessing a wide variety of services[/tweetable], and Facebook plans to replicate that model in the rest of the world – with it owning the messaging platform, obviously.

This process has already started with Facebook integrating Uber into its messaging platform. It’s worth noting that Uber isn’t integrated into the Facebook website, or the mobile client, but into the Facebook Messenger app.

vision_mobile_2

And Uber is just the beginning. As David Marcus, Facebook’s vice president of messaging products, makes abundantly clear: “We can help you interact with businesses or services to buy items (and then buy more again), order rides, purchase airline tickets, and talk to customer service in truly frictionless and delightful ways” – and that’s before Facebook becomes your personal assistant, Facebook M.

“Facebook M” starts listening in to all your conversations to suggest ways it can make your life more, as they say in such circles, “delightful.”

The Facebook wall will be supplanted by the Custom Conversation, providing a personalised interface (colour, style, emojis) for every chat thread. The visual equivalent of a ring-back tone, customised for every caller, will enable you to decide how both sides of the conversation see their interface, unless the other side has other ideas.

Walled garden of Zuck

In Facebook’s brave new world, everything is done through Facebook Messenger, and Facebook takes control of the delivery channel, removing that irritating “Open in Web Browser” which takes so much control away from the Social Network.

But that brave new world is predicated on the idea that people will install Facebook Messenger, rather than relying on the website, and email notifications, to stay in touch. Our research, in partnership with Celltick, looked at the top 10 applications installed on different handsets, and shows that while many low-end handsets do have Facebook Messenger installed, the application is almost invisible in handsets costing more than $200.

In high-end phones, Skype consistently rates top – well above the main Facebook application – and Facebook Messenger isn’t even in the top 10. In handsets costing less than $200, Facebook Messenger rates around four or five – a couple of positions below the main Facebook application, and very close to Skype.

What this means is that those who can’t, or won’t, invest more than $200 in a handset are happily installing Facebook Messenger, while those with a bit more disposable income are refusing to commit.

What it makes abundantly clear is the opportunity this presents to Microsoft. If messaging really is the future of mobile interaction, as Facebook seems to think, then Skype is perfectly positioned to grab the most important demographic.

If Microsoft were half as willing as Facebook to launch into value-added messaging, then it could make Skype into the messaging platform of the future, if indeed users really want such a platform at all.

You can read more in our free report, here (email address required.) ®

Article first published on the Register

Categories
Business

Is the Indie App Opportunity Gone?

The app stores created an opportunity for any developer to build their own products and reach a global audience with them. For some developers this offered the promise of an independent app business, giving them creative control of their work and hopefully a comfortable income. Recently there have been lots of posts (great summary list here) from current and former independent app developers about the state of the market and how much harder it is to earn a living from your own apps. If it’s tough for established indie developers then is it still possible to get started? We’ll look at how the market has changed and share some data on the revenues of over 500 solopreneurs and small indie developers versus their bigger rivals.

indie_game

The indie developer gold rush

[tweetable]A key advantage of small indie app developers is their agility[/tweetable]. They can shift their strategy to take advantage of new opportunities incredibly quickly. The success story that may have started the iOS app gold rush was built before there was an official SDK or App Store. Steve Demeter was working on ATM software for a bank and built the game Trism in his spare time, initially releasing it for free to the jailbreak community. When the App Store launched it was initially a $5 paid download that earned $250,000 in profits in the first two months. Demeter quit his day job to become one of the first full-time iOS indie app developers. Trism was reduced to $3 to stay competitive but went on to sell around 3 million copies. Four months of evenings and weekends, just a few weeks equivalent in full time development, earned a life-changing amount of money.

It’s the overnight success stories like these that continue to drive lottery-like behaviour from some developers. Playing for the outside chance of winning big. Even the media coverage at the time noted the increasing competition with more than 1500 iPhone games available in the App Store! Today’s developers would love so few apps to compete against; there are now hundreds of times as many.

Raising the bar

By 2011 life-changing solo developer success on the app store looked rather different. A $5 app created in a matter of weeks wouldn’t stand a chance. Andreas Illiger is a gifted musician, artist and coder. His Tiny Wings took 7 months of full time effort to create and sold for just $0.99. The increased scale of the platform meant he was able to sell more than 10 million copies. In 2014 it’s debatable whether a solo developer will ever repeat the feat. Monument Valley looks like the modern benchmark for a chart topping paid game title but developer UsTwo primarily serves clients in three countries and has over 100 staff in the London studio that created the game. Sirvo’s Threes! is a better comparison yet it was created by three people over a 14-month period (not full time). Threes! was almost immediately copied with numerous free alternatives to the $1.99 original springing up. Whilst Tiny Wings enjoyed a year as a top 10 game and another two inside the top 50, Threes! is already in danger of heading out of the top 100. [tweetable]There’s just so much free-to-play competition[/tweetable]. Making a more complex game to differentiate from the crowd is just beyond the scope of most small independent developers.

Not just games

Those examples have focussed on games and it’s tempting to think non-game apps might be a different story. However, consider that our data shows only 33% of developers are making games. Those developers collectively earn over 80% of store revenues across iOS and Android. So [tweetable]67% of developers are competing for less than 20% of store revenues[/tweetable].

Lets take a look at what Hunters (our name for developers that are aiming for direct revenues from their apps) can expect to earn at different company sizes.

As you can see, iOS is still a much healthier place for an indie app developer to be than Android but unless your cost of living is very low then the chances of making a comfortable living aren’t great. The bigger developers are taking over the top charts. [tweetable]If you’re outside the top app charts then it’s incredibly hard to get noticed[/tweetable]. Some of the successful smaller developers in our survey already have established apps with a strong history of downloads and ratings that keeps them high in the search results. If you’re just starting out, is it still possible to join them?

Find the right sized niche

The key difference with non-game apps is that they don’t all compete for the same attention. If your indie developer dream is to build the app you really want to use and be richly rewarded for it, you’d better have a fairly unusual problem that you want solved. Jared Sinclair’s Unread is the cautionary tale for those wanting to build for other technology lovers like themselves. An RSS reader (or client for any popular internet activity), however beautifully executed, has to compete with a vast array of free alternatives. Many of those other apps will have been built by hobbyists with no need to make any revenue at all. Anyone wanting to succeed as an indie developer today needs to think like a small business. Trying to compete with hobbyists is as futile as trying to compete with Google.

The right sized niche for an independent app is one that’s small enough not to be interesting to much bigger competitors but big enough to earn a living. Even winning the niche is not going to support a big team. The best niches will need specialist knowledge or intellectual property that make them both unattractive to hobbyists and defensible. Ben Thompson provides a great case study of Pleco, a Chinese dictionary app with some high-value in-app purchases. This example has two key advantages worth replicating: unique licensed content and a natural channel to market outside of the app stores.

What about getting rich?

If that sounds more like hard work than the indie developer dream of becoming an overnight app millionaire, it is. It’s also many, many times more likely to succeed. [tweetable]If you want to be an app millionaire then build contract apps for businesses and grow a team[/tweetable]. Then build some products for enterprise customers in niches that won’t attract immediate competition from much better funded rivals. Or get some venture capital and think really big! If you prefer the dream of being a millionaire, stick to building apps in your spare time. Better yet, buy a lottery ticket, it’s much less effort for about the same odds.

Categories
Business Platforms Tools

State of the Developer Nation: The App Economy Consolidates Before the Next Gold Rush

app economy

Our 7th Developer Economics survey broke all records again, reaching more than 10,000 app developers from 137 different countries. The full report with the survey findings has just been published and is available for free download!

The view of the app economy that they collectively provide is one of consolidation. Developers are focusing their attention on fewer platforms and app revenues are becoming increasingly concentrated amongst the top publishers. Consolidation in the developers tools sector may also be partly responsible for the decline we see in tools usage. This is also reflected by the platforms, with BlackBerry moving their focus away from consumer smartphones and Microsoft killing their recently acquired Asha and Nokia X platforms to double down on Windows Phone. Fortunately there are several indicators that the next gold rush is just getting started.

Platform Wars in the App Economy

On a global level the platform wars are ending with iOS claiming the majority of the high-end device market and Android winning almost everywhere else. This results in [tweetable]Android leading in developer mindshare at 70% with iOS a clear second with 51% of developers targeting the platform[/tweetable]. However, we’ve been tracking this metric since 2010 and there is a new pattern. [tweetable]Windows Phone was the only platform to gain developer mindshare, rising steadily to 28%[/tweetable], despite failing to gain device market share. Although Android and iOS lost developer mindshare, this was not fewer developers prioritising either platform, rather more developers are now choosing sides. The average number of platforms a developer targets has fallen from 2.9 to 2.2 over the last 12 months, with more than 40% only targeting a single platform.

DE2014Q3_Mindshare

BlackBerry 10 is rapidly leaking developer mindshare, down to 11%, having failed to gain traction with consumers. Meanwhile, it’s now becoming increasingly clear that [tweetable]the future of HTML5 lies beyond the browser[/tweetable]. Although HTML5 is used by 42% of developers as a technology for app development, only 15% still target mobile browsers as a distribution platform.

A surprisingly high 47% of iOS developers and 42% of Android developers are using something other than the native language on their platforms. While hybrid apps are the most popular non-native option for building Android and iOS apps, they’re only used by 13% of developers. Hybrid apps are HTML5 apps with a native wrapper, typically created by tools such as Cordova.

DE2014Q3_NativeMyths

App Revenues

The majority of app businesses are not sustainable at current revenue levels. [tweetable]50% of iOS developers and 64% of Android developers are below the “app poverty line” of $500 per app per month[/tweetable]. 24% of developers interested in making money earn nothing at all. A further 23% make less than $100 per app per month. The overall app economy, including all revenue sources not just the app stores, is still growing but the revenues are highly concentrated. At the top end of the revenue scale there are just 1.6% of developers with apps earning more than $500k per month, collectively they earn multiples of the other 98.4% combined.

DE2014Q3_iOS_vs_Android_Revenues

State of the Game Developer Nation

Games dominate app store revenues, yet most games developers struggle. [tweetable]33% of developers make games but 57% of those games make less than $500 per month[/tweetable]. Experience breeds success in the games market. The more games a developer has shipped the more likely they are to be financially successful. However, 70% of games developers have shipped less than 4 titles.

Games is a multi-platform world with the average games developer targeting 3 platforms versus 1.75 platforms for non-games developers. Multi-platform games benefit from cross-platform game development tools with Unity by far the most popular, used by 47% of developers. The next paid tool, Adobe Air, comes a distant second at 15%. Apple and Google’s latest graphics technologies launch a battle for the richest gaming experiences. Third party game development tools like Unity and the Unreal Engine will be key to developers exploiting these capabilities.

DE2014Q3_Game_Dev_Tools

Tools of the App Developer Trade

Third-party tools are a critical part of successful app businesses. There’s a strong correlation between tool use and revenues, the more tools a developer uses, the more money they make. We successfully predicted the rise of the Mega-SDK, where consolidation amongst tools companies allows developers to integrate multiple tool categories from a single vendor. Despite this, tool use is declining, partly due to the rapid influx of new mobile developers. These new developers are typically not aware of the tools that are available and thus reduce the average usage levels. 26% of developers that are interested in making money don’t use any third party tools, up from 14% just 12 months ago.

DE2014Q3_Tool_Popularity

The most popular category of tool is Ad Networks, with 30% of developers using them. However, this is one of the few tool categories that is not associated with higher than average revenues. More experienced and successful developers show a preference for Cloud Computing platforms, such as Amazon Web Services or Microsoft Azure, with 40% of those with 6+ years experience in mobile apps adopting them.

Enterprise Apps – The Next Gold Rush

[tweetable]Enterprise apps are already the safest bet in the app economy and they’re only just getting started[/tweetable]. 67% of mobile app developers primarily target consumers and 11% target professionals directly. The 16% of developers who target enterprises are twice as likely to be earning over $5k per app per month and almost 3 times as likely to earn more than $25k per app per month.

DE2014Q3_Enterprise_vs_Consumer

Penetration of enterprises with mobile devices and solutions is already broad but not yet deep. Currently iOS appears to be winning the battle for enterprise adoption and revenues. Yet many developers are focusing on the wrong platform with 10% more enterprise developers targeting Android than iOS. Although enterprise apps have been a historical strength for them, Microsoft and BlackBerry are seeing very weak adoption for their new platforms amongst enterprise developers due to lack of demand from enterprises.

This battle is in the very early stages. Microsoft is re-focussing on their core competence in productivity software while Apple and Google move rapidly to embrace enterprises. Google’s integration of Samsung’s Knox platform into the Android platform is a major step forward. Meanwhile Apple’s new partnership with IBM gives them a strong proposition in all the major vertical markets. These moves will undoubtedly drive greater adoption of mobile technology in enterprises and create countless opportunities for developers to help re-think the way we work.

For more information, download the full Developer Economics Q3 2014: State of the Developer Nation report and check out the war between the European and the Asian app economy.

 

Categories
APIs

Permissions in Mobile Ad SDKs

If you’ve ever tried to integrate a mobile ad SDK into your application, then you’ve definitely had to declare a few permission for it to work. Permissions in mobile platforms such as Android and iOS have been baked in from day one as a mean to control what applications could do or access on your phone, preventing despicable people getting access to your most personal and sensitive data. In this article, we will review what permissions are required to integrate 10 of the most popular mobile ad SDKs out there.

de-illustration-cropped

For the sake of clarity and consistency, we will use the Android SDK permissions. Since most of these mobile ad networks mirror their Android and iOS SDKs this is an acceptable simplification, so without further ado, let’s jump right in.

table_permissions-1024x767

The Internet Permission

This is a no-brainer really. If any ad SDK is going to be able to serve real-time ads, then it has to be able to communicate with an adserver over the internet. It’s no surprise then that all 10/10 SDKs require this permission.

The Network State Permission

Accessing the network state simply means identifying if the device is connected to the internet. If the answer to this question is yes, then this permission can also be used to identify if the connection is through a WiFi or a Cellular connection. This is the second most common permission across our sample with 7/10 SDKs requiring this permission and another 2 listing it as optional.

Access WiFi State Permissions

Using this permission is another way to check if a user is connected to WiFi or not but is clearly not the most popular method as only 2 SDK mark this as required with another 3 making it optional.

Read Phone State Permission

A less popular permission as only 3 SDKs require this but nevertheless all three make this a requirement.

Access Coarse/Fine Location Permissions

This is a very important set of permissions. Traditionally location has played a key role in advertising but has an especially increasing importance in digital mobile advertising. It comes then as no surprise that 7/10 SDKs are interested in this permission. There is a clear trend here that these permissions are mainly optional permissions because they can be considered as more “intrusive” by users so developers tend to avoid them if not using them already. On the other side, including location info with an ad request can usually boost potential by a great deal so this situation can present a great dilemma.

Other Permissions

While the permissions mentioned above are the most popular ones, you may encounter some less frequent ones like write to external storage or even record audio. Throughout the 10 SDKs mentioned in this article, we measure 12 distinct permissions which is not a very big number considering that the Android OS has more than 100 available to declare.

Most SDKs that we have reviewed for this article have very reasonable permission requirements. Ultimately, it’s up to the app developers to find the sweet spot on what they will allow these SDKs to collect and if they are willing to introduce new permissions in their apps just for this. On the other hand, by doing so, app developers can realise a substantial boost in earnings due to more targeted and relevant ads, which can be a great thing for the end-users as well!

Categories
Languages

App Security 101: A list of top 10 vulnerabilities and how to avoid them

App security 101

App development is becoming more and more popular, as web and software developers are migrating to the mobile industry. Apps have become a part of mainstream culture and entered our everyday lives – at increasing levels. The app economy is comprised of approximately 2 million apps and is expected to continue growing in the years to come.

Secure development on mobile applications, however, has not shown the same level of growth or maturity. As an Information Security firm, we’ve seen quite a few apps suffer from vulnerabilities that are linked to development bad practices, mainly due to lack of awareness. Secure development guidelines do exist in the community, while organisations like OWASP have accumulated a lot of experience in the field and are now offering much of this knowledge for free. In this article we’ll sum up the best practices and show you the best ways to build secure apps. We’ll concentrate on OWASP top 10 (and similar) vulnerabilities, as these are the most common ones found in mobile apps.

So, let’s go through the list of the top 10 mobile app vulnerabilities and how to avoid them.

1. Insecure Data Storage:

This vulnerability occurs because information that is considered confidential is not stored in the device in a secure manner. You shouldn’t assume that the devices themselves are safe. Devices can be stolen and/or tampered with, and the confidential data contained in them may be stolen. Also, you shouldn’t assume that users will protect themselves against this possibility. In order to avoid this vulnerability, the best practices are:

  • Never store credentials on the device itself
  • Sensitive information such as user authentication credentials should only be stored in the device’s keychain, using the necessary API
  • All authentication should be done through HTTPS (updated)

Specific guidelines for iOS developers:

  • You could avoid using iOS Encryption Libraries such as Commoncrypto
  • You should encrypt SQLite databases with SQLcipher
  • You might want to avoid NSUserDefaults, as well as plists in general
  • Keep in mind that the NSManagedObjects will be stored in an unencrypted database

For Android devs:

  • You should use the SD Card Storage the javax.crypto.
  • You can use the enterprise Android administration API to force encryption for local files by utilizing “setStorageEncryption”

2. Weak Server Side Controls

You should implement most controls against input attacks on the server side of the application. Nevertheless, app design should include input validation checks and controls, in order to reduce the load of work to be done by the server. Therefore, you could ensure that both the server side and the mobile client development security requirements include at minimum:

  • Input validation. You can use this kind of data validation in order to detect, and therefore prevent, unauthorized input before it gets processed by the app itself
  • Canonicalization. Data input in the app should be converted to its canonical (simplest) form in order to be processed by it
  • White lists on allowable data. The white list validation approach allows only specific types of data as input to the application; everything else that’s not included in this list, is not authorized.
  • Output encoding. You should encode the output that is presented to the user in order to prevent different kinds of attacks (e.g. XSS[1][2], format string attacks).

3. Insufficient Transport Layer Protection:

You should enforce the TLS/SSL encryption with strong algorithms between communications. A common development mistake is unencrypted connections from the application to 3d party companies. You should program your apps to display any certificate error or warning messages, so that the user is informed of the quality of the encrypted connection.

For iOS developers:

  • Use the CFNetwork API that utilizes NSStreamSocketSecurityLevelSSLv3 / TLSv1.2.
  • You should use,the setAllowsAnyHTTPSCertificate parameter to prohibit accepting all certificates

For Android developers:

  • You should set the AllowAllHostnameVerifier parameter to prohibit accepting all certificates

4. Client Side Injection

This category is comprised of a wide variety of input attacks against the application itself. General best practices for mitigation of client side injection vulnerabilities include the input validation of the application entry points, on the server side.

For iOS developers:

  • You should consider using parameterized queries (e.g. ? instead of %@, libXML2 instead of NSXMLParser)
  • In addition, you should avoid functions that are known to be prone to code vulnerabilities, such as strcat, strcpy, etc.

Android developers:

  • You should use parameterized queries
  • You should disable Javascript and plugin support for Webviews
  • You should also disable file system access for Webviews
  • You might consider using input validated intent filters between Activities

5. Poor Authorization and Authentication

These vulnerabilities are controlled mostly on the server side. The best practices that you should follow are the same with web applications. In addition to these rules, specifically for app development, device identifiers should be avoided (UDID, IPs, MAC Addresses, IMEI) since devices can be stolen and tampered with. Finally, out-of-band authentication tokens should not be sent to the same device.

6. Improper Session Handling

Although session handling mechanisms are mainly applied at the server side of the applications, secure session management practices can be applied at the devices themselves. As with the Authorization and Authentication, you should apply the web application Best Practices for session handling. Same as with authorisation and authentication best practices, device identifiers should be avoided here as well and you should implement safe mechanisms to revoke session on lost/stolen devices. Finally, the Confidentiality and Integrity of session tokens should be protected at all times (secure transmission via SSL/TLS connections, etc).

7. Security Decisions Via Untrusted Inputs

While these issues mainly affect Android-based applications, there has been precedent for iOS apps too. In general, the Best Practices that you should follow are the same with the web application ones. Specifically, input validation, output escaping, authorization controls and canonicalization should be carefully examined. Also, you should exercise extra caution when validating and accepting URL schemes.

8. Side Channel Data Leakage

This category involves data exchange that usually enhances app performance (e.g.: keystroke logging, web caches). As with Insecure Data Storage, you should build your app under the assumption that the device might be stolen. All side channels and 3rd party libraries included should be identified and enumerated for any possible data leakage that might occur. The application should be dynamically tested in order to verify that it doesn’t leak data during runtime.

iOS developers:

  • You might consider disabling screenshots, along with cut-and-paste buffers. It is also recommended to disable keystroke logging from within the application.

9. Broken Cryptography

Crypto-keys should never be hard-coded in any construct (plaintext, property files, compiled binaries) and should be controlled at the server side.

10. Sensitive Information Disclosure

Different kinds of information may be considered sensitive in an app, as application logic/business purposes define that. You should keep mind that apps can be reverse-engineered and information like this might be exposed. The best practices in this case suggest avoiding storing private data inside the device; unless absolutely necessary.

The vulnerabilities presented here are not an exhaustive list – they’re just the tip of the iceberg! During the past year, we’ve witnessed numerous attacks against apps by direct code exploitation that usually leads to the device becoming compromised. We’ve also seen attacks that leverage various app weaknesses in order to hijack legitimate user sessions and steal information and money.

Since the app market is constantly growing, we expect to see an increase in the number of attacks against mobile devices themselves. So, if you want to keep up with the times, [tweetable]you should build your next apps with app security in mind[/tweetable].

For more insights, get in touch.

– George

George Karagiannidis is a Senior Information Security Consultant at TwelveSec (TwelveSec.com). George is a seasoned pen-tester, having accumulated a wealth of experience from performing, as well as leading, Information Security projects that range from System/Network/Web/Mobile Application Penetration Tests to Reverse Engineering, Security Design and Architecture of critical Information Systems, and Information Security Management System (ISMS) implementation.

Categories
Business

The Android Monetisation Myth: iOS still rules the west

[tweetable]Revenues from Android apps saw tremendous growth in 2013[/tweetable]. If you look at the headline global figures then revenues from Android apps on Google Play are rapidly closing on those from iOS apps on the App Store. It looks extremely likely that 2014 is the year that Android will overtake iOS in total app revenues. However, dig a little deeper and you’ll find the distribution of revenues, both geographically and across apps is rather different. If you’re planning your platform strategy for this year then a dive into the details might prove invaluable.

Almost a year ago, I wrote about two important app market trends to watch in 2013, which were continued growth of app revenues (they’re still growing, Android significantly faster than iOS) and revenue distribution (it’s getting even more concentrated at the top). According to Distimo:

“On a typical day in November 2013, we estimate the global revenues for the top 200 grossing apps in the Apple App Store at over $18M. For Google Play, our estimate is about $12M. In November 2012, these estimates were at $15M for the Apple App Store and only at $3.5M for Google Play.”

That’s 20% annual growth at the top of the market for iOS and just over 240% annual growth for Android. Add to that there are also alternate stores for Android that have been growing revenues too. These figures and relative growth rates make it seem as if Android is the place to be in 2014. It might be, if you can make it to the very top. If we look at AppAnnie’s report for a similar period, they estimate that total iOS App Store revenues roughly doubled year over year*, while total Google Play revenues were a bit more than triple their year ago levels. So although Apple seems to be improving the revenue distribution slightly, it’s getting even more concentrated at the top of the market on Android.

Even the wider distribution of revenues on iOS may not be quite as good as it looks when we also consider geographic spread. Although the US is still the top revenue earner for iOS, the bulk of the growth is in Asia, particularly China and Japan. The top grossing charts in these countries look very different from the global top grossing apps and this may account for much of the widening range of high revenue apps. [tweetable]On Android, the bulk of the growth and total revenue is in Asia and thus so are the top grossing apps[/tweetable]. Japan has overtaken the US as the top revenue earning country for apps overall mostly due to growth on Android. The vast majority of the increased revenue is in free-to-play games and App Annie’s report shows that in Japan, almost all of this was attributable to just five publishers. Two of those publishers were existing major games powerhouses before the mobile era and they have several well known franchises. Two more reached the kind of scale where TV advertising became a viable route to market and exploded from there. The last of the five is LINE, who built a messaging platform with over 300 million users as a channel to promote their games.

This concentration of revenues amongst five publishers in Japan is mirrored elsewhere in the world. Consider Supercell (makers of Clash of Clans and Hay Day) were at $2.4M per day in revenues in April 2013, when they were still only publishing on iOS (they’ve since launched on Android) and were in the middle of expanding through Asia. That’s more than 10% of daily global App Store revenues for the top 200 grossing apps made by one publisher with 2 apps. Supercell aren’t unique either – according to Think Gaming’s estimates, King.com’s Candy Crush Saga is making more than $900k per day, just on iOS in the US. Indeed Think Gaming give us a better idea of the distribution. Their estimates show that the number 10 grossing game makes only a 10th as much as the top grossing game and by number 100 you’re down to nearly 100th of the revenue.

So, with revenue concentration at the top of the charts on Android even greater than on iOS, Android is the platform to target if you’ve got a world beating app with global appeal on your hands. Otherwise you’re almost certainly still better off on iOS first. Our own data, which considers revenue sources outside the app stores as well, agrees with this. If we only include the publishers earning less than $5M per month then iOS comes out on top, although if we include everyone with non-zero revenues then Android sneaks ahead. Significantly higher revenues for a tiny number of top Android developers pushes the average ahead of iOS (although the median remains way behind – there were more iOS than Android developers earning >$5M per month in our survey).

Android may become the top earning platform from App Stores in 2014 but it seems that only an elite few developers will reap the rewards. We’ve already shown that building enterprise apps and avoiding the app stores is a better bet financially but Android is not currently a lucrative platform in the enterprise market either. Still, it’s not all bad news for Android developers – the rising tide of revenues will lift all boats to some degree. Also, even 2014’s cheap Android device should be running at least Android 4.0 and have hardware capable of running almost any app well. This should reduce costs and increase the real addressable market for all Android developers. Last but not least, for an increasing number of developers [tweetable]it’s not a question of Android or iOS, it’s becoming ever more important to target both[/tweetable].

* Distimo’s year was November to November, while App Annie’s was October to October, so there may be some impacts from the relative timing of new product introductions.

Categories
Platforms

Is Android First Really a Myth?

Popular perception in the tech press is that iOS gets all the best apps first. With Android market share beginning to dwarf that of iOS globally, there’s lots of speculation around when developers will switch to Android first. Our data shows iOS is still the priority for startups in the U.S. but that doesn’t necessarily apply outside the high-growth consumer app market, or elsewhere around the globe.

VM_76_transformers

The importance of platform priority

Just over a week ago, Steve Cheney wrote the very widely shared “Why Android First is a Myth”. The post makes some well-reasoned points about an important issue for the future of the smartphone market. One of the things that makes iOS attractive to a significant subset of early adopters is that it gets most apps ahead of other platforms, sometimes exclusively. [tweetable]If most developers start targeting Android ahead of iOS then those users will switch platforms, taking their app and service spending with them[/tweetable]. Where the early adopters go, most of the rest of the market will eventually follow. As such, developer priorities are considered an early indicator of platform fortunes, particularly at the high end. So if, as Steve suggests, iOS is set to dominate Android in this area for many years yet then Apple will keep making the bulk of the profit in the smartphone market. So is he right?

Silicon Valley doesn’t dominate apps globally

The major problem with the “Why Android First is a Myth” argument is that it is incredibly Silicon-Valley-centric. Whilst the two major smartphone platforms may be developed in Silicon Valley and dominate globally, the content and services used on them does not follow that pattern. Although there are lots of apps in common between U.S. and European app store top charts, there’s still plenty of highly ranked local content in most countries. Looking at the top grossing charts of massive smartphone markets like South Korea, Japan & China, U.S. users would struggle to recognise the name of any publisher (major exceptions being Supercell and King.com from Finland and the U.K. respectively). Not only is the assumption that the apps that make a platform attractive are going to come from the U.S. (or even “the West”) flawed, the assumption that they’ll primarily come from “sophisticated startups” is as well.

Mobile messaging services provide a good example. While VC funded startups may be the way many new services get built in the U.S., WhatsApp being a typical case, the global competition is rather different. KakaoTalk comes from a startup of sorts, although founded by a former CEO of Korea’s internet giant NHN, while LINE came from the Japanese subsidiary of that same Korean internet giant. WeChat comes from Tencent, China’s largest internet company and one of the biggest in the world. It’s more than just how the apps get funded and built though, it’s the types of apps too. The breadth and depth of the app offering on a platform is essential to have all the apps that are important to any individual user, whether it be an app from their bank or niche apps catering to their interests. Otherwise the Windows Phone strategy of paying for the most popular apps to be ported would be a lot more successful. As Paul Graham says, VC funded startups are all about growth, so they have to address issues that they believe are relevant to very large markets. They don’t build more niche or local apps and they don’t build the essential extensions of existing services to mobile devices. This suggests that the platform preferences of a much wider range of developers are important, not just the “sophisticated” startup developers.

Global platform preferences

With this in mind, VisionMobile has a great source of data for monitoring this important platform priority trend. Our regular Developer Economics surveys ask thousands of developers to rank the platforms they use in priority order. Just looking at the data from the last survey on which platforms are most frequently cited as primary by developers in each country we can see strong geographic patterns.

[tweetable]In almost all countries there are a significant fraction of developers who treat Android as their primary platform[/tweetable] and overall the number of developers with iOS and Android as primary platform is almost exactly even. This is biased by a large number of Hobbyists and Explorers* who overwhelmingly prefer Android, largely because it costs less to get started and the platform is more open. As such, iOS still leads by a decent margin (39% vs 32%) amongst those full time developers trying to build or grow businesses. However, this is not true everywhere with South America being dominated by mobile web developers and most of Asia ruled by Android. Europe is fairly evenly split between the two platforms. Most countries’ developer populations follow local user preferences with a slight bias towards iOS. A major exception is Russia, where iOS penetration is low but developers have an unusually high preference for the platform – this is not just outsourced development either; good technical education, a low cost of living and access to affluent global markets seems to be a great combination for smaller independent developers too.

What about startups?

Finally, if we’re purely talking about startups (or Gold Seekers in our segmentation) then iOS is clearly preferred to Android in North America. Out of those with iOS or Android as their primary platform, 70% are iOS first versus the 30% starting with Android. By the same metric, Asia has a 66% majority of Android first startups and Europe is split 50/50. Although our data set for this particular segment might not be large enough to be comprehensive, it’s clear that “Android First” developers are far from mythical!

If you work in a startup cluster and don’t agree with our numbers then please leave us a comment.

* Explorers are part time mobile app developers with a different day job – for more information on developer segments and their preferences see our segmentation report.