Everyone who develops an app for consumer use has to face the question of price. Should your app be free to use? If not, what should you charge for it? These are difficult questions to answer, especially if you’ve spent countless sleepless hours thinking through every last feature of your app to make it the best it can be. Pricing your app is a bit more complex than classifying it as “free” or “paid.” There are four different payment models you could consider, based on a number of factors. Before you decide on an app price, take a look at all four models, the benefits of each, and then decide how you can choose the right model for your app. Meet the App Pricing Models Free The majority of apps in the Apple and Google Play store fall into this category. It’s interesting to note the contrast between the two stores. In the Apple Store, 61% of apps are free, compared to 92% of apps available for Android. This is due to Android’s open source software and the fact that it attracts more DIY, small-scale app developers. In this pricing model, your app will be free of charge to download and use. If you are looking to generate revenue from your app, your revenue stream would come through advertising and directing users towards a larger platform where people can opt into other charges. Free app developers understand their best shot to make money is not with an upfront download charge. Don’t underestimate the revenue that in-app advertising can bring — more than 80% of Facebook’s ad revenue now comes from mobile advertising. Free apps have the major advantage of being searched first in app stores. Freemium Freemium apps are free to download, but place in-app restrictions on what a person can do or access with the free version. This model acts as a teaser, giving people access to the basic functions of an app in order to hook them into paying for additional features. This includes encouraging users to buy new filters for their photos, extra lives or tools for their games, exclusive recipe content for cooking apps, or items for their virtual farm. Anything that requires the spending of real money to advance functionality in your app space. Remember, in order to get your users interested in the premium version of your app or the paid features, your free version must offer some engaging value at the basic level. This pricing model is ideal if you want to reap the organic traffic brought in by free apps, but think you have enough features worth monetizing. For some categories of apps, such as games, you may need to plan for regular updates and additions to your available in-app purchases in order to keep users engaged long term. Paid: One-Time Purchase In this model, users pay a one-time fee to download your app. Setting a price for your app will depend on a number of factors, including the demographics and interests of your target market, and competitor price points. Interestingly enough, $0.99 is not the most popular price. In the Apple Store, 12% of apps are listed at $2.99, and 8% at $4.99. These outrank the 6% of apps charged at the minimum $0.99 rate. One challenge of the one-time payment model is that users cannot try out your app before spending money on it — you’re essentially asking users to buy a product without testing it. This can slow downloads, unless your app falls under a niche market, doesn’t have much competition, or comes with heavyweight reviews. These kinds of paid apps are best for popular businesses that already have a large base of loyal customers. Paid: Recurring Subscription As opposed to charging users once to download your app, you may consider charging a recurring monthly or annual subscription. This works well for apps that produce fresh content on a regular basis (such as news apps) or those offering ongoing services (such as personal finance apps and streaming apps). One advantage of this model is that you may be able to charge users more in the long run than they’d be willing to pay in a one-time fee, generating a steady stream of revenue for your business. The subscription model also allows you to offer a free trial, which can lower the barrier to entry for new customers. This model does require you to make additional decisions, such as whether you want to bill monthly or annually, (the answers depend heavily on your target market and how the app is used). You’ll need to plan for the subscription model early during development of your app, as the app will need to recognize the time interval set for your subscription, and be able to accommodate changes in user subscription status, expired subscriptions and more. Paidmium This pricing model is a blend of the paid and freemium models. These apps require an initial download cost — plus additional opportunities for in-app purchases. The paidmium model keeps developers on their toes, but should only be used if a company is certain it can continue providing valuable content to users on a consistent basis. Choosing Your Pricing Model There are three major questions you should consider when choosing a pricing model for your app: Who is my audience? Survey results show that those in the baby boomer generation will be less likely to pay for an app than younger consumers, who have fewer reservations about spending money on app downloads. What are my competitors doing? If you are the only paid app among a sea of freemium apps with similar offerings, your product will drown. Look at the most popular pricing model for your competition and price your app accordingly. iOS or Android? The Apple Store has more paid apps than the Google Play Store. You may consider different pricing schemes, depending on whether you’re selling in one or both stores. Pricing for Internet of Things (IoT) Devices If your app is for an IoT device, scrap the regular pricing model schemes. Because these apps offer highly-personalized, on-demand services for IoT devices, they naturally demand an initial payment from the user for the actual device. Many IoT gadgets come with a selection of apps already installed by the company that produced the device. Consider whether your app would be better sold to consumers, to be downloaded onto their various IoT devices, or to the makers of the IoT devices themselves. IoT apps offer a range of services in one app (think of a home security app that can identify potential fires, intruders, and lock your front door if it has slipped your mind). While the app itself may be included for free, its provided services are not. As a result, IoT app companies are creating tiered payment models for customers, ranging from the most basic of services to higher paid tiers that offer more flexibility. This allows customers the freedom to choose their level of investment. IoT apps can also be pay-as-you-go. For example, imagine having an air conditioning unit that’s connected to the IoT, and charges you only for your rate of usage. We already see insurance payment models in which users pay for car insurance per mile driven; the rise of IoT vehicles will make it possible to not only pay-per-mile to rent a car, but also pay-per-usage for any IoT app services you may use while driving that car. The pay-what-you-use approach gives users flexibility in how much they spend for the services your app offers. Don’t Wait Until Release to Set a Price It’s best to consider the pricing model and price point for your app before you go into the development stage. This way, your development team can design and produce features that fit what’s needed for your revenue model — whether that’s elements to accommodate advertising, encourage in-app purchases, or direct users to a wider network. During development and design, you can always rework the pricing model as you add or remove features from the app. By the time you’re ready for release, you’ll not only have a well-built app but also a well-suited pricing model to go along with it, so as your app delights users it also provides you with appropriate revenue. If you need help assessing a price point for your app, Barefoot Solutions offers a full-service team to guide you in the process, from strategy and marketing to design and development — let us help you bring your app to life.

This is a question that we go through with nearly every mobile client we work with at Barefoot Solutions. Mobile technology is progressing at breakneck speed right now and it's very difficult to keep up. So to start, what are the technology options for launching a mobile strategy? While there are an infinite number of variations, the options can mostly be put into 4 buckets: Mobile Websites Mobile Web Apps Hybrid Apps Native Apps Mobile Websites are simply websites that have been optimized for mobile devices. A good example of this can be found at http://m.techcrunch.com. Changes to the layout are made by recognizing the user agent as a mobile device and optimizing for its limitations. This can include removing ads, increasing the size of clickable areas, and most importantly, accounting for the smaller screen size. Mobile Web Apps are still mobile websites, and thus must be accessed via a phone or tablets web browser. The difference between a mobile website and a mobile web app is that mobile web apps are built to mimic functionality of native apps. By adding controls like date pickers, tab bar navigation, and other native feeling controls, this gives the user the experience of using a native app. Typically these are built using frameworks such as Sencha Touch or JQuery Mobile. These frameworks are effective because they have already built most of the common controls using HTML5 and Javascript. Building all of those controls from scratch would be a significant undertaking, but JQuery Mobile you can focus on functionality, rather than building the sometimes complex user interaction necessary for mobile devices. Hybrid apps also utilize frameworks, often built with HTML5, Javascript and CSS, to produce native-feeling apps. Some examples are Phonegap and Titanium Appcelerator. The difference between a hybrid app and a mobile web app is that the hybrid apps are actually compiled and treated as native apps. This means that, on your iPhone for example, a hybrid app must be downloaded from the app store, and will live as an app icon on your home screen. Hybrid apps are appealing because they allow you to develop only a single app, but then compile for the various app stores and be available on multiple platforms. Another benefit of hybrid apps is that they have access to the phone's hardware. Access to the accelerometer, image gallery, camera, bluetooth, and other sensors on the phone are often a requirement for the more advanced apps. Finally, we have purely native mobile apps. This means that they are written in Objective-C for iPhones, or Java for Android applications. They are compiled, and submitted to the app store for distribution for that devices particular users. Mostly, native apps have to be built as a separate piece of software for each platform, and are able to share very little code. So if the desire is to make your app available on iPhone, Android, WinPhone, and Blackberry, you would need to build four separate apps. So with those as the options, what factors should go into deciding on a platform? To start, it's important to identify the goals and limitations of your mobile strategy. Then you apply those goals to the four factors below to make a decision. Cost Mobile apps become more expensive as you get closer to the fully native experience. A mobile website can often be implemented by altering layout and stylesheets of an existing website, and as such is a low cost product that can be accessed on any phone or tablet with a web browser. Native apps, on the other and, require quite a bit more development time, which then gets multiplied by the number of platforms that need to be accessible. As such, native apps are the most expensive option, by far. User Experience If this decision was based entirely on cost, then a mobile website would be the obvious choice. But what about the user experience? Unfortunately, native apps, while the most expensive option, also provide the best user experience. By interfacing directly with the native SDKs, native apps have a very fast and responsive UX. Think of the difference between using a desktop app like Microsoft Word, versus Software as a Service like Google Docs. Because Microsoft Word is a compiled and installed application, it directly interfaces with your machine and allows it to be more powerful, and responsive. The same holds true for native apps. Further, native apps have controls like pickers, navigation tabs, action bars, and others that are immediately recognizable to users of a platform. When building a single app for multiple platforms, you must find commonality amongst those platforms and therefore can't entirely mimic a native experience. While this will work for some apps, others, particularly those that are entirely consumer facing, need the native UX to provide users what they have come to expect from their apps. Difficult to develop and maintain Many organizations now have in-house web developers, or at least people with some experience with HTML/CSS. This makes it possible for some organizations to build a mobile website or mobile web app without having to hire outside of the company. Native apps however require a very particular skillset. Objective-C developers, for instance, can be difficult to find and expensive to hire. While it may be feasible to hire a firm for the initial development of your app(s), there is also the matter of continually managing this relationship to account for updates, bug fixes, operating system upgrades, and other required maintenance over the lifetime of the app. Depending on resources this may not be feasible for some smaller organizations. Reach Mobile websites and mobile web apps are available on any device that has a web browser. This is basically any feature phone or smartphone these days. As such, they have the furthest reach with the lowest cost. Hybrid apps can also be available on multiple platforms for only the cost of building a single app. Further, along with native apps, they have the added benefit of placement in the various app stores. This allows apps to be discovered by users in a way that just isn't possible with the mobile web. This also allows the possibility of reaching high in search rankings, or earning a featured placement in an app store which can provide a serious spike in downloads. So what approach should you choose? It seems to be like the odds are greatly in favor of the non-native options, but very often that is not the case. As I mentioned, the user experience on non-native apps is just not where it needs to be. Even with hybrid apps, buttons can take a half-second longer to respond to a tap, and scrolling can get slow and choppy. In the beginning of 2011, Facebook's mobile app took a largely hybrid approach. They were faced with considerable user unrest, and suffered a fairly low rating in the app stores. In the middle of the year they re-architected to a much more native experience. Their apps are now faster, more responsive, and the user feedback has improved considerably. At Barefoot Solutions, we always recommend native for any purely consumer facing app. Period. If you want to have a chance at gaining significant traction, it is imperative that you provide the best User Experience possible. It is often better to launch on only a single platform, with an excellent user experience, versus launching a mediocre experience on all platforms. When we start talking about internal apps, mobile web apps and hybrid apps become a much more cost effective solution. For example, if you're building an app to help your sales staff in the field, and this staff uses a variety of devices, it often makes sense to build a hybrid app. This will allow most of your staff to use the app on their devices, and they will most likely be willing to look past the slight lack of performance. If you are a restaurant that just needs contact information, directions, and a menu available on customer's phones, then a mobile website is probably the right strategy for you. Overall, this is a decision not to take lightly. Jumping from one strategy to another often requires an entire rebuild, so it's important to get this right the first time. At Barefoot Solutions, we're happy to provide a free consultation to discuss your mobile strategy and provide an in-depth look at what might be best for your startup or existing company.

Since Google announced its release of the software development kit for Android-powered wearables last month, the shower of interest has turned into a veritable deluge. App developers across the globe are caught up in the storm. Why? The components used for wearable devices have gotten little and inexpensive and a large number of consumers have smartphones that are simpatico with a wearable device. Juniper Research predicts that more than 130 million smart wearable devices will ship by 2018. Google is keeping the name of its newest line simple - Android Wear - but they’ve made sure to let everyone know that, while the premise is straightforward, the possibilities boggle. Initially the vanguard mobile device OS will be tailored for smartwatches and comparable trappings, but they will soon offer a closetful of trendy, fashionable body-fitting devices. But whatever form the Android Wear device takes, there are certain requirements that it must meet, according to Google. Alex Faaborg, Android designer, explains the Android Wear concept in a promotional video. “It needs to be incredibly fast, incredibly glanceable... there’s really only two components: the information that’s most relevant to you, and the ability to speak to it and do a quick command.” He goes on to say, “We designed an entirely new UI specifically for this form factor, and its really based around voice and contextual information.” Google has lined up a number of hardware and chip partners to produce this upcoming fashion line - LG, Samsung Electronics Co., Motorola, Intel Corp., Fossil, Asus, HTC, Intel, Mediatek and Qualcomm Inc. It looks like LG will be the first partner to produce - its “G Watch” is poised to debut within the next few months. And the price is far from Gucci-like at only an estimated $300. Google’s announcement “definitely gives wearables a status that it’s a market in it’s own right and it needs to be treated with the respect that a separate operating system branch gives it,” said Carolina Milanesi, an analyst with Kantar World Panel. App developers agree. They are are well aware that there are no boundaries in the wearables space, but they also know he/she who hesitates is lost. "A whole new app ecosystem is going to be born," said Shawn Hardin, chief executive officer of Mind Pirate, which released "Global Food Fight," its first game for Google Glass, earlier this year. "Those who are going to make that happen in a big way are going to be valuable companies because of it, and those who wait too late won't be a part of it." And Google - - - look out for iWatch… Sources: http://www.techhive.com/article/2109241/meet-android-wear-googles-bid-to-bring-serious-productivity-to-smartwatches.html http://gigaom.com/2014/03/10/google-to-release-sdk-for-android-powered-wearables/?utm_content=buffereef88&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer