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.
“Reduced
performance”
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.
Related Posts
Leave a Reply Cancel reply
Service
Categories
- DEVELOPMENT (103)
- DEVOPS (53)
- FRAMEWORKS (26)
- IT (25)
- QA (14)
- SECURITY (13)
- SOFTWARE (13)
- UI/UX (6)
- Uncategorized (8)