App Microtransactions: The Good, the Bad, and the Ugly

App Microtransactions: The Good, the Bad, and the Ugly

microtransactions-in-app-purchaseThe concept of app microtransactions is not foreign to consumers of mobile technology in the modern app market. Apps that include or require consumers to submit payment for additional features or add-ons have become the norm. This business model has grown organically as a result of users having a hard time deciding whether or not they should spend their hard-earned money on an app. By making an app free and offering the user the choice to pay for additional features as needed, the barrier to entry for new users to download and use an app has been greatly reduced. This model has its benefits, its downfalls, and its unsightly impact on consumers’ wallets.


The Good  

Developers have immensely benefitted from microtransactions. Developers can more easily test the waters of the market with their apps. Instead of overcoming the hurdle of figuring out whether or not their app is a good idea in the first place, they can create a slimmed-down version of it and release it as a free product. After it has been on the market as a free app for some time, developers can access the potential for the app to have continued success. If the app proves to be working, then they can take the time to implement the rest of the features and release those features at a cost to the current user base in a new update through a microtransaction.

Microtransactions have been most successful in the game app market. Games have an advantage over value product apps in that games are inherently more addictive and entice the user to want to win. Developers have a big opportunity here to add “pay to win” add-ons to help their users win by giving them in-game boosts. These boosts usually come at a small cost for small boosts, and can cost upwards of $100 for larger boost packs. This gives developers the opportunity to make more money than they would with the typical $1.99 to $9.99 price tag of most paid apps on the market.


The Bad

While this model benefits developers, it negatively impacts the quality of apps on the market by requiring a microtransaction to unlock more features. Apps are being released to the market that are not full featured and polished, leaving users with half-made apps and wanting more. While it may benefit developers to release apps on this model, it is unsatisfactory for consumers who look for apps to fit their needs but find that the apps lack the features they want.

It may be that you find a free app on the market that you really enjoy, but unless many others find the same enjoyment in the app as you, the developer might not release an update for it. You wouldn’t want to go out and buy a brand-new vacuum just to come home and find that the one you bought will require you to purchase two or three other attachments in order to vacuum in tight or high places when the packaging claimed it was compatible, right? Apps should not operate this way either, or they will continue to deter consumers from exploring and discovering new apps on the market outside of the mainstream apps that their friends and family use.


The Ugly

microtransactions-the-uglyAdditionally, apps that have success with this model are leaving users with the ugly truth that they will need to sink more and more money into an app to get the most out of it. This practice is particularly prevalent in game apps. As I mentioned earlier about developers having a good opportunity to make money, requiring microtransactions in order for the consumer to be successful in an app exploits the addictive nature of the game, and promises the user that by paying money, they will be able to win. Oftentimes these games involve high scores, and consumers will do anything to beat their peers in order to show that they are superior, whether they pay for the app or not.

Over the past few years, there have been many articles about children who are spending thousands of dollars on in-app microtransactions from games such as Clash of Clans, Candy Crush, Game of War, and others. A child in Belgium who was given a credit card by their mother to buy e-books racked up a total $50,000 worth of microtransaction charges in the game Clash of Clans. Another child in England spent $5,900 on the iPad game, Jurassic World, after memorizing their parent’s password for the App Store. While it can be argued that it is not the microtransactions’ fault for these incidents, it is obvious that microtransactions are enabling this behavior.

Microtransactions have their place in the app market when implemented with consumers in mind. Developers can use them as a tool to allow more freedom in the app-creation process. This way, developers will not be deterred from taking the time to make an app that will not be profitable. Making apps is not a simple process, and the reward of economic benefit helps developers feel better about putting forth the effort to make great apps. Microtransactions just need to be done right, and not with the intent to exploit the consumer. Consumers want to feel good about giving an app a chance and not feel like they are just going to be wasting their time by downloading a free app they can’t use. The amount that consumers can invest in apps should be throttled or deferred into donations for the developers to continue making worthwhile apps.

3 Tips to Start Using Motion in Design

3 Tips to Start Using Motion in Design

Motion connects the designers and developers who are working on a mobile application with its users. Scrolling, navigating through screens, and adding or editing content may all be inherent features of an app in 2017, but the app still needs to feel right. UX designers live for the challenge of making an app feel right to the user, and motion is one tool in their arsenal. As Shockoe tackles mastering this tool, here are three tips for how to start thinking about integrating motion into your designs.

Tip 1: Show the Relation

You’ve put in the work, made the sitemap, and even mapped out the flow. You know exactly how to get from Screen A to Screen Z. Do your users? It’s important to make sure your users will be able to navigate the app with the same fluidity you do. Probably the best option for ensuring this is one of the simplest: show your user where the screens are coming from.

Navigating from the leftmost tab to the one on the right? Show that by pushing your current content off-screen to the left, making room for the new content coming in from the right. Google Play Music is a fantastic example of how an entirely new page can originate from a single, much smaller element. It shows the growth of that element into a full page.

Tip 2: Don’t Lose the Users

This touches a bit on the last point, but it is key that you don’t confuse your users or lose them in a complicated motion. If you have too many elements moving in too many directions, or even one element moving too far, you may run into some problems.

An example of what to do and what not to do both come from different implementations of the same feature in different versions of the Android operating system. On devices that ran Android M, there was a hovering search bar at the top of the home screen. This was a great addition, bringing a Google search right to the forefront of the user’s most-frequented screen. As you might expect, the search automatically offered suggestions as the user typed.

On the newest Pixel 2, that search bar has been moved to the bottom of the home screen, just under the app drawer and just above the software buttons. A UX/hardware issue is solved here by allowing users to reach their search bar more easily, but a visual transition issue is created. When the user taps the new bottom-anchored search bar, it acts like before and is now on the top of the screen, populating your autofill search results. This is probably nit-picking and just requires some getting used to, but it makes the search bar feel like more of an “activation” and not a true, transforming element on the device’s screen. That takes away a bit of what made that simplicity in movement so special.

Tip 3: Have Some Fun. Find It, If You Have To

This point applies to everyone in design, but it holds special weight in designing motion as there is so much that can be done. This is more for your own sanity, but it’s very important in every project to have even a little fun, and not nearly enough people value taking a moment to do so. A solid check for this is looking inward and thinking about what you would want to see an app do.

Take 15 minutes, grab your notebook and a pencil, create some sketches, and just … go with it. Look at what’s been done in other apps, what hasn’t, and find what works for you. Don’t limit yourself to the mobile realm for inspiration; consider television shows, video games, etc., as well. The kind of work we’re most proud of is typically the work we enjoy making, so be sure to explore every corner of your creativity when designing motion.

So what are your thoughts?

Hopefully, these tips have helped you start thinking about the ways you can use motion in your designs. In this post, we touched on the basics of motion; we look forward to expanding on these ideas in a future post that dives deeper into the nitty-gritty details on how to make motion work in your apps. As you start integrating motion into your projects, reach out and let us know what you think, if you have any thoughts to add, or if these tips have helped you out in any way.

Editor’s Note: 

Want more tips on Design? Check out our most recent blogs:

10 Commandments of Designing for Accessibility Every Designer Needs to Know

How to Apply Minimalism to Complex Apps

Profiling Titanium: Getting a picture of the Kroll toll

Profiling Titanium: Getting a picture of the Kroll toll

As cross-platform developers, we all know that maintaining speed in a complex codebase is of paramount importance. When you’re adding layers of abstraction to your code in hopes of being able to share large portions of it across disparate platforms, the little steps you have to take to synchronize your common code with the underlying platform specific code can quickly add up to a massive slowdown that leaves you with an application that performs and feels no better than a mobile web application plopped into a WebView.

The Kroll Bridge

Titanium effectively acts as a three tier framework. At the lowest level, there is a layer of native code used to implement core application functionality. These are your views, your HTTP clients, and your other pieces of code that reach out and allow you to interact with device features like the camera and geolocation service. On top of these platform-specific native layers lies a platform-specific bridging layer, which allows you to abstract away the complexity of these native objects and translate them into Javascript-land objects (called proxy objects). Finally, on top of this bridging layer lies your application-specific Javascript code, which is where the bulk of your application logic will reside.


Titanium’s abstraction and bridging layer is known as the Kroll Bridge, and it represents the single biggest bottleneck in a Titanium application. The Kroll bridge is exactly what it sounds like, it’s a connection between the native objects in your application provided by the Titanium SDK and the Javascript proxy objects that stand in their place within your Javascript code. Every time you update one of your proxy objects, the Kroll bridge gets to work synchronizing your changes to the native object. Because of this automatic synchronization logic, it’s easy to make a huge number of Kroll calls without really recognizing what you’re doing, which leaves you with an application that has no obvious performance issues (from a code perspective) that has distinct slowdowns when placed on a physical device.

Acknowledging the Kroll cost

Titanium provides various methods of sending data back and forward between your Javascript code and your native code. For the most part, these can be divided into the categories of bulk operations vs sequential operations. Going in to this blog post, I had intended to write at length about the virtues of batching your calls and minimizing your Kroll crossings, however it seems like there may be more nuances to the performance concerns in Titanium than I had thought! For the purposes of this blog post, I’ve taken a look at how long various operations block the Titanium thread.

I’ve prepared a couple of minimal test cases, with built-in timestamping and simple profiling code, so feel free to test these cases on your own devices! For each of these tests, we’ll run some operation 1000 times and take the difference in milliseconds between the start of the operations and the end. Note that this testbed only takes a look at how long different operations tie up the Titanium thread. Many of these tests tie up the UI thread for a substantial amount of time as well, and will cause the app to become unresponsive. The UI thread performance of these tests are outside of the scope of this blog post, I’d like to circle back in a few weeks and take a closer look at the UI impact of these tests as well.

I ran all of my tests on a Nexus 5 running Android 6.0 Marshmallow and an iPhone 5 running iOS 9.1. I ran six trials of each of these tests, and averaged the results. I’ve published the test code on github. Take a look, give it a clone, and follow along on your own devices.

Creation arguments vs Create then set

Titanium provides factory methods to create proxy objects, which allow you to interact with native objects that you may need multiple instances of. Optionally, these methods accept a creation dictionary describing its initial state. Of course, you can just make the proxy and then configure it later, what’s the difference?


On iOS, this behaves largely as expected. Creation with arguments returns a little faster than the creation followed by sets. On Android, however, in addition to being substantially slower, the creation dictionary actually slowed the creation process down!

Sequential updates vs applyProperties

Similarly, Titanium provides both individual property set APIs as well as a bulk application API. Take the following examples:


Oddly enough, we observe the opposite behavior here from view creation! Android performs as expected, with the bulk API yielding better performance. iOS on the other hand runs quite slowly, and the bulk API is slower than the sequential sets.

TableView population

The table structures in Titanium also provide bulk or individual modification APIs. Consider the following examples:


Finally, an expected result! The bulk population API is massively more performant than the individual population API. Android is still a little slower than iOS, but that is mostly expected.

View Removal

When flushing the views within a hierarchy, you can either loop over the children array or call removeAllChildren.


Another API that performs differently on iOS vs Android. On iOS, the call to removeAllChildren is almost immediate, whereas on Android the call takes even longer than looping over the entire child list and removing them individually.

Event Firing

Titanium exposes a built-in eventing API used for communicating between native code and Javascript code. Additionally, Backbone exposes an eventing API for communication between Javascript objects. I frequently see the Titanium eventing API repurposed for use in Javascript-land communication, let’s see what the impact is.


Another substantial difference. Backbone events perform consistently (and impressively well!) on both platforms, whereas Titanium events are much slower on iOS, and are a little slower on Android.


The clearest take-aways from these tests are that one needs to be much more careful while modifying the view hierarchy on android, that Ti.App events are quite slow, and that there isn’t a one-size-fits-all performance solution for Titanium. There’s no magic bullet that you can adopt in your codebase and not have to worry about platform-specific performance issues. Android’s slowness when handing creation dictionaries and iOS’s aversion to applyProperties makes it more difficult to write platform agnostic performant code. That being said, in the general case, applyProperties is still worth using, because of the small performance hit we took on iOS and the performance bump we get on Android (which is usually the issue from a performance perspective).

At the end of the day, there’s no substitute for profiling your application and making use of the platform-specific Alloy preprocessor directives (OS_ANDROID, OS_IOS) to deal with platform-specific performance issues. And now that we’re armed with concrete data, we’re ever so slightly better equipped to do that!

Know Your Business to Know Your App

For a moment, imagine if you owned a hotel chain. If you were going to create a mobile application for phones, should it make the focus on transactions? Should it make the focus doling out coupons and discounts to would-be customers?

You’d think so, right?

Not necessarily if your are the Ritz-Carton Hotel Company.

While the luxury hotel chain’s App does do those things, they certainly are not the focus of the marketing campaign or of the the mobile application itself, according to a recent announcement by Ritz-Carlton. The company has unveiled a new mobile application for Apple iOS and Android smartphones which provides more than just standard hotel searches and reservations. The Ritz-Carlton App highlights a feature for hotel guests called “Presidential Tips” in which Ritz-Carlton president Herve Humler shares his favorite spots, features and unique touches of each and every Ritz-Carlton Hotel from their chain of hotels around the world. It’s like a guided tour by the president, available for every guest in every Ritz-Carlton hotel, available at all times.

Brilliant, right?

“In my role, I am fortunate to be able to visit all of our stunning locations around the world,” said Humler about the App. “I want to enrich the Ritz-Carlton experience for our guests further with details about the things I have found to be quite unique and memorable in my travels. With The Ritz-Carlton App I can now do that very easily and in real-time.”

For even the most seasoned and pampered of luxury travellers, staying at a Ritz-Carlton is still a special experience, so allowing their exclusive clientele some VIP insider information delivered directly to their smartphones can only enhance their experience and will only increase the guest’s likelihood of sharing that experience with others.

The value of the Ritz-Carlton brand is in its luxuriance, its privilege, its uniqueness and its cultural and historical value for each of their properties, sharing those details can be difficult for a fully functioning hotel, even one with the level of service that even Ritz-Carlton affords. But the mobile application has made it very easy to provide more service and enhance the experience while tying right back into the core identity of what Ritz-Carlton is.

This mobile application ties in nicely with the overall exclusivity and luxury of the brand, while giving users reason to continue to use the App as they travel from one city to another to learn more about the company’s offerings, maybe those users will even find a deal or two along the way.

Even luxury travellers like a deal now and again … right?

What is unique about your organization or brand? How can you use that differentiation to your advantage through a web or mobile application? Can Shockoe help you uncover and utilize those key distinctions for your own mobile or web application? Please let us know in the comments, we’re here to help!