Categories
Tools

Agile tools for the Samurai Coder

This post is not meant to help you understand agile methodologies. A simple Google search will be enough to reveal tons of posts presenting, explaining, analyzing and suggesting how to make agile methodologies work to your advantage. And we have to keep in mind that they all usually apply to teams of 3 or more people. This post is about the freelance developer who just needs a simple way to manage tasks and projects. I do not claim that I present the absolute and irrefutable Truth; every person has their own way of working. This post simply intents to be a starting point to another way of doing things.

Meet Sally. Sally is a developer, a Samurai Coder, a hero of the day and she absolutely loves writing code. She works as a freelancer and the other day she got a new project from a customer.

Before starting work, she picks up a piece of paper. She writes down the day’s tasks (to-do’s, appointments, ideas etc) and crosses off the completed ones. She repeats the same process every day. These sheets of paper pile up and follow her everywhere… until she finds Evernote. Evernote replaces the paper and uploads her notes to the cloud, but still…. The notes multiply just as much and just as quickly as the papers do. They only stop creating piles on her desk.

Sally is desperately in need of solution – a way to capture and track her customer’s numerous requests as well as the 100+ things she has to do. What about a bit of agility and organization? How about combining simple methods and tools to get things done? Sally gave it a thought and found out the 5 most important things to her:

  1. Ability to separate projects and tasks.
  2. Clean visual overview, i.e. understand what needs to be done, watch the progress or the big picture, and prioritize accordingly.
  3. Sharing and Collaboration features.
  4. Accessibility, i.e. ability to retreat her work through any device in real time.
  5. Speed, i.e. Sally’s work is programming, not using tools. Tools should work for her, helping her save time, and not the other way around.

The simple process

  1. Here’s a really simple and basic five step-process that Sally could follow. This kind of flow is Kanban-like (but I will talk more about Kanban on another post).
  2. Create a repository for every project.
  3. Separate it virtually in 3 areas: to “To Do”, “Doing” and “Done”.
  4. Add new tasks, requests or bugs in the “To Do” area.
  5. While working on a task, move it from “To Do” to “Doing”.
  6. Move the task to “Done” when completed.

image00

The tools

There is a great variety of software tools in the web; tools for small teams, big teams, distributed teams… But how about one single person? We will see how Sally can follow this process with the use of 3 simple tools: a) Trello, b) Asana and c) Wunderlist

a) Trello

Trello’s visual layout is very intuitive. Imagine a dynamic whiteboard with columns (lists) and cards (like advanced sticky notes).
How to use it:

  1. Create Project with the use of Trello Boards: Each Trello board represents a project. Add lists (columns) to simulate progress. Add cards as tasks. And that’s all…
  2. Managing Tasks: A new Board has by default three basic columns: “To Do”, “Doing” and “Done”. You can drag a card over these columns anyway you like and you can always visually track both the card and its status.
  3. Handling of requests or bugs: Trello has a color mapping that you can apply on the cards (e.g. red color for bugs). You may add lists, comments and much more.

image01

b) Asana

Asana is an advanced task list oriented application with an equally intuitive visual layout to Trello. It is fast, easy to use and quite popular.
How to use it:

  1. Create Project with the use of Asana Projects: Start a new project and add tasks in the center column.
  2. Managing Tasks: Tasks added in the center column get a level of hierarchy and may be stacked. You can start by creating the three high level tasks “To Do”, “Doing” and “Done” and then fill them with specific tasks accordingly. You can easily create a task, drag it to move and edit its details on your right hand side (add sub lists, comments and more). There is a checkbox in front of every task and may be checked if the task is completed. By doing so the task is removed from sight but if you prefer you can manually drag it bellow “Done”.

image02

c) Wunderlist

Wunderlist is a pure task list oriented application, though their newest update has many improvements including Collaboration and Public Lists. It has a clean UI and is much simpler than Asana, quite fast and user friendly.
How to use it:

  1. Create Project with the use of Lists. Add a new list and add tasks in the main column. Just like a true boss…
  2. Managing Tasks: Add tasks in one column. In order to create some kind of flow for your tasks, create more lists (see the example in the pic below). Wunderlist is quite easy to use, but not as advanced as other tools, i.e. missing collaboration features, ability to assign subtasks, etc.

image03

All of the above tools are equally fast, have the ability to collaborate (add more people to your list/project) and can sync to other available devices.

Quick Verdict:

Trello

 

+ Nice visual and collaboration.

 

– No task sub lists (there is a great checklist feature, but there is a minor problem: you cannot assign tasks to these lists. As a result you need to create separate cards).

 

– The visual style with the cards may overcrowd the board making it look messy.

 

Asana

 

+ Nice interface, quick.

 

– Not a nice “big picture” or “flow” visibility

 

Wunderlist

 

+ Nice simplistic UI, powerful task list.

 

– Missing advanced features the other tools offer.

 

+ Their recent update added collaboration features.

 

Sally in our story has therefore many great tools in her disposal. All she has to do is put her pen and paper aside and work easier and faster. And you can all join her!

Categories
Tools

Users Are People Too: The Key to a Successful App is Knowing Your Users

Given the staggering odds against the success of any app in the marketplace, it is surprising that so much effort is devoted to the creation of apps, many of which never see the light of day.

Today, there are over 1.2 million apps in both Apple’s App Store and Google Play, of which just 500,000 are ever downloaded. Out of the 500,000, 20 percent are only opened once in the first 6 months after download, and almost 50% are used no more than 5 times.

brains_thumbnail

Growth hacking relies on incomplete data

With very few exceptions, pure word-of-mouth and organic growth without additional effort on the developer’s part is not enough for an app to surface above the noise. As a result, an entire cottage industry of “growth hackers” has emerged, one which takes traditional marketing approaches and combines them with rigorous metrics to make sure that every step of the process is measurable and actionable. For example, Quora closely monitored the behavior of their most active users. They found patterns that were used to stimulate other users to behave in the same way.

[tweetable]One of the limitations of the growth-hacking approach today is that the mobile ecosystem is still a Wild West[/tweetable], similar to where the desktop software industry was some 10-15 years ago. The most established mobile tools, such as Flurry and Google Analytics are really good at telling developers how users are using the app… which version, operating system, for how long a user engages in the app, which buttons are being pressed, etc… but do little to tell you anything about the wants and needs of the people using the apps.

While these descriptive analytics are critical, there is another piece of the puzzle for creating a successful app, which has been undiscovered by developers today: human understanding.

Human understanding is defined as the knowledge about a user’s demographics, interests, and intents. While tools like Flurry and Google Analytics are starting to provide more of these user insights, they are typically presented in aggregate form, which makes a user hard to understand on an individual level.

Understanding your users

So what can be seen as an improvement? How do you know if you are providing more value to a user or if you’re slapping on features your users don’t care about? The answer lies in understanding your users.

A good place to start in trying to understand your users is to use analytics tools. This seems obvious but only 21% of app developers use these. The most basic information that could provide significant value is to know the demographics of your users. Are they mostly male or female? What is the age distribution? What is their income distribution? Also, from what countries are your users and what languages do they speak? With this data it is possible to make broad categorizations of users. For example, data can show that your app is popular in France among middle aged women. Without being prejudiced, one can assume their English is not great. Translating your app can boost its popularity even more and increase overall satisfaction with your app among these group of users.

The subsequent step is to find out what interests your users have. Integrating social media login possibilities in your app and asking for the right permissions can provide you with all the self-declared interests of the user. Combining this with their demographic data gives you improved segmentation options, which is another step towards a true understanding of your users.

Contextual information is important to consider as well. Where are people using your app; at home, while commuting, at work or in the gym? When are they using it? Only at night? Several times a day? How does this correlate to other users and what conclusions can you make from this? Also, on which devices/operating systems are they using your app at home and which ones while travelling? Figuring this out can direct your creativity and efforts to build features that cater to the context in which your app is used.

Given the vast amount of apps that are offered, no matter how unique your app is, your app has competition. To understand your user isn’t limited by figuring out who they are and how they behave in relation to your app, it’s about the competition as well! How often and how much do your users log in to competitive apps? What are the unique features of the most used competitive apps? Knowing this provides valuable information of what users appreciate in competitive apps.

When all these questions are addressed there is a huge opportunity to grasp. Combine the segmentation information with the usage data from your app – sessions, time in app, ads clicked, screen flow, transactions, returning user, etc.- to identify your most valuable, most engaged and/or most loyal users. Who are they? How are they using your app? If you find answers to these questions, you’ll have identified the people who value your app the most, as well as how they use it and which features create value for them. Having this insight can mean the difference between the life or death of an app. However, it’s important to consider that ultimately the actions that are taken based on these insights decide the future of the app.

What to do next

When you know who are your most valuable (whether this means most loyal, engaged, contributing to revenue, etc.) users you can start targeting and catering to the needs of those users. For example, when implementing changes in the user interface, most developers use some form of A/B testing to figure out what the effects are. This acclaimed method of improving your product can be even more effective when you filter out the effects of those users that are of little value to you. For example, you can be A/B testing an ad in order to optimise clickrate, but seeing very small differences between the two groups. However, if you segment your audience you may see vastly different results; your target group of ‘valuable’ users might be much more engaged with the content than other user groups. The same technique can be implemented for building new features, expanding your offering of in-app purchasable items and personalizing content. [tweetable]By knowing your users you are able to make better and more timely decisions to improve your app[/tweetable]. Over time, your most valuable users are perfectly catered to which makes them love your app even more. This results in a higher retention rate, more engagement and a higher chance of getting recommended to their peers.

Financially, knowing your users makes sense as well. You can offer your ad space to advertisers that are targeting the segments you identified to be your most loyal and engaged users, which raises the eCPM and lowers idle time of your ad space. Additionally, marketing efforts to obtain new users yourself can also be highly targeted. Most developers greatly underestimate and are dissatisfied with the cost of acquiring new (valuable) users. With true user understanding it is possible to specify efforts and use your marketing budget efficiently and effectively, simply getting more bang for your buck. This is especially relevant for developers who are trying to make a decent living from their apps. These findings correspond with those of advisory company Gartner. They concluded that in order to make an app profitable, developers need to win customer’s loyalty and satisfaction by delivering a well designed and top-performing product.

Building your next app

Success is a concept that can mean different things to different people and different kinds of apps. Some developers don’t like to discuss marketing and the business side of developing and maintaining an app, but it’s an indispensable part of making an app successful. For the people that are in it to make a living, knowing your users is crucial. Raising your ads’ eCPM, lowering its idle time, getting a higher return on marketing investments and a higher Life Time Value (LTV) is worth taking the time to get to know your users. Your efforts will be focused to cater to your most valuable users which greatly improves effectiveness across all your activities, from building new features to marketing your app.

Having these insights doesn’t have to be limited to just one app. Building your next app based on this vital information can give you a head start. You can use it to answer questions such as: What platform should I focus on? iOS, Android, both or try other platforms with less competition? Optimize for smartphones, tablets or both? What sort of features were most appreciated by the most valuable users in your other app? Who were the users that did not show any improvements in usage after an update? What can you do to turn the least valuable users of your other app into the most valuable for your next one?

Having a successful app is every developer’s dream when they push their app live. However, given current statistics on overall user retention in the app stores, there is a lot of room for improvement. The old saying “to measure is to know” is very applicable in this matter, but it’s only half the work. Turning what you know into actionable information is when the real magic happens. Only then you are on the right track towards systematic improvements to your app and getting that elusive success you are dreaming of.

Categories
Business Platforms Tools

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

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

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

Platform Wars in the App Economy

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

DE2014Q3_Mindshare

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

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

DE2014Q3_NativeMyths

App Revenues

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

DE2014Q3_iOS_vs_Android_Revenues

State of the Game Developer Nation

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

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

DE2014Q3_Game_Dev_Tools

Tools of the App Developer Trade

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

DE2014Q3_Tool_Popularity

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

Enterprise Apps – The Next Gold Rush

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

DE2014Q3_Enterprise_vs_Consumer

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

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

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

 

Categories
Tools

How to choose a good mobile ad network

You probably have already tried a handful of mobile ad networks, spending the good part of a day every time to integrate them and have experienced so far both feelings of disappointment and satisfaction. If it helps, you are not the only one.

shutterstock_113952028

The road to building a successful app business is not an easy one and you have to constantly experiment with new ad networks and technologies to find the one that best matches your app’s unique needs.

It doesn’t have to be a painful experience though and here are 5 different angles to look at a mobile ad network before you decide to invest your time and give it a try.

Angle #1 – Fill Rate

MobileGoogleAnalytics

A quick look at your mobile analytics provider will show the countries or regions the majority of your users are coming from.

Geography: If most of your users are coming from North America, for example, you should actively search for mobile ad networks that have a high fill rate in this region otherwise you will not be making money at your full potential.

Consistency: This is slightly tricky to evaluate beforehand, but aim for a monetization partner that in the last 3 months had consistently high fill rates in the regions you are most interested.

Many in-app advertising solutions have developed mediation technologies and partnerships with ad exchanges to combat these issues and while touting near 100% global fill rate, make sure you evaluate on hard numbers and not just marketing talk.

Angle #2 – eCPM

Choosing a mobile ad network based only on its average eCPM has a caveat because eCPM measures performance on a relative basis. Only when combined with the fill rate and your estimated monthly ad requests you can get a good sense of your expected earnings in absolute terms.

Have in mind that there are many factors that will cause significant fluctuations on eCPM, including the seasonality of advertising campaigns and the quality of traffic you send from your apps. You should anticipate fluctuations, especially if you are working with a single mobile ad network, and use the network’s average eCPM to get an “order-of-magnitude” feeling on what to expect.

Angle #3 – User Experience

AvocarrotScreenshot

People who download a free app are well-aware that it has to be funded somehow and they expect that the app might include a form of advertising.

App developers, however, have a choice whether they want to deliver a spammy user experience or interrupt the normal user flow to display ads and by choosing to do so they consciously take the risk that user retention can fall dramatically.

If quality user experience is important to your app, some mobile ad networks are more flexible than others and have started embracing native advertising technologies to offer developers more control on how and where ads get displayed.

Angle #4 – Technology

You can also evaluate a mobile ad network based on its technology.

SDK: A lightweight SDK that has been battle-tested enough will ensure your app’s performance will not be impaired at any time.

Dashboard: A fully-featured dashboard can enable thorough monitoring and effortless fine tuning which helps in both maximizing your revenues and increasing transparency.

Ad Server: This component is the most difficult to evaluate but among others, low-latency infrastructure and yield optimization algorithms are the backbone for a good eCPM, so you can use that as a proxy.

Angle #5 – Payment Options

We’ve covered previously the different payment options offered by major mobile ad networks and is important to be familiar with them well in advance in order to avoid unpleasant surprises.

Payment methods: Mobile ad networks often support a limited number of payment methods and you have to make sure your individual circumstances can be covered before you start integration.

Payment schedule: This is usually not a deal breaker, but some networks offer a faster payment schedule than others.

Sum Up

Experimenting with various solutions to find the ones that best match your needs is critical for a successful app monetization strategy but due to the sheer volume of mobile ad networks out there it can get quickly overwhelming.

Avocarrot have explored here 5 different dimensions that can hopefully help you get a well-rounded picture of any mobile ad network you come across and quickly decide whether or not you will invest some of your time to give it a try.

Categories
Tools

Finding the Right BaaS

Mobile apps — just like any other — need a place to store data. Fortunately, the industry’s push towards outsourced infrastructure (i.e., — “cloud” services) has had a profound impact on both the affordability as well as the availability of cloud-based data storage, often referred to as Backend-as-a-Service (BaaS), or Mobile-Backend-as-a-Service (MBaaS).

find-the-right-baas

What is BaaS?

At its core, [tweetable]a BaaS provider typically enables you to store your data & interact with other critical services in normalized manner[/tweetable], without the headaches and cost of maintaining your own infrastructure. Cloud-based storage is just the beginning of a BaaS offering, though. Quite often, BaaS providers enable push notifications, integration with other social networks, user administration, custom business logic and more.

Which BaaS is Right For Me?

To determine which BaaS can work for you, you need to start with at least asking these two questions:

  • What platforms do I need to support? It’s common to expect to see SDKs for most major platforms — and usually an HTTP service layer fallback which nearly any client could easily utilize.
  • What features do I need?
    • Storage (should be a given)
    • Push notifications
    • Usage analytics
    • Dashboard/UI
    • Social integration
    • User Administration
    • Custom Code Integration

The second question above really breaks down into all kinds of sub-questions, and by no means covers all the possible features you can find in a BaaS. [tweetable]It’s important to understand the needs of your app before selecting a BaaS offering[/tweetable]. So – what feature-specific questions may be helpful to ask as you analyze your needs?

Feature Analysis

Storage

While every BaaS provider will offer some kind of storage, there are wide variety of differentiating factors. Is the storage schema-less? What’s the search API like? Can you establish relationships between stored items? Can you query geospatial data (without 3rd party intervention)? Are changes pushed to connected clients, or do they need to re-query for updates? Does the BaaS support “data connectors” — allowing you to sync the cloud-based data to another system behind your own firewall? Where are the servers physically located (this can be a critical question to ask both for availability and regulatory reasons)? How difficult is it to export your data en masse should you decide to leave the provider for another option? What kinds of data can be stored — does it include files/binary data storage?

Push Notifications

If you’ve used a mobile app, odds are you are familiar with push notifications. Whether it’s a news app pushing breaking headlines, Twitter alerting you of direct messages or any number of possibilities — push notifications allow you to get important information to your users without the costs of other channels (SMS, for example) and without requiring your app to be in the foreground at the time. As most push notifications arise due to a change in data, it’s logical that many BaaS providers are including this as an offering. Good questions to ask: What platforms are supported (iOS, Android, etc.)? Will I get a consistent/normalized API to work with, rather than having to work with each platform-specific push notification API? Will I get the advantage of automatic scaling during periods of high demand?

Usage Analytics

Does the service enable you to track the number of API calls, storage quota or other feature usage? Since many BaaS pricing plans can vary based on usage, having a means to view analytics is a vital part of wisely (& economically) using the service. Depending on what metrics are tracked, usage analytics may also give you insight into how your app is being used. Does the service support custom “events” which you can provide to track either feature usage, performance data and/or campaign response(s)? Does the provider give you the ability to query the usage over time, filter the data and export reports?

Dashboard/UI

Does the provider give you an option to browse/search your data through some sort of portal or dashboard interface? Can you manage users or use a form to generate push notifications? Most BaaS providers have a web-based interface which you can use to manage your data, services and view reports.

User Administration & Social Integration

Many BaaS options provide built-in user management features. Does the service allow you to create users? Does it focus on role-based user permissions, or allow granular claims-based permissions? At what level can you restrict information — schemas/tables, records, fields? Your target users may not care to create yet another login in order to use your app. Does the BaaS provide integration with 3rd party authentication with sites like Facebook, Twitter, Google and others?

Custom Code Integration

It’s difficult to generalize to a common use-case, and still enable enough flexibility to users without giving them a means to inject custom logic for certain operations. Whether it’s validation, injecting a custom step, priming a cache or other needs, a good question to ask is your provider allows you the necessary hooks to inject your own code. Not only that — but what language(s) are supported?

Options?

Of course, knowing which BaaS options exist is important as well! Below I’ll share a few observations of the BaaS’s that I’ve had experience with to some degree, but this is by no means an exhaustive list. Check out a larger list of the tools we’re tracking in this space.

Parse

Parse was well known before it was acquired by Facebook in April of 2013, even more so after. It supports storing photos and geolocation data, 3rd party/social integration, push notifications and realtime usage analytics. The analytics are particularly impressive, in that they allow you to track custom events & types of devices, highly customized reports and more. Parse has an impressive array of client SDKs. Officially, Parse provides SDKs for iOS, Android, Windows, Windows Phone 8, Mac OS X, JavaScript and Unity (the cross-platform game engine). You also have the option of utilizing the HTTP REST API. Third party developers have created client libraries for .NET, ActionScript, Clojure, Java, Qt, Ruby, PHP, Python, WebOS and more!


Firebase

Firebase is a recent — and interesting — option in this space, focusing on a specific kind of use-case as opposed to larger, more general offerings like StackMob: realtime data synchronization. Multiple clients accessing the same data can see realtime updates (if you’re wondering about latency, it’s impressively low. To users, it will be instantaneous). Firebase also has a very flexible security model — including the ability for you to incorporate your own auth tokens or those from third party services. SDKs are available for JavaScript (both web clients and node.js), Objective-C (iOS) and Java (Android) and an HTTP REST API also exists. Realtime BaaS’s have interesting challenges in the areas of how they handle transactions and conflict resolution. Firebase is one of the first I’ve seen that provides the necessary hooks you need to inject conflict resolution logic without also dictating the client-side UI framework stack. In fact, Firebase provides officially supported integrations with AngularJS, Backbone.js and EmberJS (all client-side JavaScript frameworks). A number of third party libraries exist as well, extending Firebase client support to Python, PHP, Ruby, Clojure and Perl.


Telerik Backend Services

Telerik Backend Services (formerly known as “Everlive”) is another recent and feature-filled option. The backend storage is an object store, but you can create relationships between objects, upload files, store geospatial data (and query it comparatively to other locations for distance) and more. You can inject custom code — written in JavaScript – to be executed before or after items are created, read, updated or deleted. The user management features allow you to create users, assign roles, constrain permissions to resources and data, integrate with third parties like Facebook, Microsoft (LiveID) and Google or even your own corporate Active Directory. Telerik Backend Services support push notifications for iOS and Android, as well as email and SMS notifications. It’s worth noting that the management dashboard provides very easy-to-use tools to define schemas, manage users, create/edit data and test push notifications from within your browser. You also get usage analytics for database size, file storage, bandwidth used, push notifications and emails sent and HTTP requests.


StackMob

StackMob is one of the more well known names in this space – though their recent acquisition by Paypal will result in their services shutting down in May 2014. They directly support SDKs that cover iOS, Android, JavaScript & Java, and they expose an HTTP REST API for other clients as well. StackMob also benefits from an active community which has written 3rd party tools focusing on OAuth integration with other languages & platforms like PHP, ActionScript, Python and Sencha as well as an Appcelerator Titanium SDK.

StackMob has an impressive feature list. Their storage engine uses schemas which can be auto-generated for you based on your data, or you can use a dashboard they provide to define them. They support file storage if you have an Amazon S3 account (their services wrap the calls to Amazon). StackMob supports OAuth 2.0, as well as integration with Twitter and Facebook, and provides adequate user administration/permissions features (depending on your needs, you may need to elaborate if you need as granular as field-level permissions). You can upload custom Java, Scala and/or Clojure code and expose it via HTTP endpoints while having access to their data APIs from within your code. Another interesting feature is StackMob’s HTML hosting, which cannot only host your app, but also integrate with GitHub, enabling you to deploy your app based on what’s committed to the git repository.

So Much More Awaits

Those are only four examples — we’re tracking at least fifty BaaS offerings, and it seems more options appear nearly every month. Are you using a BaaS provider now? We’d love to hear which one(s) and what features drove your decision in the comments below.

Categories
Tools

Which App Stores Should You Use?

Publishing your app in a store can involve significant effort. Depending on your goals some app stores can be more attractive than others. If you’re looking to earn direct revenue from your apps, which are the best stores to target? What follows is some general advice backed up by data from our latest survey.

app-stores-you-should-use

To publish, or not to publish?

If you only want to build an app as a hobby, first consider whether you need to publish it on a store at all, or whether you can just share it privately with interested parties. There are more than enough apps already in the stores and the poor developers trying to make a living from their apps have to contend with a lot of noise in the very basic search results as it is. If reaching an audience is an important part of your hobby creation then building an Android app and publishing on Google Play is the obvious option. It’s low cost, there are few rules and there’s a very large user base.

Apple is where the money is

If you’re building an app to generate revenue directly then an iOS app on Apple’s App Store is still the best option initially unless you’re only targeting countries where the platform has very low market share. Even with an ad-supported revenue model, the larger user base on Android is usually more than compensated for by better engagement and higher rates on iOS. When aiming for reach then the most important thing is to match the target demographics with those of the platforms. In most cases you’ll want to target both iOS and Android.

These are the common cases and this is fairly common knowledge. As such you can see it reflected in the overall popularity of the various stores below.

If you already have an app published on one or more stores, the decision to add it to another is not always an easy one. Even if you don’t need to port your app to a new platform to access a new marketplace, you still need to learn about the publishing process, create (and usually pay for) an account, publish the app and future updates and monitor reviews and visibility within the store. If the audience using the new store won’t be reached by your existing marketing efforts you may have to expand those as well.

More stores = more money?

Looking at the average revenues of developers based on how many stores they publish on, it’s tempting to think that publishing to as many stores as possible (and thus using a cross-platform development tool) is the way to go.

However, this is getting causation backwards. There is an improvement in revenues for almost anyone adding more potential customers but looking at the median rather than mean we can see this is unlikely to cover the cost of managing the app across several extra stores. What we can really see here is successful apps tend to port to more platforms and so [tweetable]it’s apps that already have high revenues that then publish in additional stores[/tweetable]. There is also a [tweetable]higher than average proportion of developers working on a contract basis who publish to five or more stores[/tweetable], which pushes the median revenue up.

The same phenomenon causes the average revenue of all developers who publish in a particular store to be very misleading. Developers publishing in the smaller stores often already have successful versions of the apps on the leading platforms, or are simply contracted to port those apps. If we split developers by the number of stores they publish on and look at revenues by platform then the differences become clear.

Where to publish next?

Looking at developers who only publish on a single store, [tweetable]Apple’s App Store is far ahead of every other store except the Amazon Appstore[/tweetable]. However, the number of developers who only publish to Amazon’s store is extremely small (only 16 in this sample) so this figure is not reliable. That said, [tweetable]developers who publish in Amazon’s store and one other are far more numerous and have high average revenues[/tweetable], plus data from Distimo suggests that some Android developers are seeing significantly better revenues from Amazon than from Google Play.

If we consider those publishing to two stores then Apple leads with Google in a clear second place, while Amazon still shows relatively good revenues. The other interesting data here is “where do BlackBerry developers go” – those publishing to BlackBerry World are much more likely to have Google Play or the Windows Phone Store as their second store than others. Only 11% of developers publishing to BlackBerry World and one other store also publish to the Apple App Store. That’s somewhat surprising given BlackBerry’s previous dominance of the enterprise market and that iOS is now taking over in that space.

When developers publish to four or more stores we see a significant jump in revenues for those publishing to the Windows Phone Store. Since the revenues for those who only publish to that store are so low, it seems unlikely that it’s revenues from Windows Phone itself creating the difference. More likely is that Microsoft and Nokia have been providing incentives for the most successful apps to port to their platform. Microsoft’s Windows Phone platform is strongly differentiated from the others. Developers have to design a new UI and generally build it with different technology in order to target the platform. The associated costs are much higher than adding another Android or web-based platform’s store. As such, at similar scale to many alternatives, Windows Phone is unlikely to produce a good return on investment unless Microsoft provides a strong financial incentive.

Conclusion

For developers not looking for direct revenues, an Android app on Google Play is probably the obvious first choice. For those who are looking to monetize their apps directly, Apple’s iOS App Store is the clear leader, with Google Play as the first place to expand after that. BlackBerry World appears to be very unattractive versus the other options from a revenue perspective. Beyond that, the Windows Phone Store seems to be more popular than it deserves (although this might be due to ports paid for by the platform owner) whilst the Amazon Appstore seems unfairly unloved. Some developers have had issues with Amazon’s developer agreement and pricing policy but the results of those using Amazon’s store suggest it’s worth another look.

Categories
Tools

The Ins & Outs of Mobile App Testing

Over the last decade, application testing has continually proved itself to be an important concern. When done well, testing can drastically reduce the number of bugs that make it into your release code (and thus actually affect your users). In addition, good testing approaches will help your team catch bugs earlier in the development lifecycle – resulting in a savings of both time and money (not to mention reputation with your users). Code that has good test coverage enables you and your team to make changes and introduce new features to your app without the fear of it breaking existing functionality.

shutterstock_131210207

The word “Testing” is a large umbrella, and is usually better understood when you break it down to specific types of testing. For example:

  • Unit Testing – automated tests written by developers, with each test targeting a narrow slice of application behavior.
  • Functional & Acceptance Testing – typically performed by QA personnel or automated UI testing frameworks.
  • Performance Testing – often performed manually with profiling tools (for example – heap and CPU profiling tools), though many mobile app developers are moving towards integrating app analytics to gather this data from real usage as well.

That’s certainly not an exhaustive list of the types of testing, but enough to make an important point: [tweetable]mobile applications face several challenges when it comes to testing[/tweetable]. Key among those challenges are:

  • Platform & Device Diversity
  • Immature Tooling
  • Lack of Awareness

If you opt to write native applications for each target platform, then any code-level testing (i.e. – Unit Tests) will not be transportable as you move from Objective-C (iOS) to Java (Android). In addition, any scripted UI-Automation testing tools may not work for multiple platforms (or at the very least require separate scripts for each platform). Hybrid solutions like PhoneGap, or cross-compiled solutions like Xamarin can offer a single approach to unit testing (given a single codebase for multiple platforms) – but do not always offer the same level of quality as native tooling when it comes to performance profiling. Despite the trade offs involved, I’ve found in my own experience that [tweetable]the biggest barrier to entry in mobile app testing is often a lack of awareness of what tools are available[/tweetable]. That is the barrier which I hope to address in this post.

Unit Testing

Unit testing for specific platforms or cross-platform tools is not difficult, and your options abound. Let’s look at a sample of some of these choices.

iOS

iOS developers who’ve been writing Objective-C for a while may be familiar with OCUnit, which shipped with XCode prior to the XCTest framework. It’s still supported in XCode 5, but the understanding is that new and future projects should focus on using XCTest.

Don’t let Apple’s sparse documentation on unit testing deter you from checking out the XCTest framework. If you’re running an OS X Server, you can also take advantage of the XCode service’s continuous integration features. As part of a continuous integration workflow, you can create “bots”, which can continually build and test your app.

Many developers prefer a Behavior-Driven-Development (BDD) style syntax for unit testing. If this describes you, be sure to check out Kiwi – a BDD style unit testing framework for iOS.

One other important mention is OCMock a mocking framework for iOS. Mocks are an indispensable part of writing adequate tests around your application’s behavior.

Android

JUnit is perhaps by far the most well known (and officially recommended by Google) testing framework for Android. The JUnit Android extensions allow you to mock Android components, but I’ve also seen quite a number of Android developers use JUnit with Mockito, another Android mocking framework.

Robolectric takes a different – and very interesting – approach by allowing you to run your Android unit tests in the normal JVM (Java Virtual Machine), without the need for an emulator. This enables your tests to not only run from within your IDE, but also as part of a continuous integration workflow.

Qt

Qt made the top 5 most used CPTs in 2013. If you’re building mobile applications with Qt, you’ll be happy to know about QTestLib, a unit testing framework built by Nokia. Based on my research, it appears that QTestLib can be integrated with a 3rd party continuous integration workflow – enabling very helpful testing automation.

PhoneGap/Apache Cordova

Web-based hybrid approaches to mobile apps can take advantage of a host of testing and mocking frameworks, not to mention scripted UI/acceptance testing tools as well (more on that in a moment). When it comes to unit testing JavaScript, three of the biggest names are QUnit, Mocha and Jasmine. I’ve personally used all three, with my favorite setup including Mocha and expect.js (which provides a BDD style test syntax). Mocking and “spy” frameworks abound in JavaScript as well, with Sinon.js and JsMockito among the more popular stand-alone mocking options.

Many PhoneGap developers take advantage of tools like PhantomJS – which is a “headless” (no UI) WebKit browser, with a JavaScript API. PhantomJS can be easily integrated into a continuous integration workflow to automatically run unit tests against your hybrid mobile application’s codebase.

Xamarin

Xamarin uses a customized version of NUnit (ported from JUnit), called NUnitLite which enables you to write unit tests against your Xamarin iOS & Android projects. For any shared codebase, you can use the unit testing framework of your choice.

Scripted UI Testing

Not every team can afford to hire an army of manual QA testers, despite how valuable that can be. Automated tooling can bridge the gap.

If you’re writing native iOS and Android apps, you’re in luck. Apple provides an “Automation instrument” that will automate UI tests against your iOS mobile application. The Android SDK provides the “uiautomator” library, described as “A Java library containing APIs to create customized functional UI tests, and an execution engine to automate and run the tests.” In addition to these, you can use third party tools like Squish, Ranorex and Perfecto Mobile’s MobileCloud Automation to automate UI tests against Android and iOS apps, web apps and more. It’s worth mentioning that Perfecto Mobile’s MobileCloud Automation exposes an API to better facilitate integration with existing build/continuous integration tools. Perfecto Mobile also offers MobileCloud Interactive, which enables you to “perform remote manual testing on real smartphones and tablets regardless of where you are” – who wouldn’t want to have a “testing army” of real mobile device users at their disposal?

Among the more interesting developments in mobile UI automated testing is the emergence of an open source project named Appium. Appium uses the WebDriver JsonWireProtocol to interact with iOS, Android and Firefox OS apps and gives you the choice of writing your UI tests in any WebDriver-compatible language (Java, Objective-C, JavaScript, PHP, Python, Ruby, C#, Clojure, Perl and others).

Performance & Profiling

Apple’s Instruments is one of the more impressive native toolsets I’ve seen recently. With Instruments, it’s possible to profile how your app executes, run stress tests, record and replay user actions, create custom instruments and a lot more. If you’re writing native iOS apps & not using Instruments, I recommend reading through the Quick Start to get up to speed.

With Android apps, you have several (albeit, lower-level) tools available: Systrace & Traceview. You can also use the Device Monitor to view memory usage based on logcat messages.

For hybrid mobile apps, you have a host of mature desktop browser tools (Chrome Developer Tools, Firefox/Firebug, etc.), which you can bring to bear on your app to profile CPU usage, memory, DOM manipulation and much more.

Many mobile developers have started taking advantage of third party analytics services such as Google Mobile Analytics, Countly, EQATEC, Flurry, Perfecto Mobile’s MobileCloud Monitoring and many others. The focus of these kind of analytics is usually more about how your app is actually used, user engagement, demographics, feature popularity, etc. However, it provides an opportunity to measure certain pieces of application performance from within real-world usage. While I wouldn’t recommend this being your first line-of-defense in performance testing, having the ability to track real world performance metrics can be a powerful tool in tuning your application to your users’ needs.

We’ve only scratched the surface of the various testing options available for mobile app development. What testing approaches & tools are you using when writing mobile apps? If you’re not currently testing your application, what are some factors that would change your mind?

– Jim (ifandelse)

Categories
Tools

A Look at Some of the Top Mobile UI Frameworks

Deciding on a cross-platform tool (CPT) when developing mobile applications is really only the first step of a larger journey. When you choose a web-based CPT (PhoneGap, for example), you’re typically faced with the decision of what UI framework to choose as well.

Blog007-Final

The good news is that there are number of powerful options available. We’ll take a brief look at a few of these in this post. There’s a wide range of what’s available in a UI framework – some focus entirely on widgets (UI components), others provide light app framework functionality and still others provide a more comprehensive set of behaviors covering widgets and application framework concerns. The “right” choice for your project will depend largely on what you need, your team’s background and what kind of control you want to retain over certain aspects of the application architecture.

There are SO many interesting options, it can feel overwhelming even if you’re a veteran of HTML5-based mobile development. Limiting this post to only 4 frameworks was difficult. I will include a list of additional frameworks at the end in case you’d like to explore beyond the few we cover. If you’re looking for a full list of UI frameworks, check out the relevant section on ToolFinder – our online app for helping developers find the right tool!

jQuery Mobile

jquery-mobile

jQuery Mobile is arguably the most widely used mobile framework – benefiting from association with the nearly ubiquitous jQuery project. Due to its recognition and association with jQuery-based open source development, jQuery Mobile boasts a huge number of 3rd party plugins, extensions, tools, themes and more.

High Level Overview

Developers writing mobile and hybrid mobile apps using jQuery Mobile will encounter the following:

  • Heavy use of HTML “data-*” attributes. For example, a “page” in a jQuery Mobile application is simply a DOM element with a “data-role” attribute value like this: <div data-role="page"></div> Experienced web developers will pick up these kinds of framework conventions quickly.
  • jQuery Mobile provides a light application framework – primarily covering navigation, & transitions between views. This can be extended via plugins, or through integration with more comprehensive frameworks. If your “app framework” needs extend beyond transitions and navigations (for example, templating, two-way binding and more), jQuery Mobile alone may not be a good fit.
  • It’s designed to work within a Responsive Web Design (RWD) context – enabling developers to target a wide range of devices.
  • A wide array of device and browser support as well as a helpful theme roller to help with quickly customizing the otherwise “clone” look and feel.

Despite its popularity, jQuery Mobile has been criticized for performing poorly in mobile browsers. The jQuery Mobile team continues to work to improve the framework, including performance issues. If your team opts for jQuery Mobile, avoiding deeply nested DOM structures & unnecessary reflows and investigating the use of libraries like FastClick can help you avoid some of the typical pitfalls that have earned jQuery Mobile the “slow” label.

Widgets

jQuery Mobile’s site currently lists 22 built-in widgets (though the number of custom/3rd party widgets is much higher). Among them are header, footer, navbar, listview, slider popup and more (all the basics you would expect). Creating customized widgets is likely a moderate amount of effort for most developers. jQuery Mobile’s good documentation and examples will be helpful for any team. You can view a list of demos here.

The screen capture below demonstrates one of jQuery Mobile’s widgets: the responsive grid listview:

Licensing

jQuery mobile is free and open source (MIT licensed).

Kendo UI Mobile

Blog007-Final
Telerik’s Kendo UI Mobile framework has emerged as a powerful and performance-minded framework for mobile web and hybrid mobile applications. Kendo UI Mobile provides both UI widgets and app framework functionality. Kendo UI Mobile is part of a larger Kendo UI framework that can target both desktop and mobile devices. In addition, Kendo UI Dataviz is arguably one of the best data visualization libraries available for both desktop and mobile web clients*.

High Level Overview

Developers writing mobile and hybrid mobile apps will encounter the following:

  • Theming that matches the ‘native’ look and feel of iOS, Android, Blackberry and Windows Phone 8, as well as a “flat” theme that looks nice across multiple devices.
  • Similar to jQuery Mobile, Kendo UI Mobile makes use of HTML5 “data-*” attributes. For example, a “view” in a Kendo UI Mobile application is a DOM element with an attribute/value of ‘data-role=”view”‘. This naturally extends to Kendo UI Mobile’s widgets as well, since (for example) an unordered list element can be made into a “listview” element simply by adding ‘data-role=”listview”‘ to the element.
  • Two-way binding, with a declarative syntax. Kendo UI Mobile provides some fairly sophisticated application framework features, with MVVM (model-view-viewmodel) infrastructure included. Application state is typically maintained in ‘view models’, which are bound to views (DOM templates). As data in views change, the view models are automatically updated (and vice versa). By “declarative” we mean that the metadata necessary to enable two-way binding can be provided in the actual markup. For example, to bind the text content of a span to the “firstName” value of a view model, developers simply include this in the markup: <span data-bind="text: firstName"></span> Frameworks supporting two-way binding often help eliminate the same tired boilerplate code necessary in traversing DOM structures to retrieve state (user input, etc.). This can be a big productivity boost for your team.
  • Also included in the application framework features: view transitions, navigation & layout templates (which can be highly customized) as well as “DataSources” – an abstraction over retrieving data from multiple kinds of sources (for example, simple HTTP services, local data or even some Back-end-as-a-Service offerings). The Kendo UI team has gone quite a ways further than primarily UI/widget focused frameworks like jQuery Mobile in providing more substantial application architectural help.

Widgets

Kendo UI Mobile’s site lists 13 built-in widgets, ranging from ListView, ModalView, and TabStrip to Navbar (including support for header & footer), Drawer and Scroller (and more). Kendo UI Mobile supports creating custom widgets as well.

The screen capture below demonstrates a couple of Kendo UI Mobile’s adaptive widgets: the Grid and Scheduler. You can view additional Kendo UI Mobile demos here.

Licensing

Kendo UI mobile is a paid framework which starts at $199 (includes support for 1 year).

Sencha Touch

Sencha will be a recognizable name to many web & mobile developers – likely due to their response to Mark Zuckerberg’s assertion that “HTML5 Wasn’t Ready”. Sencha went on to prove that HTML5 is, indeed, ready for many complex use cases in mobile applications. Sencha Touch – Sencha’s mobile focused HTML5 development platform – goes much further than providing only widget-focused features.

High Level Overview

Sencha recently updated Sencha Touch so that their device APIs fully support Apache Cordova (i.e. – PhoneGap). Similar to Kendo UI Mobile, Sencha Touch makes use of HTML5 and CSS3 (taking advantage of hardware acceleration where possible) to create web-based UIs for mobile apps that aim to rival native UI performance. Developers building projects with Sencha Touch can expect the following:

  • Sencha Touch leans more heavily towards “full app framework” than many other popular options. It provides an MVC style architecture, complete with storage, device profile and top-level application abstractions.
  • Sencha Touch ships with 50 built-in components (and developers can create their own as well).
  • It’s my understanding that Touch shares some common code with ExtJS (and common conceptual paradigms), so developers familiar with ExtJS will pick things up quickly. I would also argue that developers used to frameworks like Backbone.js will also pick up the concepts more readily than developers used to UI frameworks that focus on declarative bindings in markup.
  • Sencha Touch provides its own abstractions for things like history management and XHR – which is in line with expectations of any framework seeking to be a more “one stop/full-stack” option.

Widgets

Components are a key part of Sencha Touch’s architecture. Among the 50 built-in components are ones such as Carousel, Slider, DataView, List, DatePicker and more. In other words – like the frameworks we’ve looked at so far, the essential things you’d expect plus a bit more. The screen capture below is showing some of the animation demos in the “Kitchen Sink” demo application, which highlights many features available in Touch:

Licensing

Sencha Touch has a wide array of licensing options (which can be seen here). It’s free for commercial use (and a GPLv3 option is also available). Sencha offers paid support options for Sencha Touch, starting at $1395 for a 5-developer package.

Chocolate Chip UI

Chocolate Chip UI’s beta debuted on Github roughly 3 years ago. Currently at version 3.0.6, the project has been gaining recognition as a powerful and performance-minded option for both mobile web and hybrid mobile applications targeting iOS, Android and Windows Phone 8. Chocolate Chip UI’s site lists 12 widgets, but simply skimming the documentation will reveal many more. Chocolate Chip UI provides a substantial amount of UI/widget focused features, but also ventures somewhat into “application framework” territory by providing a number of utility methods & view transition features – though it stops short of client-side routing (though there’s nothing preventing you from integrating any number of routing libraries).

High Level Overview

Developers using Chocolate Chip UI will encounter the following:

  • Chocolate Chip UI makes use of semantic HTML5 elements to drive its widgets. Your team may find overtime that this aids markup readability.
  • Chocolate Chip UI encourages the use of their own JavaScript library (ChocolateChip.js) in lieu of jQuery. They maintain that it was created specifically for mobile use and that it is both faster and smaller. It is possible to use jQuery 2.0.3 on Chocolate Chip UI version 3.0.3 and newer. This may prove useful if your team has jQuery plugins which are essential to the project.
  • Chocolate Chip UI provides API hooks to create your own widgets which follow the same paradigm as creating jQuery plugins. This will aid your team’s transition from jQuery to ChocolateChip.js.
  • Chocolate Chip UI uses OS-specific theming, allowing you to target a specific mobile platform (currently iOS, Android and Windows Phone 8) simply by sourcing the appropriate CSS file.
  • Chocolate Chip UI provides layout behaviors to help organize your DOM structure, as well as a number of utility methods including script loading, type testing, string utilities, AJAX communications and more.

Widgets

As mentioned above, Chocolate Chip UI’s home page lists 12 widgets – among them things like Popup, Paging, Range, Switch and multiple types of Lists. However, as you review the documentation, you’ll notice mention of additional widgets such as slide out menus, masks (semi-transparent overlays), split layouts (for tablets) and more. You can see a few of these in the screen capture below (specifically, range/slider and pop-over):

Licensing

Chocolate Chip UI can be licensed either under BSD or commercially. For commercial terms, you need to contact Sourcebits to get a quote. I reached out to Sourcebits to get more information on commercial licensing, and they were very prompt & friendly in replying:

“…our terms for commercial use are an acknowledgment that Sourcebits’ Chocolate Chip UI was used in the creation of the app, something along the lines of “Powered by Chocolate Chip UI”, either in the app’s splash screen or ‘About’ page with tap/link back to ChUI’s awesome landing page, as well as permission to use the brand’s name/logo on our website. In addition we might also wish to collaborate with the brand to create a case study around their use of ChUI. We’d have the same asks if a ChUI web app were being deployed for internal use by an enterprise, too.”

Further Resources

Markus Falk has a fantastic mobile frameworks comparison tool which you may find quite useful in evaluating which options will work for your team. One thing to bear in mind: this comparison chart doesn’t differentiate between UI frameworks and cross-platform tools (like PhoneGap), so it’s useful if you’re looking up supported features for a given framework or comparing two frameworks of the same type (i.e. – apples-to-apples comparison of two or more UI libraries, or CPTs, etc).

Also – check out our own full listing of UI frameworks, on our ToolFinder web app,

This post can’t possibly cover all the UI framework options available – and choosing which ones to write about was extremely difficult, given the amazing number of good choices out there. I’d like to list a few more here to give you the option of further exploring which UI framework(s) may work best for you. Bear in mind that these are web-based UI frameworks for mobile web or hybrid mobile solutions that make use of web-based assets (like PhoneGap):

Have you used any of these options? If so, we’d love to hear about your experience. Feel like one is missing? Let us know! We’d love to hear what you’ve been using.

* I’ve used Raphael and D3.js – and love both (not to mention, both are free frameworks). I think very highly of Kendo UI Dataviz primarily because of the wide browser support (it uses canvas, SVG and VML, depending on the browser) and because of the accessible/intuitive API.

Categories
Tools

HTML5 performance is fine, what we are missing is tools

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools?

HTML5-cover

In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).

html5_stoppers

We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.

Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.

Experts point to a tools gap

As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).

It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.

Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”.

Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?

HTML5 is like a car without a dashboard

[tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.

With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.

Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.

Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.

Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.

Better tools are needed

HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.

With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.

Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.

What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.

Categories
Tools

Pros and Cons of the Top 5 Cross-Platform Tools

As the market temperature for cross-platform tools (CPTs) continues its steep climb into hotter territory, it’s understandable why many feel we are witnessing a mobile fragmentation that is perhaps much larger and more significant than the recent wars waged over the desktop. If this fragmentation tells us anything, it’s that [tweetable]cross-platform tools for mobile development are often not a “one-size-fits-all” solution[/tweetable] – and that there are numerous veteran users of these tools that do not believe the problem has been solved as well as it could be….yet. In our Developer Economics Q1 2013 report, the breakdown of the top CPTs looks like this:

18-01

How many of these tools do you know? Test your skills in the new Developer Economics Survey and win awesome prizes.

As you’d expect, each approach comes with trade-offs. Let’s examine the top five cross-platform tools (PhoneGap, Appcelerator, Adobe AIR, Sencha, Qt), as identified in our research, and list out the more salient pros and cons of each. This is not an exhaustive list, of course, as each platform can’t be explored in depth in one post alone. Want toexplore more cross-platform tools we’ve identified? Check out the CPT section on our ToolFinder tool atlas

Apache Cordova/PhoneGap

Apache Cordova (known by many as “PhoneGap“) holds the top slot in developer mindshare. Cordova/PhoneGap developers write their mobile applications using HTML, JavaScript and CSS. These assets run in a “WebView” inside a native application container on the target platform. It is, conceptually, a web application packaged within a native application container where your JavaScript has access to device-level APIs that normal web applications would not (more on that below).

The name “PhoneGap” is quite possibly one of the more recognizable names in this space. Originally created by Nitobi, the name was changed to “Apache Cordova” when it was donated to the Apache Software Foundation. Adobe purchased Nitobi – including rights to the PhoneGap name – and now distributes Cordova under that name.

Pros

  • Regardless of server side platform & language experience, a significant number of developers have experience with HTML, JavaScript and CSS. Apache Cordova allows developers to immediately leverage these existing skills. The value of this can’t be overstated – as it reduces training and can enable a quick-to-market stance in companies ready to adopt it.
  • Cordova apps install just like a native application, and are able to leverage app store discoverability.
  • Cordova follows a plugin architecture, which means that access to native device APIs can be extended in a modular way. There are a lot Cordova/PhoneGap plugins to choose from – enabling developers to focus on the web-based skills they already have. (This is a weakness as well, as we’ll see in a moment.)
  • Cordova is open source and free, so there are no licensing costs (also a potential weakness, mentioned below).
  • Cordova/PhoneGap solutions existed in this space early on, and have matured to the point where value-add offerings on top of the basic CPT are the norm. For example, both Adobe’s PhoneGap Build and Telerik’s Icenium enable developers to build for supported target platforms in the cloud, without local SDKs (meaning non-Mac users can build iOS applications). In addition to Icenium’s cloud build services, Telerik also provides Kendo UI Mobile (an MVVM framework targeted for performance on mobile), app analytics via EQATEC and a Backend-as-a-Service (BaaS) offering named Everlive. Adobe has integrated PhoneGap Build capabilities into Brackets (a web based IDE) and Dreamweaver.

Cons

  • Of course, being free is no guarantee of success. In fact, the emergence of PhoneGap Build and Icenium are clear demonstrations that a “bare bones” Apache Cordova is woefully incomplete. The strength of being open source – and leveraging the talents of a wide array of contributors – is both a blessing and curse. If you need to extend your app with a custom Cordova/PhoneGap plugin, odds are you will find one. Yet it may be out of date and not support the target platforms you need.
  • The plugin architecture works well if you can find the plugins you need or if your web developers are capable of changing gears to write their own custom plugin(s) as needed. However, odds are that you chose Cordova, in part, to avoid the need for specialized native platform skills.
  • The performance of Cordova/PhoneGap apps has often been criticized. Native UI will always outperform a hybrid solution, but improvements in device hardware and WebView implementations have narrowed the gap. Your web developers will need to pay close attention to performance, which means their knowledge of profiling tools as well as which web UI frameworks are mobile-friendly is essential.

Appcelerator

Appcelerator’s Titanium provides a unified (across devices) JavaScript API, coupled with native-platform-specific features. Developers write JavaScript and utilize a UI abstraction (the Alloy MVC framework) that results in the use of native UI components, greatly aiding UI performance compared to other hybrid options.

Pros

  • The use of native UI components is a performance win, and the Alloy framework attempts to normalize UI across platforms.
  • The use of JavaScript to normalize code across platforms enables you to leverage existing skills on multiple target platforms.
  • Appcelerator provides value-adds such as a Backend-as-a-Service (BaaS), app analytics and a marketplace for 3rd party components.

Cons

  • Developers are required to manage target platform SDKs locally. It’s highly recommended for your team to establish a controlled build environment/CI process if you choose to manage SDKs locally, especially if you target multiple platforms. SDK version & build-related issues can be a horrific time sink, when you really need your team delivering features.
  • Normalizing the UI across platforms, while arguably a “pro”, is also a “con” in that your team will need to train on a proprietary technology to gain skills that are not directly transferrable outside Titanium.

Adobe AIR

Adobe AIR is “a cross-operating-system runtime that lets developers combine HTML, JavaScript, Adobe Flash® and Flex technologies, and ActionScript® to deploy rich Internet applications (RIAs) on a broad range of devices including desktop computers, netbooks, tablets, smartphones, and TVs.” The problem with that description is that you cannot use HTML & JavaScript to write Adobe AIR applications for mobile applications (Flash/ActionScript skills need only apply).

Pros

  • Adobe AIR has impressive reach – running on a wide array of desktop and mobile devices. In addition, if you plan to have a more involved/animated UI (and don’t plan to use a native approach), using AIR over a HTML/JavaScript/CSS approach may help.
  • Most Flash/ActionScript developers consider the IDE tooling for these technologies as mature.

Cons

  • The “elephant in the room” for many mobile developers is the fact that Adobe purchased Nitobi (and the rights to the PhoneGap name), clearly signaling to many that AIR may not be a long term strategy for mobile development. This combined with the rapid decline of Flash erodes the confidence many developers might otherwise have in choosing AIR.

Sencha

Sencha Touch is an HTML5 mobile application framework for building web applications that look and feel like native applications. Apps built with Sencha Touch can be used with Apache Cordova/PhoneGap or Sencha’s native packager – either which will package the application in a native container and enable access to select device-level APIs unavailable to traditional web apps.

Pros

  • Sencha have produced a larger quite of interoperable products, from “Sencha Architect” (a visual HTML5 app builder) and “Sencha Touch Charts” (for data visualization) to IDE integration with the Sencha Eclipse Plugin and an secure Enterprise app deployment story with Sencha Space.
  • Sencha Touch offers an MVC style architecture, a library of UI components, an extensible API and UI themes among other features.
  • Native packaging is possible via Apache Cordova/PhoneGap or Sencha’s SDK.

Cons

  • Mobile apps written with Sencha Touch can suffer from the same performance pains as Cordova/PhoneGap apps if developers aren’t disciplined in writing efficient JavaScript and DOM structure(s).
  • Many developers already have established opinions and experience with preferred frameworks for building HTML5/JavaScript/CSS based apps. Sencha’s emphasis on its own stack will be perceived as vendor lock-in.
  • Extending a Sencha Touch app with access to additional native APIs will likely involve writing custom Apache Cordova/PhoneGap plugins. This will require specialized platform skills (or training to acquire them).

Qt

Qt (“Cute”) is a cross-platform development tool that targets a number of embedded, desktop and mobile platforms. Developers write using “QML“, touted as a “CSS & JavaScript like language”, and apps are backed with an extensive set of C++ libraries, and utilize graphics/UI components written in C++. [UPDATE: As clarified by @qtproject, “Qt exists as a free and open source version from @qtproject and a commercial offering on top, from @QtbyDigia“]

Pros

  • Qt provides a substantial set of libraries containing intuitive APIs for things like threading, networking, animations and more.
  • Qt’s IDE tooling (Qt Creator IDE & Qt Designer) appear to be solid development tools, and code profiling is available in QML Profiler.
  • Qt Linguist enables translation and internationalization in applications – giving you the support of multiple languages within your app (in a single binary).

Cons [updated thanks to new information from Digia]

  • Qt’s tools are advertised as a “complete tool chain”, and QML is a proprietary language specific to Qt’s stack. Committing to this approach could be seen by many companies as ‘platform lock-in’, given that most businesses are seeking to re-use existing skill sets when adopting a CPT, not fragment skills further. (The leap from JavaScript to QML may not be as far as a leap from web-based skills to Objective-C, for example – each team just needs to evaluate what it can handle).
  • [Updated] Originally we listed pricing as a “con”, since full commercial support could exceed €4,000 (this includes plug-in development, platform development, device modification as well as unlimited support and updates). The cost of this kind of support is significantly higher than support costs for the other CPTs we’ve looked at. However, Digia reached out with a link to the recently announced Qt Mobile Edition. According to Digia the monthly fee will be $149 (approximately €110) and will launch in the coming weeks after the release of Qt 5.2.  This pricing level puts Qt’s mobile development costs more in line with the alternatives we’ve discussed. (It’s also important to note that Qt supports an open source LGPL v2.1 license.)

Reality: You’ll Probably Use More Than One

In our Developer Economics 2013 report, we noted the following:

Developers most often use several cross-platform tools; on average CPT developers will use 1.91 CPTs, confirming the lack of maturity and niche nature of cross platform tools much like we observed in our dedicated CPT survey just over a year ago. Moreover, we found that one in four developers will use more than three cross platform tools.

What CPT(s) do you plan to investigate or adopt? Check out the full list of CPTs we’ve identified.

 

Which of these are your favourites?  Test your skills in the new Developer Economics Survey and win awesome prizes.