How is cloud and desktop developers landscape evolving? We’ve prepared an infographic with some key insights that can help you better understand the cloud and desktop development, based on our recent report focusing on the topic. Here are some of the key insights:
49% of developers are working professionally across both cloud and desktop
41% of desktop developers are creating applications which never leave the browser
54% of cloud developers who use advertising are making less than $500/month
Check out the Cloud and Desktop Developers infographic for more insights:
Softeq Development is involved in everything mobile: from business apps, digital imaging and utilities to mobile games, wearable technology, sensor-rich equipment and its remote management. They have built dozens of embedded solutions, web, and mobile applications for such clients as Nike, NVIDIA, Omron, AMD, Atlas Copco, EPSON, Disney Parks and Resorts. T. Our associate author, Alkis Polyrakis, discussed with Softeq’s CEO, Chris Howard.
What is the philosophy that you employ in order to assist companies take advantage of the full potential of the latest technology?
To me, our philosophy is to be ahead of the curve. It means we try to know and adopt new APIs, tools, and technologies before customers actually need it. We obtained and evaluated Google Glass, EPSON Moverio, Oculus Rift, LEAP motion controller and many more new tech novelties long before the first project came along. Once a customer approaches us with a project for those new technologies, Softeq is already the most competent tech provider the customer can possibly find on the market. Having close ties with many companies in Silicon Valley, we were one of the first tech firms in the world to access and implement, for example, Microsoft’s high speed video APIs on Windows Phone before they were available to the public.
Digital magazines
What are the benefits of implementing a Proof of Concept in business projects?
A proof-of-concept (PoC) is a great first step on the way to a new product, device or technology that was never seen before because it’s a low-risk and low-investment approach. Often, it requires a 10-20 times smaller budget than actual new product development.
In our business, we have come across two different goals, or approaches if you like, to building PoC apps. One is when a customer is looking to prove the feasibility of his new business idea. At times, our clients need to demonstrate a working prototype of an upcoming product at a trade show, board meeting, or at an investor meeting. Prototypes later can become Minimum Viable Products (MVPs) and both can be stages of a full product development cycle if the idea gets approval.
Xamarin framework
Business apps development
Atlassian Jira
Project management
LabView – LabWindows – MathLAB
Wearable devices
Flurry – Google Analytics – Localytics – Adjust – Parse
Monetization
Unity
Games development
Softeq’s Toolset
The second typical need is when a technically advanced company researches next-gen ideas, software or hardware they’re looking to jump into. Here, building a proof-of-concept in the first place is a way to test the feasibility of their vision for the application of new technology, a hardware component, or form factor. Just like that, our R&D teams have been working for Nike, Intel, and EPSON to help then visualize their new ideas and prove it is actually possible to do what they envision.
Do you have a specific development procedure when working on a PoC?
As a PoC is always something pretty innovative and non-standard, generally the development procedure is to identify the key features of what a client is trying to do in a bigger project, focus on only testing and proving out the specific new APIs or new hardware, and building a very simple framework in order to demonstrate that specific capability. After the PoC is approved by the management team, the investor, or the end-client, we proceed to flesh out the rest of the features and ship an actual product.
Which development and project management tools do you employ in order to facilitate your needs in cross platform development?
There are several cross-platform frameworks trending on the market now, and this is fair enough. The mobile market is no longer dominated by one platform, and most of our customers, both in the B2B and B2C segments, need to target wider audiences with various OS preferences. We use the C# based Xamarin framework for business apps, and Unity for games. Speaking of project management tools, we use Atlassian Jira by default or any other tool the client is more comfortable with.
Our readers would like to hear some examples that show how you managed to pump up a company’s marketing efforts with your apps.
Marketing apps for Blizzard and Branson Ultrasonics
Marketing apps vary, and we’ve delivered several dozen of them: from Blizzard’s BlizzCon event management app for helping improve the guest experience, to mobile CRM, promotional games, mobile magazines for corporate clients, and demo apps for tech events and industry-specific trade shows and all the way up to international tech summits and even Mobile World Congress where companies present their new or would-be products. We’ve built several kiosk apps for in-store demonstration of new gadgets to buyers. One of them was for NVIDIA’s SHIELD – the world’s first Android TV console. The kiosk mode allows demonstrating all functional features, including games, videos and music playback, while blocking access to system settings.
What are the main challenges that you face when you attempt to build solutions for wearable devices?
We’ve been working on embedded devices for a very long time, over 15 years now, that’s why the era of wearables came very natural to us. The challenges anyone designing a wearable device inevitably faces are technical limitations of the form factor, such as short battery life, small amount of memory, insufficient performance, custom communication protocols (infrared, Bluetooth low energy) and more.
However, Softeq is uniquely positioned in this market and beyond, in the Internet-of-Things (IoT) space, because we do everything from hardware, low-level and firmware to web backends and mobile apps covering all our departments end-to-end. To extend that further we have a game department, and that even gets mixed in with wearables and the IoT.
Hardware Design and Embedded Development Lab deployed in Softeq’s HQs in Houston, Texas
Can you tell us about some of your wearable device projects and the tools that you employ?
One of our current projects involves embedded touch panels, and we do both firmware for the panels and Qt-powered games for them. Another product we helped create – the BlinkFX Wink, which is a wireless control LED light wearable device – is being used for an upcoming game show at CBS.
There’s a wide range of tools and instruments, mainly in C, that we use for such projects. For instance, recently we started receiving multiple requests for projects involving drones. We suggest using such behavior modelling tools as LabView, LabWindows and MathLAB, but it’s not the tools that matter most. The most complex part is building math models and algorithms based on them.
Do you provide consulting services as to which model can maximize a game’s revenue?
The monetization system of a game is usually built by a tandem of experts – a game designer and a marketer. The game designer is responsible for building game mechanics in terms of monetization and balancing economics while the marketer drives user acquisition campaigns.
To ensure we deliver the maximum amount of effort on our end to ensure the game’s success, our game designers invest a lot of time in research, comparative analysis of top apps, exploring best practices and efficient mechanics to put them in our arsenal. From the game design perspective, we certainly consult developers at the early stages of building the monetization system: building the core loop, the in-game store, retention mechanics, economics balance, analytics, A/B testing system implementation, etc. For instance, we work with such analytical tools as Flurry, Google Analytics, Localytics, Adjust, Parse and the selection of tools depends largely on the game specifics and client’s preferences.
Thank you very much for taking the time to share your strategy with our readers.
For the last two and a half years I’ve been building and selling apps directly on the iOS App Store, however only in 2014 I committed to some substantial effort on this. I’d like to share some numbers about my experience last year and draw some insights about what things went well and which ones didn’t.
Hopefully this analysis will be useful to others and will give me some insight about where to focus in 2015 to grow my app revenue.
January 2014 brought along my most successful app so far: My Oyster. This app has been in development since October 2013 and even though it had a rough start on the first few months of the year, it is now my most consistent app in terms of downloads and revenue. Along with it, I started selling My Oyster Pro as a 69p ad-free alternative as I wanted to evaluate how well the freemium and paid pricing models would work for the same app. As it turns out, this paid version contributes to sales figures comparable to the ones of the freemium app.
Alongside this, I have been working on improving Camera Cube, which has been live since 2012 and takes the second spot for this year on revenue. Most notably, I released a major update with iOS 7 compatibility in July and added support for iPhone 6 and 6 Plus in December.
In August, I also released Perfect Grid as an iOS port of a simple puzzle game I previously made for Android.
Finally, in November I launched Pixel Picker, my first app written in Swift!
Alongside these new entries, my two old apps Puzzle Camera and Camera Boom are still live on the App Store, however I have not been updating them this year.
My App sales numbers in 2014
Total Revenue
Paid Downloads
IAP Revenue
Ad Revenue
£ 584.23
£ 151.80
£ 199.21
£ 233.23
App Annie Yearly Revenues 2014 – Source: Musevisions blog
The first important observation is that 86 % of my total revenue comes from the My Oyster and My Oyster Pro apps which both went live in January and brought in 504.86 £ by the end of the year. Overall the freemium version accounted for 70% of these sales (fairly equally split between in-app purchases and ad revenue) and the paid version for the remaining 30% of sales.
This shows that the choice of differentiating my revenues across advertising, in-app purchases and paid downloads has paid off and I plan to keep all these streams going for My Oyster in the future and try them with my other apps as well.
App Annie 2014 Revenue Graph – Source: Musevisions blog
The graph above shows how my revenues have changed over time during this year. For various reasons, I had to remove My Oyster from sale during the January, February and April timeframes, and this shows clearly in the revenue graph.
For the rest of the year, revenues have been varying between 1.5 to 2£ per day on average and peaks of 4 to 6£ per day.
Expenses
In 2014, the costs of running my app business have been as follows:
Apple iOS Developer Program: 60.00 £ Domain Hosting: 102.47 £ Facebook Ad Campaign: 200.00 £ Outsourcing services: 408.69 £ iOS icons pack: 16.10 £ Total Expenses: 787.26 £ Total Revenue: 583.86 £ Net Loss: 203.40 £
The biggest expense has been some outsourcing work I’ve done to create UI artwork for my apps, however this was necessary to create some high quality UI elements and I’m happy with it.
Marketing
This year I have tried a few marketing strategies to give my apps more visibility. These three have been the most effective:
Keywords optimisation Particularly for My Oyster, the number of downloads has had a high correlation with the ranking of the keyword “Oyster” in the UK App Store. The app has been ranking third for this keyboard through the whole year and averaging 50 to 70 downloads per day.
On one occasion it jumped up to second spot due to one of the competitor apps being temporarily removed from sale and the downloads spiked to over 300 a day as a result. This shows that direct search ranks are fundamental for user acquisition on this app.
Facebook advertising In an attempt to get My Oyster to the top of the UK Travel rankings, I ran a Facebook Ad campaign in the London area for 10 days, allocating 12£/day initially and spiking this to 40£/day towards the end. The campaign succeeded in boosting the app from position 200 to the top 50 in the UK Travel category, however as soon as I stopped the campaign, the ranking dropped again to its previous levels. With a cost per mobile app install of 0.12£ and an average revenue per download of 0.01£, I would have had to generate 12x more revenue per download, or decrease the cost per install by 12x in order to break even with this strategy.
Hacker news I have promoted Perfect Grid and Pixel Picker by sharing the apps’ iTunes links on Show HN and asking some friends to upvote them. I did this for Perfect Grid on the day after launch, managed to get 14 upvotes and stay on the Hacker News front page for a few hours, but this only resulted in 180 downloads on that day, which I presume could be attributed evenly to Hacker News traffic and the app just having gone live.
Pixel Picker fared much better and managed to get 2200 downloads in one day, largely attributable to Hacker News traffic.
My Oyster UK Travel Ranks 2014 – Source: Musevisions blog
My Oyster Facebook London Ad Campaign May 2014 – Source: Musevisions blog
My Oyster Downloads May 2014 – Source: Musevisions blog
Pixel Picker Downloads generated by Hacker News traffic, November 2014 – Source: Musevisions blog
Additionally I have been spreading the word about new releases of my apps on Twitter and Facebook, however I haven’t noticed an increase in downloads as a result. Writing to bloggers to request a review for My Oyster also proved ineffective and a big time drain so I’m not going to invest more effort on this going forward.
Overall, I have been quite impressed at the number of downloads that a high traffic site like Hacker News can generate, however in my experience this only helps in getting a spike in downloads. I haven’t yet found a way to sustain high download numbers over time, other than through paid advertising which is an unsustainable model given my current ROI.
Going forward I’d like to share my apps on other high traffic sites such as Product Hunt and Reddit, as well as trying other advertising platforms.
User Engagement
So far, My Oyster is the only app that shows promising engagement metrics with around 5000 MAU and good retention rates:
APP
Period
AVG session
duration (min)
Monthly active
users
Returning
Users (%)
New users
per month
My Oyster
November
6.47
5441
94.4
2116
Pixel Picker
December
2.06
738
41.1
575
Camera Cube
November
1.18
681
50.0
N/A
Perfect Grid
November
3.05
98
86.1
N/A
Having around 640 daily active users and an average session duration of over 5 minutes, My Oyster performs much better than my other apps in terms of ad impressions and revenue.
My Oyster Ads Report 2014 – Source: Musevisions blog
As outlined in the graph above, My Oyster received 3000 clicks at a cost per click of 0.06£. Next year I plan to experiment with Ad Networks other than AdMob to determine if a higher CPC is achievable.
Customer Support
To facilitate user feedback, all my apps have a help/about screen with an option to contact customer support via email.
One peculiar aspect of the My Oyster app is that it lets users check their Oyster card data which comes from a 3rd party website. As the content can be unavailable at times and users sometimes have issues with their accounts, some time is required to answer customer emails, so the revenues from this app aren’t completely passive.
The positive side of this is that a lot of customers get in touch with me directly and their feedback helps me improving the app over time.
As download numbers and engagement metrics are not good for my other apps and I very rarely receive emails from customers that have downloaded them, I can infer that those apps are not as discoverable as I’d like them to be and they don’t generate much interest from customers. From a business perspective perhaps I should focus on My Oyster instead and try to grow its user base and functionality.
Conclusions
As many others have noted, [tweetable]bootstrapping a consumer app business on iOS is hard[/tweetable]. My personal experience so far has been that from a purely financial standpoint this is unsustainable and I should be investing my time in something more lucrative like consulting, which at the time of writing brings in 30x to 50x more revenue per hour worked.
However, I believe there are a lot of intangible benefits in making and publishing apps:
They make for a good portfolio Prospective clients will be able to assess the quality of my work and my apps always help me getting jobs and consulting gigs.
I keep acquiring new skills Making apps is by nature a creative process, and I have the freedom to choose all the latest tools and technologies for the job at hand.
Full product lifecycle Making apps forces me to think about the whole product: development, UX, support and marketing.
Flexible workload I get to choose how much or how little I work on my apps, as well as choose what I want to work on. For me this is very valuable as I can enjoy working on these side projects without having too much pressure.
I get to talk at events Sometimes I feel it’s worth sharing my findings and experiences as an app developer, and this also is beneficial for building my brand and network.
Goals for 2015
In 2014 I was hoping to hit and maintain 100 £ in revenue per month. I have missed this mark by about 50%.
As most of my revenue came from the sales my My Oyster, I plan to focus on further developing this app and try a few more marketing channels to improve its visibility.
While I plan to do some more independent app development in 2015, my app business so far has struggled to take off and I feel that I could invest more of my time in other relevant activities, including:
Open Source development I’d like to focus more on creating small and reusable iOS libraries and components and share them with the community. I find that such projects are very well suited for giving presentations of technical nature. Additionally, I’m reading a lot of stuff on functional programming and I can’t wait to share a lot of functional stuff on my GitHub page.
More consulting work I see consulting as an opportunity to see what challenges companies face and work on problems that I would not have the chance to take on as an indie developer.
Write technical material, courses and seminars This could be a new exciting venture for me and I feel that there is a great community around iOS development and software programming in general. As I become a better developer, I’d like to share some of the lessons I learnt in a format that can be most useful to others. Further down the line, I would like to start running my own courses and seminars.
Time will tell how things will go, but I feel very privileged to be an iOS developer in 2015 I can’t wait to build more products and awesome stuff this year!
Which skills do you want to develop?Take the Developer Economics Survey and we will compare your skills to the global average. You can work on those skills and maybe get your lucky break.
In our latest report, App Economy Forecasts 2015 – 2017, we estimate the number of mobile ecosystem in 2014 at 5.5 million developers. Demand for mobile development skills has never been higher and yet revenue from app store sales cannot possibly pay their salaries. Luckily they don’t have to as developers aren’t all building apps full time and there are several other revenue sources in the app economy, some of them comparable with or even significantly larger than the app stores.
Estimating the developer population
Counting mobile developers is hard. A lot of software developers look into mobile platforms and a lot of people are curious enough about how they’d make an app for their phones that they’ll try to find out. We can’t meaningfully count all of these as mobile developers. However, we also know from our Developer Economics surveys that a huge percentage of developers creating the apps that fill the app stores are not full-time professionals. Popular programming Q&A site StackOverflow has around 35 million unique visitors and it is only an English speaking community. That probably includes a lot of students trying to get help with their coursework. Meanwhile bottom up estimates for the global professional developer population based on job classification data from multiple sources are just under 20 million. This is highly error-prone due to the way developers are classified along with other IT professionals in many places around the world. How many of those are really building mobile apps anyway? Apple has over 9 million developers registered on their developer portal. Some of those are for Mac and Safari but the majority are iOS developers. Then again, the number of developer accounts with any apps published on the App Store for iOS is only around 350,000. Google Play has fewer active publishers than iOS. The truth must lie somewhere between these extremes.
For the purposes of our estimate we decided to count developers who are actively building, or planning to build in the very near future, publishable apps for a mobile platform. Students building toy apps to learn and hobbyists who only build things for themselves aren’t taken into account. Those people could join the ranks of mobile developers in the near future but they aren’t doing anything to satisfy mobile app demand yet. 5.5 million is the number of developers required to maintain all of the published apps that have been updated in the last 12 months, plus build all of the new ones released in the same period. In our report we also forecast the number of new and updated apps going forward and the number of developers required to sustain that app growth through 2017.
Keeping the pizza and coffee flowing
Developers are in high demand and as employees in the US they will typically earn upwards of $100k per year with relatively little experience. Proven talent in Silicon Valley can easily earn 50-100% more. Salaries in Western Europe are not quite as eye-catching but not that far behind either. In countries where the cost of living is much lower, developer salaries are obviously more modest but actually often a greater multiple of the national average wage.
Why would anyone with such earning potential build and sell apps that are likely to produce a poor return on their time. There are several answers:
Some apps make fantastic returns and some developers believe, or at least hope, they could emulate those and use their skills to make a small fortune
Other developers are trying to build small but sustainable businesses on the app stores, targeting niches and working as artists and entrepreneurs
Some developers build their own apps as proof of their abilities in order to sell their skills for a higher rate on contract development work
Many developers just love to code and already earn a full time salary in their day job, they build apps as side projects or for a hobby, either for fun, a little extra income or to sharpen their skills for their next career move
Some developers are purely learning and having fun, usually either at the beginning of their careers and in some cases after they’ve retired.
Note that only the first two of these are depending on the apps for income. Of course not all developers are trying to make a return from apps via paid downloads or in-app purchases. Advertising is also a big source of revenue in the app economy, although most of it goes to a few giant corporations. The typical developer monetising through ads does much worse than those using in-app purchases, so that’s not the answer. However, there are other models where developers have better odds of making money. Subscriptions are the fastest growing revenue opportunity according to our forecasts, although for pure Software as a Service rather than content subscriptions that will mostly be selling to enterprises. The biggest revenue opportunity of all in app economy over the next few years is definitely not in pure software businesses. Indeed, it’s the rather old-fashioned business of selling real physical things! Find out just how big it is by purchasing our latest report.
Testing any mobile app presents a wide range of challenges. The often repeated but rarely followed software best practice of test early, test often is harder to adhere to than usual due to the fragmentation of the target environment and the relative maturity of tools. The increased acceptance of apps by mainstream consumers and intense competition have raised the bars for user experience and quality. There is more to test than ever, yet often very limited budget for doing so. Fortunately every challenge presents an opportunity and a vast array of tools vendors are racing to fill the gaps.
What to test?
Much of the traditional software testing literature focuses on various forms of functional testing – ensuring the system does what it’s meant to do. With a strong trend towards simpler, single purpose apps, this is often the easiest thing to verify in a mobile app project. There is now a much stronger focus on the user experience and this requires testing of an entirely different nature. The most effective way to test that an app is easy (or even fun) to use is to get feedback from real users. Doing that and finding major issues after the app has been built is a very expensive mistake to make, so most developers and designers will want to create mock-ups or prototypes for early feedback. There’s a wide range of tools to help with this task from simple wireframing through to full interactive prototyping. Given the importance of animations within mobile apps to enable users to discover interface interactions and learn to navigate, more complete prototypes are becoming increasingly desirable. As users become more sophisticated and specialist tools reduce the time and effort required to create interactive prototypes this trend is likely to continue.
With the majority of app store revenues coming through in-app purchases, another more specialized form of testing the design of an app is becoming increasingly important – split testing. On the desktop web, tools for trying out design and copy variants to optimize sites for specific user behaviours are very mature and the best of them can be used by staff with no development skills. In the mobile world most of the tools in this space are still very immature and developer-focussed. The responsive design trend on the web and the more restricted deployment options for native apps make this a more challenging problem for mobile devices but we expect the tools in this sector to mature rapidly.
[sectors slugs=’prototyping-mockup’]
When to test?
The earlier you find problems with software, the cheaper it is to fix them. As such, it makes sense to start testing as early as possible. How about testing the idea for the app via a mobile market research service before you even create your first wireframes? It’s worth considering – if you can’t generate interest in your app idea with a simple pitch it’s not going to be easy to get people to download it from the store either.
For most apps (particularly native apps) it’ll be worth using one of the mock-up or prototyping tools mentioned above and test the design before you start coding the real app. It’s much cheaper to iterate a simple design prototype than a native app. However, you’ll still want to try out the actual app with real users before you launch it. To help with that there’s a range of beta testing services that can help you distribute your beta app and find and/or manage testers. There are also services to help you get feedback from your users before and after the app launches. Providing a highly accessible feedback channel for users in the app is your best hope for preventing the inevitable disgruntled few from leaving bad reviews.
Ideally an app will be developed and tested iteratively with functional testing of new features and full regression tests for the existing functionality run for each iteration. This level of testing can get extremely expensive and time consuming unless it is automated. Fortunately there are several tools, open source frameworks and third party services that can help out there too.
Another major problem for mobile developers is the scale and fragmentation of the market they’re trying to serve. Collecting a full library of test devices with major firmware variants is way beyond the budget of most developers, let alone the effort that would be required to test manually on all of them. Automated testing solutions can help here also and some services provide access to a large set of devices for remote testing too. However, it’s simply not feasible for most developers to test every version of their apps on all the device and firmware combinations they support. This limitation means some bugs are almost guaranteed to escape into the wild; the important thing then becomes how quickly you discover and fix them. For this reason, crash analytics and bug tracking tools are becoming increasingly important. Another useful weapon in this battle is your usage analytics data – it can enable you to focus testing on the devices which are most popular amongst your user base and also spot changes in use on particular device models that might signal a non-fatal error that’s causing users to abandon the app.
Finally, for some apps, where they are tested geographically may also be important. Do you know what the performance of your app is like for users who are far from your servers? If you use SMS, do you know how long it takes to get to users on different networks around the world (or if it even gets there). Have the localisations for your app been tested by native speakers? Our automated testing and app certification sectors include companies that can crowdsource beta testers or provide access software testing professionals almost anywhere in the world to help you scale globally without leaving your desk.
The reason why ASO is getting so much attention right now is because in today’s charts-driven app stores 10% of apps gets 90% of downloads. For developers, the only effective mechanism to catch attention is buying large amounts of app installs to catapult their app into the top 25 charts where people look for inspiration. But this approach has become very expensive as app install prices soar.
Indie developers who have limited resources struggle to compete and get their app in front of users’ eyes. At XYO, our goal is to change this and enable long-tail app discovery by helping users discover what they want even though they can’t express it. To build our site XYO.net we looked into search behavior to understand how people find apps. What we learned is that the majority of users has no real concept of how to search for apps and no idea about the vast supply of great apps out there, because they can’t see them.
To optimize for search it’s important to understand how users are searching. On the web, there is SEO as a proven tool for which countless SEO companies provide rich insights, and tracking success is easy. For mobile apps however, it’s mostly guesswork. “These are the super early days of ASO”, said Tomasz Kolinko founder of ASO specialist Appcod.es. App Store Optimization (ASO) at the moment boils down to optimizing a list of keywords for queries that users are likely to type.
So how do users search? Based on our data on XYO.net and by looking at the publicly available studies by Chomp (acquired by Apple last year), we have identified four types of users in app search.
Our main findings conclude that app search is dominated by vaguely expressed intents and very generic queries. Users are inexperienced in how to find apps and have difficulties navigating cluttered app stores.
80% of user searches are generic category or interest searches
Most app searches happen with only a generally expressed intent. The majority of users (around 75%-80%) type general app categories into the search box. Examples of such categories are ‘social networking’, ‘education’ or ‘racing games’. Our findings are consistent with what app search company Chomp was publishing in its Monthly App Search Analytics study.
Around 10%-15% of all search queries look for simple inspiration: These users either type ‘games’ or ‘apps’ into the search box or add adjectives like ‘new’, ‘free’ or ‘fun’. Examples of such queries are: ‘addictive games’, ‘fun games’, ‘free apps’, ‘new apps’.
Only 5% of all users seek specific app brands or titles. Our data and other sources indicate that while some users are aware of mainstream brands like Angry Birds or Facebook, other mobile brands are mostly unknown.
For apps there is another category: functional app searches where the query describes what the user wishes to achieve. Examples of such searches are ‘crop photos’, ‘block calls’, ‘view movies’. Those functional queries are super important for classic web-based SEO – in mobile app search they are marginal at around 5% of searches.
Optimizing search for users who don’t know how to search
App Store search is based on app title and a keyword list. For Google Play the app description also counts, which opens up more opportunities for developers to add seasonal or trending keywords (e.g. ‘easter’ or ‘gangnam style’).
In general, it’s advised to use a keyword tool such as appcod.es, MobileDevHQ, SearchMan , and appnique.com. These tools give an idea of keywords competitors are using and where the sweet spot of high search volume and low competition lies for a specific app.
[sectors slugs=’app-store-optimization’]
“Longer phrases are 70% of search volume on the web (indicator), they’re less competitive, and probably see higher post-click conversion (download) rates because the user explicitly searched for ‘free video poker game’, Niren Hiro, CEO at SearchMan told us. His conclusion: Developers can take steps to get the No. 1 rank under each of their ‘long tail’ keywords. That is, developers can optimize their rankings for keywords that will give them better results on the App Store when users go searching for certain kinds of apps. Optimizing for the long tail is key, because generic keywords will have high search volumes but a lot of competition and often lower conversion.
“We go from low(er)-volume, high-conversion keywords (such as ‘golfcoaching’), all the way to what we call secondary and tertiary market keywords, like ‘coaching’ or ‘sports’. Conversion for branded and function searches are likely to have higher conversion rates than inspiration or interest searches – and interest searches may have even better conversion rates than inspiration searches,“ explained Patrick Haig, VP, Customer Success at MobileDevHQ. If history from the web will repeat itself, then it will become cumbersome for users to browse results, and they will start entering more descriptive phrases to get relevant results fast.
Apart from optimizing the keyword list, an app’s title is of utmost importance. We recommend including the most important keywords in the title to get found.
Showtime: App description and screenshots increase conversion
When users browse search results, two things matter most to increase conversion: app descriptions and screenshots. Over and over again we see the first three lines of description wasted by developers babbling about achievements that are meaningless to new users. Sure, a “Game of the Year” award is great news – but it’s secondary information as long as users don’t have a clue what the game is about. That’s why the app description should explain what the app does in the first 2-3 lines. Bullet points can be used if necessary, as well as precise and short copy. Later in the text authoritative reviews can make sense to build trust, especially for Android where this text is also indexed for search. “For Google Play, it’s even better if you can include reviews that include targeted keywords,” said Patrick Haig.
Screenshots have gained relevance significantly and are a popular medium for developers. Users rely on screenshots to see if they like the look and feel of an app they’re about to download, and –again– to find out what this app actually does. Jai Jaisimha CEO at Appnique: “Moment of truth: iOS6 design increases importance of the screenshot because that is mostly what they see in the App Store client on the phone.” That’s why adding explanatory text is useful – and developers should get creative about it. Patrick Haig: “Treating screenshots like a stop-motion commercial can be powerful.”
Reviews turn users into app ambassadors
Once a user has downloaded an app, ratings become priority because they are crucial for ranking: “We have an article here from Inside Mobile Apps that illuminates how important ratings are, segmented by each store (Google Play and iTunes). Also, it’s becoming even more important for publishers to improve upon their current version rating, as that’s the only rating seen by a searcher in-device (i.e., searching on their iPhone or iPad). Users have to dig in order to see the All Versions rating, which just doesn’t happen,” Patrick Haig from mobiledevHQ told us.
Though important, ratings are not that meaningful to base a download decision on: The average rating is 3.8 making it difficult to see the nuances within the star rating system. To increase conversion, internal and external reviews are getting more and more significant. Being proactive in asking for reviews can save a lot of pain: Prompting users for feedback makes them convey a problem before they post a negative review, recommends Appnique.
Conclusion
At the moment, a big trend in app store optimization (ASO) is trying to overcome the obvious discovery problem by stuffing app’s titles with keywords, longer descriptions or almost complete sentences. The race for the best phrases keywords is in full swing. Obviously user experience will suffer in the process if keyword optimization will be used too excessively by a large number of developers. A backlash might be the result, similar to when Google punished some of the shadier SEO practices with their Panda update.
The ASO tips presented above are not meant to be a ‘silver bullet’ for app discovery. ASO is a useful set of techniques used to increase discoverability through keywords, complementary screenshots and –most importantly– understanding how users are looking for apps. But it’s just one of many approaches to attract attention in a crowded app store, the main one being: having a great app that’s worth discovering in the first place.
Sebastian Brannstrom, Lead Engineer for Lyft at Zimride, talked to us about their app and the business that the technology enables. Sebastian has been working in mobile software since 2006, initially on Symbian and then transitioning to iOS, Android & Web by way of a side project, created in collaboration with designer and product manager Anna Alfut. In 2011 he joined VC-funded startup Zimride, who at the time only had a handful engineers, to create social ride-sharing services. Zimride’s initial service was an online marketplace for people to sell seats in their car on longer journeys. It was (and still is) growing but relatively slowly by Silicon Valley startup standards.
App Background
The company decided to create a new real-time marketplace for shorter trips and hence Lyft was born in 2012. Lyft has iOS & Android apps with two modes, driver and passenger. Lyft drivers are thoroughly screened, background checked, trained and insured with a $1M excess liability policy. Passengers can use the app to request rides that are tracked by the service, which suggests a minimum donation to the driver at the end. The driver mode notifies drivers of a nearby pickup request and gives them a short time window to accept it before it’s passed to another driver. The whole system enforces use of Facebook for identification to provide some additional security.
Track Record
The concept caught on and quickly became the main focus of the company. The engineering team has roughly tripled in size and the growth of the service is only being limited by how quickly they can recruit, screen and train drivers. Whilst they advertise for drivers on services like Pandora, Spotify and Craigslist, they have never marketed to passengers at all, apart from their signature giant pink mustaches on participating cars. Word-of-mouth marketing at its best, straight out of Seth Godin’s Purple Cow playbook. They have hundreds of registered drivers and tens of thousands of passengers in their first city, San Francisco. The company was nominated for three Crunchie awards and named runner-up in the “Best New Startup of 2012” category. According to TechCrunch, they very recently closed a $15M series B round of venture capital funding and have also just launched their service in a second city – Los Angeles. Open job vacancies make it clear they’re planning significant further expansion.
Competition
The disruption of transportation enabled by near ubiquitous smartphone adoption is an opportunity several startups are attempting to exploit. Lyft faces direct competition locally in San Francisco from SideCar, whilst Uber provide a high end alternative and have stated an intention to create a direct competitor in the lower cost segment. Fairly high-profile competitors with similar technology but not yet competing in the same geographical markets are Heyride, HAILO and Taxibeat, although the latter are enabling existing taxis with similar technology rather than encouraging peer-to-peer ride sharing. There is also indirect competition from existing taxi services.
Business Model
Lyft do not monetize their apps directly, it’s free to download and there are no in-app purchases for new features. Like almost all online marketplaces, Lyft make money by taking a cut of the transactions on the market. In this case the transactions are donations from the passenger to the driver. These are entirely voluntary (which gets around legal issues with drivers using their vehicles for commercial purposes) but the app provides a suggested donation and drivers can set a minimum average donation – passengers that don’t pay much/anything are likely to find no-one will accept their requests very quickly.
Lessons Learned
A successful service is much more than an app. The technology only enables the business at Lyft. Sebastian was quick to point out that the key to the success of the company is the operations team, building a community of drivers and passengers. If they’d simply built the technology and put it out there to see who wanted to use it, it’s very unlikely they’d be enjoying the growth they see now.
Projects will expand or contract to fill the time available to them. The initial concept for Lyft was originally scoped out as an 8-week development for a team of 5 (3 engineers, a designer and a product manager). One of the founders, playing devil’s advocate, said “what if you’ve only got 2 weeks to do it”. This forced them to really cut the concept down to a true Minimum Viable Product. They eventually got the first version built in 3 weeks (server and iOS app) – even today there are still several of their original requirements sitting at the bottom of their backlog unimplemented. The things you think will be essential parts of a service can often turn out to be unimportant for real users.
Team chemistry is essential. It would have been impossible to build such a complex service so quickly without fantastic collaboration. The relationships and collaborative working mode are more important than physical location – Lyft has been hiring top talent from around the world and sorting out visas and relocation to San Francisco afterwards. Sebastian was based in London when he was hired, their iOS lead was in Uruguay and the Android lead in Russia (the extreme time difference was sometimes an issue in the latter case).
What’s in the Lyft toolbox?
Like many successful development teams, Lyft use a lot of third party tools to help build their product:
Several open source libraries, Square was noted as a source of some high quality ones
Multiple server monitoring solutions, including New Relic and Circonus
Also, although they have built their own backend service, creating a highly responsive notification system was a challenge they solved with a combination of polling for updates when sending driver location, the Apple Push Notification Service, Google Cloud Messaging and a paid service from Pusher. However, the latter was initially a source of many crashes due to immature client libraries (Pusher only provide official support for a JavaScript client library, other platforms are community supported).
Sebastian’s desire for the tools space was very much in-line with our outlook in the latest developer economics report – consolidation. Fewer SDKs to integrate and fewer monitoring consoles to log into.
King for a day
Finally, if Sebastian could change just one thing about the platforms he works with, what would it be?
Better support for web/native hybrid app development (Lyft explored and abandoned that approach), with the Android WebView particularly in need of improvement, was a close contender but the top of the list for fixing was the Apple App Store review process. 5-10 days of waiting and they can see from their server logs that the reviewer doesn’t even login to the app with Facebook Connect before approving it. There must be a better way.
iOS is the best platform for generating revenue,
Android provides a better development environment
We asked developers to pick the top platform, among all platforms they have used or are planning to use, on a number of different aspects of mobile development such as discovery, learning curve and monetisation. We then compared how iOS and Android fare against each other, based on the opinions of developers using both platforms.
The outcome is a tie when it comes to user base, with developers’ opinions divided between the two platforms. However, iOS was ranked higher on 4 out of the six remaining categories, with a clear advantage on app discovery (50% iOS vs. 23% Android) and revenue potential (66% iOS vs. 12% Android). The perception that iOS provides better monetisation opportunities is well engrained with developers and is backed by Developer Economics 2013 survey data. App discovery has developed into a problem for both platforms given the size of their app stores, which now well exceed 700,000 apps. However, despite some initial complaints about the new curation model on App Store, the developer verdict is quite clear on app discovery, which goes to iOS. iOS also leads, but with a smaller margin on development environment and documentation & support.
Android has a clear advantage on development cost (32% Android vs. 14% iOS) and a small lead on the learning curve ( 26% Android vs. 20% iOS). However the total score for the two platforms on the latter two aspects was lower than 50% indicating that most developers that use both Android and iOS believe that neither is best in these areas. In fact 24% of developers among those using Android and iOS indicated that HTML is the best platform in terms of learning curve while 7% indicated that its Windows Phone.
For most developers, the platform perceptions boil down to a decision about which platform to prioritise, i.e. where to invest more resources and which of the two platforms to develop for first. Several other factors may come into play when making a decision on the “lead platform”, such as prior experience or local demographics, but it is fair to say that iOS comes out as the winner in developer perceptions. This is consistent with our figures on lead platforms: among developers using iOS and Android, iOS is the lead platform for 42% of developers, while Android is the lead platform for 31% of developers.
[doritos_report location=’DE13 Article – iOS vs Android shoot-out’]
Most app makers are not primarily in the game to make money. The primary reason for developer platform selection is not app monetisation, but reach; irrespective of platform, 54% of developers adopt a platform because of reach, while 43% cite low cost and 30% cite revenue potential. Moreover, out of the eight types of app developers we identified, only three segments (Explorers, Hunters and Guns for Hire) are directly motivated by money when committing resources to a new platform.
Among those of you that are in it for the bling, developer profitability is a hotly debated topic. Apple’s iOS is generally thought to support greater revenues per application, compared to Android, but the evidence is mostly anecdotal. Many stories of overnight successes circulate the internet, but it’s not clear if they are replicable.
[newsletter message=’Want more content like this? Subscribe now!’ button_text=’Jump In’]
To stay above the app poverty line you need to make a sensible budget plan for your app. This requires that you have realistic expectations about the costs and revenues that you can expect. Based on VisionMobile’s Developer Economics 2012 survey, we can now offer you an informed opinion.
