Posted by:


When “Write Once Run Anywhere” is done right it can produce applications that are “better” than native apps by targeting the highest common denominator.

by Shail Almog, CEO of Codename One

Some would claim that native is the best approach, but that looks at existing WORA tools/communities, which mostly target cost saving. In fact, even native Android/iOS tools produce rather bad results without deep platform familiarity. Native is very difficult to properly maintain in the real world and this is easily noticeable by inspecting the difficulties we have with the ports of Codename One, this problem is getting worse rather better as platforms evolve and fragment. E.g. Some devices crash when you take more than one photo in a row, some devices have complex issues with http headers, and many have issues when editing text fields in the “wrong position”.

There are workarounds for everything, but you need to do extensive testing to become aware of the problem in the first place. WORA solutions bring all the workarounds and the “ugly” code into their porting layer, allowing developers to focus on their business logic. This is similar to Spring/Java EE approaches that addressed complexities of application server fragmentation.

If you review most user feedback on mobile applications you will quickly notice that a company that releases applications often and fixes issues gets consistent 5 star reviews. The ability to provide a stable app across platforms is a much tougher nut to crack than most developers assume, bugs are remarkably portable even between programming languages. Being able to scale your development team to give fast response times to user requirements is a huge deal. Being able to use Google Play as a beta site for the more conservative (and slower to approve) iTunes is a remarkable benefit for any developer.

Codename One is relatively young, so we don’t have a blockbuster, multi-million downloads app that contains a large enough representative segment (we do have some huge customers and great apps so its a matter of time). However WAZE (recently acquired by Google for over 1b USD) was constructed with a WORA solution, has multi-million downloads and 4.5+ star reviews on iOS/Android. I’m not crazy about their UI (as a matter of personal taste) but I think it proves that a HUGE majority of users want a functional, stable, and fast app. The word native and its various interpretations are only a part of the developer lexicon and don’t matter as much to actual users.

Using the native platform has a huge conflict of interest problem, e.g. Google is very keen on developers building Android applications. However, it has slowly migrated new API’s into the Market app, which only enables them for Google sanctioned devices. This makes sense since vendors have been very slow at migrating to newer Android OS versions. However, this also means that non-Google devices such as the Kindle (and future Amazon phone etc.) wouldn’t work with those API’s. Thus, we have a situation where the platform vendor wants us to develop to his platform alone while, as developers, we want to have as many users as possible. Yes, iOS users provide better monetization but that might change in the future and as developers we have an interest in agility.

As a side-note, Google itself uses a relatively simple WORA solution when targeting iOS named J2ObjC its a great solution for porting libraries from Java to Objective-C.

In the past, the conflict of interest between the platform developer and the tool developer pushed many developers from Microsoft tools to Borland tools and later on to Java/Swing. I believe we will see similar trends as mobile platforms migrate towards the enterprise and we are already seeing such development with PhoneGap despite all its faults.

 

The Native Is Easy Myth

Often when I bring these things up, I get the strong knee-jerk reaction from the fans of native claiming that native is the best approach. This completely ignores the long-term complexities of building/maintaining complex applications across platforms. For example, a well known Google developer asked in a recent Google IO who in the audience understood the activity lifecycle, he then made fun of the audience members who raised their hands claiming that despite all his years in Google he still doesn’t get the activity lifecycle (I built a few VM’s in my life and I can attest that this is indeed a complex subject with many edge cases).
iOS is not much better, the compiler/runtime doesn’t protect you from basic mistakes such as wrong function arguments (function, not message), memory access issues etc. You need to maintain around seven splash screens for a typical universal app, which you need to update with every change to the first view and don’t get me started on provisioning profiles…

The main issue isn’t writing the code, it’s maintaining it in the long term, scaling it for additional team members, and working in a corporate environment. As the mobile market matures from app startups, who have relatively small teams of hackers, and moves to the enterprise the need to scale the development becomes far greater. Enterprise developers need the ease of Swing, Visual Basic or Powerbuilder when it comes to mobile development.

They also usually prefer vendor independence when possible. Just like Java EE, SOA or ESB took over backend development we will see mobile services take over the client side. Developers who didn’t work in demanding Enterprise environments or worked in a very specific niche in an enterprise sometimes claim, “well they should hire better developers”. But that isn’t really the issue, projects such as these are maintained over years when developers hand them off from one person to the next as manpower/positions change. In such circumstances tools must be very simple to enable efficiency.

 

Speed & Flexibility

Performance is a big issue with WORA solutions, unfortunately we are sometimes judged by the performance of a specific application which might not always be under our control. The Pareto principle applies here: by improving a very small section of the code we can improve everything. Most of our rendering code is native and if you have mission critical code you can always write it natively to reach the performance level you would expect from any solution. Unlike HTML5, which is effectively throttled by how fast webkit can reflow, in a proper WORA solution you are throttled only by the performance of the native OS.

Since we can invoke native code we can pretty much do anything we want within an application e.g. integrate with the Dropbox API via OAuth while using a native intent to invoke Dropbox on Android. This is actually implemented by some applications to enable easy usage of files within a mobile app, which is a painful experience on all mobile platforms.

 

Final Thoughts

My goal here isn’t so much to convince native developers to abandon native programming, but rather to change the basic “WORA as a compromise” attitude where native is considered as the best approach.

I think this approach rose from sub par WORA solutions and implementations, such as the much maligned Facebook app. Despite the fact that I think embedding HTML5 (as is done in PhoneGap) isn’t a very good approach, I think that in the right hands it can produce a decent app. As a developer I try not to blame my tools but rather look at how the tool works and try to understand if its limitations are inherent or temporary. I think most of the issues we see in WORA tools are being resolved and we will see far more WORA apps on the market in the coming years.

Posted by:


With the release of Android M, Google has taken some major steps to improve usability.  Some of the improvements will have positive effects on apps overall, and some will certainly help conversion.

As a users I am perhaps most excited about “Doze” which allows for the phone to have a deeper sleep when not in use. According to Google, this just may double battery life on some phones, depending on the usage pattern.  But of course, as a developer, perhaps one of the most important impacts will be on conversion rate due to improved permissions. Two major changes stand out:

1) Permissions happen on usage, not on install

Users who download an app may not be ready to make a decision on permission at the point of download or first open. Delaying that until they open the app and will actually use the feature (which is when it makes logical sense to ask for permissions), may just mean a lot more apps will get installed and opened.

2) Users control permissions

This is good news, as users who may get spooked about what they need to permit can now fully customize what they allow an app to do. This of course puts the onus back on the developer to entice the user to open up permissions as they get familiar with your app, but that is how it should work in the first place. It should also serve to cut down on rogue apps who grab unneeded permissions and spam users, which will help the market overall.

Check out the entire improvement session below. Well worth your time!

Posted by:


Windows Mobile has in large part been heralded as a pretty good and sleek operating system. Consumers however, have not caught on at all, and Microsoft’s market share in the mobile OS market has been minimal. With Windows 10 and some strategic moves, it could mean the return to mobile relevance for Microsoft for a couple of reasons. However, Microsoft also has a unique opportunity to truly change the game in the industry through adopting a simple measure in the business model and technology used.

First, the reasons why they may become relevant to developers and consumers again:

1. Windows 10 is the same on every platform

This means there is no need to maintain separate code for mobile, tablets and desktop.  Potentially this opens up for app developers in a much bigger way, as whatever they make will default work on any platform. Naturally developers would be wise to design to screen sizes and use cases (i.e. users on the go vs stationary etc), but the OS allows for this fairly easily.

2. Your Android or iOS app will work

Perhaps the biggest news is that with small modifications, Android and iOS apps will be able to run in a Windows 10.environment. This is huge, but is in line with Microsoft’s strategy of releasing their office and productivity apps on iOS and Android. What it means is of course potentially instant availability of equivalent app catalog to Google and Apple.

So, what’s still missing?

A well functioning eco-system means not only that an app can run on a handset.  There are still a few gaps we see that still need to be addressed:

The store:  Where will users be able to download apps?  Will they follow Apple and only allow it on the Windows store?  In our opinion (big surprise), we think this is a big mistake if that turns out to be the case.  Being good at software and platforms does not mean you’re good at retailing. And creating yet another mega marketplace where only the big boys can compete gains nobody. Our advice: Allow for anyone to distribute and sell Windows 10 mobile apps.

The business models: No news have come out in terms of any changes in how Microsoft will deal with in-app billing. Does Microsoft expect developers to integrate their proprietary payment SDK? If so, big mistake. Our advice:  Make the MS payment SDK available on OPFIab (formerly OpenIAB) and mandate use of OPFIab in apps run on Windows devices.

Why does this matter? Because most stores that hope to profit from the in-app revenue require the developer to put in a different payment SDK than Google’s. Adding payment SDKs is a big hassle and most developers simply will not do it. We’ve seen this even for stores generating millions of downloads per month that persuading app developers to integrate a new payment SDK is very, very difficult.

Microsoft is the organization with true market power to really catapult the adoption of OPFIab as enough developers would use it in order to have their apps available on Windows devices. This means Microsoft could truly break the Google Play chains and allow for the proliferation of a multi-payment SDK that works on a large number of stores – thereby enabling more stores to be created and be in the value chain. That would be a true win-win for the industry.

Posted by:


David Jones from Streethawk and Paul “The App Guy” Kemp are two very sharp minds in the mobile world. CodeNgo co-founder Chris Jones had a chat with both of them. The focus of course is about Alternative App Stores, and what alternative app stores can do for developers, but covers wide ranging topics from subscription models, China, payments and payment SDKs, pricing strategies and more.

For the App Guy interview, you can go on the site, and the interview with David Jones is below. Key takeaways are:

  • Utilities Apps are very well suited to many Appstores because they are globally in high demand.
  • These marketplaces are often easier for your App to be featured – so you increase user acquisition dramatically.
  • Cost per install campaigns (CPI) are now a more efficient method available in some of these stores. Run campaigns against a feature placement.
  • Apptoide allows users to create your own specialised store if you have a quality brand and a number of properties.
  • Managing feedback is critical, be proactive about that and use the ability in Google Play to respond or shift the conversation. Tools like HelpShift or Apptentive are examples of product that can help with that.

 

Posted by:


Games development can be fun. But fun does not pay the bills, if you intend to live as a games developer. The economic viability of being a games developer is constantly being questioned, and with millions of apps now available, should you be getting to mobile games development at all?

First comes the notion that only a few people pay for gaming content at all, and playing the ad supported revenue game, where millions of installs are required to make money, is not something most developers can play.  TechCrunch certainly feel it’s a market where only the big can play, where you need at least 10 titles (with $1m in budget for each development(!)) in order to “make it”. That’s of course if you aim to be in the top 10 (or 50) publisher list globally.

But there is evidence hinting that greener pastures are coming.  First, paid content is growing. 239 billion apps will be downloaded this year, and revenues are expected to climb to $99bn in 4 years. That is fairly significant (in perspective, the total console gaming market for 2014 was slightly less).

Second is that Android is becoming as profitable as iPhone. That is good news, as there are a lot(!) more Android devices around than iOS. Android LTV has jumped from 20% to 60% of iOS in one year.

In the end, it comes down to the fundamentals:  First you need a product that is of a very high quality (i.e. works well, loads quick, does not crash etc) and has a high entertainment value (somewhat hard to predict, but practice makes perfect. It took Rovio 51 attempts before Angry Birds).  Second you need to understand which revenue model works best. If you are starting small, then reading case studies like the one from Andrea Bizzotto is a good start. Case studies provide a great learning platform to figure out what works well, and some of the best highlight tricks from people who’ve driven millions of downloads.

Days When a Gaming Video Hit Top 10 Trending on YouTube List

Source: Google

It is no doubt that the games genre is becoming mainstream. Minecraft was the second most searched topic on YouTube in 2014.  There is a general agreement in the industry that gaming is moving towards mobile, so the potential for windfall is there.  Mobile games content revenue is currently outgrowing all other digital revenue.

According to various estimates, there are over 5m mobile app developers out there, perhaps as many a 8m. Only a few will succeed and make it to the big leagues. Less than 2% of college football players make it to the NFL as well. That does not stop players from trying. We think it’s a good time to be or become a mobile games developer – but you need to be as smart about your business as you are about the app. We’re here to help on the first part, the second part is all you.

 

 

Posted by:


Today we are speaking with Branislav “Banne” Gjorcevski, the CEO of IT Labs, a global technology company that offers mobile and custom software development and technology consultancy. They have been in business since 2005 and have the luxury of 100 team members. IT Labs is in the process of launching their own techcelerator and venture program for startups, allowing startups to tap into their very large pool of resources and strategic partnerships, including financial resources and different distribution markets.

CODENGO: What should mobile developers look for when hiring a good outsourced mobile app team?

BANNE: I think there are several factors to consider when deciding what outsourced team is right for you. They are, in no particular order:

  • A good team should strive for innovation. Latest UX, latest tools, lean and mean approaches–improvements, improvements, improvements.
  • Agile approach. Mobile teams should be agile–very adaptive to business models and work in sync with back-end teams. By nature, mobile development has a shorter span than the back-end development. But for a mobile team to be able to work in sync with a back-end team without any lag on either side–that is a great accomplishment, even for a fully in-house team.
  • Business mind. Having a team that understands both the business and the revenue model of the complete product is very important. It contributes to more efficiency, better productivity, and innovation.
  • Experience and price. Obviously, experience is always what each project needs. Experience allows a team to take into consideration its vast knowledge and variety of skillsets and price it accordingly.

 

CODENGO: What would you say is the biggest hurdle of mobile developers as far as teaming up with an outsourced team?

 

BANNE: There are few hurdles like scalability, communication, documentation. Not every company can have a team available as needed with the necessary skillsets and for a specific duration of time. That is why we partner with multiple teams to always have resources available as needed. Timing is everything.

You need a team on board now and fully staffed within days, not weeks. That requires a good communication strategy that places experienced resources to facilitate the communication between the teams. It’s vital to assign savvy project managers who do fast on-boarding, execute proper expectations management, and utilize suitable task management tools to automate the task handling and reporting as easily as possible.

Sounds very obvious–but it is amazing how important documentation is when it comes to multiple distributed teams, especially if they are in different time zones and when they speak different languages…crucial. A good business analyst saves the day!

 

CODENGO: What is the magic strategy for teaming up as an outsourced development team?

 

BANNE: The magic strategy is the one that is most adapted to the setup on each side. At IT Labs, we do that by aligning the goals and steps, identifying what resources are available on each side, and teaming up on both sides to achieve full team capability with flawless process handling. We then run that setup through a communication scenario for development and maintenance, then define/approve the teams and, of course, start the project.

We are fortunate enough to be able to handle a full project in house A to Z, but a hybrid approach is probably the best practice.

It-Labs-print-screen

CODENGO: What about pricing? We see a notion out there that outsourced development should be very “cheap” and that anyone can hire developers to build a mobile app…how do you respond?

 

BANNE: Just like with everything, you get what you pay for. High quality development has its price in every country, even in the most affordable ones. What we offer to our partners and clients is a full package along with the development team, which means they receive a suitable and adapted process, high quality standards, liability protection, vast knowledge and experience that comes from a lot of in-house resources, and a money-back guarantee. This kind of offering guarantees high quality deliverables within time and budget and with appropriate expectation management.

Posted by:


Articles on the profitability of app making never seem to stop. A barrage of data has been released lately that posts a picture that could be interpreted either way as an app developer. Games still drive the majority of the attention for app revenues and profitability, so naturally the focus is on this genre.

The downside of recent statistics from eMarketer is perhaps that only 33% of users in the US are expected to pay for apps this year.  However, this needle has not moved much over the years, and is not expected to move much. It is well known among games developers that the lions share of the revenue will come from a small subset of users anyway. eMarketer also points out that in-app purchases is the best revenue model – again, not a shocker.

On the brighter side, Android is seemingly catching up to the profitability per user compared to iOS:

Android LTV compared to iOS (Source DAU up)

This is good news given the staggering size of the Android market. Research by DAU UP, if accurate, shows to a 3x increase in relative ARPU in 2014, which if true, is quite staggering. More importantly though, the advertising costs on Android is 20-50% lower than iOS, proving that the ROI for Android is increasingly looking better.

So what does it mean for a games developer?  Tadhg Kelly, a consultant in this space, argues in a TechCrunch article littered with case studies that gaming may not be a high growth business, but that there is inherent potential in mobile gaming but that it is very much a hit based media business:

“Many of the big success stories of the games industry tend to come from nowhere before the facts are known. From Atari all the way through to Zynga and beyond, our history is littered with the unlikely gamble, the hunch and the “I just need you to believe” sort of moments that transform into billion dollar fortunes.”

Regardless of the stats presented and what you believe, there is no doubt the importance of mobile apps (and gaming) is becoming significant. According to eMarketer, games revenue steadily represents about 12% of total mobile app revenue, and the games market, and therefore overall market grew nearly 20% last year and will still maintain double digit growth for 2015. This is good news for all.

Posted by:


Today we spoke with George Christopoulos, founder of the SlideME app store. We asked him to share tips and strategies on how developers can can better understand the Android ecosystem outside of Google Play.

1. How should developers see the Android Open Source Project (AOSP) and how should it impact their development and marketing strategies?

Firstly, many developers are unaware that there are two flavours of Android that device vendors can leverage:

A.Most developers are aware of the Android that is bundled with Google Play Services and Google apps such as Gmail, Maps, Google Play, etc. that are proprietary apps and services to Google and thus cannot be open sourced and

B.The second is the Android Open Source Project (AOSP) as project name indicates is fully open source that device vendors can leverage for their devices without the licensing requirements or associated fees from Google.

As more device vendors naturally move away from other OS platforms towards Android, we are seeing exponential growth for AOSP devices without Google Play.

This direction is expected to continue due to Android’s success. In addition, since Google restricts which OEMs have access to its proprietary services, more and more devices are being introduced with Android AOSP and smart developers should be thinking about a two-fold distribution strategy:

1.Plan for targeting devices with Google Play if they plan to depend on the Google Play Services & their API’s,

AND

2.build their app(s) with SDK’s that are not dependent on Google Play Services for distribution to AOSP devices (that have no Google Play Services).

Fortunately, work has been done by the One Platform Foundation that SlideME and CodeNgo both support called OpenIAB, a single open source SDK to support In-app payments for multiple stores, including Google Play, Amazon, SlideME and any OpenIAB supported store. This dramatically simplifies supporting both flavors of Android for developers and gives them significant flexiblity in their distribution strategies.

SlideMe

 

2. What are some of the key markets, OEMs and/or Carriers using AOSP and what kind of consumer adoption are AOSP devices seeing?

Besides the huge volume of Android devices coming out of China with AOSP, we’re seeing OEM’s that target niche markets preferring AOSP as it provides them the flexibility to create their own experience with curated content for their target audience.

Carriers on the other hand, even though a small percentage of devices are without AOSP, all carriers within that country do not differentiate in their offering as they all provide the same content if they all serve the same Google Play store. Some carriers are now moving away from Google Play to be able to provide content they have control to curate for their subscribers with differentiated billing models (such as monthly subscriptions models that we are also soon inviting developers to opt-in to). In addition carriers will earn most of the revenues as opposed to earning some percentage with Google from the 30% withheld from developers.

Consumers admit preference to curated content stores like SlideME that are dominant today on AOSP devices, but many users express the problem with missing apps that we for example do not currently offer. It’s a matter of time before developers realize the AOSP opportunities and optimize their distribution strategies to the large amount of devices without Google Play.

 

3. What trends do you see in the marketplace that smart developers should be aware of?

•Go niche to differentiate from the rest of the pack and the enormous amount of apps that largely get lost within all the junk apps available in the apparently major store(s).

•Take advantage of any featured free options available to the extent the developer can handle the service requests

•Move towards implementing OpenIAB for in-app payments for multiple stores, including SlideME, Amazon, Samsung, and others.

 

4. What mistakes do you see developers make or challenges they should be aware of when it comes to monetizing outside of Google Play?

•Firstly, any apps distributed outside of Google Play looking to maximize their earnings potential need to choose an alternative for In-app payments to Google’s. OpenIAB is an excellent solution for both. In addition there are also many alternatives to Google Maps and Google Play Game Services that will function properly on both AOSP devices and Google Play licensed devices (see below).

•Lack of promoting their apps or mentioning their apps when available on other alternative stores that primarily drive AOSP (non-Google Play) devices when the numbers indicate that AOSP has >30% Android market share and climbing.

•Neglecting to localize their apps or even translate their app descriptions when the relative cost of doing so is very low in comparison to effort/costs of development.

•Large companies, tend to be the most uninformed about Android ecosystem and what AOSP is. We see many large companies making mistakes such as duplicate sets of permissions in their apps which cause all sorts of problems (even from Google Play devices). Indie developers tend to be more Android savvy. We tend to have a sweet spot for Indie devs, and are happy to feature their apps for free as they deserve that extra push. In addition, large companies assume all devices are Google Play enabled and wonder why bother distributing outside of Google Play. For example, one very large company we know tried Amazon and they have much better conversion compared to Google Play. Some developers also see more conversions and installs with their new apps from SlideME than on Google Play with the help of the SlideME free featured promotions we offer.

•Managing distributions is another challenge. Fortunately services like CodeNgo and initiatives like AppDF, supporting the many distribution channels (stores) can be simplified and managed at the same time. Something as simple as failing to upload proper screenshots can result in few returns at any store, as many users will skip right past an application that simply has an icon as a screenshot.

 

5. SlideME rejects close to 60% of the apps submitted to your store. What type of content is successful in the SlideME store?
Applications that are not just following trends, but provide original or unique functionality (even if only modified from some other popular application), tend to be the most successful. Many indie applications by a single developer are successful because they provide something new and have invested more than a few hours of time into developing the application.

Common or simplistic applications are not going to provide much success to the developer, particularly those that every new developer might have experimented with at some point (i.e. flashlights, tic-tac-toe, endless runners, snake games, wallpapers, 15-slider puzzles, etc.). These applications are a dime-a-dozen across all stores and devices; most people have had enough of them, and such applications are not going to really receive any additional exposure.

 

6. What mistakes do you see happening in Android?

There is an amusing one we very often see, mostly from the so called ‘security’ companies. Where editors mention another reason to not download apps from stores other than Google Play Store. The Google Play Store is the dominant store, and if you add to it the fact that their is no curation process on Google Play, (submit any app and its shortly available to all users), means Google Play becomes a risky source of apps. Not saying alternative stores are any better, but the ones that have a curation process in place and abide by it and spend quality time to test each app, are definitely a better source than Google Play’s.

Additionally, if a developer does choose to submit to alternative stores, why are they doing so without removing the Google Play dependencies. Why submit a demo or trial version of your application to an alternative market that links back to Google Play to purchase when said user on the alternative market cannot buy it? This is a common mistake that does not take much additional time to resolve before submitting to other stores. It doesn’t help the developer’s reputation, big or small, to limit its users; and in return does not help with that application being successful financially.

 

7 . If developers had to choose alternatives to Google Play dependent services, what options do you have to suggest?

For developers wishing to decouple themselves from Google dependencies, we have some options for them to review. At SlideME we welcome and approve any apps that are not dependent solely on Google Play to function. We approve apps that would also function as expected on AOSP devices.

Please see some of the services that we recommend below.

For in-app payments:
OpenIAB
Fortumo
Paypal
For Maps:
OpenStreetMaps
Nutiteq
Mapquest
For Cloud Messaging:
onepf.org/openpush/
parse.com
eclipse.org/paho/
autobahn.ws/
LVL:
SlideME’s SlideLock

Leaderboards / Gaming:
Scoreoid
Swarm
gamesparks.com
soom.la

Any others potential candidates are welcome to suggest their services to us to extend this list.

Posted by:


The first thing most developers think about when they hear the words “revenue” or “advertising” seem to fall in the same ballpark as the terms CPM and impressions. These old conventional methods of advertising are becoming more antiquated as new categories of applications arise. Ad pushing, interstitials, and smart-wall banner networks promise to draw in customer attention. And that is the very issue, they do just that. The old method of advertising is not only intrusive, but interferes with UI, app functionality, and affects the retention rates of your applications.

by Graham Beck, Beck and Beck LLC

Although users acknowledge the ads, they do not act on them and are bothered by their presence. These methods have a low fill-rate causing you as a developer to have a low average CPM and a bunch of angry users. On top of the root issue just described, depending on the category of your app (emoji, wallpaper, lost game, widget, etc) overlaying ads just seem to conflict with experience. The only alternative seems to attract revenue by creating a so-called “Freemium model” where users get an app for free with no advertisements but can upgrade to a premium or in-app product indirectly.

I am here to tell you that these are not the only methods out there to enhance your revenue.

Why data analytics are the next big thing

An entirely new method of advertising is conducted using data analytics. Unlike the ad pushing method above, data analytic SDK’s run entirely in the background of any application. The entire point of this method is to draw attention to the functionality of your app so your users enjoy the experience (not how many ads can be displayed on one page). Users don’t know they are being monetized and still enjoy the app without ads.

Data analytic companies are code based, meaning after SDK integration there is no UI change. If you used a conventional ad network, you would have to specify spaces for banners, and interstitials.

Data analytic companies pay competitive DAU’S (Daily active user) and for users who retain your app. This means that if a user installed your app not only will the user be monetized in the app (when using it), but even when the user is out of the app! This point alone attracts many wide-eyed developers as the revenue potential far exceeds the conventional method (CPM/Impressions). Since the data analytic SDK’s run in the background, they are also compatible with other methods of advertising. By integrating with a data analytics company, you are tapping into an entirely new revenue stream that would not have existed before.

Beck and Beck LLC Case study

When I started developing my live wallpapers, I used the conventional approach (integrating Airpush). Due to the conflict of interest between wanting to push ads and user experience my CPM was very low.

See the impressions vs CPM chart below:

Beck and Beck case study

From over 19 million impressions at a .18 average cpm, roughly $2,000 was generated. I turned to a location analytics company and now my apps make much more $40 per 1,000 DAU per month.

Aside from the high revenue turnout, my retain rate has increased by 20% (due to no ads, and my customers are happy).

If you are interested in learning more or connecting with a compatible data analytics company, contact us

 

Posted by:


Starting in January 2015, a fundamental shift will happen in the EU affecting all app developers. If you are doing business in the EU (as defined by an end user in the EU downloading your app), you will have to start paying VAT (value added tax, or sales tax, GST, whatever you may call it) on each and every sale. What does that mean to you as an app developer? While we are not tax experts, and this is not tax advice, we point out a few things you should consider looking into.

1. You will retain less revenue

The main effect on most developers, if your app store of choice has not started doing it yet, is that you will keep less of the revenue that you sell for.  If you sold for €0.99 in Germany for instance, the app store may have paid you 70% of that, or €0.69.  Now however, the app store will have to pay 19% of the end user price to the German government, leaving you with a net of €0.58 as a payout of the after tax amount.  Many app developers may have already experienced this from stores that are already enforcing VAT charges.

2. You may have to pay the tax yourself

If you have a PPD business model where the app store charges the user, or if you use an in-app billing SDK that the app store uses, you are generally covered as the app store is likely to take care of the reporting and payment of tax for you. Naturally you should check this..

If you however use a third party in-app SDK, the app store will most likely not be considered the entity selling to the consumer, rather you will be. The whole scenario is well explained by tax experts Bird & Bird:

Paying your VAT (Source: Bird & Bird)

In their “Pocket Guide to EU VAT & Digital Commerce“, they go:

“the contractual relationship could be as follows: The final consumer purchases the app via the app store and enters into a contract with the app developer and/or app store; the app developer concludes a contract with the app store provider, and enters into a separate contract with a payment processor (e.g. mobile operator/credit card company) which debits the final consumer the gross price for the app. It withholds a certain percentage of the gross amount and forwards this percentage to the app store provider and/or to the bank/telcom provider (if the final consumer pays through its mobile provider). The remaining amount is then forwarded to the app developer.

The supply chain is often long and can stretch across borders. In such cases, it can be challenging to determine the point in time when the services are actually supplied to a final consumer and the identity of the actual supplier in the supply chain who should be responsible for the VAT payment on that supply.”

What does this mean? Well, it means if you are using in-app purchases not supplied by the app store, you may be legally obligated to:

  • Register for VAT in an EU territory
  • Track and record all sales by consumer location
  • Pay VAT to that state on a regular basis for sales across the entire European Union

This can get further complicated if you use mobile carrier billing, such as Fortumo or Bango, as the carrier may be withholding VAT before paying the content provider (or the payment service provider), in which case VAT has already been paid – but if they have not, the responsibility may be on you. The key here is keeping good records and understanding what your billing partner can provide.

3. There is no escape

It does not matter where your business resides. What matters is that you are selling to European consumers.  So whether you are based in Brazil or Taiwan, if you are deemed as the one who supplies the service to the end user, you will have to register for VAT, and start paying it.  The good news is that you only need register and pay VAT in one country, as that country’s tax authority will then settle to other EU territories. However you will have to know exactly where your users have paid, so you can pay the right amount of VAT.  This information will likely have to come from your payment provider, whether PayPal, Amazon, Fortumo or others, or through tracking the country code of the users mobile phone, etc.  The Explanatory Notes from the EU provides a lot of detail about identifying the consumer location.

The problem gets even worse, in that IF you make mistakes, and classify the country where the end user resides wrongly, and a government comes after you for it (if they suspect you have used VAT rates in low VAT countries like the UK instead of high VAT countries like Sweden on purpose), you cannot rely on a third party’s information (see the Explanatory Notes above for more on this). So then what?  We could be looking at many developer headaches.  Of course, the chances that they will come after small companies is of course slim – but your best bet would be to play by the rules.

And while the EU is doing this now, expect this to happen in other countries soon. If 2014 was the year of mobile (or was it 2013?), 2015 may be the year of the tax lawyer.