Tag: Costs

Categories
Business

Are you using the right app revenue model?

The most popular revenue models appear to be those that are easiest to implement. The developers using them tend to have lower revenues. This may be due to greater competition or it might just be a result of less sophisticated app businesses producing less valuable apps. There are some interesting differences between platforms but [tweetable]subscriptions appear to be a relatively untapped gold mine everywhere[/tweetable], although maybe not for everyone.

VMMoneyNote2_800

Revenue models versus average revenues

Our research shows some significant variation in average developer revenues depending upon the revenue models being employed. An investigation of the relative popularity of revenue models versus revenue generated across the major platforms produces some useful input for app development strategy and planning. Unsurprisingly, the simplest revenue models to implement, like paid downloads and in-app advertising, tend to be the most popular. The often repeated stereotype that “Android users don’t pay for apps” also leads to a strong preference for ad-supported apps on Android, while iOS developers prefer paid downloads. Slightly more surprising is that although Android has a larger user base who seem less inclined to pay up front for their apps, freemium and other in-app purchase schemes are less popular than on iOS. It would seem that on average [tweetable]iOS developers are more sophisticated in their approach to the app business[/tweetable].

Revenue distribution

When considering revenues it’s important to note that the distribution of revenues in the app business is highly concentrated at the top and there are a lot of hobbyists who earn nothing. We exclude most hobbyists, those who’ve not started earning revenue yet, the mega-rich chart toppers and large publishers from our analysis by only counting developers with between $1 per month and $5 million per month in revenues here. Even so, there is a fairly large “middle class” of smaller independent developers with a lot of users and high revenues. As such there’s a massive difference between mean and median revenues even in this subset.

The revenues shown in the chart above don’t necessarily all come from the platform or revenue model they are linked to – [tweetable]developers use multiple revenue models and multiple platforms[/tweetable]. For example, amongst developers who target iOS first the in-app advertising model appears to do much better than for those who target Android. Although iOS advertising rates are higher, this isn’t the primary cause, since very few of our iOS respondents derived most of their revenue from ads. The actual reason is that many of those using ads also used a freemium upgrade model (presumably paying to remove the ads and possibly add features) and derived a significant fraction of their revenue from that also. The same strategy does not appear to work as well on Android. Although not entirely accurate, we’ll refer to revenues by platform and revenue model as a shorthand in the rest of this post because it’s a reasonable approximation in most cases.

Less popular, more people, more revenue

Interpretation caveats aside, one thing that seems clear from this data is: [tweetable]the more popular the revenue model, the less successful the developers using it[/tweetable]. The exception here is contract work, which shows much higher revenues on iOS and lower on Android relative to its popularity. Although there’s some evidence that contract development rates for iOS are slightly higher, the difference is mostly due to where the platforms are most popular with developers. Otherwise, most revenue models show slightly higher mean revenues on Android but significantly lower median revenues. There’s also a link between the average number of people involved in app development in an organisation and the revenue model. More people involved, may signal more complex development for the associated apps. The fact that this is also associated with increased revenue is possibly related to using the extra development complexity (or team size) on a more sophisticated revenue model. It is not the case that more people involved results in higher average revenues per person in general. In fact, there is a very strong peak in mean revenue per person for organisations with 6-10 people involved in development – there are probably some significant efficiency losses above this size.

The subscriptions gold mine

Across both Android and iOS, [tweetable]subscriptions generate by far the highest mean revenues[/tweetable]. Median revenues for subscriptions are also higher than every revenue model except contract development. At the same time, only just over 10% of developers use a subscription model and the average number of people involved is lower than for all but the simplest revenue models. Mean monthly subscription revenues for Android-first developers are 3 times higher than for their iOS-first counterparts. It seems that Android users not paying doesn’t apply to subscriptions. However, median monthly subscription revenues on Android are less than half those on iOS, so there are a smaller number of very big winners with Android-first subscription businesses.

Should more developers be trying to build subscription-based businesses? Almost certainly yes, but they’re not for everyone. While 53% of developers using the paid download model and 45% of those using in-app advertising are in 1-person companies, that’s only the case for 20% of subscription businesses. In fact 53% of the subscription businesses in our survey had more than 5 people, not all of which are directly involved in app development. This is because many popular subscriptions include continuously updated content and there’s significantly more work (and cost) involved in providing ongoing content for subscribers. Our survey has also shown that money is not a primary motivator for lots of developers and managing the content side of the business may not be something they’d want to be involved with. For entrepreneurs looking to build successful app businesses, the subscription model is definitely worthy of further investigation.

– Mark

Categories
Tools

Cross-Platform Tool Trends – Freemium & Flexible

CPT trends

CPT trends

Creating versions of an app for multiple platforms (at least iOS & Android) is an increasingly common requirement. Building and maintaining native code for every platform supported is both difficult and expensive. Cross-Platform Tools (CPTs) offer a solution to this problem by enabling sharing of code across platforms and in many cases a single code base can target multiple platforms. With such significant cost savings available, why don’t all developers use CPTs?

Learning curves & licensing

Unfortunately the platform spanning magic provided by CPTs doesn’t come without any costs. Most CPT vendors depend on licensing revenue – developers have to pay to use the tools. Of course the cost of licensing most of these tools is far less than the cost of a full native port of an app to one additional platform. However, there are more costs associated with adopting a tool than the license fee; learning to use a CPT and building confidence in it’s suitability for future projects requires a significant time investment. The potential future cost of switching away from a tool that isn’t working out as hoped is also something that developers must consider.

The spread of Freemium models

In order to build sufficient confidence in a CPT to build their businesses around it, some developers need lots of time for evaluation, perhaps building a side project before risking major apps or customer projects. For many the 30 day trials that were typical in the sector just weren’t sufficient. One of the first mobile CPTs, MoSync, was very early to recognise this and had generous free options early on, they even went open source with a dual licensing model back in 2009 around the time many of their competitors were just launching. This year has seen a tipping point, possibly partly due to increased competition in the sector but also to capture a larger share of the ever growing demand for mobile development – Appcelerator, Corona, RunRev, Unity and Xamarin have all either switched to freemium models or expanded their free offering for mobile. RunRev has also joined MoSync in releasing their code under an open source license, Appcelerator have open sourced more of their code and Xamarin have just open sourced some of their cross-platform API wrappers. Having access to the code for the cross-platform layer can help remove developer fears of getting blocked by a bug in their chosen tool and being entirely dependent on the vendor for a rapid fix.

Technical tradeoffs

In many areas platforms are sufficiently different that it’s not possible to unify them under a single API. CPTs get around this in a number of different ways:

1) Not providing access to the problematic functionality – this restricts what developers can create.
2) Providing a lowest common denominator API – this prevents developers from using the full power of the native platforms.
3) Providing their own implementation of the functionality – this can bloat apps and often prevents them from having a fully native experience.
4) Providing thin wrappers or separate extensions for each platform – this gives maximum control but adds complexity to the code, reducing the benefits of a cross-platform approach.

Different apps, or even parts of apps, will have different priorities that determine which of the above approaches are acceptable. For example, a mass market consumer utility app is likely to require a completely native look and feel for the UI, while an internal app for a large enterprise may want to look and feel exactly the same on all platforms to minimise both development and staff training costs. The same tradeoffs won’t always apply to every part of an app either; most games have a completely custom UI and don’t require access to the native platform UI components at all, however, they may well want access to the new Google Play game services, or the iOS 7 Game Controller APIs as soon as they are available.

A flexible future

Faced with a still growing list of platforms to support and wide array of new features in each new platform version, CPT vendors now have to specialise for a sufficiently profitable subset of the market that has fairly narrow requirements or become increasingly flexible. Most vendors currently provide flexibility through a native interface that enables the creation of third party extensions or plugins. Xamarin’s approach to flexibility enables developers to (semi-)automatically generate wrappers for any native API or library, which is ideal for developers who want to stick with C# for all of their own code yet build on the work of native developers for each platform.

Even greater flexibility is possible though. What if you could just build the parts of an application that made sense to be cross-platform with a CPT? RunRev has a beta for an embeddable library version of their engine to enable this, although currently only for iOS. They are also re-architecting their engine to put 3rd party extensions on an equal footing with the core functionality – even allowing them to extend the language where necessary. Another interesting option going forward here is Digia’s Qt, the open source cross-platform framework that was acquired and re-purposed for mobile by Nokia before they dropped it in favour of Windows Phone. Qt is now the native framework on BlackBerry 10, Ubuntu Mobile and Sailfish OS and is close to production readiness for iOS and Android; it also has a Tizen port ahead of the release of that platform. The core of Qt being C++, it can easily interface with native code on most platforms and has always been delivered as a library, so it’s also embeddable within native apps.

Flexibility enables greater agility

This library format means that developers can start cross-platform and add or optimise parts of their app with native code later. It’s possible to just add a full native experience for the platforms that get the most traction. Alternatively, starting on a single platform and then adding new functionality that works across all platforms after achieving some success and starting to port to other platforms is also an option. Last but not least, the library format also removes any concerns about lock-in. If a developer decides to migrate away from a CPT, they can do so gradually, without having to port/re-write everything in one go. It’ll be interesting to see how many vendors can push flexibility this far and how many developers take advantage of it.

Categories
Business

How Much Is An Active User Worth?

Revenue per user

App store analytics providers have been telling us that almost all of the growth in app revenues in the last year has been through in-app purchases. However is that just because the model has become more popular? Or because revenue has been concentrating at the top of the market where the strategy is very popular (particularly in free-to-play games)? Probably a bit of both but it’s also the case that subscriptions and in-app purchase do produce the highest overall revenues. If you exclude the developers of top apps (anyone earning over $50k per app per month on average and with over 500k active users) then it turns out that aside from apps that provide enough value to justify a subscription model, the important thing is acquiring users and keeping them engaged. The average revenue for an active user is fairly constant, regardless of the monetization method.

How much do you think is an active user worth? Take the Developer Economics Survey and have your say!

For the purposes of our survey, freemium could be a limited free app with a separate paid version promoted by the free one, or a free app with a premium upgrade via in-app purchase. In-app purchases can be any content, features or virtual goods purchased in the app, which itself can be paid or free. Paid downloads, advertising and subscriptions are hopefully self-explanatory. Note that it’s possible (and indeed quite common) for developers to use multiple revenue models, either on separate apps or within the same app – e.g. freemium with advertising in the free version. The average number of revenue models per developer in the sample above was 1.7. However, if we only look at developers using a single revenue model, the pattern is very similar (and average revenues are lower across the board).

Make the core functionality free if you can

For the majority of developers, an active user is worth around $0.04 per month. All other things being equal, unless you have a sufficient reputation or well known brand association that you can get paid downloads in large numbers, then it’s better to avoid the user having to pay directly for the core functionality of your app. This results in more downloads and a larger user base. Freemium comes out badly here, it seems that the free trial may get lots of downloads but overall slightly fewer active users (and paying users) than a straight paid download. Advertising and in-app purchases had almost identical user bases and overall revenue. Subscription apps had the smallest active user bases but by far the greatest revenue, however, this revenue model requires some kind of ongoing service that is external to the app, which will have associated costs.

In-app purchase beats advertising at the top end

The picture is a little different if you include the highest earning apps. At this point paid downloads fall far behind, both in terms of ARPU and overall user base and revenues. This is not to say you can’t have a very high grossing app with a pure paid download approach (Minecraft is a great counter-example), just that the probability of doing so is much lower. Subscriptions still come out on top but not by so much. The lower ARPU for subscriptions at this level suggests that the top subscription apps have a very popular free tier. Freemium does slightly better than paid downloads for active user base size and significantly better for revenues, suggesting that top quality paid apps with a higher price may sell better with a free trial of some kind. Finally, in-app purchases and advertising both generate the largest active user bases by offering their core functionality for free but a well designed in-app purchase scheme beats advertising for monetization by some distance.

Beware service costs eating all your revenue

In addition to revenue model selection there are also implications here for apps which connect to backend services. The average monthly revenue from an active user needs to exceed the costs of providing the service significantly to make a profit. If the majority of developers are only making $0.04 per user every month on average then say a Kinvey (purely because they price per user for iOS and Android, making the comparison easy) BaaS at $0.03 per user (for 200-5000 users at current pricing) does not leave much for the developer.

 

In-app purchases or ads?  Take the Developer Economics Survey and have your say! You may win awesome new gear.

Categories
Tools

Cross-Platform Tools – Does it pay to use them?

Cross-platform tools

In our January 2013 Developer Economics Report, we revealed that multi-platform developers are better off. Our survey data also reveals, rather unsurprisingly, that users of cross-platform tools (CPTs) target more platforms than those building separate apps for each platform. Of those interested in making money, users of CPTs target 4.33 platforms (3.1 mobile platforms) on average vs 3.46 platforms (2.57 mobile) for those building separate apps. We also know that the most popular class of CPTs (using web authoring languages) tradeoff app capability to get the increased portability. At the same time, popular opinion on the internet and amongst venture capitalists is that a cross-platform user experience can’t compete with using the platform native frameworks. So how do these tradeoffs translate into revenue for CPT users?

CPT users make more revenue

On average, CPT users make slightly more revenue per app per month than developers not using such tools. With the reduced cost of development provided by the CPT, this suggests that they’re significantly more profitable.

Averages can be deceiving where the distribution of results is far from normal, as with app revenues, so it’s worth examining the details. App revenue is heavily concentrated at the top end of the market, with a large fraction of the (mean) average coming from a small number of very high earners. If we exclude all developers earning more than $50k per app per month then the result holds – CPT users still generate more revenue.

Not all CPTs are created equal

There are also several different types of CPT. Games have been responsible for close to half of all app revenues (at least those generated directly through app stores) and since they typically don’t require many platform-specific APIs or UI elements, they’re a good candidate for building with cross-platform. This suggests that users of primarily games-centric CPTs like Corona, Unity 3D & Marmalade might be responsible for the out-performance of CPTs, while users of the low development cost tools taking advantage of web authoring languages, such as PhoneGap, Appcelerator, Brightcove & Sencha, generate slightly lower revenues. However the data shows that the opposite is in fact the case.  Users of the games-centric CPTs are generating below average revenue, whilst the web-centric CPT users are significantly better off. These results also hold whether or not we include those earning over $50k per app per month.

A plausible explanation for this is that most of the larger and more successful game developers are managing their own cross-platform compatibility or code re-use whilst many smaller independent game developers relying on 3rd party tooling are struggling with the fierce competition in the games market. At the same time it seems that, when it comes to revenue, a fully native user experience and native performance are not as important as their proponents suggest. The very high earners using web-centric tools are most likely to be existing publishers selling their content through mobile app subscriptions and our revenue estimates are probably too low, since the top income band in our survey is everything over $100k per app per month.

Both ends of the revenue spectrum

For several CPTs in our survey we didn’t have enough respondents to be sure differences in revenues for individual tools are statistically significant, however, there are a couple of individual ones worth highlighting. At the low end, revenues for Qt developers were significantly below average – this probably reflects the fact that Qt does not yet have official support for iOS or Android (planned for this year). At the high end, although we only had a relatively small sample, revenues for Brightcove App Cloud users were more than 3 times the average making the difference statistically significant, whether or not we include those generating over $50k per app per month. Brightcove appear to be focussing their solution on a particularly profitable market segment.

Tool selection – do it for the right reasons

Finally, if you’re looking to select a CPT, make sure you do it for the right reasons. Main selection criteria including access to native APIs and the ability to create a native UI look and feel are correlated with above average revenue, whilst the availability of third party extensions and choice of authoring languages are correlated with below average revenue. The former criteria look to minimise some weaknesses of the cross-platform approach whereas the latter criteria focus on reducing one-off costs. The latter are not necessarily bad reasons for choosing a tool but if they are amongst the most important reasons for your selection then it’s worth re-evaluating priorities. Work out what will enable the creation of the best product at acceptable cost rather than simply minimising cost. If the lowest possible development cost is critical to make the app concept viable then it’s probably time to come up with a higher value concept.

Categories
Languages

HTML5 vs Native – What are the tradeoffs?

HTML5 vs Native

In our latest developer survey we asked developers who use or plan to adopt HTML5 why they do so and also what the technology needs to compete with native alternatives. The results show a tradeoff of increased portability and lower development cost against capability, in the form of reduced API access and a poorer development environment. In this scenario, the key to success with web technologies is taking advantage of their strengths in areas where their weaknesses are less of a handicap.

Developer Economics 2013 - HTML5 trades off native optimisation for portability and cost

HTML5 is becoming a viable alternative to native development across a number of app categories. We found that HTML developers mainly focus on specific app categories such as Business & Productivity (42% of HTML developers), Enterprise (32%) and Media apps (28%). On the other hand, Games are not a common category among HTML developers (12%).

We asked developers that use or are planning to use HTML about the reasons for platform selection. The majority indicated code portability as the main incentive for using HTML5. Low cost development is the second driving force for HTML5 adoption, highlighted by 51% of developers. HTML is still an “extension platform” in that only 26% of developers who use it consider it their main platform. We asked developers that use, have used or are planning to use HTML what they think HTML5 needs to compete with native platforms. Access to native APIs is a top challenge with 35% of developers indicating this as a critical success factor. HTML5 will always be a step behind in support for native APIs, given that cross platform tools and browser vendors will always have to implement support for a new API after it is released to developers by the platform vendor. In addition, the HTML5 development experience is subpar, with developers indicating that a better development environment (34%) and better debugging support (22%) are needed. More importantly, optimised HTML5 devices were not seen as important as the native API access or dev environment. This leads us to conclude that HTML proponents such as Facebook, Mozilla and Google should focus on cross platform tools and development environments on at least equal levels as they focus on full platform efforts like Facebook Platform, Firefox OS and Chrome OS.

[doritos_report location=’DE13 Article – HTML5 vs Native’]

Categories
Business Tips

The Costs of App Security

app security costs

The security features of an app are often ignored in the rush to get a new product to market. We naturally tend to focus more on what an app should do, rather than what it shouldn’t. Making sure that an app doesn’t have security issues is a difficult and potentially expensive process. Lately there is evidence that developers are trying at least to face app security costs issues. A recent post from our partners in DZone shows exactly this.

There are no automated tests to ensure user data hasn’t been left vulnerable. This goes for unencrypted passwords as well. Typically this requires a manual audit of the code and some form of penetration testing, with a skilled developer attempting to compromise the app. However, the costs of implementing security features and adding security testing to your development process are much smaller than the potential costs of a major security breach.

Problems with payments

For some types of app the consequences of this are more obvious. There are even standards in place to try to ensure a minimum level of security. For instance, any application which handles payment card details needs to process that data securely as specified by the Payment Cards Industry. However, PCI standards compliance is only audited for large merchants. Smaller merchants self-certify compliance.

If an app or service for a small merchant was compromised, resulting in abuse of payment card data, then any non-compliance discovered could result in significant fines or even liability for any fraudulent payments. Merchants who add interfaces to their existing payments infrastructure to support mobile apps need to be particularly careful. New attacks can be made possible when the payment authorisation occurs on a native mobile client, rather than a website.

Even for apps selling digital goods via in-app purchase there are still payment security issues to consider. Of course stakes are nowhere near as large. However, attackers can still impersonate the official store provider servers and simulate in-app purchases without any genuine payment.

Apple’s system was compromised in this way last summer. Another hack was reported for payments on Google Play just before Christmas. There is no link to this because, although it was only for rooted devices, we’re not aware of a fix in place yet. (Indeed it may even be a scam to get users to install malware).

Losing data can cost you even more

For enterprise app developers, being associated with a major security breach could mean the end of your business.

A harmful loss of data for a client could send valuable market data go to the competition, or even key employees. You would lose trust (and business)! If the breach is sufficiently public, you could lose the trust of all potential future clients as well.

The larger a company the more vital it is that they implement good security practices.

For consumer apps, leaking user data to attackers has direct costs. Firstly, in terms of service downtime whilst fixing security holes (usually in a hurry with the aid of expensive experts), notifying those affected and possible compensation. Secondly, there are serious indirect costs in terms of lost trust and users. Again here, the larger the user base, the more attractive the app is to attackers and the more serious any breach.

Invest in app security appropriately

Investments in security need to be proportional to the risks. How many users are involved and the value of data stored should determine the level of effort required to ensure that data is safe.

Not knowing about the security implications of your application is somewhat like driving without insurance.

Everything is fine until the unthinkable happens. Then it’s likely that lots of innocent people suffer and you get into a lot of trouble.

The technical details of app security are beyond the scope of this post. However, we have prepared a list of top 10 vulnerabilities and how to avoid them. Read on if your app deals with any user data or payments.

Categories
Business

PhoneGap and Appcelerator lead developer mindshare across tens of CPTs

Cross-platform tools (CPTs) address real challenges for developers. Cross-platform tools allow developers to create applications for multiple platforms – usually mobile, but increasingly tablets or TV screens – from almost the same codebase or from within the same design tool. CPTs reduce the cost of platform fragmentation and allow developers to target new platforms at a small incremental cost. More importantly, cross-platform tools allow software companies targeting multiple platforms to reuse developer skills, share codebases, synchronise releases and reduce support costs.

CPTs can be used to develop native, hybrid and web apps and come in several technology flavours: JavaScript frameworks, App factories, Web-to-native wrappers, Runtimes and Source code translators. There are over 100 CPTs that we identified in our Cross Platform Tools 2012 report.

Developers most often use several CPTs; on average CPT users will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our CPT survey a year ago. Moreover, we found that one in four developers will use more than three cross platform tools. The lack of a one-size-fits-all and immaturity in the CPT landscape is what is stalling cross platform tools from shifting the balance of power in the iOS / Android duopoly towards alternative platforms.

Cross platform tools are most popular for developers focusing on HTML development, with 38% of of them using CPTs for development. CPTs and particularly JavaScript frameworks and Web-to-native wrappers, provide a relatively smooth transition to mobile apps for web developers: in our Cross-Platform Developer Tools 2012 report we found that 60% of developers using CPTs have over 5 years experience in web development. Usage of CPTs is popular among iOS developers, while usage among Windows Phone developers is much lower, presumably due to historical lack of support for the iOS platform from CPT vendors and Microsoft’s financial incentives for the creation of native apps.

DE13-18-01

PhoneGap tops CPT rankings, used by 34% of developers, followed by Appcelerator and AdobeAir with 21% and 19% developer mindshare respectively. With over 100+ cross platform tools available, the choice for developers can be a challenge. Choosing between CPT technologies is not always straightforward (i.e. whether to go for a web-to-native wrapper or a JavaScript framework). Moreover, developers need to try out a cross-platform tool to see if it aligns with their needs in terms of performance, learning curve, access to native APIs or look & feel. It’s never a black or white decision.

The most important selection criterion for CPTs is their availability across platforms. Due to their deep platform integration, CPT tools support iOS/Android platforms first, and others secondly. Beyond cross-platform availability, 38% of developers using CPTs select their tools based on development speed and 33% based on the learning curve. Since CPTs aim to expedite and facilitate development across platforms, they should provide a clear advantage over native platforms when it comes to speed and ease of development to justify their use. Amidst differentiating features for CPTs are access to native APIs, performance optimisation and the ability to reproduce native UI elements on each platform.

[doritos_report location=’DE13 Article – CPT’]

Which CPTs are other developers using?


[toggle title=”Important things to know about this interactive graph”]

  • All the filters in the graph refer to survey questions in which respondents could select multiple answers. This means that there is no direct link between the filter and the use of the tool. For example, filtering on “Android” means that the respondents develop Android apps. It doesn’t imply that they use the tools for their Android apps specifically, or even that the tool supports the Android platform. Use filters as a guideline only.
  • Keep an eye on the sample size. If the sample size is low, the graph doesn’t offer strong conclusions about the popularity of different tools. Use your good judgment when making decisions.[/toggle]

Find the best CPT for you!

[sectors slugs=’cross-platform-tools,app-factories,hybrid’]

Categories
Community

Developer Economics 2013 Survey: iOS vs Android shoot-out

iOS is the best platform for generating revenue,
Android provides a better development environment

Developer Economics 2013 - Android vs iOS shoot-out
We asked developers to pick the top platform, among all platforms they have used or are planning to use, on a number of different aspects of mobile development such as discovery, learning curve and monetisation. We then compared how iOS and Android fare against each other, based on the opinions of developers using both platforms.

The outcome is a tie when it comes to user base, with developers’ opinions divided between the two platforms. However, iOS was ranked higher on 4 out of the six remaining categories, with a clear advantage on app discovery (50% iOS vs. 23% Android) and revenue potential (66% iOS vs. 12% Android). The perception that iOS provides better monetisation opportunities is well engrained with developers and is backed by Developer Economics 2013 survey data. App discovery has developed into a problem for both platforms given the size of their app stores, which now well exceed 700,000 apps. However, despite some initial complaints about the new curation model on App Store, the developer verdict is quite clear on app discovery, which goes to iOS. iOS also leads, but with a smaller margin on development environment and documentation & support.

Android has a clear advantage on development cost (32% Android vs. 14% iOS) and a small lead on the learning curve ( 26% Android vs. 20% iOS). However the total score for the two platforms on the latter two aspects was lower than 50% indicating that most developers that use both Android and iOS believe that neither is best in these areas. In fact 24% of developers among those using Android and iOS indicated that HTML is the best platform in terms of learning curve while 7% indicated that its Windows Phone.

For most developers, the platform perceptions boil down to a decision about which platform to prioritise, i.e. where to invest more resources and which of the two platforms to develop for first. Several other factors may come into play when making a decision on the “lead platform”, such as prior experience or local demographics, but it is fair to say that iOS comes out as the winner in developer perceptions. This is consistent with our figures on lead platforms: among developers using iOS and Android, iOS is the lead platform for 42% of developers, while Android is the lead platform for 31% of developers.

[doritos_report location=’DE13 Article – iOS vs Android shoot-out’]

Categories
Platforms

How Much Time Could You Save With Backend-as-a-Service?

Backend-as-a-Service (Baas) provider Kinvey published an interesting infographic on the average time taken to build an iOS or Android app (with a backend service) this week. The data comes from a survey of 100 developers with their estimates averaged. Before interpreting the data, it’s worth bearing in mind the following:

  • This is only to build a Minimum Viable Product (MVP) – it’s nowhere near the total that would be spent on a successful app.
  • The features included create an app with a relatively rich backend service and a fairly basic client.
  • This is only building a client app for one platform rather than several.
  • Building a robust API versioning system would not normally be part of an MVP.
  • This survey has been created specifically to promote the benefits of BaaS.

Even so, the the items included in the infographic would be common to a wide range of applications.

Continue reading “How Much Time Could You Save With Backend-as-a-Service?”
Categories
Platforms Tools

Cross-Platform Tools – Functionality and Trade-offs

CPTs components

Cross-platform tools (CPTs) are a class of developer tool that aim to enable a single implementation of application functionality to run across multiple platforms. If that definition seems very broad it’s because the category covers a wide range of use cases, technology approaches and forms of app deployment. In our analysis of this sector from February 2012 we identified over 100 tools across three forms of app deployment (native vs. web vs. hybrid) and five different technology approaches.

Fundamentally the various platforms are not compatible and the use of a third party tool to solve this issue comes at a cost. The effort saved through a CPT often has a financial cost but more often the largest trade-off is against a loss of flexibility, control or performance. Different tools produce different compromises. In many cases what is lost is not required to deliver the desired experience, so it’s worth understanding the different approaches and choosing the right tool for each project.

Continue reading “Cross-Platform Tools – Functionality and Trade-offs”