Month: November 2014

Categories
Tools

Popular ICEs for mobile hybrid app development

If you want to target multiple mobile platforms without having to maintain a separate code base for each one of them, mobile hybrid apps is one way to go. What mobile hybrid apps won’t do, though, is relieve you of the need to manage and use multiple tools, e.g. building your app for a specific mobile platform requires installing the platform’s native SDK on your machine.

popular-ice2

ICEs are here to take this headache away. ICE stands for Integrated Cloud Environment and it’s essentially an IDE that does some of its work in the Cloud. A typical ICE for mobile hybrid app development provides you with tools to design, write, test, debug and profile your app. It also allows you to configure the build settings of your app, manage its signing keys and compile it for various platforms.

[tweetable]One of the most popular features of ICEs is building your app in the Cloud[/tweetable] – they grab your code, upload it to the Cloud, build it and come back with the produced app bundle(s). Since the build process no longer takes place on your machine, there is no need for you to install any native SDKs. Apart from building, ICEs may also use the Cloud for storing your app or for pushing it to a device for testing purposes.

A mobile hybrid app development ICE traditionally comes with a companion mobile app that can be downloaded for free from all major app stores. This companion app acts as a container for your own app (your app runs inside it, so you not need to install the former on the device) and also provides some extra functionality (e.g. checking for new builds of your app).

So, here are four of the most popular ICEs for mobile hybrid app development (PhoneGap Build is not really an ICE as we’ll explain later on). But before diving into the details, the following tables provide a handy overview of these tools.

Tool Owner Free? Type
AppBuilder Telerik No Desktop-based (Microsoft Windows), Browser-based
Intel XDK Intel Corporation Yes Desktop-based (Microsoft Windows, Ubuntu Linux, Apple OS X)
Monaca Asial Corporation Yes * Browser-based
PhoneGap Build Adobe Yes * Browser-based

* A free subscription plan is offered (among others).

AppBuilder Intel XDK Monaca PhoneGap Build
Code editor ✔ ✔ ✔ ✘
Drag-and-drop tool(s) ✔ ✔ ✔ ✘
Source version control ✔ ✘ ✘ ✔
Collaboration ✔ ✘ ✔ ✔
Device simulator ✔ ✔ ✘ ✘
On-device debugging ✔ ✔ ✔ ✔
On-device profiling ✘ ✔ ✘ ✘
Builds ✔ ✔ ✔ ✔
Companion app ✔ ✔ ✔ ✘

AppBuilder

With AppBuilder (previously known as Icenium) you can develop your app in collaboration with other members of your team, using both a code editor and a drag-and-drop tool (experimental and limited to apps that use Kendo UI).

AppBuilder allows you to test your app on a built-in device simulator, on native emulators installed on your machine, as well as on real devices (both connected and remote). In the case of real devices, you can either install your app or run it inside the AppBuilder companion app.

While your app runs on the simulator or on a connected device, you can debug it using the bundled debugger that’s based on Web Inspector. AppBuilder also allows you to automatically reload your app as you make any changes to its source code.

❢ AppBuilder offers Cloud-based storage and version control for your apps.

app-builder

Intel XDK

Intel XDK contains a bundle of tools: a code editor that is based on Brackets, two drag-and-drop tools that help you design your user interface (one supports App Framework, Bootstrap, jQuery Mobile and Topcoat, while the other is limited to App Framework), and a device simulator that is based on Apache Ripple.

In addition, Intel XDK allows you to test your app on real devices that are connected to your machine or are in the same wireless network as your machine. In both cases, you need to have App Preview (Intel XDK’s companion app) installed on your device. Similarly to Telerik’s AppBuilder, Intel XDK automatically reloads your app (if you’re using an Android handset) as soon as you make changes to the source code.

With Intel XDK you can also debug and profile a running app. On the device simulator you can use a debugger that is based on Chrome Developer Tools (CDT). On a real connected Android device (with both App Preview and App Preview Crosswalk installed on it), you can use weinre (WEb INspector REmote) and a built-in profiler that helps you identify hot-spots in your Javascript code.

❢ Intel XDK supports live layout editing. While your app is running on a connected Android or iOS device, you can preview the result of the changes you make to your HTML and CSS files as soon as you hit save.

intel-xdk

Monaca

Monaca allows you to collaborate with other testers and developers on developing your app. You can chat with them as you write code, and share your thoughts, as well as screenshots of your running app, while debugging it on a real device.

With Monaca, you can preview your app in a browser (with different device screen sizes and orientations) or run it on real devices inside Monaca Debugger (the companion app of Monaca). In both cases your app gets automatically reloaded every time you make changes to the code and save them.

You can debug your application in preview mode, using the debugger that comes with your browser. Alternatively you can debug on a real device, using Monaca Debug Panel, a tool based on Web Inspector. Some debugging features are also available on the real device; for example, you can view the source of the current page or inspect the application log.

❢ Monaca stores your code in the Cloud, and you can access it at any time and from any place using WebDAV.

monaca

PhoneGap Build

PhoneGap Build is not really an ICE, but rather a build service that works in the Cloud. It pulls the source code of your app from either a .zip file or a (private or public) Git repository, and then allows you select the platforms you want to build your app on. Throughout the building and testing process, PhoneGap Build enables you to collaborate with testers and developers from your team.

PhoneGap Build allows you to build debug-enabled and/or “hydrated” versions of your app. With debug-enabled builds you can remotely debug your app using weinre, whereas new hydrated builds can be automatically pushed to the devices and replace older ones.

❢ PhoneGap Build does not store the passwords for your signing keys for more than one hour since the last time you used them.

phonegap

To sum up

Mobile hybrid apps allow you to target multiple mobile platforms with less code, in less time, and with fewer programming languages. ICEs for mobile hybrid app development move parts of the development process in the Cloud (e.g. they build your app there), thereby adding one more benefit to the above list: fewer tools.

There are several reasons for trying out an ICE – the choices differ according to what you’re trying to achieve. If you enjoy writing code on the Web, you can use Monaca, while if you want to spend less time on writing code, AppBuilder’s and Intel XDK’s drag-and-drop tools might make your life easier. Keep in mind that using an ICE does not require abandoning your current editor or IDE – you can use any editor or IDE you like and then import your code into an ICE to test, debug or build your project. Finally, there are some cool features in this post that might have caught your eye – e.g. Intel XDK’s remote profiler or Monaca’s collaboration tools. So, get started with an ICE – and let us know what you think!

Update Dec 15, 2014: Monaca kindly informed us they also provide full debugging functionality via USB, using Chrome on Android and Safari on iOS devices.

Categories
Business

How to make money with apps

A major theme in our State of the Developer Nation reports is an increasingly gloomy picture of typical developer revenues. [tweetable]The vast majority of developers make very little money from their apps[/tweetable]. However, there are a lot of developers out there and a decent fraction of them make a good living, some are building thriving businesses on the app stores and a few at the top are even creating multi-billion dollar companies. So, what’s different about the developers that are succeeding financially versus those that are living in app poverty?

chapter3

Are you making money from your app? Let us know and you might discover new tools that can make you even more profitable. Start here.

There are two major risks when analysing groups of successful individuals or companies to try to work out why they succeed when others fail; the first is survivorship bias – ignoring the many failures that may have done exactly the same things, the second is confusing correlation with causation. In the latter case there are many things that developers do because they have a successful app, like porting it to lots of other platforms, that are completely unrelated to how they became successful in the first place. [tweetable]There isn’t a magic formula for success on the app stores[/tweetable] but we can try to avoid falling into these traps by looking at factors that might increase your chances of success.

In our last report we showed two major factors that correlate with higher revenues, targeting enterprises rather than consumers and using 3rd party tools. The former is almost certainly a direct cause of financial success, the later is probably indirectly related, tool use indicates a more sophisticated approach to app development as a business. There are many more factors that can make quite a significant difference to the chances of financial success with apps, so lets take a look at some of them.

As our benchmark we’ll use the rather modest (but challenging) goal of making more than $5k per app per month. This is a revenue level that would allow a single app to support a developer in the US or Western Europe but is below a typical employed developer salary in those places. In some countries it would support a whole team living very comfortably. How much more likely are developers to be earning above this level depending on which platforms, categories and device types they target or what revenue models they use?

Platforms

It’s been widely reported that iOS is still ahead of Android for revenues but there are suggestions that Android is closing the gap. Looking at overall revenues from the platform or the earnings of the very top developers, this may be the case. Some even earn more on Android than iOS. However, revenue is more concentrated at the top on Android than iOS, so the chances of earning above the $5k per app per month level are still much higher for those who primarily target iOS. Despite the decreasing popularity, targeting the mobile browser is quite far ahead of building Android apps too. In this case though, many targeting the mobile browser may already have successful desktop web businesses, so this might not be so easy to replicate for those starting new businesses. Windows Phone and BlackBerry 10 are both offering very low chances of a decent financial return as primary platforms. Note that this doesn’t imply that there’s no revenue available on either of these platforms, it could all be going to apps that succeeded on other platforms first and then ported.

App categories

It’s no surprise to see enterprise apps and business and productivity software at the top of the high earning app category charts. What’s more interesting is the “other” category between them. Developers who seek out and dominate niches outside the standard app categories are doing very well; it’s not the route to a billion dollar company but it’s a smart strategy for a small business. Despite the many reports of fitness trackers ending up unused in drawers after a few months, health and fitness related apps are doing quite well. It’ll be worth watching how the major platforms health and fitness data platforms impact this category. The success of the communications and social networking category at this revenue level is slightly counter-intuitive, this is a category with significant network effects favouring a few big winners. It seems that this is such popular use case for mobile devices that there’s room for a lot of developers to add value. To contrast with these, the categories at the bottom of the list are Kids (16%), Games (17%) and Education (17%). These bottom categories are pulled down by their popularity with hobbyists, giving full-time professionals targeting these categories a lot of free competition.

Device types

Smart TVs and set-top boxes are a surprise leader in terms of device types to target first. Only a tiny fraction of developers in our survey had these as their primary target, so this isn’t a reliable sample. It’s hard to get visible on TV platforms and you usually need content, so this might not be a strategy to emulate. The Internet of Things is also unexpected at number 2 considering how immature the market is. It may be the case that hardware sales are involved in many of the higher revenue earning businesses here, in which case there are much higher costs associated than for pure software businesses. While smartphones are a massively more popular primary target than tablets, the chances of an app earning above the $5k per month level are quite a lot higher on tablets. There are likely to be several factors involved here; less competition, more tablet apps targeting enterprises and with the reliance on free apps making most of their money from a small fraction of users, it can pay to provide an optimum experience for the heavy users on a larger form factor. This last point is valid right up to the highest revenue levels – Supercell have built their games tablet first with a scaled down experience on smartphones.

Revenue models

At the top of the revenue model tree is per device royalties or licensing fees.This is likely to be a mixture of enterprise apps and successful apps that have managed to get pre-installs on devices. This is a highly desirable revenue source but certainly not available to all apps. The next best is contract work at 30% of developers earning more than $5k per app per month. Contracting gives a decent chance of making higher revenues but of course the app belongs to whoever it is built for, so the upside is also very limited. At the same time this is by far the lowest risk model, with twice the chance of making more than $5k per app per month than the worst model, advertising. Subscriptions and e-commerce are tied for third place at 29% and affiliate and CPI programs are not far behind at 28%. These models are often harder to implement but our data suggests that the effort is likely to be worth it if they can fit the app concept.

Finally, an interesting comparison towards the bottom end of the revenue model scale is paid downloads (18%) versus free apps with in-app purchases (19%). There is very little difference between the two revenue models at this level of revenue. This is a very strong contrast with the total amount of revenue earned through each of those models. This probably reflects the fact that getting a freemium model with in-app purchases to work is difficult – there’s a very big risk of just giving a free app to a massive majority of users and getting no more paying users than for an equivalent paid app.

Conclusion and warning

There are a number of different ways you can target your apps and select your revenue model to increase your chances of financial success. What we haven’t analysed here is how these combine. Some of them probably won’t, for example, tablet first and iOS first is a good combination, but tablet first and Android first probably isn’t. Our analysis in the State of the Developer Nation report has also shown that some of these combine in an additive way, for example, building enterprise apps for iOS has very high chances of financial success.

 

Take the Developer Economics Survey, test your skills and compare them to the global average. You can work on those skills that need improvement and become more competitive. Cool, right?

Categories
APIs

What the logs don’t tell you

In a world that is increasingly dominated by mobile applications and cloud services, APIs are becoming crucial to developers and service providers alike. But what are developers actually getting? And is this what service providers think they provide?

error-logs

Developers

Developers want to use APIs that extend their service without having to either build the technology themselves or comply with required legislation or security (think payments or anything to do with storing large amounts of personal details).

[tweetable]Developers want simple, scalable, well-documented APIs that are as reliable as possible[/tweetable]. They do not want API they use to make their service unreliable, buggy or slow, i.e. make them look bad. Poorly-performing APIs can harm a developer’s reputation but also the API provider’s, should the branding of an API be visible to the world (think Twitter, Facebook, Instagram).

API Providers

API providers grant access to a service or services through the use of public or private APIs; a private API being a service that is not for public consumption for privacy or security reasons. Why grant access at all? To allow developers to use services and functionality that they do not have to build themselves and provide stickiness to an existing user base. Salesforce has done an amazing job of allowing third-party developers to use and extend the functionality that is provided and has even allowed developers to build a thriving apps and plugin community.

API providers look to balance the load on their servers that may also be dealing with other services. They are trying to provide minimum response times whilst maintaining the access and integrity of the data and the service for the developers.

Schrodinger’s API, it both works and doesn’t work at the same time

Here lies the problem; when an app that relies on an API performs badly whose fault is it? Is the app performing how the developer expected or is the API not responding and thus slowing the service? I[tweetable]t is very easy for the API provider to believe that just because the green light is on that the API is working[/tweetable]. Many systems behave completely different from the theoretical under load, when exposed to extreme conditions or elements beyond normal operation or even users doing unexpected things to the API.

Logs

System logs, either from servers, application monitoring tools or other conventional developer operating systems are excellent at hiding things because there is usually a lot of data to digest and identifying the issues from the noise can be nearly impossible.

Some examples include:

Averages – Whilst an average latency of 300ms may look ok its not if you are still getting a number of calls that take 10 seconds. To understand whether or not your slow performaning outliers are an issue means you have to look at the distribution of latencies and the frequency of the outliers.

Errors rates – hopefully these are low. Even a low error rate in a popular API can represent a huge issue. Consider an API that deals with 2 billion transactions a day at 0.2% error rate still has 4 million failed calls a day.

Logs only measure calls – If the API is not frequently used then the logs are not going to tell you anything. If the bulk of transactions are say only done on a Friday but the services failed on a Thursday then the detail will not be in the logs. Only frequent monitoring will notify you of issues before they hit your users.

Basically what the logs don’t tell you is how APIs work end to end, in different geographic regions and what the end-to-end latencies are when using real transactions.

Some simple rules

Monitoring is for life not just for Christmas.

An API that is switched on may not stay on but may be on every time you check.

The reliability of an API is inversely proportional to the number of people using it and the number of developers trying to do things that may break it.

The use of server logs is a function of user base and the amount of data being recorded.

Test the API like it would be used in the wild, end-to-end across a range of cloud services and apps. In this instance cloud services means hosting platforms like Google Apps Engine, Amazon Web Services and Azure to name a few.

Key question to ask is whether the servers are being tested for performance or the API and the impact on users and the overall experience?

As a developer and a user of services it’s the experience that matters. Poor experience equals poor brand perception, which leads to trying a different API or app, losing the client whether it’s a developer or a guy with an iPhone migrating onto the next app.

Things to consider when testing

Where is the data being served and where are your users?

An app that works in San Francisco when the server farm is in Mountain View may show differences when the same server farm has to serve the app in Europe. Test the API from different locations.

I got a HTTP200 response that means everything is fine, right?

Whilst most of us have seen HTTP 404’s, page not found, we also know HTTP 200 indicates an OK response from the server. The challenge comes from when a HTTP 200 means that things are not OK. For example, in order to avoid browser problems, some APIs only return HTTP 200 with an error message which needs to be parsed. Alternatively, the API might be returning invalid content which could cause an App to fail.

API search function comparison

facebook-vs-twitter-latency

In the above figure it can be seen that the average latency for search using the Facebook and Twitter API is approximately 2 seconds apart with Twitter being the faster and less erratic. Whilst we can only guess at what is happening in the background the reality is Facebook Graph Search appears to be less responsive to anyone using this feature in an app.

Regional server response variation

facebook-api-geo-latency

The above figure shows Facebook Get response across 6 regions globally. It can be seen that Asia and particularly Japan are poor cousins when it comes to regional performance. This behavior has been viewed with other APIs that have been tested in this way.

Caching data

search-caching-impact

The above figure shows the effect of caching on server response. After caching was implemented on the server it can be seen that response improved, even during refreshes (the spikes) overall performance was up.

Server issues

dropbox-api-latency

The above figure shows intermittent server issues over time. This can be indicative of load balancing issues or a problem with a server in a server cluster.

What is the future?

[tweetable]The number of APIs is only going to increase and developers are likely to rely on 3rd party services more and more[/tweetable]. It is also likely that more than one API from more than one provider will be used in an app. How can we mitigate against the response of one API compared to another? We see a need for intelligence in the app that can let that user know that something may be awry with the service trying to be accessed. This should be utilized as part of the UI flow to warn that ‘hey looks like is not responding, please bear with us’. This would be enabled by pinging the monitoring service to determine if there are any issues reported or the app being alerted automatically on a fail scenario that is outside pre-determined boundaries.

Intelligence in the monitoring will also lead to better understanding of the results and give a heads up to the API providers when issues occur or when the data is showing that a server is about to fail and allow providers to avoid downtime.

Disclaimer: Data was provided by APImetrics.io who focus on API Performance measurement, testing and analytics. John Cooper is advisory board member at APImetrics

Categories
Business

North American App Developer Trends 2014: Insights into the app economy powerhouse

North American app developer trends

North America plays a very central part in the app economy. Firstly, it is home to the companies that create all of the leading mobile platforms. These include some of the largest developer communities.  Secondly, it is the largest creator of app revenues. We estimate that in 2013, North American app developer trends contributed 42% of the world’s app economy. Developer mindshare in the region is also considered particularly valuable by OEMs and tools vendors. This is due to the disproportionate global shares of both venture capital and media coverage focussed on the region. North America is often the starting point for new developer trends with high smartphone penetration and relatively mature 4G networks.

07-NA-App-Economy 1200x900

For those that seek to understand developer trends and preferences in North America we have created a new report which compares the region to the rest of the world. The report covers developer mindshare for platforms, languages and tools. It also includes revenues and deeper dives into enterprise and game developer markets.

North America App Developer Trends report: Questions answered

  • Why are developers in North America more likely to target mobile browsers than those in the rest of the world?
  • Android mindshare is higher than iOS in North America. But by how much?
  • Despite lower mindshare, iOS is prioritised by more North American developers than Android. But how many?
  • How much more revenue does a developer in North America earn on average than one elsewhere in the world?
  • How is that extra revenue distributed amongst the developer population and across platforms?
  • Which revenue models are most popular and which are the most successful in North America?
  • Enterprise developers in the region make significantly more revenue than those targeting consumers. How many times greater is the average revenue?
  • Which revenue models do these enterprise developers favour? What’s their share of the total revenue pie?
  • Games are also monetised differently than other apps. Which are the most popular revenue models for North American game developers?
  • Ad networks are the most popular category of tool globally but not in North America. What’s more popular there?
  • What’s the breakdown of developer tool usage across platforms in the region?

The North American App Developer Trends 2014 report includes many more insights and explanations of key trends. If you need to know more about developers in the region then this report is for you.