““ Make an application for people ”- this is not to be scribbled on the knee”: about mobile development in CFT

What problems arise when increasing the mobile team by 10 times? For what reasons, in the same company, Android developers prefer to use well-known libraries, and in iOS they often write their own solutions? What is life like for mobile developers in fintech?

The Center for Financial Technologies took part in our Mobius conference, and in this regard, we asked two CFT employees: Kirill Zuev was responsible for iOS , and Mikhail Emelyanov was responsible for Android .

The text turned out so expanded that we even made up a table of contents so that it would be easy to go to a specific part:

• About the company and mobile development in it
• Mobile team growth
• Third-party solutions against internal development
• Swift and Kotlin

About company

JUG.ru Group: Introductory question: tell us about the company and what you personally do in it.

Kirill : It’s impossible to tell briefly, since the CFT business areas are very diversified. But try the “big touches” about the most popular products and services.

CFT has been operating in the Russian fintech market for the third decade, and we say that we did fintech when such a concept did not exist.

Today, CFT is both processing and production of software for a large number of various financial organizations, insurance companies, state corporations, and retail.

This is the Golden Crown ecosystem, which includes a pool of services of both b2c and b2b format: online currency exchange, cash and online money transfers, loan repayments, loyalty programs, transport and social cards.

The processing center "KartStandart": issue and acquiring of cards of payment systems Mastercard, Visa and "Mir".

The Federal System "City" aggregates several tens of thousands of various services: from paying kindergartens and utilities to making tax payments and replenishing transport cards.

Faktura.ru online banking services are used by more than 130 banks. The CFT automated banking systems are used by even more different organizations.

The CFT employs large R&D, ML and AI divisions, which are integrated into almost all areas of the company. We have a powerful information security team. In general, these are more than 3,000 people who have been busy solving fintech tasks for the past 26 years.

One of the CFT “young” products is based on the service “Golden Crown - Money Transfers” (which is already 16 years old) - it is “Money Transfers Online”, a direction that we launched in 2016. And today it is a locomotive of mobile development in CFT: in total, 70 people work on it in iOS and Android. And this number continues to grow, we plan to grow to hundreds by the end of the year.

There are also mobile directions in the “Prepaid cards” divisions (they are developing solutions for the “Corn”, “Beeline”, “Kari” and other cards), in Faktura.ru, the “City” System.

And Misha and I are just in the “Online Money Transfers” division engaged in team development, expansion, and introduction to development processes. Initially, we worked in the "Prepaid Cards" Directorate, the teams were small, platform, and we lived in the concepts that were in 2014-2015.

Mikhail : When everyone is sitting in the same office, they work, communicate.

Kirill : Such small warm and lamp teams, for 10-15 people, taking into account everything - both testing and the backend. And now we have new challenges.

Michael: Yes, organizing the work of 10 developers is one thing, and 50 is another. This includes all the processes for the development, scaling of the team, its professional development, and the project itself: if our engineers solve technical problems, we are engaged in the development of the project architecture. We are looking for problems that will interfere with the scaling of this project, and try to solve them in every way.

JUG.ru Group: We will come back to the issues of growth, but for now tell me this: how is mobile development in CFT different from other companies, and what is similar? What you need to know about it for those who have never worked in fintech? Do you need any special knowledge at the interview stage already?

Kirill: When we talk with candidates who come from outsourcing, they have a desire to work in a product team, a desire for stability. But they always have concerns: is fintech a kind of swamp, strictly regulated and surrounded by security, in which it will be uncomfortable to engage in self-development from the point of view of the developer.

We always tell that in our case mobile development is exactly the same as any market product development. Fintech is not a word to describe the way of life, but simply a line of work, something that we face every day.

These are the same mobile banking clients, various payments, contactless payment services and so on. But this does not mean that you need any special skills or knowledge: any cool mobile developer is able to start doing fintech if he is interested.

Of course, we need minimal knowledge at the primary level: what does a bank card look like, what is a bank account. But if there is deeper knowledge, then this makes it easier and faster to understand the wishes of analysts. There are developers who want to understand not only “how to do the task”, but also “why.”

There is also its own specificity, for example, the requirements of the regulator represented by the Central Bank. But, as a rule, this is all taken into account in business requirements and it is enough to read them, ask the necessary questions, and everything will be clear.

There are certain points from the point of view of information security, this is understandable: fintech is about security. But I can’t say that mobile developers are the first line of defense. Still, fintech products are designed in such a way as to be safe on the backend and data storage side.

Yes, it happens that a developer comes from a startup and starts saying that the API could be designed better: they say, here you can make one request, and we do three. But this is due to the fact that the API is designed in such a way as not to give the entirety of the information. And when the developer understands that this is an engineering decision, and not a stupid move on the part of the developers, he immediately accepts.

And from the point of view of security of mobile applications, we had a report on the past Mobius. We did not discover America there and did not show hacking tricks, but showed a checklist that a fintech application developer must go through in order not to make silly mistakes:



We don’t commit them, because there is a code review and there are recommendations from the security team who made us an excellent checklist. It states where the vulnerability should be worked out and by whom (on the side of business intelligence, backend developer, mobile developer or tester ) All these areas of responsibility are known to us, we just follow the rules.

It is important to understand that we are not just sawing boring cans, but trying to turn our faces to customers, including the technological side. Therefore, we are always for innovations like contactless payments.

Our iOS “banks” in 2018 took 4th and 5th places in the Markswebb ranking in the Daily banking category.

We are trying to be an application that “is not ashamed to show mom”, which can be used by people far from smartphones, and those who understand a lot about technology. Why are some mobile banks successful and some not? Because they are made technologically, with animation, maybe even with some kind of cultural references.

Michael : I’ll briefly add that we are really focused on customers - living people who walk the streets. Since we carry out operations with money, we strive to make them as usable as possible, easier for people.

At the same time, when employees come to us, they need to understand what to truly “do for people” is not to scribble “as I see” on their knees. Before working at CFT, I did almost all of the design and UX myself without a designer. But the company doesn’t work for us like that. There is a whole UX laboratory with designers who conduct experiments, and there are focus groups that test hypotheses.

And when a person comes to us, he must understand that everything will be focused on making it easier for the client to use the product, so as not to die when filling out a form of 50 fields. The work is focused on the needs of the end user.

The second is code quality requirements. We have really high requirements for quality, review, clean architecture, application of SOLID principles on all layers. It’s unacceptable for us to sacrifice quality for the sake of time.

And this is adjacent to modern technology, there is no lag behind the industry. All Android products are now written in Kotlin, and iOS on Swift. In Android we use Rx, Dagger, in some projects coroutines. When new developers come, we regularly ask for feedback to understand what people like and dislike. And I don’t remember that the employees complained that something was outdated and offered to change something. We only have time to throw ideas, “let's try MVI in such and such a module”, and everyone starts to generate.

When a person comes to our team, he should be ready to understand the modern technology stack and be able to navigate it. We welcome this. This, perhaps, is even a paradox: a person goes to fintech, to banking development, expecting conservatism, and he is required to know how Rx and Kotlin work with all the goodies. This, it seems to me, is a unique feature.

Mobile team growth

JUG.ru Group: You already said that you are solving problems that arise with the growth of the team. Is there a concrete example?

Michael : For example. When six people in a team conduct a pull request review, 3-4 people in a pull request, they pass quickly enough (especially if people are in the same office). The situation changes dramatically when employees work in different cities and time zones, and the team grows and separate cells appear inside it (development teams united by one team lead).

We noticed that with an organic increase in the number of reviewers, pull requests began to linger already up to 5-6 days. This was a problem: we could not deliver features to the business on time.

There was also a problem with git flow: if you sit in one branch and saw for a long time, at that time the other team can also saw 2-4 features in other branches, and then all this is frozen in the branches by the release dates, we get pain in the form of a merge conflict.

The second problem was solved by changing git flow. They began to apply the trunk-based development approach, that is, pouring directly into the development branch, abandoned feature branches. But since pouring inoperative functionality is impossible, this will break the project, then we applied the feature toggle approach. And thereby reduced the term for issuing functionality to the release branch by several days. I talked more about this on Twitter @mobileunderhood .

There was a problem with the review. Previously, about 4-5 people took part in us, since the quality of the code is important to us, we have fairly strict principles and approaches to quality. We were afraid that if we reduce the number of reviewers, our quality will deteriorate. In this case, for 50 developers, for example, 30 conduct quality reviews, and the rest are junior developers or middle ones who have not yet developed a real skill.

Therefore, we took a different path and came up with the formula “1 lead + 1 senior developer + 1 any developer”. At first, we used this formula within the framework of teams: for example, the developer of team “A” issues a pull request, puts a review with the curator and some individual developer. About 20 pieces of pull-requests appear in a day and a half: if in the morning we conduct a review of everyone, then by the middle of the next day there will be about 20 new ones.

But we ran into another problem. If a developer constantly puts his lead and a neighboring lead from another team, then the leads become overloaded. They are less involved in development and spend more time on review. About 20 pull requests are serious work if you approach it qualitatively.

And we went even further. They left three slots for reviewers, left the same roles (tech team, senior developer, and any other), but did not bother that it should be people from your team. And now we have pull-requests taking place in a day, a maximum of one and a half. No more long stories.

And all this in combination with feature toggle: when a developer takes on a feature, he first of all makes a disabling flag in the code so that it is on a cold start. And then it starts development. All this is checked in one day, no matter what city the team is in.

A separate story with time zones. If we do a pull request in St. Petersburg, we donate by the evening, then in Novosibirsk +4 hours, and while we have another night, they already watch pull requests in the morning. They leave work - we get their pull requests and watch. It turns out a constant continuous stream in which time zones work on hand.

Kirill: Yes, returning to the question about the company: in addition to the fact that we have more than 3,000 employees, our development centers are located in three cities (Tomsk, Novosibirsk and St. Petersburg), and mobile teams are distributed among them. It’s a little complicated that there is a lag of four hours, but the total working day of the company is extended to 12 hours.

Michael: Time zones help more than just reviewing. We have formed a single Android-development, there is no such thing that in different cities everything is separate. Our teams are cross-functional, but united by platform characteristics, as communities. There are standards, general principles and accepted practices, including code style and the like. And therefore, if suddenly problems arise that require a hot fix or other urgent action, I can take on those who now have working hours, even if they were not originally responsible for this code. People in other cities can help while we sleep, and vice versa.

JUG.ru Group: When a team grows, no developer can already know the whole code base or it’s easy to clarify anything from a person sitting nearby. In this case, probably, another challenge arises: record keeping?

Kirill:Here it is worth saying this: when we planned the team to grow 10 times, we realized that we would not release 10 times more features (or even 7 times). With such growth, just to maintain the previous level of quality, additional efforts are required. And one of the exercises for new developers was just writing the documentation before starting to do something.

Thus, in a short time we covered the key components of the application in the documentation. And they started to let the jones into such components, because with such documentation it is already possible to afford code reviews and testing. It was a “delayed exhaust" zoom.

Now that a year has passed, we have prepared the base, and now we bring developers who came a year ago to the full level of productivity. The further we go, the easier it becomes. Based on the created documentation, we built checklists with the structure and interaction of the components, with our integration with the main services, and now all this does not cause a panic: “I came here to program, and you have an enterprise here.”

Michael: I will supplement Cyril. After the team had more than 30 employees, there was a period when team leaders and senior developers spent a lot of time on one or two supervised developers, because they constantly transmitted information. We understood this in advance and began to act. Therefore, Android allocated a separate space in Confluence and there gathered all the principles, practices and conventions for the development not only in this project, but also in others.

When an employee comes to a team, he first sits down and studies how we conduct development, what are the rules and practices, and what architecture of the project. He doesn’t even take up the code while studying. Then answers the control questions. Any training without security questions is not effective enough.

Now we have gone even further and are creating the Galileo automated training system. Its essence is in several levels of gradation of education, from the principles of development and methodologies, from architectural principles to the principles of the Kotlin languages.

After such an immersion, half of the questions are swept away. What the lead did before is now automated. When the developer goes directly to the production, in a week or two, he asks pointy questions, which is not a problem. And before that there really was a problem.

I believe that even if the project is for 10 people, you still need to lay documentation in advance. Do not run into this matter, but lay down some principles. There will be a scaling - it will not, and in any case, when a new developer arrives, the documentation removes a bunch of questions and saves a lot of curator time.

We have platform documentation (for Android and iOS), and there are projects (business scenarios and the like).

Kirill : We switched to some crowdsourcing. When a newcomer arrives, they say to him: “Look, this is what to read on the first day, here on the second.” There, setting up, providing various accesses, tools and so on. And if a person is faced with a problem, one of his tasks is to write the problem on the same check list for the next newcomer. Such things pursue different goals at once: we also prepare documentation for the next generations, and teach the beginner the value of documenting what he does. And he has no fear of what to write.

Particularly zealous immediately begin to draw UML diagrams, which is encouraged. Once someone sets a good example, everyone gets involved. And we are not beating anyone, as we understand that time is needed, and we give this time.

Third-party libraries against internal development

JUG.ru Group: I would like to talk a little more about the “inner kitchen” in the context of iOS and Android. As far as we understand, you have on iOS a policy of rejecting third-party solutions, but Android initially also tried to write everything themselves, but then left it. Why?

Michael : Android has historically been this way. In 2013, when we were making a mobile bank for the Kukruza card, there were almost no standards for architectures and libraries in Android development. Even Google itself did not understand where it should develop Android. We started development when there was no Android 5 yet, we had KitKat 4.4 as the maximum version.

Since there are no libraries, we write ourselves. The self-written works more efficiently, it is better to accompany it, and other people's jambs are more difficult to fix. We took only basic things: for example, we used the Volley HTTP client before, and on top of its own API protocol like Retrofit (but less flexible). And they thought we were cool. But time passed, new technologies began to appear. Dagger began to work not through reflection in runtime, but through code generation, the same Retrofit appeared, the word “architecture” began to be pronounced, standards and patterns appeared.
Business came and asked to do something, but we understand that it’s not so flexible, and you need to change and refactor something first. There was such a problem with Volley. And we thought that we were really lagging behind time, because instead of business tasks we were engaged in refactoring and editing the technology stack.

We also began to notice that development engineers became less interested in working on the project. The stack is old, in the hype world, Rx has appeared, but we have nothing. The employee could work for six months, complain about boredom and leave. This was a problem for us. We now devote as much time as possible to the development of developers. A modern stack should be present not only to solve problems, but also to make it interesting for engineers to work and offer something.

If the company is constantly busy with bicycles, the engineer says: “Listen, we’ve found a wonderful library here that will do better”, and they answer him: “Something is somehow not there, better come on later,” it demotivates.

We completely abandoned this approach, we decided to make maximum use of world practices and libraries, so as not to waste our time, but to engage in business features. Just then Kotlin began to spread, we still somewhere from version 1.0 began to use it. We began to incorporate cool technologies, best practices and approaches to architectures. And we managed to keep up with the times and put the processes on stream.

When the story of rewriting the Money Transfer application from the Golden Crown went, we already had experience. And now we are not dealing with technical debts in libraries and bicycles, but with business functionality. We have one of the most modern stacks and we support it.

Some companies, on the contrary, use a more transitional practice: first, a deep analysis, they look for some advantages, cons, and only then they collectively implement the project. This was also the case with us, but due to the fact that the team is large, it is possible to experiment, the whole architecture is built in such a way that the project does not break during the experiment as part of a module. We create experimental prototypes, immediately test the technology. Because time is expensive, you need to release business functionality, and not engage in long analysis.

Kirill: We in iOS, in turn, are not ideologically for bicycles. We have pragmatic solutions. We need to do something - we estimate how much it will take time. If it’s some kind of framework like AFNetworking, how long it may take to implement is 40-50 hours in the volume we need (we don’t have to implement it completely). Therefore, we allowed ourselves this.

Last year there was a demonstration report on Mobius (there is a transcript on Habré ): Felix Kraus talked about the security of third-party solutions. He tended to the fact that not everything that was downloaded from a third-party repository is always what you wanted to download. But for the most part, this means that we must audit the code that we accept for the project.



As for the network subsystem - who knows what kind of processing of SSL certificates is there and whether we have enough time for this entire audit, as well as the ability to reverse-understand what the engineer wanted to do.
In addition, mobile development, in principle, is developing very quickly, frameworks and technologies flash bright stars and fade away just as quickly. For example, ReactiveCocoa, which was the flagship of reactive development 4-5 years ago. Firstly, where is he now, and secondly, what would happen to us if we switched to him? If you had long and firmly hooked on him, and then Swift came, you would generally be in an awkward situation.

If there are seers who are willing to appreciate the long-term nature of the technology, it is very healthy, but we are not seers. On Android, in the case of solutions like Dagger, the difference is that it is a solution from the platform’s provider, Google. If Apple issued something like that, we would go over. Well, she betrayed Swift, and of course we switched to Swift.

We have been working on the product for 6 years, and some pieces of code in general from 2011. Let's look at 6-8 years in advance: where will the frameworks made by enthusiasts and the community be? I’m not ready to guess on a crystal ball, so all we have allowed ourselves is SnapKit (because everything is convenient to browse in one file) and, of course, service frameworks — analytics, crash log collecting systems, yes. We do not specialize in these areas, and are not ready to develop and raise a whole service in order to conduct our service business.

Everything else is a matter of thought. A certain trend appears, we, engineers, discuss, consider and decide that this or that technology requires our attention and implementation in the part that we need.

But let's face it: from the latest iOS super innovations, only the appearance of Swift can be distinguished. Everything else is just constructions that are made by engineers that can be repeated, which are not always equally understood by different people. Almost everyone UI-architecture, anyone you ask, everyone sees in their own way.

Swift is the direction in which former Objective-C developers want to develop, there are still quite a few of them. Here they get a technology stack that is changing, an opportunity for self-development, sharing knowledge and about what they read, learned, put into practice ...

And when 3 years ago our “ultramodern architecture” at VIPER stopped satisfying our business tasks, we simply said: “ok, we will have an MVP similar to VIPER”. And within the framework of our MVP approach, we are now solving a business problem with a sprint speed. This is the indicator we are striving for, and in terms of production, we have achieved it.

Swift and Kotlin

JUG.ru Group: Michael in @mobileunderhood wrote “we are leaving Java altogether, we are rewriting everything on Kotlin”. Usually, even when new code is already written in Kotlin, existing in Java is changed very slowly, and it can remain in production for many more years. Why did you decide to do it more actively? And do you get rid of Objective-C code as actively in iOS?

Michael: I always liked Java. I always loved her, even passed the Oracle certificate, and she was fine with me. But the development of Java in Android and the development of Java in enterprise are two different things. And a few years ago, when Kotlin was just starting, using Java in its bare form without libraries began to tire. Long constructions, a little syntactic sugar, here some colleagues with C # also threw what they have, but we don’t, it generally demotivated. I wanted to write code that runs logic, and spend less time writing this code itself, use more goodies, it’s easier to understand and read the code.

Then came things like Lombok. At first I liked it, and then it stopped, because this is some kind of additional library that allows you to simplify the code, wrap it in syntactic sugar, but this is only a plugin, not the Java compiler itself. And the Kotlin Data Class and the regular Java class with all the property and get / set encapsulating methods are completely different things.

And we decided for a long time for the first time to try Kotlin at the level of one project. We wrote it, some things confused us - well, Kotlin and Kotlin, we kind of tried it, okay, there is one project, we return to Java. They returned, and after some time I realized that I could no longer develop in Java. That's it, I'm tired of her, I can’t see her anymore.

Apparently, I got used to some syntactic things, to the minimalism of the code. And in the end, it was decided that we need to use Kotlin. It is better perceived and read. Some developers were against it, but it seems to me that this is a matter of habit. Introduced practice: write new projects on Kotlin. And the old projects remained in Java. But when some major refactoring took place, we copied everything to Kotlin. We have gained experience to do this quickly. This does not mean that we converted the Java files to Kotlin with hot keys, and then fixed this code - we ourselves rewrote it immediately in Kotlin-style.

There are literally two Java projects left, and the transition is gradually going on there too: new modules are written in Kotlin, new tests in Kotlin, and the old logic in Java. If the logic changes due to refactoring, we write in Kotlin. And one of these projects is undergoing a lot of refactoring right now. Thus, we put the migration on the stream, and after two years with Java there remained literally one and a half projects.

No one was particularly opposed. There was some skepticism “Kotlin is just hype”, of course, but it really helped us when Google officially recognized Kotlin for Android development, for us it was just a bomb. It was no longer necessary to convince engineers: either you are on the wave of all modern developers, or outside this market.

Kirill: And with Swift, the very first meeting was this: I needed to make a small presentation for one of our conferences in Novosibirsk, and when I brought a piece of code to the screen in Objective-C, it became clear that it could not be read at any screen size. And then I wrote that piece of code for the presentation in Swift, although there was not a single “swift” line in the project.

Then we tried Swift on the Golden Crown Transport Card project, which we wrote from scratch. We ran some language moments there. It was interesting what we were doing wrong, a bit started working towards creating our own styleguide. From the second Swift we also “moved” to the third, took a sip of grief, which then haunted everyone.

And if you look at the pull requests we have now, 95% of the Swift code is written there. We don’t have a super task to transfer all available code from Objective-C to Swift at any cost. Nevertheless, the share of the Swift code in the Money Transfer mobile application is 60-65%, we issue a “swift digest” in which we draw a graph for Swift / Objective-C files, for lines of code, and depending on the release and date everything is seen. A 65% share does not mean that we copied 6 files out of 10 - primarily growth due to new files.

We tried different transition techniques, for example, in the mobile bank for the Corn card, we made a unidirectional transition (that is, our Swift code is based on Objective-C, but we do not transfer Swift constructs back to Objective-C). We are not dragging Swift functionality to speed up the process of switching to Swift in this way. In this case, when it really gets snappy and Objective-C code requires all the Swift dependencies, we can say that it’s time for the component to completely switch to Swift.

Since products for the Golden Crown - Money Transfer service are more important than development speed than simply increasing the share of Swift, we have bi-directional stories. They may look less beautiful from the point of view of Swift adherents, but since this approach gives the product the ability to move faster.

Developers came without any knowledge of Swift, the language was mastered in two weeks, it began to work. Sometimes they are afraid that we have 60% Swift, but it's okay, there has not yet been a case where an employee was not able to master it. There are opposite stories - when they find out that we have 40% Objective-C, they begin to say that we are retrograde, and you need to first rewrite everything on Swift, and then cut features. But here everything is individual, and we work with each individually.

There are mixed projects, unidirectional mixed projects, there are clean projects on Swift, we tried everything. Everything works pretty well, there is no silver bullet.

JUG.ru Group: About Swift and Kotlin they say "because they are similar, it has become convenient for developers for Android and iOS to look into each other's code." Do you have developers for different platforms looking into each other's code or not?

Kirill : I remember stories when Android developers who wrote in Java looked into the code of iOS developers on Objective-C and vice versa, when we wrote one of the most complex components of the mobile application for the Corn map - the famous form designer, An example of Backend Driven UI architecture. There is a very intense interaction with the backend through a certain protocol, and not doing it the same was simply criminal. Of course, we peeped.

And now we have different architectural approaches in applications, applications are based on different UI architectures. The maximum where we can peep is the business layer, and even then we should rather dig in the direction of testing tools that allow you to write in one of the programming languages.

Applications, in fact, are a client for the service. For the most part, it responds to user input and displays data from the server. Somewhere to write something completely wrong is quite difficult. And in this sense, perhaps, there are some examples.

Michael: I have examples. Since we now have cross-functional teams, iOS and Android developers almost simultaneously do the same business functionality on different platforms, they look into each other’s code less and less, because there is nothing to look at, and the whole development goes smoothly.

But when someone goes ahead, at the same time, the person realizes that some of the most chips are implemented, when the business hints “look at how Android is done,” and analytics is not ready yet, there are times when developers from both sides can drop by and see how it's done. And here it really helps that Swift and Kotlin are very similar.

In mobileunderhood, I shared my experience that I had when I worked on a project in which we did not have a cross-functional team, but a startup on loan repayments. And I liked to look into iOS development, it was interesting how they solve certain problems, maybe even throw something to them. And they loved to throw me. And we constantly, for hours could stand at the blackboard and talk about how pure polymorphism looks in iOS and Android, how to cook it.

It comes to discussing what abstraction is, to some kind of formal concepts, and it all happens rather fun, and starts with the usual code. You look and think: why did you do this, is there a lot of overhead? And they explain to me that everything is planned and consciously go for it, so as not to spend 2-3 days searching for the best solution, if, for example, this code changes through the sprint. I think: smart guys, we need to do this sometimes, and not think over for five days some kind of internal architecture, about which it later turns out that it is not needed.

As a result, I often came up and looked at the Swift code. Looked at Objective-C too, but I like Swift more. Although I didn’t develop it, I don’t think that there would be any difficulties writing code. Android developers have the same thing.


Kirill: In general, we do not just have a platform team, inside of which we tell them: “You are the best because Apple gave such a tool.” The guys from iOS and Android interact, participate in planning together, and work on issues with system analysts.

And they also act together in relation to backend developers if they try to come up with some not-so-suitable API. And in this symbiosis, they can spy everything in the repository, we have an open system, and all developers have access to the repository.

In the “Prepaid cards” directorate, we had stories when backends were sewn up, and then Android developers set up the environment, the environment and filmed a couple of bug fixes, just to help.

Michael: I recalled a very recent case. There, in order for the client to be more subtle for us, the backend needed to do more work, then our mobile tricks joined together and began to push through their general idea. They all came together, discussed how they would be comfortable on both platforms, went to the backend developers and announced how they are more comfortable working and what violates the concept of thin client. Backenders agreed with them.

Now, if one platform said: “We will do everything”, and the second refused, saying that it’s hard, then they would force the second to somehow agree and do. And so it all happened together. Therefore, synergy, team development is working. And languages ​​really help in this. After all, if Java and Objective-C are completely different hemispheres in terms of syntax and principle, then Kotlin and Swift are really much closer.

Kirill: By the way, there are examples when the guys became switches, and even double switches, switching between platforms. There was one who switched to iOS, got acquainted, “got his hands on it”, and went back to Android. And then he left at all in DevOps. In this regard, we are also open, such moments are simplified.

It is great that the guys want professional development, even on different planes. We give opportunities, and they themselves choose which way they want to develop, and almost all of our guys are motivated by the product, by the tasks that they work on, which is very cool.

JUG.ru Group: Last question: what about cross-platform development?

Kirill: We have a product in development for the Federal City system. That's where React Native is chosen for implementation. And we do not feel any jealousy for this, because it is always interesting to conduct an experiment and find out how it will end. Moreover, we have front-end developers who are well aware of their business, and it is interesting to try something new and enter new platforms.

Michael : We have projects on React Native, but this is rather a bit wrong, because it is done by front-end developers, and iOS and Android developers do not overlap much.

As for the cross-platform, I personally see it for small teams: when there are few resources on iOS and Android, and the project needs to be done for both platforms, why not. We have enough resources, and the products are technologically sophisticated, we can afford a separate development for iOS and Android.

It also historically happened that when we did most of our projects, there was no cross-platform yet. Now, naturally, we would think about separating a part of business logic and abstract logic into general modules, because no one likes to do one job. But historically, we do not have this.

However, this does not mean that it will always be so. We have many promising tasks and projects from business, there are prototypes, and sooner or later we will try either Kotlin Multiplatform from JetBrains or Flutter, which is more interesting for us.

Cross-platform has not yet been standardized in an industrial form, in which you can take and use it in an enterprise. Judging by the communication with cross-platform developers and their reports, now there is a constant “rake run” and problem solving. Therefore, you can take and file a project, but more often it will be just a fight against a rake, and I don’t think that business features can be sawn efficiently. Recently, JetBrains was asked at the report whether it is possible to use the multi-platform version of Kotlin in production at all, and they say that it is still in an experimental form.

At the other end there is a Flutter, which took off in the last year, this thing is really interesting, Google is not weakly invested in this business. And I know that many do pet projects on Flutter, which are already laid out in application stores. And this is more interesting for us. We got fed up with Kotlin a bit, with Kotlin / Native we have to collect a lot of rakes, but Flutter with Dart is a completely new thing.

We love everything new, so we will definitely have cross-platform development. Not specifically in the Money Transfer application, but in some small separate applications it will be.

JUG.ru Group: Thanks for the detailed answers!