There’s a mobile strategy, which is more or less common for the major part of the businesses. The main point of the strategy is to start with one platform and convert an app to another one, later on, scaling gradually. The reasons why it happens are pretty simple. First and foremost - lack of resources. The second one is closer to marketing and is about reaching the customers and trying out new communication channels. The second reason appears mostly when the business owners have doubts regarding the potential outcome. This way or another, the business comes to the idea that converting an app to another platform might bring some additional outcome. The story is pretty similar to a lot of brands including Instagram. They converted the app to Android only 4 years after it was initially launched. So it was done when the outcome became really gross. If you want more examples to look at, consider Airbnb. The app was converted a year after the initial launch. And it was done mostly to increase the mobile presence.
In the previous article, we've already considered transporting iOS to Android and its reasons, so today we gonna turn to vice versa.
Most of our readers already have an idea about the benefits they can get from converting the app. If so, jump straight to the next parts where experts explain how the converting process should be handled. In case you still have doubts or want to have a clearer vision of the situation, feel free to read further.
There are two players on the mobile market - Android and iOS. And, let’s be honest, the alternative is not visible in the near future. Both these platforms are and will be the only parties, sharing the market in recent years or perhaps even decades.
In simple words, in case your app will be converted for the alternative platform, you will literally cover the whole market because Android and iOS have 98% potential customers in total.
The second point comes from the first one. If the app is available for both platforms, it means not just full market coverage. It means much more - a possibility to dominate the new markets, new cities and countries, and even new segments of the target audience.
It is vivid and clear when we are talking about the shift from iOS to Android. It opens huge possibilities and undercovers the potential of Asian and Eastern European markets, not talking about Africa and South America.
If you do vice versa, you will get better coverage in North America and Eastern Europe because iOS devices are preferred there.
Regardless of the monetization model you use, it is clear that having an app for two platforms is more profitable than having an app just for one platform. You can literally make more money. But how exactly will the income be boosted?
It leads to another fact worth considering - having twice fewer iOS users than the Android ones you can generate the same income or even hit the new goals of getting the revenue.
It would be perfect if we had some converter where you could convert an app by pressing the button. But does such a service exist? Unfortunately, not yet. The platforms differ and each of them has its own peculiarities, so it’s impossible to process the conversion with one click. One of the best and the most obvious options is to create a second app, a separate product, and work with it in marketing terms. The one and only exception are when you use some framework like React Native or its competitors.
It might seem that shifting an app from one platform to another is something like the old good of converting a PDF to DOCX or something like that. Unfortunately (or not?) it’s not even close.
If you ask us what metaphor can be used, we would pick the process of building the house. Imagine you have two separate patches of land (which will represent the platforms). And if you want to build a house on each of them, you should do it twice. Simple copying does not work here. The second house will be built from scratch, the same as the second app. We have some good news, however.
Here are some tips we have come to in Celadon
Programming languages like Swift and Kotlin (used for mobile development under iOS and Android) are relatively “young”, so they have some common features, making shifts easier for the developer. Among the common features are:
For you, it means that if the app was written using one of the modern languages, the developers can adapt it for another platform faster and with ease. So technically converting takes less time.
The developers distinguish the features related to business logic and the ones which are specific to the platform. The UI part is mostly “ruled” by the platform-specific code
With this knowledge, the priorities can be set according to the business needs. However, it has a huge impact on the estimations and they're being correct and adequate. One might ask a question if it is possible to discard this part and work only with the business-related features. The answer is no - the platform-specific code is the thing making the app look native.
It might seem that converting an app to an alternative platform is just about rewriting the code and reusing the code snippets, common for both (if any). But when it comes to the point, the reality turns out quite different. We have collected the list of pitfalls you might meet and some advice on how to cope with them.
It surely is worth considering. But the most important thing here is the OS version. The users do not update the versions and their reasons are different. So it is not the best idea ever to make an app for the latest version. You won’t like it and you, technically, shouldn’t, but the only way out here is to create an app, working well with all OS versions from the very beginning.
The good news, however, is the following one. Yes, it will take more time and effort. But if you are working with the professional development team, there will be no issues and troubles with creating an app, working well on all the actual versions. The same situation is with adjusting the app for a new OS - a high-skilled developer will do it as easy as a pie.
Cover as many OS as you can, expand your market presence. At the same time, there’s no need to cover all the OS that exist in the world at the moment. A couple of versions for iOS, some for Android, starting with the 5.0 version and that’s it.
Another thing that should be taken into account is the difference between screen sizes and resolutions for the devices. Not surprisingly, statistics are pretty much the same as the one for OS distribution.
The good news, however, is the following one. There’s no need to develop the mockups and adjust the app for all 20+ screen resolutions for Android. The magic key is density. Just pick 5-7 most commonly used resolutions and the system will do all the adjustments on its own. Of course, the list of differences is not limited to the screen sizes and resolutions but these points should be handled precisely.
Now it's time to talk about one of the most important parts of any app - design.
The interfaces of Apple and Google are completely different and it was done for purpose as well. It led to better audience coverage and reached some other marketing goals, but at the same time, it added some pain for the developers and designers in case of converting an app from one platform to another. It means that one can’t simply reuse the layouts and design. Concept differences, related to the approaches of the companies, are the main “why not” reason. Google uses a material design approach while Apple works with HIG (Human Interface Guidelines). The best way to see the difference is to have a look at two examples put next to each other.
Object placement is the main difference. A hierarchical arrangement of objects works for material design. Just on the contrary, the objects in Apple designs look flush.
Lists. Apple added arrows on the left side, while Android implemented custom icons.
Navbar. For iOS, the titles are centered, for Android - placed on the left side. The difference in the height of the element is also pretty huge - the height for Android is bigger in comparison with the same realization for Apple.
Look at the data pickers and you will get the main idea here too. Android's date picker is more about tapping; a date picker of iOS is more about scrolling.
Typography is here, too. San Francisco is a default font for iOS, and Roboto is a common choice of default font for Android. They look pretty similar but they're not the same.
Icon shapes. Because of the strict rules set by iOS, you can't simply reuse the icons because the ones for Android will not meet the requirements of the ones for iOS.
The part about the differences is over. But there’s yet one more step you simply can’t avoid and must not skip while converting an app from one platform to its alternative. And this part is testing.
QA is essential, though some business owners who want to save up some funds try to skip this part at all or hate checking some critical functionality only. Testing ensures that all the requirements are covered, as well as everything that has been mentioned.
If the testing phase is skipped or shortened because of a lack of budget the user gets a raw product with typical bugs. If the user is not satisfied with the product, he stops using it and goes to the competitors, picking the competing product. Not the best scenario, right? As a rule, QA processes take up to 30% of all the development cycle time.
So our second "converting" article is close to its ending and now we are pretty sure you have grasped the idea of the classical way how the conversion from Android to iOS (and vice versa) flows. But in other words, the process can be described as “Building another app for another platform with as little effort as possible”.
But if you are smart enough to research in advance and are looking for a solution with a shared codebase, our developers can do it! Find the answer here
If you’re looking for a team, which will help with the iOS to Android migration or vice versa, feel free to reach out.
No comments yet. Be the first to comment.