How do mobile Bitcoin Wallets work? – Blockchain Technology [Part 1]

It is hard to find someone interested in technology that has not heard about Bitcoin – a digital currency. Or better, – cryptocurrency that is considered a payment medium of tomorrow. As more and more online and traditional businesses start to accept payments in Bitcoin, a Bitcoin Wallet – a type of a blockchain app, comes in handy. In this post, I will tell a few words about it and its features.


“The blockchain allows our smart devices to speak to each other better and faster”

— Melanie Swan, the Founder of the Institute for Blockchain Studies


What is a mobile cryptocurrency wallet and how to get one?

In a nutshell, it is an app that gives you access to the Bitcoin wallet address and therefore to your money. To get a wallet, all you have to do is to go to the Google Play or App Store and install one. If you have trouble choosing one, I can recommend Blockchain Luxembourg app [download for Android] & [for iOS devices]. It is very user-friendly due to its good design and simple navigation. You just set up your account. Then you are ready to receive and send funds in cryptocurrencies like Bitcoin and Ethereum.

If you’re looking for mobile app development for blockchain purposes, keep in mind it needs to result in a secure and stable product. That can be done only by a highly-skilled team of developers. That must be guaranteed with best standards and procedures. Mood Up team is the mobile apps software house, that you should check out.

Utilisation of the QR-Code technology for the sake of super-fast blockchain transactions

To make transactions much simpler, most of the wallets integrate the QR-Code technology. So there is no need to provide recipient address and amount manually when sending funds. All you have to do is to scan the QR-Code of receiver’s wallet address and you are good to go.

Technical side of a mobile Bitcoin wallet and its security for blockchain transactions

In short, a Bitcoin wallet stores private key. It is needed to access the Bitcoin address of your wallet and to sign every transaction. But how is your money protected if you don’t need to provide the key every single time? Well, in this case, you should ensure an appropriate level of security to prevent unauthorized usage. You can set up a pin code which you have to enter every time you open the app. Moreover, some other apps offer email verification for every transaction.

How does a mobile wallet differ from a desktop one?

Mobile Bitcoin wallets, due to the limitation of mobile devices, do not download the whole blockchain. It’s because it would consume a significant amount of phone memory and mobile data transfer. Instead, it just gets a very small part of it needed for performing the transaction.

And that would be enough for a quick introduction to the mobile cryptocurrency wallets. I don’t want you to feel overloaded with too much information 🙂

In the next part, we will take a look at the underlying technology – the blockchain. And we will focus on blockchain applications that go far beyond cryptocurrencies.

How to code (pt.1): RxJava + Retrofit

RxJava is an implementation of ReactiveX library for observable streams of data or event by using combination of the Observer pattern (read more). You will find more info on Retrofit (here).

I would like to show you how to call RestFull API enpoints using RxJava and Retfrofit 2.0. We are going to show you how to switch Retrofit’s Services method to RxJava Observable as well.

RxJava and Retrofit in practice

Before we get started, let’s add needed dependency to your gradle:

compile ‘io.reactivex:rxandroid:1.2.1’
compile ‘io.reactivex:rxjava:1.1.6’

RxAndroid included classes to RxJava that makes writing reactive components in Android applications easy.

After that add retrfoit dependencies:

compile ‘com.squareup.retrofit2:retrofit:2.1.0’

If you are using GSON please add converter for retrofit. Converter is needed to deserialize HTTP bodies into your custom class model. If you are not using it Retforit deserilizes HTTP bodies into OkHttp’s ResponseBody.

compile ‘com.squareup.retrofit2:converter-gson:2.0.0-beta4’

Here is a list of official converter modules provided by Square:

  • Gson: com.squareup.retrofit:converter-gson
  • Jackson: com.squareup.retrofit:converter-jackson
  • Moshi: com.squareup.retrofit:converter-moshi
  • Protobuf: com.squareup.retrofit:converter-protobuf
  • Wire: com.squareup.retrofit:converter-wire
  • Simple XML: com.squareup.retrofit:converter-simplexml

You can create custom converter yourselft by using Converter.Factory interface.
Next dependecy will help us return Observable object from Services:

compile ‘com.squareup.retrofit2:adapter-rxjava:2.0.0-beta4’

Thanks to that we have defined Service.

public interface APIService {
@POST(“list”)
Call loadCar();
}

In order to switch RxJava observable only one change is needed:

public interface APIService {
@POST(“list”)
Observable<Car> loadCar();
}

 

Now let’s modify your Retrofit Builder and add CallAdapter and ConverterFacvtory:

public Retrofit provideRetrofit(){
return new Retrofit.Builder()
.baseUrl(“http://api.geo.org/”)
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.addConverterFactory(GsonConverterFactory.create(new Gson()))
.build();
}

Right, now let’s move to some examples, shall we?

Example 1

We can start and call first Restfull API method with RxJava. Let’s begin with creating simple example that will provide object car.
We are about to do some simple activty where we have included APIService object already and are ready to call loadCar using RxJava.

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe();
}
}

Now we want to call asynchronous task. In order to do that, we have to use subscribeOn(Schedulers.io) to execute the observable on a new thread.

If we want also to get result in main UI thread, we have to use observeOn(AndroidSchedulers.mainThread()) which means that result emits through on the main UI thread.
subscribe() method is kind of trigger. If you don’t call it the request never executes.
If you take a look closer to subscribe method you will notice that there are more overloaded methods. I prefer to use subscribe method and handle errors. I will explain this below.
Let’ modify our request and add to subscribe method parameter Subscriber.
It should look like that:

public class Activity extends AppCompactActivity {
APIService apiService;
@Override
protected void onCreate(Bundle savedInstanceState) {
apiService.loadCar()
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(new Subscriber<Car>() {
@Override
public void onCompleted() {
}
@Override
public void onError(Throwable e) {
}
@Override
public void onNext(Car car) {

}
});
}
}

There are couple of important things. Let’s start from onNext method. That method provides you with response for loadCar request, in our example that is object Car and immediately method onComplited executes.

onNext method calls everytime unless you have kind of error, for example JSONException, IOException etc. In this case method onError called instead of onNext() and onComplited doesn’t execute.
There are couple of cases to execute onComplited and onNext instead of onError when you have error. But that is subject for next tutorial.

Example 2

Let’s see what happens when we use subscribe method without parameters. We are going to resource Observable and find couple of overloaded subscribe methods. Let’s check subscribe() method:

public final Subscription subscribe() {
Action1<T> onNext = Actions.empty();
Action1<Throwable> onError = InternalObservableUtils.ERROR_NOT_IMPLEMENTED;
Action0 onCompleted = Actions.empty();
return subscribe(new ActionSubscriber<T>(onNext, onError, onCompleted));
}

On the surface everything looks pretty nice. Above we have three Action object for each action in our request. But what is weird is static value:

InternalObservableUtils.ERROR_NOT_IMPLEMENTED.

Take a look closer, In InternalObservableUtils class found:

public static final Action1<Throwable> ERROR_NOT_IMPLEMENTED = new ErrorNotImplementedAction();

Implementation class ErrorNotImplementedAction with method call will throw exception:`OnErrorNotImplementedException`;

public void call(Throwable t) {
throw new OnErrorNotImplementedException(t);
}

Final note

So if we subscribe to observable using subsribe() (method without parameter) it will work fine. But as I wrote above, it is possible to get error which is handled by onError method. In this case you will have crash because of throwing exception OnErrorNotImplementedException.
We should handle error in our side either by implementing onError action or providing Subscribe object.

Hope you enjoyed this coding tutorial, you can expect more in the future.

What are the costs of making a mobile app?

When thinking about developing your own application, one question will surely occure: ‘how much will it cost to build a mobile app?’. It’s only natural and we’ve received this question a lot from our prospective clients here at Mood Up Labs, so we’ve decided it’s high time to put some light on costs of making an app.

Costs of making an app

As you propably are aware of, costs can vary. That’s why it is simply impossible and more importantly not wise to just put the price tag on an app. Instead of that here are some factors that have direct influence on costs of an app:

  1. Your priorities
  2. In-house or Offshore
  3. Devices and platforms
  4. Design
  5. Features
  6. Maintenance
  7. Testing
  8. Marketing

Let’s explain all of the above in a few more sentences.

1. Your priorities

First of all you need to be honest with yourself, a golden rule to follow in app development (but not only) lies in the picture below.

mooduplabs-good-fast-cheap-triangle

You can choose only two attributes: high quality – cheap – fast.

If somebody tells you that your app can be made day before yesterday, it will fulfill your needs and you will still have money in your pocket is full of… let’s just say he might be talented seller but definitely not honest one.

When something sounds too good to be true it usually is. That’s why your priorities are crucial. You know best how much time, money you can spend and what results are you expecting.

2. In-house or Offshore development

Another factor to consider is whether you can delegate a team of developers to build an app inside your firm or you want to hire somebody to do it.

Offshoring is well known practice to cut costs and it’s derivative – nearshoring is what we strongly believe here at Mood Up Labs and from our experience is highly effective.

With travel distances within Europe and ways to communicate avaible, nearshoring is almost as effective as in-house development and far more cheaper.

3. Devices and Android or/and iOS platforms

With the amount of devices out there, you need to be specific who you want to reach. And here are some things about choosing the right platform to consider.

4. App design

The goal is to make your app beautiful. User Interface is one of the most expensive parts of your app, if done well. It’s because outstanding UI cannot be just beautiful, it has to be useful. After all you build your app for users, so User Experience plays huge role in it’s success.

5. Features

There is not such an app that can do everything, yet many have tried and failed. More features won’t save your app. The features you want to add to your app should be clear right from the start so that you can focus on them. After a while you will be able to decide which are the most important or which ones should be added.

6. Maintenance

App isn’t just fnished after realease, it’s a process. At first you will be able to make some improvements after user’s feedback. After that you need to remember that each new version of the app or Operating System will require bug fixing and updates so that your app will run smoothly.

7. Testing an app is very important

Whole purpose of testing is for you (your users) to be satisfied with how the app works. Costs will rise with the amount of testing, but testing procedures play major role in app success.

8. Marketing

Finally, your app is ready. Now you need to decide how to monetize it. There are several ways to reach potential users and that should also be considered as cost of building an app.

Conclusion

Remember that estimating costs of building an app is far more complex than simply v1.0 budget. If you are really giving yourself a chance, you need to see beyond that. Take factors described above under consideration and it will help get you started. If you hear from someone about the price without asking detailed questions, be sure you’re talking to newbies and getting into trouble.

Should you have any questions, Mood Up Team of mobile experts will be happy to help.

Why nearshoring in Poland is a good choice?

Growth and development of bussineess means facing a lot of challanges. One of them is definitely deciding how much investment you can put into developing projects. Nearshoring in Poland allows to get the job done and cut the costs significantly.

When developing in-house team to certain projects is simply too expensive in current situation, the solution is easy: you find somebody to do this project for you for lower cost.

That’s why terms like outsourcing, offshoring are so popular right now. I would like to describe slightly different, efficient way: nearshoring, particularly in Poland.

What is nearshoring?

Nearshoring is derivative of offshoring as you’ve already probably guessed. It means outsourcing processess to companies in nearby countries, very often sharing a border with the target company.

When it comes to Europe, it’s safe to say that even countries that don’t share same borders can nearshore, e.g. company with headquarters in London can easily cooperate with company in Poland, even though it’s different time zone. Distances aren’t that big to become a problem – it’s just 2 hours flight.

Why nearshoring?

Nearshoring has quite similar advantages as outsourcing and offshoring:

  • Lower costs – it’s plain and simple and most important advantage. Whether we talk about production costs, research, labor and living costs, you name it.
  • Much larger talent pool – you can hire professionals that work at the same quality standards as in your country.

But there are some advantages unique only for nearshoring:

  • Same time zones (or similar as I explained before) – no more pulling an all-nighter to consult the progress with company on the different side of the globe.

    Employees will appreciate it and the risk of staff-burnout drops significantly. And you won’t have to worry about quality of code caused by bleary-eyed developer on graveyard shift.

    By eliminating time difference problem you will also gain optimum time-to-market schedules and you can focus solely on developing your product.
  • Few cultural differences – the same continental region means fewer cultural differences you will face (check the video below, perfect example of this is: how an European can know when Japanese people want to ask a question about your presentation, because they don’t rise hands. Answer? Easy, it depends on how bright their eyes are).

  • Still cost effective
  • Faster problem solving – when problem occurs partners can collaborate faster and easier to solve it. There will be no unnecessary delay caused by different time zones
  • Proximity – short distances allow to more frequent and less expensive face-to-face meetings and that will definitely boost productivity of the collaboration. It will also allow your full involvement. Here at Mood Up we are keen to send out our team members to the client’s headquarter. It’s often important to work closely together at certain stages of projects.

Why nearshoring in Poland?

Moving your IT processes to Poland is a smart move. The population of Poland is larger than Scandinavian countries combined. Every year over 40,000 Polish IT engineers gradute.

When it comes to new technologies, Polish engineers are considered one of the most competent in Europe. Thanks to European Union and Schengen area membership labor and information can be freely exchanged.

Polish culture is European and Poles have no problems in adapting to other countries mentality. They can communicate in English well.

Another important factor is that Poland is accessible from every major European city within 2 hours and prices are very competetive.

Polish economy is described as the one showing constant growth, high level of trust and low level of corruption. What can be said about this country is that it is stable both eonomically and politically.

All these factors ensures stability, flexibility and scalability which makes locating IT processes in Poland very attractive.

Conclusion

While growth of business means more and more challanges, offshoring is one way to be able to reduce costs. Nearshoring is very interesting and promising alternative. Position of Poland makes nearshoring here really beneficial for companies from all over Europe

Powerful Designers & Developers Mix

Collaborate more, communicate more – this is the most important motto of modern product development life cycle – very different to what it was in the past. Days when roles of designer and developer was so clearly separated from one another are gone.

We need to put them next to the same table and let to work as one man. This opens a world of opportunity to improve and speed up submitting finished product to the store.

 

 

How close cooperation between designer and developer can shorten the development process?

#1 Instant problem solving

In Mood Up Labs we’ve noticed that pulling conversations out of text barriers and even digital calls increased our productivity a lot. Gathering feedback is quicker, solutions can be found in fast team brain storming and everyone gets on the same page immediately.

Email isn’t fun. It’s also slow, hard-to-follow way of talking. We know it so we start use applications like Slack and Skype. They add a big dash of fun but still… explaining something by tapping many, many keyboards keys can be painful. So what next? Recording audio message? Video conversations?

Maybe just a quick talk face to face?

 

#2 No more backtracking

Designers developers together

We build app with the title powerful mix from scratch – working together prevents having to backtrack after something has already been approved by the client. In Mood Up Labs we know that joining forces can eliminate hiccups.

Designer is a keeper of client’s idea and he explore it everyday with developer who can make him evaluate the choices he might otherwise take for granted.

Pair programming is well known technique to boost yield, and simply being familiar with design before it hits developer plate can make building things so much easier for him, so we pair programming & designing to be sure that we can hit in client needs.

 

#3 Budget-friendly project

Both the developer and the designer have different tools and they use them in different ways. Developers are from technical standpoint and they can propose some new concept, more budget-friendly design, while designers being ingenious can meet it with original arrangement.

When two different minds collaborate to solve a problem, they create some type of harmony and we take advantage of it. There are situations when designer project something that looks like it will be superb, but once it gets built, it might not be so cool. Developer is the one who can foresee this might happen.

 

#4 Speed up the process

As we stated above, getting on the same page immediately is crucial to get things done easier and sooner but it’s not friendly to achive in industry passoniate by asynchronous electronic communication, that’s why we have both the designers and the developers on board in Mood Up Labs.

Documentation is irreplaceable as a reference but alone it often doesn’t matter – beyond that, there should be regular two-way solutions transmission in person. Marked-up screens aren’t the same as asking best friend sitting in front of you, especially in time when dynamic products require dynamic solutions.

 

Yes, it really can work

Designers developers together

When I joined Mood Up Labs, I’ve started to understand this. Communication is the key – found it incredibly useful to my designing to have developers in the same room. We start being collaborative team managing to accomplish significant amount of high-quality work in short timeframes.

We work in Agile and within our daily meetings, we discuss each other work, what and how have to be done further, find ways to improve and create well built product. It was new to me, but it turned out to be the best what we can do for clients.

 

We’d love to hear your opinion – what’s other ways that close cooperation between designer and developer benefit projects?

Why more features won’t save your app?

Doing too much at once is known to be one of main reasons why product fails miserably when developing a mobile app, more features won’t save your app. Here are some tips that will help you avoid that and create something valuable for your users.

 

80 percent of consumers are using smartphone to browse through the Internet, that’s why so many businesses are keen to develop their own app in order to get into that growing mobile market. Statistics clearly show that 90% of time on mobile devices is spent on apps so it’s only natural to come to conclusion that a branded app will enhance your business growth. That being said, your product’s success requires careful planning and development.

What is wrong with app development

One of obstacles to overcome when developing an app in team is overly long list of features to be included. It can result in customer’s confusion and most importantly not fulfilling his key needs.

Product owner is the solution

By that I mean identifying a person within your organization that will be able to stand his ground. His main task will be to say ‘no’ a lot more than saying ‘yes’ during brainstorming sessions.

Nothing changes without his approval, it will cause quite a stir in your team because of shooting down ideas for features, but it will result in focused product that brings value: a win-win situation.

Identify key features

It’s really hard to say ‘no’ to a person who signs your paycheck, that is one of reasons why identifying product owner in startups is so demanding. One of the most crucial rules in mobile world is that by trying to make your app do everything, you will usually end up with product that doesn’t make anything particurarly well. That’s the risk you want to avoid.

evernote_ios

Solution to that problem is to focus on key features. Apps like Evernote or Shazam are examples of how it should be done. First is an easy way to take notes, the latter helps you find out what is the song you are listening. These are the core features and they are first things that come to mind when thinking about those apps.

shazam_discover_music

Note-taking app should offer taking notes in a fast, easy way. Adding more features such as customized skins or social sharing is not needed.

Before even considering adding new features, focus on making core aspects of the app run smoothly and intuitively.

Testing

User testing helps to uproot features that don’t add much to the user experience. Besides in-house testing, it’s always good to check out what is customer’s reaction.

Tracking tools such as Google Analytics will help you decide which features are worth implementing.

Developing your app is a process

Your app won’t be perfect when it’s first released, however it is always possible to improve user experience. Focus on listening to feedback instead of adding more features, simplifying an app’s design and making them avaible with fewer taps is more effective.

Adding new feature is not always a bad idea but you need to describe the reason behind it correctly. Otherwise you are taking risk of complicating your product.

Paid vs. Free app – what should you consider?

Choosing a model of how you will offer app to your potential users can be very ambiguous. Do you want to charge for each download? Maybe you want to develop free app which can be upgraded (freemium)? Or maybe you are considering monetising it differently, e.g. by in-app advertising?

As easy as it may sound, choise is crucial and can affect entire future of even the most brilliant product. On one hand – paid apps are considered guaranteed revenue from the moment they launch, but on the other hand price tag can scare off potential users browsing the store – no one likes to buy cat in the bag.

Let’s have a look at some things that might clear this up a little bit for you.

What is the purpose of your app?

If you are lucky enough – this is the only question you should answer. There is great chance that business app user will find in-app advertising irritating and would consider paying for it in the store. However, gamers would most probably prefer to download it for free, prepared to just ignore the ads, click them to discover other games or simply upgrading after they see the app is worth it.

pricing_stategy_in_different_app_categories

The whole point of an app should be to allure users and provide oustanding user experience and because of that, you should consider if they are willing to pay for it. Keep in mind things that affect it directly such as demographics or loyalty.

What is your revenue model?

It is quite obvious that your app will be more popular if you make it avaible for free. It will help achieve major victory in development world, which is breaking the psychological barrier – price. There are thousands of great free apps with awesome UI and various functionalities and if you decide to make your app a free one, you will join this competition and could leave paid apps far behind. Less paid apps are developed now than ever before.

But in order to do that you will have to earn money by creating revenue model where there are advertisers, in-app purchases or content providers. Number of users is directly connected to revenue then and of course you can get more users by offering your app for free.

App will not be always sustainable revenue

This is really important thing to remember – no matter how much you will charge ($0.99 or 100$), a price sticker on your app will be only one-time payment. Even widest user base won’t change the fact that the revenue you can get will be hard cap. No one will pay for the same app twice.

However, if your app is free you will not generate revenue up-front at all.

Conclusion

Deciding to offer a free or paid app is difficult and has been causing headaches for quite a while now. In app development keeping your user happy is most important, so you should find a balance between that and your business needs.

Should I support tablets?

A long time ago in a galaxy far away, in 2010 to be exact, Apple introduced iPad and it was game changer. Not long after that Samsung’s Galaxy Tab came and a lot of other Android tablets. Good ones and bad ones. Fast forward 6 years and tablets are heading towards extinction. Is that right? Let’s have a quick look.

Whole purpose of tablet was to use it to consume media, large screen was their biggest strenght. But there is variety of smartphones with large screens right now. That makes playing games, watching videos and reading quite comfortable. Customers are currently thinking: ‘Do I really need tablet as well? My iPhone 6s hardly fits into my pocket already’. Smartphones are killing tablets.

ipad-mini-v-iPhone-Plus_thumb800

No one could have predicted precisely how smartphones would evolve to be so useful and important they are in our lives right now. On the other hand, tablets were meant to be technological home for newspapers, books, magazines and even grocery flyers. Industries behind all those mentioned things were supposed to thrive thanks to new media infrastructure.

Reality turned out differently as pretty much always. Now everybody wants news immediately on their phones. Even typical tablet app like Flipboard are now focusing on smartphones.

So right now you might think that there is no need to support apps on tablets, that ‘tablets are dead’. Well, it’s of course hard to predict the future and there is no doubt that concept of tablets need revision. But there is also one thing that makes me believe that tablets will come back swinging eventually: it is predicted that in 2016 15,6% of global population will use tablet even though the sales are slowing down, mainly because people don’t change their tablets as often as smartphones. That’s over 1 billion of users, number that companies won’t forget about and will try to come up with solution.

Let’s remember that not everyone is happy with bigger phones – that’s why iPhone SE was introduced. Such people will consider using tablets. Apple and Android producer’s must rethink their approach. We shouldn’t give up on tablets when deciding which devices should be supported just yet.

Choosing platform for my app: What should I consider?

With estimated more than 2 billions smartphone users in 2016, saying that mobile apps are playing important role in our lives on daily basis would be saying nothing. Average US adult citizen spent around 3 hours per day using his smarpthone on nonvoice activities last year. That’s 45 days in a year. This number doesn’t change much when it comes to users in EU.

Not suprisingly, the so called platform war was fierce, and only two preveiled: Android and iOS. Together they have over 90% market share. Everyday more than a thousand new apps are uploaded to both, App Store and Google Play. Windows Phone and Blackberry combined have only around 4% so it’s safe to say that generally they won’t be natural first choice.

So, you know which two operating systems to choose from when developing your app, the question is: which one will be right for you? Well, to answer this you need to consider couple of things described below.

Demographics

operating-system-market-share.aspx_-1 (1)

Mobile/Tablet Operating System Share via Netmarketshare

Average price for iPhone is around 2.7 times more than Android devices. The latter has biggest market share globally which means you will be able to reach more users. It’s very popular in developing countries and lower income areas.

Android devices are more affordable and this indicates also that user might prefer free apps.

On the other hand iOS users usually have higher income and are willing to spend more. That might make the number of users slightly less relevant.

via Fortune

via Fortune

Of course, those characteristics are general and as such shouldn’t be considered as written in stone.

Revenue model

This aspect is somehow representative for Google’s and Apple’s approach. According to report from app analytics company App Annie, despite number of downloads is much bigger for Android, iOS is still generating more revenue.

via App Annie

via App Annie

Loyalty

Another important factor to consider is customer retention and loss rate. Two year research conducted by CIRP (Customer Intelligence Research Partners) in US market shows that around 80% of Android and iOS users are sticking with previous operating system.

Customer Retention and Loss – Previous and Current Operating System for Customers Activating a New Mobile Phone, 2013-Q3 – 2015-Q2 via CIRP

Customer Retention and Loss – Previous and Current Operating System for Customers Activating a New Mobile Phone, 2013-Q3 – 2015-Q2 via CIRP

Percentage of switchers from iOS to Android is slightly higher than from Android to iOS. However, the most interesting fact is that over 60% of first time phone buyers choose Android, it’s big difference comparing to iOS – 24%.

Security and updating

iOS is considered more safe than Android, mainly because the latter makes it easy to configure the OS to allow personalization and flexibility. One of the biggest advantage of Android is what makes it vulnerabe.

Apple works hard to ensure the latest version of iOS (and with that also security updates) is installed and is known for triggering mass updates. As of today around 80% of devices are using iOS 9. On the other hand, 35% of devices have Android v. 21 (Lollipop) installed and there is already another one – Android v. 23 (Marshmallow), yet only 1.2%.

Android OS versions via Android

Android OS versions via Android

iOS versions via Apple

iOS versions via Apple

All this means that on iOS you are able to focus more on newest versions while being sure that it will reach broad audience. This should allow to stop supporting older devices sooner and overall reduce time spent on testing.

Tablets

Although tablet sales is slowing down, it’s estimated that in 2016, 15,6% of global population will use tablet. It suffices to say that number of potential users is not to be ignored.

Android is projected to hold over 60% of that market and iOS around 25%. However, it seems Apple’s iPad is more popular among business users. It will be a challenge to find Android tablet in a meeting room.

Conclusion

Hopefully, taking data from this article under cosideration when choosing platform for your app will be helpful in decision process. It all depends on your app so by keeping in mind all described factors you will be able to decide whether to support iOS, Android or both. It seems the best solution is to support both platforms right away but whatever you decide, don’t pick Blackberry as first choice :)