Mobile app development guideline for a newbie
You have decided to create a mobile application. How to begin? How do not miss important points? There is a lot of information on the network that needs to be considered from the point of view of marketing, but if you are a beginner, then most likely you are interested in answers to specific practical questions.
- What is the best way to develop – natively or cross-platform?
- What to release first – Android or iOS?
- Can I somehow test the application before publishing for live users?
- Is it worth it to open the game immediately to the whole world or only in one country?
- How to attract users to your application if the budget for this is limited or doesn’t exist at all?
- How do I know if my application is performing well or poorly? How to find out if there are any problems in it?
- How often is it worth updating the application?
- Can I see where users come from?
- Is it worth it to make advertising in the application, or will it scare away users?
- What to include in the application in general and not to miss something important?
Few years ago, I also didn’t have answers to these questions, but now I do. Three or four years ago, the mobile industry was on its beginning stage, and half of the important and necessary tools simply did not exist. But now we have almost everything we can dream of. The main thing is to know where to look. It surprises me that the network still doesn’t have a single competent and useful information for beginners. Although, perhaps I just didn’t meet it.
I survived with a hundred releases and updates, did dozens of experiments to gain experience, which I will share with you. I will try to avoid tips like “Your icon should be attractive,” but at the same time I will proceed from the assumption that you don’t know anything, so for experienced colleagues I will most likely be too detailed.
So, you are developing a mobile application or even just starting to design it. The first and probably most controversial question is what to do on it. Should it be a native application or does it make sense to look towards cross-platform solutions?
Recently, I come to the conclusion that native development makes sense only for a complex specific application, for which it is necessary to use native interfaces – resource-intensive and using a lot of libraries. It can be, for example, a game or social network.
Why do we need cross-platform? It allows you to save on time and resources, convert a project divided into two separate processes (and two teams) to one. This is an advantage that cannot be overestimated. In my opinion, double saving of resources is an argument that only a combination of several negative factors can outweigh, and you are sure that you cannot avoid them.
Cross-platform engines have now reached a very good level, got a lot of lightweight tools. Therefore, no matter what you do, whatever you design, first study the issue of cross-platform development. There must be very strong arguments to abandon it. I talk a lot with developers who make custom applications, and they all shout “Do not cross-platform!”. But there is a nuance: native development (separately iOS and Android) doubles the time and resources.
Therefore, if you have a custom application, then listen to the developer company very critically: due to the pricing accepted in the market (payment for hours of programmers, designers and managers) it is not beneficial for them to reduce your costs. There will certainly be a conflict of interest, and a rare developer will avoid the temptation to increase his income. If you are convinced that cross-platform is absolutely not suitable for your application, ask specific questions why.
This is the most common horror story, but when I ask for specific examples, few people answer me (I have never managed to get specific examples) or refer to the NDA. But the NDA, as a rule, doesn’t extend to the fact of development itself. Moreover, any developer needs a portfolio, and they are defending the right to show their experience with all their might. Mentioned NDA should immediately alert you: most possible, real arguments are simply absent.
“More responsive interface, high speed”
This argument should not mislead you either. Specify, ask questions. What does “more responsive” mean? How much higher speed? Yes, the cross-platform implies an additional software layer, which requires additional resources.
But if you don’t have a 3D game or a client-server application that constantly exchanges data, then your user may not notice the difference or it will not be critical for him. It’s strange to refuse to save if the application slows down on a certain process that the user encounters once in a session, agree? Optimization of working with memory, logical alignment of processes, graphics and other things solve most of the problems.
Yes, some countries have a huge amount of weak Android devices and this is perhaps the biggest minus of the cross-platform. And here you need to decide: do you want to reach everyone? Even the poorest with weak devices? Then this argument is not in favor of a cross-platform solution. In general, go to the engine website, there are always a huge number of examples, look for something close, download, run on a weak device and see for yourself. Slows down?
“Cross-platform will be very expensive to maintain”
This is the second most common argument, and it always makes me feel very strange. How do resource cuts double the cost of project support? Ask this question. There is, of course, a nuance: it is more difficult to find a specialist, sometimes there are difficulties with plugins and libraries, but is this really a plus of 70-100% by time? Ask specific questions: what exactly will increase the cost of maintenance?
“There will be big problems with plugins, libraries and SDKs”
This is a really powerful argument. Indeed, it very often happens that the engine’s own solution or a third-party solution is not suitable for one reason or another, and then this turns into a headache. But this is a solvable problem. Be sure to ask your programmer or company which plugins or libraries can be problematic.
You already understand the functionality – that means you can say with 90% probability which components you will need and study the question of the availability of solutions on the market. Ask in what projects the adviser had problems. Did they look like yours? It is impossible to foresee everything here, but at least some vision will appear in you.
Sometimes an application requires native interfaces, but they are different on iOS and Android. If you have just such an application or you are in love with material design (like me), then yes, the cross-platform will not suit you.
But I have never seen any data anywhere that would say that users leave the application just because its interface is not native. It should be convenient, beautiful, but ordinary users, as a rule, do not operate with considerations of nativeness and are unlikely to run away in horror, shouting: “This is not native!”. In the end, there are fixel and murl that use native code without a layer, but it’s almost exotic.
In general, there is no single answer. Although I am a supporter of cross-platform solutions and the industry is also slowly migrating in this direction, there are cases when cross-platform is contraindicated. But you need to make sure that the arguments “against” are not contrived and can actually make the project more expensive or scare away users.