How to develop a successful mobile application using the 1C platform

Nikita Baksheev

06.08.2020 26 min

3.png

What is this article about?

Today I will attempt to shed light on how to develop a successful mobile application using the 1C platform. This will be of interest to developers, IT managers and anyone who wishes to invest in mobile development. In this article, I want to uncover the features and nuances as well as the possible complexities of this subject.

Why is this worth taking note of?

To begin with, I will explain a little as to why it is possible to take note of our experience. We have been developing mobile applications since 2013. As of now, our mass market replication solutions have been downloaded by more than 3 million people, of which more than 30,000 have left ratings and reviews. The overall average rating is 4.5 stars. This is a very positive indicator.

Furthermore, our applications have made the Top 10 on the App Store and Google Play in 88 countries. As well as this, we've been selected as a featured application on the App Store on several occasions.

We only undertake large-scale market development for the mass market.

Our applications

At the moment, we have three flagship solutions. The first one is Boss. This solution is for managing a small business. It has been downloaded by more than 600,000 people, and has an average rating of 4.5 stars. In total, we have 5,000 reviews for this application.


If we look at the evolution of downloads, there are currently 25,000 downloads per month. We have translated the application into 20 languages. Overall, we take a serious and instant approach to translations once the application is developed, thinking on a global scale.

Let's take a look at how downloads are split between languages.


 

Portuguese takes first place, and Russian is the runner-up. Their percentage share is more or less equal. The Spanish, Turkish, English, and Vietnamese markets have a noticeably lower percentage share. There are other languages, but they have considerably smaller percentage shares, so I didn't include them.


This is how the evolution of our paid users looks. I am delighted with this upward curve over the past 1.5 years, and I hope it will continue in the same fashion.

Our next application is Fitness. This application is not for businesses, but average people. It is for people who go to the gym to keep in shape, or for those who engage in professional sports.


This is currently the most downloaded application developed on the 1C platform: it has been downloaded by more than 1.5 million people. It also has the highest rating of 4.6 stars on the App Store and 4.5 on Google Play. In total, there are 15,000 ratings. On average, a little more than 50,000 people are downloading the application monthly, and it has been translated into 20 languages.

Let's take a look at how downloads are broken down by country.


The slide shows that Russia is in second place while Brazil takes the top position. Italy is in third followed by the United States. Their percentage shares are comparable, while other countries have a much lower percentage.

Another of our applications, Budget, is an application for managing personal finances. This was the first application that we made. 


As of now, it has been downloaded by 500,000 people, and it has a rating of 4.5 stars on the App Store and 4.3 on Google. In total, there are 5,000 ratings and, on average, it is being downloaded by around 10,000 people per month. It is also translated into 20 languages.

Who is the mobile developer 1C?

Many people believe that if a person knows how to program on a desktop platform, then they automatically know how to program on a mobile platform. I would tend not to agree with that point of view. If we talk about mass commercial development or a made-to-order development with around 50 users, then this theory does not work at all. A "desktop" programmer wouldn't be able to make a decent mobile application just like that. There is a number of objective reasons supporting this. Some of them are displayed on the slide. But there are still many more.

In general, in order to delve into mobile development, a person needs to develop several other skills.

The first concerns the fact that mobile applications have weak hardware. And we, as developers, have no room for an unoptimized code. We have to code in an optimized way because, if we don't, then the weak hardware will operate so slowly that it will be impossible to use.

The second aspect to consider is the small screens. Knowing how to write interfaces for small screens is something I would single out as a separate skill to be learned. Making a comfortable and user-friendly interface for these kinds of screens is no mean feat.

The third particularity is the fact that there are many integrations. As a rule, a mobile application is a mirror of an already existing system. And many companies have a "zoo" of systems; they want to see the main indicators in one application. That's why there can be many integrations. In our last project, for example, there were 5 integrations with different systems.

The fourth feature is the specialized functions. Here, I'm not only referring to functions such as GPS, SMS, or calls. These are rather simple functions that don't need to be learned but can be quickly gotten to grips with. I'm talking about the functions of other applications. In reality, it's very common to have to use functions from other applications and this is a very complex task that can be handled using add-ins. One example is user authorization. Nowadays almost all applications, including Google and Facebook, have a user login feature.

The next feature is user behavior analysis. With desktop development, this isn't a particularly relevant subject, but with mobile development, if we are doing mass commercial solutions, then this is for all intents and purposes mandatory. We have to analyze how our application is being used, whether the customers understand it or not. Perhaps, they are not correctly managing their account, maybe they are not using certain functions, or they could be experiencing issues during use. If we don't analyze all this, then our chances of success are very slim. Virtually all successful mobile applications are doing this, and a significant number of them are spending more resources on this than the actual development of the applications.

The journey to creating a mobile application: from an idea to promotion

Step 1. Think of an idea. How does one think of a good idea?

First: we think, get creative, fantasize.

Second, it's vital to look and see what there is on the market, what's on the App Store, Google Play and other resources. However, don't get restricted to one country. Look at the most competitive market, the United States, and look at other markets. A good life hack is to look at Appannie.com, which publishes trends, i.e. applications that are currently gaining popularity, and that has just appeared on the market.

Recently, I came across a very cool application. For example, we are meeting our friends in a cafe and we decided that we wouldn't touch our phones so that we could chat with each other instead. This is a very relevant subject these days. And someone has developed an application which makes sure that nobody uses their phone. If someone picks up their phone, looks at it, and starts doing something, they will have to pay as a result. Cool, no?!

In general, if we look around, we can find some really interesting ideas.

The third thing to do is to improve. We all have experience of using a popular service and there's always something we don't like which isn't clear or practical. We can make a similar application which includes a solution to this problem, giving us a competitive advantage. There are many positives in doing this. For example, the user base is already there.

Step 2. Once we have chosen an idea, we need to check it and test it economically. Perhaps we've just invented garbage that will never bring in any income. How can we check this?

One of the first things we can do is to check our competitors. We look at our direct competitors. If there are no direct competitors, we look at indirect ones. A couple of resources that help us with this are Appannie.com and Sensortower.com.

These sites help identify competitors and show how many downloads they have and what revenue they bring in. Appannie.com will show this information with 100% accuracy, but it is a paid resource, while Sensortower.com will show you approximate figures, although this resource is free.

Step 3. Next, we need to calculate the potential revenue in order to check the economic feasibility of the idea.

For that, we need to know the number of users and a viable price. What do we do to establish this information? We refer to facts that we already know and are already aware of. When we don't have these facts, we use hypotheses. Hypotheses should be made as plausible as possible.

To have more facts than hypotheses, carry out things such as surveys. They help tell us more about the field. To establish a viable price, carry out experiments, collect focus groups of your potential users, and learn more about the field. This will help us to correctly calculate the revenue.

As well as this, don't forget that there are many publicly available investigations. A lot of analytical companies carry out investigations and publish them, and this can be of great help.

Step 4. Once we have established an idea and carried out the economical checks, we think about the development and the cost. 

From experience, to make a quality first release, and I stress that this is from our experience, the developer would need roughly one year with the designer and the design engineer needing three months each. This is a considerable, but good time frame. And this is just the first release. If we compare the functionality of an application developed on the desktop to a mobile application, then the mobile version would usually be more complex and more expensive.

Step 5. Once we have selected an idea and know the cost of development, we have to carry out a technical check. 

We already know which functions our application has, but we need to check whether or not it is at all possible to do them on the 1C platform. If it is possible, then we need to check whether the user convenience level is good enough, if this user convenience level of the application is competitive, and whether or not we can make a competitive interface level.

Step 6. If all of this is fine, then we can move on to the next step – engineering. 

We have one important principle for everything which concerns the developer from engineering to engineering support and even design: make things clear and practical. It is only by following this principle that we can really make quality and helpful application for users. Don't do what the picture on the slide shows.

I think even the person who made this wouldn't be able to figure it out.

Let me give some examples of good and bad engineering. On the slide, there is a picture of the pilot's cabin in a Boeing 747.


If we look at the panel on the right, we can see around 500 controls. They are rather monotonically arranged, and even if a person knows how they work, it will still be difficult to manage. This is an example of poor engineering.

Now let's take a look at the cabin from a Boeing 787 plane.


The system is considerably more complex here, to say the least. But look at the pilot's control panel. It is much smaller, only contains the necessary items, things are well grouped, everything can be understood intuitively, and are all in the correct places. Overall, this is great.

Now let's look at more relevant to our field examples.


I think I'd need some sort of diploma to get to grips with this program. I wouldn't know how to work with this.

And here is an example of good engineering.


In theory, there are still quite a lot of elements, but all the sections are immediately clear to me, and I instantly understand which information is displayed, how to change this information, and how to filter it.

Now let's look closer at our field – the 1C interface. What is possible to do on 1C from an engineering perspective? When we design a system and in general start developing, we face the need to adapt all forms. We cannot take a form as it is generated by the platform. Also, we often confront the need to change many business processes of the forms.

I will give some examples so that it's clear.


On the left, there is a phone screen. Look at the lower panel. This is the sections panel. This panel exists in almost all applications and is very typical in native applications. However, the platform doesn't know how to draw it, and, on the right, you can see how this can be done on 1C.

Take a look at the upper panel. This is the actions panel, another fairly typical item in native applications. It opens some kind of documents or, perhaps, filters or reports. This can also be done on 1C using settings.


This is a list form. If we leave a list form the way it is generated by the platform, it will be a fused text without breaks that’s very difficult to read. How can we build it in a more readable, clear, and practical way? We've added grouping, we've added icons, we've highlighted the most important items, and we've made others almost undetectable. And now, it is fairly easy to read.


Here's an example of a situation where we've gone beyond 1C. We wrote these forms on html because our task was to make nice looking forms with nice backgrounds and nice images (see the two screenshots on the left). It's impossible to do this on 1C, but everything can be built-in. That's why we also use other technologies.

The right-hand screenshot on the slide is also on html. This is an example where we need to output a lot of data, and it's very important how the information is located so that users could easily understand and read it. It requires very fine settings, which is why we did this on html.

Let's look at some more examples.


On the left, there's an example of a standard solution. These are indicators written by the platform itself.

In the middle, you don’t see a modified form, but a changed business process. We choose a new currency or an item from a small list, and we display this list directly in the same form. That way, it's clearer and more practical.

On the right, there is a selection form, which is also more simplified, but with a changed business process. The selection form opens, we just have to click on what we need, and it all goes into our basket. Again, this is a fairly typical feature in native applications but is not done as a standard.


Now, let me talk about the mistakes that we often encounter in our line of work. Please, do not do that!

The first mistake is the complex implementation of features. There can be some particularly complex features, and the developer may gather all the parameters of this functionality in some kind of form. When users see this, they go crazy; they don't know where to start, what to look at, what's important and what's not important. Often, when we change these kinds of things, we see that the majority of parameters can be pre-filled so that the user doesn't have to fill them out themselves. Then, we can group them according to different characteristics and highlight certain features to give the user a helping hand so that everything is logical for them. This simplifies the work considerably.

The second issue we often come across is notifications without suggestions. What does this mean exactly? For example, we write a sales document, and the system gives the error message that says "you don't have this item in stock". And with that message, it's over. This is an example of poor engineering and what not to do. In most cases, we know what the problem is. So, why not offer a solution right here, wouldn't that be convenient? The user wouldn't have to leave the application and look at some kind of reports or documents. We could tell them that they don't have this item, immediately offer them to order in one click, and instantly post this transaction. We could also either suggest to do inventory or propose other next steps. But with any of these options, the system developer is usually aware of what the problem is.

Another mistake is having many functionalities. It’s often thought that having more features means having a top-notch app. But practice shows that applications with just one function are a lot more popular, and everybody uses them. That's why a recommendation would be to write the most basic features of an application.

1C terminology is another problem that we also always face. The average user doesn't understand 1C jargon. For example, one of the most common commands is "to post". The user wonders what this means, where they should post something, and why. So, users who don't have any links to 1C don't understand this at all. And there are many other examples. Even simple concepts such as "directory" and "documents" are not understood by the average user, despite the fact that they would appear to be clear. However, people begin to wonder which documents are being talked about. Maybe they need their passports...

The fifth mistake is a denial of responsibility. I would like to bring particular attention to this point because it is very important from the development perspective – it's a change in thinking. Let's take the example of Johnny the programmer and Peter the user. The programmer has made a really cool feature, and he is pleased with himself. He believes that everything is great, and he rolls it out into production. Peter the user sees that a new feature has been released, and he quickly rushes to get to grips with it. So he enters some information, but suddenly the application gives an error message. “What on earth! These programmers have made some more trash and are releasing it with bugs again”, he thinks. The user writes to the support service that he entered all the information correctly, but there's some kind of error. Johnny the programmer looks at it and thinks "darn, this again". He writes to Peter that the program wasn't designed this way, the accounting is built differently, and that Peter should have done this and that. And Johnny the programmer thinks to himself how stupid these users are. But, strictly speaking, there are no stupid users, but only poorly designed systems. I would like to set the mentality that if users are regularly encountering problems, it isn't their fault. They aren't stupid. It just means that the time has come to change something - to change a certain feature to make it easy-to-understand. This is a very important mindset.

The sixth error isn't related to development but more to evaluation and the sales aspect of the project. When taking on a mobile application, many providers evaluate it based on the desktop version. But this is incorrect (in the previous slides, I've already given some examples of why this is the case). They believe that they could probably do it in a couple of months on the desktop. So, since this is a mobile application, it must be even quicker. But this is fundamentally incorrect. In fact, mobile applications take longer to make. Plus, they are more expensive – on average, 50 percent more expensive.

Mobile development has certain functions. The first is the synchronization. I would again like to put particular emphasis on this because mobile synchronization has other requirements, greater than on the desktop. Usually, when we develop mobile applications, our clients want online synchronization. They are not interested in the fact that the reason why they don't synchronize is that they have different versions. They want constant synchronization, no matter what the version is. Some did the version update, some didn't, but they want it to work constantly. There can't be any additional settings. Furthermore, there mustn't be a separate server deployment for each synchronization. And, of course, synchronization must be highly optimized because the device is weak. When we look at the transfer of synchronization from the desktop to the mobile, we constantly face the problem that everything works fine on the desktop, but synchronization with the mobile takes so long that it becomes impossible to wait and impossible to use. That's why we have to rewrite the synchronization and often have to architecturally change many things.

Step 7. We have already established the idea, done all checks and designed our application. Now it's time to move on to promotion. 

I would like to share some experience to warn people against rushing into advertisements. Because the overwhelming majority of advertising expenses are not worth the cost. It's better to focus on search engine promotion. This doesn't require any financial expense but can give a very good return in terms of promotion.

What exactly needs to be done here? Here, we're talking about keywords on the markets. Each time we release new updates, we have to change the keywords. In other words, keywords and the search positions that certain phrases take need to be checked before each update. If we see that we are very far from the top in searches and no one can see our application, that means that we need to change some words to make all the keywords work somehow. It's also important to remember that with time applications change in their popularity and less popular keywords need to be changed to more popular ones. This is how you can get more traffic.

Definitely have a look at the keywords of competitors to avoid missing something important. On the slide, there are links to services where it is possible to look at the keywords of competitors.

When you add new keywords, it's crucial to analyze how competitive they are. Add keywords that are too competitive, and the application will be at the end of the search result with nobody finding it. There can also be words that are not competitive at all. In this case, at least the application is at the top of the search result, but, still, nobody will download it as nobody is searching using that word.

Step 8. Now, a few words about monetization. Here, I'm only going to talk about the most popular form of monetization. That is when the application is free, and there is a subscription for a premium service.

It is very important to separate functionalities between the free and premium versions. The free functions are designed to keep hold of users. That's why it should contain enough so that the user gets some useful features out of the application and continues coming back. The paid functions should convince users to purchase. For example, if we give away too many free features, the user will stay but without making a purchase. And, vice versa, if we give away too little of free content, then the user will not stay.

We have now looked at application development from the birth of an idea to the promotion of an already made product. On the way, we have highlighted the most important features for a 1C developer. So, make use of our experience in developing mobile applications, and I wish you to achieve success with your projects. You have been with Nikita Baksheev. Thank you for your attention.


Be the first to know tips & tricks on business application development!

A confirmation e-mail has been sent to the e-mail address you provided .

Click the link in the e-mail to confirm and activate the subscription.