June 14, 2018 - 3 comments

Animate common interactions with Angular Animations


Angular offers
@angular/animations package that enables you to write complex, hierarchical transitions in a declarative way. The package is still in the experimental state as of Angular 6, yet it’s totally usable, and it’s not like such fact has stopped us before, is it?

Low-intermediate understanding of Angular is assumed.

The very first animation

Well, there is no good way to describe UI animations with words so below I present to you an editable example. We have buttons that can change the Angular version number very rapidly, modeled after admin dashboard in Angular HQ 🌞.

I wanted to capture few nice things about Animations:

  • It’s simple to define multi-step transitions that look natural, just add more items to an array.
  • You can duly on computed values with *
  • Inserted and removed elements can be animated easily
  • With state(), you can apply inline supporting styles that are active as long as the specified state. They sit next to transitions and are grouped conceptually
  • Framework provides many common state change expressions like :increment

Why should I care?

True, we already have many ways of creating motion on the web and Angular apps support them all. Animations package seems somewhat redundant at first sight, but it exists for a good reason. It provides seamless integration of many animations with themselves and also with the framework. You can of course mix them with other solutions where appropriate.

Previously, to achieve hardware-accelerated motion you could use:

  • CSS transitions that offer a simple way of declaring basic, two-state changes with constant duration. You can make duration variable by binding to style.transition-duration but it feels hacky at best.
  • CSS animations - more complex, you can describe keyframe sequences, declare (possibly infinite) repetitions and so on but you can’t express relations between various elements of the page.
  • requestAnimationFrame that allows you to make imperative animations, and you certainly could use power of RxJS to create neat reactive animations but it will require additional glue to tie everything back into framework in many cases. (Nevertheless it’s a viable, novel solution for certain problems, greatly explained in this talk by Ben Lesh, creator of RxJS)

Angular Animations in a nutshell

  • It’s a bunch of functions that you compose in a certain way (a Domain Specific Language if you prefer).
  • Animations are triggered by changing value bound to @triggerName. They mix well with change detection, component lifecycle, and other framework concepts.
  • Can be externally disabled for whole element subtrees with @.disabled synthetic property. You can for example disable animations for initial page load and later transition between routes.
  • You can pass parameters along with state values and interpolate them inside animation definitions.
  • They offer callbacks named @triggerName.start and @triggerName.done that greatly improve over for example transitionend event.
  • You can save your declarations in separate files and reuse them in many components.

BTW

The official guide for animations was, let’s say, not sufficient, during Angular 5 era and before, so reading is discouraging. Animation parameters is one example of poorly documented, yet powerful feature.

 

Setup

There are some things you must ensure when setting up your project with Angular Animations

  • First of all check if @angular/animations package is installed
  • Import BrowserAnimationsModule in your AppModule.
  • Now you can add @-prefixed properties to your templates.

BTW

There is also NoopAnimationsModule for when you want to disable animations globally. Without importing either animation module any template with animation-specific symbols will fail to compile.

Wiring everything up

In the Component decorator you can pass an array of animation definitions. Most examples do it inline, but it can become messy very fast and it doesn’t support reusability, so we will go with the good practices from the start.

import { squash } from './squash.animation';

@Component({
 animations: [squash],
})

You can see a shortened squash.animation.ts file below. Basic animation usages will start with topmost trigger() containing array of state() and transition() functions that I’ll explain later in the article.

export  const squash = trigger('squash',  [
 state('*', style({
 'text-transform':  'uppercase',
 })), 
 transition(':decrement',  [
 animate('100ms', style({
 transform:  'scale(0.9, 0.9)',
 })),
 animate('300ms'),
 ]),
]);

Finally, you need to bind something to animation property. Value can be anything as long as it makes sense for the animation definition.

export  class AppComponent {
 version =  6;
}

<p [@squash]="version">...</p>

The DSL

import {  
  trigger,  
  state, transition,  
  style, animate, keyframes,
  group, sequence,
  query, stagger, animateChild,
  animation, useAnimation,  
} from '@angular/animations';

Whoah, it’s very intimidating at first and I probably shouldn’t have frightened you with this complete list of DSL functions, but don’t worry as you’ll only need to grasp 4-5 of them to begin with. I’ve grouped them into related groups for your convenience.

NOTICE

Some time ago there was another way of importing animation building blocks but it was removed as of Angular 6 and deprecated earlier.

One of the pain points of Animations package is that all of the above functions return internal metadata and sadly it won’t tell you much. The same thing is with overly complicated input parameters. That’s where tutorials come into play.

I’ve listed below some simplified definitions of most common functions in Typescript pseudocode. You can actually omit some things, for example treat some single-item arrays as just items, but they needlessly make everything harder to grasp.

trigger(name: string, definitions: Array<state() | transition()>)

It will be the outermost function you’ll use most of the time, at least at the beginning. It defines name of the property you will use to bind your state variable. trigger('example', ...) <=> <div [@example]=value></div> .

definitions is an array of composed state() and transition() functions. Conflicting definitions are evaluated from left to right.

state(name: '*' | string, style: style(), options?)

It applies inline styles when bound value matches name argument. Wildcard * always matches.

transition(stateChangeExpr: string | Function, steps: Array<Step>, options?)

Defines visuals that happen after bound value changes.

stateChangeExpr in it’s simplest form is a string in the form of fromState => toState, but there are some special rules. Keep in mind that state values are converted to strings before comparison.

  • <=> to defines two-way transition.
  • * matches any state.
  • void is a special state that means nonexistence. It’s something different than null (here we go again 🙄…). The elements are in this state before insertion into DOM and after removal.
  • :enter and :leave are quite handy shortcuts for void => * and * => void, respectively. You can pair them nicely with *ngIf and others.
  • :increment and :decrement are nice example of behavior that otherwise would be only possible with custom function. They match numeric changes, I’ve used them in an example at the top of the article.

In contrast to state(), applied styles are removed after animation is done, for example transition(..., [style(...)]) does nothing, because it lasts for 0 frames.

style(css: object)

It defines actual styles. css properties can be written in camelCase or dash-case. You can use value computed from the element with * - it enables for example expanding accordion menu. For example:

{
  height: '*',
  transform: 'scale(1.3, 1.2)',


  lineHeight: 3,
  'text-transform': 'uppercase',
}

animate(timings: string | number, styles: style() | keyframes())

First function in this listing that actually creates motion. timings is a number of milliseconds or string in format duration delay easing. Only duration is required. Parts of the format behave like CSS transition counterparts, but the order is different. In the basic scenario you compose animate() with style(), and transition happens from the state existing before animate() to the one specified with style(). You can chain multiple animate()together and mix them with standalone style() to create multi-step transitions. You can omit second argument in the last animate() to transition to styles declared elsewhere, i.e. plain CSS.

keyframes(steps: Array<style()>)

Instead of chaining multiple animate() together you may wish to specify many steps as an array in composed keyframes(). By default they will stretch evenly over duration of animate(), but you can override it with special style property offset taking 0-1 ratio value.

animate('300ms', keyframes([
 style({color: 'indianred', offset: 0}),
 style({color: 'cadetblue', offset: 1}),
]))

It's the same as

animate('300ms', keyframes([
 style({color: 'indianred'}),
 style({color: 'cadetblue'}),
]))

or

animate('150ms', style({color: 'indianred'})),
animate('150ms', style({color: 'cadetblue'})),

Random yet useful info

Endless animations

That’s a bummer with Angular Animations - there isn’t a built in way of declaring them, but you can emulate it in many ways, for example by declaring universal transition * => * and changing trigger in @triggerName.donehandler. I won’t go into details here but you get the idea.

Order of execution

Animations happen after things that trigger them. For example, when animating :leave state change, ngOnDestroy gets called just before animation starts. Similarly :enter transition happens after ngOnInit and whole first change detection cycle.

Animation parameters

Take a look at the following example. Template-style {{interpolation}} can be used to bind dynamic values, for example mouse coordinates. You may need to provide defaults as params key in - previously omitted - last argument to almost all DSL functions.

someControl: FormControl;

@HostBinding('@triggerName') animation;

handleClick() {
 this.animation = {
 value: 'state',
 params: {  
   offset: this.someControl.value,  
 },
 }
}

trigger('triggerName`, [
 state('state', style({  
 transform: 'translateX({{offset}}%)',  
 }), {params: {offset: 0}}),
]);

 

BTW

In Angular 5 and before, Animations were fully powered by Web Animations API, whose support is currently spotty. Dynamic features of Angular Animations still rely on this API, but it’s something out of scope for this article. There is a polyfill available if you need it.

That’s all

I hope that this article explained briefly the basics of Angular Animations. There are many more nice bits about this package, unfortunately scattered around many places. I highly encourage you to read API docs. Play with more advanced functions - I haven’t even touched query() and hierarchical animations. Check source code if you wish. Happy hacking.


Tomasz Błachut

 

Published by: admin in blog
Tags: , ,

May 14, 2018 - No Comments!

Hybrid vs native apps. What suits you best?

Choosing the best approach for an app development can be tough. Your users have to obtain the best UX possible, other way - they'll stop using the app and will probably never return.
In this article we’ll discuss pros and cons of a hybrid and a native app. At the end, you’ll be able to make the right call for your project.

Wander no more.

What is a native and a hybrid app?

Native app
is a software program, developed for use on a particular platform or device. A native app has the ability to use device-specific hardware and software. Such apps provide optimized performance and take advantage of technology (for example GPS).

Hybrid app
combines features of native and Web applications. As they work through Web technologies,  they seem more flexible and easier to update.

Three important issues you MUST consider when choosing between native or hybrid are:

  • the purpose of an app
  • the benefit you’ll gain
  • the budget


Cons and pros of hybrid apps.

Hybrid apps come with such drawbacks as:

  • Poor UX - creating a great UX when building a hybrid app is hard. You often have the one and only chance to make a good impression on the user, and you won't achieve a native-like experience with hybrid. 
  • Lack of native features - be aware that some features offered by Android or iOS won't be available.
  • UX problems and lags - a significant drawback, that can frustrate your user. And probably it will, as hybrid apps can be problematic when it comes to the performance.
  • Lower efficiency - they are considered as slower than native apps.

..and we jump straight into pros!

  • you may save time and money - as you won't need to develop different versions of an app for IoS or Android
  • development process is relatively easy - you won't need a big team of developers working on the project.
  • hybrid app is good for BYOD policy - it works on different platforms and is compatible with various devices.

Native apps cons and pros.

If you're not convinced whether to take your chance with hybrid apps, compare its characteristics with the native ones.

There are few cons that you should keep in mind:

  • they are considered as much expensive
  • the process of development is longer
  • the cost of app maintenance and app updating is also higher for native apps, especially if this app supports more than one mobile platform

 

But, if you choose to go with them, you can expect also..

..many good stuff coming.

 

  • native apps are more user-friendly - they provide better user experience and performance.
  • they get approval of the app stores and marketplaces - the users are assured about their safety, so they're more willing to explore the app.
  • iOS and Android features are available - developers are provided with all needed tools therefore the process is much more convenient.
  • internet connection is not always required - it's an important feature considering the fact, that often the user doesn't have an access to the WiFi.

What should you choose?

Take a moment and decide which works best for you. What are your project's resources and objectives?
Every type has its cons and pros, that's why you have to choose individually. If you want to provide the best quality, choosing a native app will be a good decision. As good as a hybrid app looks, it seems convenient and flexible only at the beginning.

Investing in better solutions eventually always brings benefits. Deliver best experiences and build great UX for your users. They will certainly appreciate it!

More detailed information about hybrid and native apps will follow in one of our e-books so stay tuned! 🙂 Got some questions in mind? Drop us a line at office@summer.agency! :).

 

Published by: admin in blog
Tags:

April 25, 2018 - No Comments!

Embedded systems development process. Step by step.

Before we begin my friend, with some obvious definitions, let’s start from the other approach.

Developing embed is like climbing a high mountain without trails. You see the summit that is your goal and you have to climb it with your partner, the hardware. Together you must make the way upwards. In well organized teams both partners help each other not because there is some obligation but because the cooperation gives more than hostility. On the way upwards, to obtain a perfect product, hardware is the one that’s slightly less flexible. It’s hardly modified and makes basis for software. Remember,  that without hardware, peripherals software cannot communicate with the outside world. Before starting, a predicted way to the top is pointed out as well as some stop points. For climbers that would be camps, for products that would be milestones. There is much more in common with hiking and developing products. There are unexpected problems like avalanches or hardware faults. Sometimes our estimated way is insufficient or unable to obtain, so there must be found a new one. I’d like to take you, my friend, on this journey with me. I will show you all my tracks and tricks on the way to obtain a perfect product. Ready? If yes, let’s start!

First, we must make some research where to go. Usually there is a meeting handled with a client where a main goal is discussed.

So how to get to a camp?    

After that meeting, there should be carried another one, but now the team involved in developing that product should also be present. It’s an internal meeting with a hardware engineer and at least one embedded software developer. Usually a mobile software developer is also there. On this meeting, the way to the top is discussed. Where to start and how. This is where engineering part begins. We take a map and plan our way. We point the most risky parts of development. Also, we set some milestones usually connected with functionalities and test steps. First stop will be our base and it’s usually the first prototype.

Acclimatization

Usually, creating the first electronic version of a product takes few weeks. So does it mean that embedded developers have nothing to do? Wrong! There are evaluation boards with microprocessors. If you have the right one you can start building your software. That boards have connectors to which peripherals can be connected just like in the finished device, so you can start writing your code. It’s like trekking to the first base. You get out from a plane or a bus and then you see...your mountain! So you see your mountain but it’s an inaccessible region. You must take your backpack and ramble to a place where you’ve started your journey. This is the moment when you can learn your microcontroller. Every manufacturer has its own product and support policy. Especially in a low level, so if it’s a new processor, the work must be done from the beginning. 

You have already written some code. Maybe you have set some peripheral drivers and the main loop outline when the first prototype arrives. It’s like setting a camp. You know, you have found the valley at the map and you seek for a good place but there is no such thing around? I known that from the embedded point of view. Useful things are patient and oscilloscope. Remember not to give up and check if a microcontroller do what we desire. Nothing can be left for later because there may be lack of water or because peripheral cannot work in the way we want it to work. This part must be done in the coordination with a hardware designer. If any hardware faults are spotted, they must be replaced in the second iteration.


We reached first base, what’s next?

Attack the summit? No, not yet. Now it’s a moment to explore the slope. Making progresses, testing abilities, writing drivers and the main program. We have all the components and starting from now, we have to make it work perfectly. Functionalities are being laboriously added. It’s like rigging and making camps on our way upward. No one can make this way fast, every step and every rig must be added carefully. If you want the program to work efficiently, it must be well organized. Similar situation is with the trail that must be set reasonably. In other way, it would be dangerous or the program will hang. Continuous tests are extremely useful.
Then you write software tests that continuously check if software has any bugs. They may be prepared by the main product developer but also they should be examine by a software engineer outside the project. 
They should start from the first day of developing.

The test shows lack of bugs and our software is ready..

Is it the end of our journey? No, it’s not! Now is the moment for testers that will use your device and tell you if there’s something to change or which parts are not intuitive. If a tester is not technical, the result will be better.
It's the moment of a summit attack! You are almost there! You’re tired, but you still strive for success. You go back to find that one line that make your code not optimized. It’s the longest part and it can be parallel to clearing stones. When it’s finished, the first release ends. It’s like achieving the goal, standing at the summit. Your work is finished. You made it.

The return.

After all you have done, you have to come down from the summit. How to do it? Usually in the easiest way. For developer, it means providing support after releasing the product: fixing bugs or adding new features. Nevertheless it’s a different story. Maybe next time I will bring it up. Here the research and development ends. Thanks for walking this way with me!


Goodbye my dear friend!

Published by: admin in blog
Tags:

March 22, 2018 - No Comments!

How the Iot Hardware Is Made

Have you ever thought of creating your own IoT product and bringing it to the market? If so, creating the electronic part of the project was surely one of the biggest issues. But did you find the solution to resolve it?

There are many firms on the market including startups, that don’t have the resources to work on the hardware area of their products. Many of them intent to create the whole project but they fastly realize that the process is much more complex and demanding that they thought before. What’s more, the feasibility stadium of ideas is often not appropriately analyzed, which provokes bigger delays and costs.

#1 Checking the feasibility of an idea

This is the first, extremely important phase when creating the IoT electronics. Without specifying whether given assumptions are technically feasible, you can’t begin designing the electronics. When you’re sure that the project is profitable and feasible to create, you may start working on the actual parts of the product, such as electronics. The first step is analyzing what are the requirements for certification. On this stage you have to find out what certificates your firm should acquire in order to legally distribute the product. Just remember, that depending on the usage and the destination of it, the requirements can be drastically different. The expectations are huge!
Remember, that all certification requirements should be included in the final project.

2# Working on the first iteration

Next, start with designing and producing your first prototype of the product. It’s worth to mention, that the preparation of electronics along with software may or even should happen simultaneously. Although it requires additional resources, it definitely lowers the time of producing the first prototype. Additionally, in case of any sudden issues to solve, there’s smaller probability that the project will be delayed or will get stuck. What’s more, all difficulties, that require dynamic introduction of changes can be resolved much faster and in a more efficient way.

3# Preparing prototypes

Preparing prototypes is the next stage when creating an iteration. The process begins with acquiring imprescindible components and establishing the pricing of elements. The list of all parts used during the process is called the Bill of Materials. On its’ basis we may create the first prototype that should be accepted by our client. After the first approval, the next stage should be preparing the PCB design project along with the product documentation, that must be also revised by a client. Moreover, at the same time the process of building the first archetype should start. It consists of smaller tasks such as: the revisal of the material list, ordering components and the PCB, gathering all required elements and at the end - building a prototype by combining all these parts together. The final work of this stage should result in a ready hardware prototype part, though without the embedded software.
As mentioned before, you may continue working on the required software which consists of several, smaller subsequents:

  • launching the programme environment
  • preparing the main algorithms
  • launching the necessary libraries
  • configuring peripherals
  • writing the program code

The last element should be debugging the code, which should start at the same time as launching the first, ready-made hardware prototype. As a result, the software development process should end successfully, through implementing the software on the hardware part of the prototype.

4# Launching the first prototype

When it comes to the stage of launching the first prototype of the product - it should end
with transferring the device to the customer for evaluation and acceptance. The client will be able to see how the finished device will work. It’s the most important stage of a client’s verification, because at this stage most comments occur. In the next step, after the evaluation of a potential solution, the prototype should be tested in accordance with the required certification process, analyzed at the very beginning of the project. This step completes the process of the first iteration. When the first prototype of the product is ready, it’s time to implement changes. Then the second iteration of the prototype begins.

5# Documenting and modifying

Next stage is the PCB modification and gathering the product documentation. Now you can begin working on the second prototype and you should pay attention to:

  • revising the components’ list
  • ordering all required parts
  • creating PCB
  • completing the components

During the second iteration, implementing changes in the software area can happen simultaneously with working on schemes’ modification. All corrections in software should be introduced before launching the second prototype, so after finishing the update of both software and hardware part, the device should be revised once again by a client. The final stage of the second iteration should rely on conducting tests, according to the plan. Usually, it’s the last step in the process of creating the IoT electronics.

It’s worth to mention, that in some cases, the project should be subjected to another iteration. The decision about introducing other modifications, should be made on the basis of a client’s judgement along with tests’ results. You should be aware that additional changes require time along with human and financial resources.

Published by: admin in blog
Tags:

March 7, 2018 - No Comments!

Women in Engineering: Why There Should Be More of Us

I was always encouraged to discover my abilities in fields I found interesting, and the truth is -
I have always been interested in how things work. My passion for technology started in school from a very prosaic reason - a broken computer. It was one of the triggers that simply made me curious about building and repairing devices. I followed the idea later on and began my studies at the University of Science and Technology. During the studies, everyone tried to inspire and motivate us - 17 girls out of almost 300 Electrical Engineering students. Many of us after graduating, chose the path of being a developer. I started to plan my career and look for opportunities. The more I’ve read, the more stereotypes I’ve found.

The changing perception of a female engineer

One of them was a conviction that it’s really hard to preserve that feminine aspect while being a female engineer. I’m a woman who likes soldering in high heels, so I believe there’s no such thing I can’t do while wearing a skirt.  
Many times I heard opinions of my female colleagues that were insecure of the other team members’ reaction. When I started my career, I came across nothing but admiration of my courage, my technical skills and ideas. Everyone was always open and glad to help, so we quickly developed an effective communication and a great relationship that lasts till today (sending love to our software embedded team!)
Another common issue is a matter of passion. Everyday I come across opinions that engineering is probably the biggest passion of mine. I’m a hardware engineer, but except diving into technical news and projects’ insights, I’m also crazy about cooking and dancing. So when I’m not at my desk right now developing products, search for me at dancing or cooking classes!

Unbelievable facts and statistics

Did you know, that only 9% of the engineering workforce is female? What’s more, the proportion of women studying engineering did not change since 2012! With the engineering industry facing a problem of finding qualified professionals, it is crucial to encourage future engineers to work in this industry.
As for outstanding skills presented by female engineers, the ability of quick learning and multi-tasking was mentioned many times by employers. They also consider diversity in their teams as a strong positive factor, that has an enormous impact on their employees’ productivity. And they’re right!

In our team, we exchange ideas on a daily basis, and the important thing is - we have different points of view. Such various opinions enrich the communication and are the key to resolve complicated issues. We perceive solutions in a different way, and at the end, we choose the perfect, most advisable one.

My advice to every woman interested in engineering?

The world is more and more open, people are always positively surprised and the possibilities are endless. Enabling women to meet their full potential in work could add as much as $28 trillion to annual GDP in 2025. Diversity is crucial for innovation: in a global survey, 85% corporate diversity and talent leaders agreed that a diverse and inclusive workforce is crucial to encouraging different perspectives and ideas that drive innovation.
Working in a tech environment gives you plenty of opportunities and makes you more creative every single day.
If engineering is your passion, go for it!

 

Published by: admin in blog
Tags: ,

February 15, 2018 - No Comments!

5 Golden Rules for Product Development

As you probably know, bringing innovative products to life and creating hardware devices is a complex task. It takes few months to make a perfect market research and analyze a demand for that product. Then it’s time to think how to generate a perfect solution and verify correct operation at the prototyping stage. And of course, it doesn’t happen in a blink of an eye.

A methodology of creating innovative products and services based on deep understanding of the problems and needs of the users is not a short-term process, and it needs a decent construction. Structuring to the process of design thinking let us solve complex problems by understanding users’ needs. What’s more, it allows re-framing the problem in human-centric ways, creating ideas in brainstorming sessions and adopting a hands-on approach to prototyping and testing. In other words, this structure lets us define our 5 golden rules of creating products desired by users, technologically feasible and economically justified. So how to design a great hardware for a product?


Creating a product -  step by step

  • Empathize. Innovation starts with empathy

New solutions are created mainly for people. That’s why the first point is to gain an empathic realization of the problem you are trying to solve. You have to conduct research to develop an understanding of your users. It is crucial to recognize the hidden and intuitive motivations that affect human choices and behavior. You have to know what your future consumers need and gain perfect knowledge about similar products. Which of them have not succeed? Why? What made the others succeed? Follow the “must-do” actions and avoid competitors’ mistakes.

  • Define the problem and get to know your customers

During the defining stage, together with your team you combine all your research and observe whether a problem exists. You need to check if your future client needs your solution. What’s the main value of it? Is the price affordable? Or will your customer use a cheaper product from your competitors? Try to frame the problem correctly so that you will gather more certain data and good solutions.

  • Generate the ideas and brainstorm with your team

This stage involves generating as many crazy and creative ideas as possible. Your team members have to ‘think outside the box’ to identify new solutions to the problem statement you’ve created. Remember not to ignore ideas that seem obvious or easy — they can turn out to be the brilliant ones, if only you focus on them. To finalize this stage, write down the best ideas and try to test them to find the correct answer.

  • Build a prototype which will meet the expectations of customers

At this stage you have to build real, tactile representations for your product. For now, don’t make things more complicated than necessary. Your top goal is to make a prototype that is visually ready to present the idea to users and quickly gather feedback on the solution. The final shape of your product needs to be designed and built according to the user feedback and with a particular focus on their tips or needs they’ve described. This brings us to another point…

  • Test the product and eliminate all the inconveniences

The stage of testing is extremely important and should not be overlooked in the course of the project. This is the moment of confronting the idea of a product design with its users. You have to prepare a well-working device. Feedback has the greatest importance at this stage because it enhances your involvement in the product growth. If the users love the product it means that it's ready to entry the market. But if they flag some inconveniences, it’s up to your team to get back to the third point and figure out new ideas for your users' satisfaction.

Published by: admin in Uncategorized

February 12, 2018 - No Comments!

Our Year in Review

May 12, 2017 - No Comments!

Monetizing your free app

Text by our friends from Gummicube – leader in providing App Store Optimization and App Store Intelligence

While every app developer wants to say they made a successful app, the fact remains that they still need to turn a profit. There are many ways developers can go about monetizing apps, and each strategy comes with their own form of success depending on the type of app. But how does a free app make money?

Apps can use a variety of options to improve their revenue stream, and the three most common forms of monetization are:

  • Advertisements
  • Upgrading to premium
  • Microtransactions

While these forms of monetization are the key to increasing any app developer’s bottom line, they still beg the question of how much money can be earned?

Monetization Broken Down
Even though the above methods of earning money apply to any form of “free app,” let’s look at one type of app fares. Mobile games, which are often offered for free, tend to make millions and even billions of dollars each year; while the games industry generated a little over $108 billion in revenue, mobile games accounts for over 54% and generated $59.2 billion.

While the exact numbers will vary from person to person, the average user spent around $35 on “freemium” games and apps in 2016, and that number is only expected to rise. Around 47% of the in-app purchases or premium upgrades people bought cost between $9.99 and $19.99, and around 6% cost between $0.99 and $1.99. For mobile games, however, around half their profits came from the dedicated players, around .15% of their users, who were willing to constantly spend to get ahead.

So how can other apps besides games put these monetization efforts into practice? Let’s break down each type of effort and how it can help app developers.

Monetizing with Advertisements
Advertisements are exactly what you would expect: banners ads or commercials that show up in the app. Ads can be:

  • Small, unobtrusive banners at the bottom of the screen
  • Pop-ups that show up every couple of minutes
  • Large videos that show gameplay or UI and more

The more clicks they get, the more developers earn, but too many ads will drive users away.

One way apps try to entice their users to stay is by including in-game currencies that often make viewing advertisements optional. In return for watching a 30-second video ad, the players will receive a small amount of the game’s currency, encouraging them to view the ads regularly. This in turn brings profit to the developer, advertisers and the users.

Upgrading to Premium
For many apps, free versions provide just a small sampling of all the features the app can offer. All other features are locked behind a “premium” paywall. So while a user could very well enjoy the app for free, the temptation to upgrade to premium grows more appealing the more they use it.

Often times, apps will offer free versions with advertisements, or premium versions without any. That may be the only difference, or one of several, but some customers will be willing to spend a dollar or two just to make the advertisements stop. The goal is to encourage users to upgrade to premium, not to pester them in to it.

Take, for example, Spotify – the app is available for free, and the unpaid version offers optimized playlists, recommendations, and full-length songs to anyone. However, there are some caveats: free users can only skip songs so many times per day, and short advertisements will play between songs.

As a result, Spotify sees a stunning 27% conversion rate, turning over a quarter of all free users into paying customers. Given that the industry average is closer to 4% conversions, Spotify’s success is nothing short of impressive.


Microtransaction and How They Work
Microtransactions are purchases made available within the app to provide certain enhancements or in-game currency at the cost of real money. The prices can start off small to nearly a hundred dollars for a far more significant amount.

Microtransactions are everywhere within mobile games, from casual phone tappers to the most intense of action games. “Candy Crush,” one of the most popular mobile games, earns hundreds of millions of dollars annually through microtransactions. They can also be seen frequently in mobile apps referred to as “gacha games,” short for “gachapon,” the Japanese term for vending machines that offer little toys in capsules. Players can slowly earn currency by logging in and completing events
over time, or they can spend actual money for a larger quantity at once.

Developers need to be careful as some apps that offer microtransactions have recently come under heavy criticism due to users spending large sums of money without the guarantee of succeeding, if your app is a game offering any sort of “loot box,” be prepared for the controversy.

Key Takeaways
Now that developers know the different forms of monetization, they simply must ask:

  • What kind of app are you providing?
  •  Is it one where a few ads on the side won’t interfere with the user experience?
  • Can you offer premium services without crippling the free version?
  • Would users be willing to spend repeatedly to gain new features?

Consider what services the app offers, and what it’s worth to the users. From there, developers will be able to figure out what monetization option is right for them.

Published by: admin in blog
Tags: