Business Interviews Tools

Dev Evolution: Meet Vasil from 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.


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.


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:

Gradle DSL

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.


App developer trends Q1 2015

Our 8th Developer Economics survey has once again achieved an industry-leading scale, including responses from more than 8,000 app developers and 143 countries. Their collective insight shows us an app economy that’s beginning to mature. Platform mindshare and priorities are fairly stable and developers are increasingly turning to cross-platform technologies to deal with the multi-platform reality. Tool adoption is gradually increasing and a shift in focus towards enterprise app development is underway. You can get a copy of the full report here – it’s a free download.


The big changes on their way are in development languages and the Internet of Things. Apple’s new Swift has had an impressive level of uptake but C# and JavaScript are also growing in importance. Meanwhile mobile developers are showing a very strong interest in the next wave of connected devices.

Platform Wars
The platform wars have ended in a stalemate. [tweetable]Apple have an increasing lock on the high-end with iOS and Android dominates everywhere else[/tweetable]. Windows Phone is still growing, now at 30% mindshare, but not generating enough sales to break through the app-gap. The split of developer platform priorities amongst full time professionals best illustrates the stalemate. Android has 40% of developers, iOS has 37%, whilst Windows Phone and the mobile browser have just 8% and 7% respectively.


Although not yet a priority the mobile browser has also bounced back strongly from an all-time low in terms of mindshare 6 months ago, with 25% of developers now supporting it. With the massive growth of mobile apps it’s important to remember that the desktop and mobile web combined is still the most important digital channel for the majority of businesses. [tweetable]The web is definitely not dead[/tweetable].

The Rise of Swift
Our development language rankings show absolutely unprecedented growth for Apple’s new Swift language. [tweetable]20% of mobile developers were using Swift just 4 months after it was introduced[/tweetable] to the world. For comparison, Google’s excellent Go language doesn’t make it onto our new top chart for server-side programming languages, having reached just 5% mindshare amongst mobile developers after more than 5 years. [tweetable]Amongst the first wave of Swift adopters, 23% were not using Objective C[/tweetable], a sign that Swift may succeed in attracting a much wider range of developers to build native iOS apps.


Growth in direct revenues from the app stores is slowing. As these direct revenues are preferred sources of income for the Hobbyists, Explorers and Hunters that make up around 60% of the mobile developer population, competition for them is becoming more intense. 17% of developers who are interested in making money generate no revenue related to apps at all. A further 18% of developers make less than $100 per month and the next 17%, bringing us to a total of 52%, make less than $1000 per month.


Those low revenue earners are not at all evenly distributed across platforms. Of those that prioritise iOS, only 37% are below the app poverty line, making less than $500 per month on iOS. On the opposite end of the revenue scale, 39% make more than $5,000 per month on the iOS platform. Rather surprisingly, the revenue distribution for Android-first developers is not much different than for those targeting BlackBerry 10 or Windows Phone. In fact, developers that go iOS first actually earn much more revenue on Android than those that prioritise the platform.

Internet of Things
Despite the relative immaturity of IoT platforms, mobile developer interest is high. A massive [tweetable]53% of mobile developers in our survey were already working on some kind of IoT project[/tweetable]. Smart Home was the most popular market with 37% of mobile developers working on IoT projects targeting it. Wearables were a close second with 35% mindshare. The majority of these mobile developers involved in IoT development are doing it as a hobby (30% involved at this level) or side project (just under 20%), whilst working on mobile apps in their day job. This is expected at this stage of the market where revenue opportunities are still limited.

Tool awareness is increasing. The fraction of developers not using any third party tools at all has fallen to an all time low of 17%. The second most popular category of tool is ad networks, with a 31% adoption rate. Unfortunately this is the one category of tool that’s negatively correlated with revenues. Cross-platform tool adoption is on the rise. The percentage of developers using these tools has grown from 23% to 30% over the last 6 months. While cross-platform tool use was previously uncorrelated with revenue it’s now a positive revenue indicator. We don’t believe this is due to a significant improvement in the tools, rather it’s because of their disproportionate use in enterprise app development.

Enterprise vs. Consumer
The enterprise app gold rush is now well underway with 20% of developers primarily targeting enterprises, up from 16% in Q3 2014. This shift in focus is paying off. [tweetable]43% of enterprise app developers make more than $10K per month[/tweetable] versus 19% of consumer app developers reaching the same revenue level.

Amongst consumer app businesses, the majority of the revenue is coming from free-to-play games. A typical game is giving a third of gross revenue to the app store provider as a cut of in-app purchases and spending half of what’s left on ads to acquire new users. These game developers are starting to look more like typical fast moving consumer goods businesses, with significant benefits from scale. Despite overall revenues from the stores still rising, life is getting much harder for the small independent developers that try to serve consumers.

The good news for consumer app developers is that 3 of their top 5 favourite categories are common with enterprise app developers. It’s definitely not too late to re-focus on B2B rather than B2C sales. Also, the skills developed building consumer apps are in greater demand than ever now that more and more businesses are taking mobility seriously. This is a trend that will keep running for several years yet.

Want more? Download and read the full report!

Business Platforms

The 3 key Apple Watch features that nobody talks about. Yet.

[If Apple wants to create a new, large product category out of smart watches, they need to create mass-market demand for their new product. What are the 3 most important features that will define the future of the Apple Watch? The ones that enable developers to innovate on top of these devices and create demand for smart watches.]


“We believe this product will redefine what people expect from its category. … It is the next chapter in Apple’s story.” With these words, Tim Cook made it very clear that the Apple Watch is more than just an excellent product. As with the iPod, the iPhone and the iPad before it, the Apple Watch aims to shape the future of wearables and create a whole new market reality.

As it stands, the Apple Watch v1 is a nicely designed timepiece, an engineering wonder, but competition will be fierce. Since fashion is about self-expression, by definition, there will be no single winner.

If Apple wants to create something bigger than fashion accessories, the Watch needs to be a functional tool. If it’s a tool, [tweetable]Apple must answer a fundamental question: what is a smart watch for?[/tweetable]

Will notifications become the killer app for smart watches? Unlikely. Not only is it unclear that we really want more interruptions, but it’s a bit of a dead-end for innovation. There can only be so many improvements in notifications, and only so many companies making those improvements.

If Apple wants to create a new, large product category out of smart watches, they need to become something much more that a timepiece with notifications and sensors. Something that allows people to do things that were not possible before. How Apple can do this? By following the same path that worked so well for iPhone and iPad: Tap into the limitless innovation power of co-creators to discover new use cases and possibilities we cannot imagine today.

The most important features of the Apple Watch going forward are the ones that enable developers to innovate on top of these devices and create demand for Apple’s smart watches. What are these features?



The straightforward way to expand the functionality of the watch is the WatchKit SDK, which allows developers to create “watch apps”. Other smart watch players like Android Wear, Pebble and Razer have made similar capabilities for developers. Developers are already showing strong interest in smartwatches. For example, the developer program of Pebble boasts 20,000+ developers and thousands of apps,.


The Apple Watch has a strong emphasis on embedded sensors for fitness and wellness. On the launch event, the company dedicated an entire section on it. Tim Cook: “This is a very important area for me and a very important area for Apple.”

But a few sensors and apps do not make a platform. The real potential lies in the HealthKit SDK that Apple launched at its WWDC event earlier this year. While its not technically a feature of the watch itself, it is this SDK that can take the device’s functionality and expand it in a whole new way to monitor activity and other wellness data . Could it be that the category that Apple wants to redefine is not the watch, but wellness and healthcare (in the broadest sense of the word)?

Certainly several other companies seem to go after that opportunity. Among them Google (Google Fit), Validic, Samsung (SAMI), Human API and most recently Jawbone (Jawbone UP API).


Like the Nymi wristband, the Apple Watch has all the technology in it to identify you personally. Apple has already demonstrated how digital identity combined with the Apple Watch can be used to make payments or even open hotel doors. (The clever integration with the new Apple Pay can drive adoption for both.) However, the possibilities are much broader. Biometric identification can be the end of not only passwords, but other kinds of ID as well. Another product category for Apple to redefine and absorb into its iOS universe?

Digital identity is a key control point for many digital leaders, including the likes of Google, Facebook, Twitter, LinkedIn and Salesforce. They are all actively working to hold your identity information and build your online persona on their platform. For Apple, the importance of identity is also evident in their deepening integration between devices and in their introduction of fingerprint sensors in all new phones.

Users first

What is a smart watch useful for? Beyond fashion and self-expression, a new kind of health monitoring and identity are prime candidates for the title of killer use case. Apple is going at it with their proven recipe for launching digital ecosystems: users-first. Apple starts by releasing a well-designed device for hardcore fans with a lot of value built in by default. Once there is a critical mass of users, Apple connects them with developers, who create real mass-market demand for the product.

It will take the ingenuity of a community of developers to explore all the possibilities and create a category killer, and Apple knows it very well.


App Industry Picks & Shovels: How to succeed with mobile developer tools

In the great app store gold rush of the last 5 years a lot of vendors of virtual picks and shovels have set up shop, hoping to cash in on the boom regardless of which individual developers succeed in a fiercely competitive market. Having surveyed developers on their tool choices and revenues, we can see how popular these third party tools and services are. We can also reveal whether those buying the virtual picks tend to do better than those who opt for the virtual shovels, or whether you really need both developer tools.


With great opportunity comes great complexity

As the expected level of quality and functionality in mobile apps is increasing, the monetisation strategies are also getting more complex. [tweetable]In order to succeed, most developers need advanced tools to manage quality in a world of fragmentation[/tweetable]. To optimise revenue models beyond the simple paid download, systems to acquire and analyse the behaviour of users are also essential. Most developers turn to third parties to provide some or all of these tools. Many additionally look to third parties to provide some of the functionality, particularly via scalable cloud-hosted services.

Over 85% of developers who completed this section of our survey use at least one third party tool, while just over 45% of developers use tools from at least 3 different categories. There’s clearly significant demand but how does tool adoption correlate to revenue? Looking at only those developers who generate between $1 per month and $5 million per month (i.e. excluding those not trying to make money, not yet making money and the mega-rich – n=1596) we get the following:

More developer tool use, less risk

Looking at only the mean average revenues you could be forgiven for thinking that developers should be avoiding most third party tools, since by far the wealthiest developers are those not using them. However, a look at the median revenues shows the opposite. Some of the largest and most successful developers can afford to build and control their own tools so don’t need third party offerings. [tweetable]The vast majority of developers trying to make it without any third party tooling support generate hardly any revenue at all[/tweetable]. The median number of people involved in development for the organisations not using tools is 1, whilst it is 3.5 (2-5) for all other results. In general the increasing median revenue with use of more tool categories suggests that those who use more tools have lower financial risks. It’s tempting to speculate that there’s some causation here where developers are able to offload some risk by using proven third party solutions. In fact, the major driver is that the tool categories cover such a wide spectrum of apps that the more you use the more likely you are to be doing a lot of contract development – an inherently lower risk revenue model.

It’s not what developer tools you use, it’s how you use them

How use of tools in the various categories correlates with revenues doesn’t produce any great surprises. Those using cross-promotion networks, game development tools and ad networks are at the bottom of the revenue pile. Large game developers and publishers tend to have their own game engines, can cross-promote with their own titles and even run their own ad systems. The [tweetable]smaller, independent developers who rely on third parties for this typically struggle to climb the app store charts[/tweetable]. App store analytics users are next up from the bottom, this may simply reflect the relatively poor revenues of those who rely on app stores. Most other tool use was correlated with fairly average revenues. Notably above average, ranking second overall, is Backend-as-a-Service (BaaS) – where the mean revenues are about 35% higher than average and the median revenues 50% higher. As a result those using a BaaS typically beat average revenues by significantly more than the associated costs.

Using the data from our survey at the beginning of the year, we previously argued that developers who collect lots of analytics and quality data for their apps and act on it are significantly more likely to succeed. Users of crash analytics tools had the highest mean ($26k/person/month) and median ($2.1k/person/month) revenues of any single tool category in the latest survey. Nearly 50% of respondents to this section of the survey now use usage* analytics tools so it’s unsurprising that their mean revenues are almost exactly average ($17.5k/person/month) although noteworthy that their median revenues are 50% above the average ($1.5k vs $1k). Those using both crash and usage analytics tools had similar mean revenue to those just using crash analytics but significantly higher median revenue ($3.5k). The only tool combination to beat this was crash and usage analytics plus beta testing, which had mean revenues of $33k and median revenues of $3.75k. Beta testing tools can also help developers to improve the quality and usability of their apps, as such it’s interesting that those using just crash analytics and beta testing had extremely low mean ($5k) & median ($750) revenues. Possibly this last tool combination typically signifies a developer with a quality problem rather than one proactively seeking quality?

Is selling picks and shovels where the real money is?

There are some massive app developer success stories but our data suggests that the typical app developer (as represented by median revenue) is struggling to break even. It turns out that the developer tools market is similarly competitive. Selling services to developers ranks third in mean revenue per organisation and per person involved amongst all revenue models (behind per device royalties/license fees and subscriptions). Compared to the users of the tools the mean average income at $29k/person/month is slightly higher than for users of any single tool category but the median income is exactly the same as for the tool users.

* This category gets called both “user analytics” and “usage analytics”. The developer tools do both, although if you only use them to get an idea of who your user base are and how often they use the app (user), rather than what they do in the app (usage), you’re probably doing it wrong.