One day at Alfa-Bank: mobile development

Alfa-Bank was one of the pioneers of mobile banking: applications for iOS and Android appeared to him as early as 2010, when the opportunity to “top up the balance of the phone from the phone itself” was unusual. And what about the mobile development in the bank now, after all these years?

Previously, we published the text “One day in Alfa-Bank: Java development”, and now finally it’s time to continue, where we asked about work on iOS and Android applications. Ilya Tsarev and Anton Puhonin answered us. If you write their names as iLya and Anton, it becomes immediately clear who is responsible for what in the company!

“When in 2010, the habraiser announced the appearance of an Android application with Alfa Bank, he wrote,“ It took more than half a year to research the market for the need for such an application. ” Since then, mobile banking has become such an integral part of life that today these words sound funny. And how does this change in the world affect mobile development? You are not working on Alfa-Bank applications from the very beginning, but the last years have caught up - what has changed over the years?
')
Anton: First, the speed: now you need to quickly cut, quickly release, a lot of functionality to drag it into the mobile phone.

And the second is that now mobile first and even mobile only. The application should now have everything, even under-used. About three years ago my personal opinion was this: in the mobile application, you need the functions that you use at least once a month. If less - go to the site go, and everything will be fine. Something is used every few years, for example, card activation. Previously, I would definitely say: why is this needed in the application? Open the site.

Ilya: Insert the ATM.

Anton: At the ATM somehow completely bottom! In general, now it does not work that way anymore, you need to add it to the mobile application.

In order to develop such rarely used features as quickly as possible and spend less time on maintaining them, WebView appears increasingly in applications. In the “card activation” section, where the user visits every five years, he doesn’t need beautiful animations and an immaculately refined interface. He can poke the button once and forget about it. And if we develop this feature not in the native, but in WebView, we get development acceleration, because it is already implemented on the site, and the update speed, because we can update something in just a few minutes. This greatly influenced our work.

The life of JavaScript developers, of course, also influenced. Previously, you make up the screen and you don’t steam about the cell phone, but now you know that the site will most likely be opened on a smartphone, you need an adaptive layout, and there is also a native application, if you like to look like it inside the mobile. They set up CSS for us.

- The words “mobile only” have been sounded - does it happen that they add a feature to Alpha-Mobile, but not to the site?

Anton: This is not enough, but there is. For example, in the case of affluent (5% of the richest clients of the bank) there are bonuses when certain conditions are met (to have more money in the account than the amount X, to make operations more than Y per month), and certain related functionality is available only on mobile.

- Again, remember the post of 2010 about the appearance of the Android application. I was then uncomfortably surprised in the comments by its size of 29 megabytes: at that time, Android users had to count every megabyte, and the typical application weighed a lot less. Now it seems like other times, even in inexpensive smartphones there are dozens of gigabytes, but still there are posts “why the Facebook application is so big, it's crazy”. Therefore, it is interesting to compare: how much do your applications weigh now?

Ilya: We have 66 megabytes on iOS.

Anton: We have about 40, plus or minus five.

- Is there any problem for you now? Does it grow over time, do you have to make efforts to reduce it?

Anton: The size of the Android application is not particularly increased. The amount of code is growing, some libraries are being added, but over the past two years the application has only decreased. Google introduced VectorDrawable, resources are no longer stored in PNG boxes in 4 sizes, but simply by a vector pattern that weighs a few kilobytes. No soap in the app is visible in the UI. Now, from the big pictures in the mobile application, in my opinion, only a couple of backgrounds. Everything else stretches from the backend as needed.

Ilya: I have just opened the App Store - he writes that the application weighs 90 megabytes, but this is the unpacked version, it will take up so much space after installation. What is being downloaded, at the time of my arrival in Alpha weighed 60 megabytes, now 66. Why did it grow? Partly because of Swift, which was not there before. Besides the resources, yes ...

But, for example, I have 12 gigabytes of traffic per month on my iPhone. It seems to me that this is not a very urgent problem.

Anton: For Moscow.

Ilya: We have a distribution of users with a very large bias to Moscow.

In general, we do not do anything radical to reduce the application, and hardly anything special can be done. All PNG's shook, and constantly refactor the code, remove the excess. But even if you remove 100 code files, a maximum of one megabyte will go away, and that is if you're lucky. That is, all the simple things have already been done. New do as needed.

Now in the App Store limit of 150 megabytes when downloading via the mobile network, we normally go through, there are no problems. Here Facebook really weighs about 200 megabytes, and in the unpacked form 400. They have a lot of libraries there, all sorts of pieces, and at the same time they are also released very often. I read one interesting post about dimensions. There, a person wrote about application updates “why I have to download 300 megabytes every week, you're crazy”. But it seems that we all go to this story, all companies are trying to release more often, more often to make some value, and that's cool.

Anton: In the meantime, I looked at the exact size of the Android version: it now weighs 42.26 megabytes. In principle, we strive to reduce the size to the extent possible. All resources that take up a lot of space are cleaned, we translate everything either into a vector, or into drawing in the code, or into loading from the backend.

But this is like working on the overall quality of the code application. If the task was to “cut down the application to a minimum”, we would take it and cut it down even more. But why look for an extra job where there will be little result from it? In the product metrics, it seems that even if we reduce the application from 40 megabytes to 10, it will bring a small value to the product. It is better to spend time optimizing downloads, work speed, beautiful animations - it will be better for the user. Well, this is my subjective opinion.

- For users, Apple Pay and Google Pay support by the bank is very noticeable, but this story is not about the bank’s mobile application. When their support is implemented, are mobile developers required at all, and how big is their role?

Anton: If you just need to add Apple Pay / Google Pay to the bank, you need to involve mobile workers and you don’t need a front. But if you want to do well, then they will be needed.

Ilya: Well, for example, this is about the fact that we can suspend the operation of any digital card from the application. There is a list of devices where Apple Pay and Google Pay work, you can pause or remove the binding to them from the application.

Anton: But in general, the work is minimal at the front. Even if you set the maximum task and thoughtfully read the documentation, it is done in 2-3 weeks. The main work falls on processing - making friends terminals, agree with Mastercard and Visa. Each map binding is, in fact, a new virtual card. For her, a new identifier is allocated, and all the problems are somewhere in the intestines. And we just need to make friends with the application Apple Pay or Google Pay.

Ilya: Well, Apple or Google should allow it.



- The word "security" is associated with the word "bank", and how does this affect mobile development? For example, is it possible that all work should be carried out exclusively within the office?

Ilya: For all developers, there is a VPN that connects to our internal network, so it is possible to work on applications from anywhere in the world, there is access. There are logins, passwords, certificates on laptops, if the device is lost, you can simply block everything. In general, since mobile developers have no access to any combat servers, the risks are lower.

Anton: If we talk about the security of a mobile application, then most of the vulnerabilities are closed at the API level: all operations are confirmed by one-time passwords that come via SMS, filters are configured to block suspicious operations. With minimal suspicion of fraud, the operation is blocked and the call center operator calls the customer. Interaction with the server goes on an encrypted channel, implemented verification of certificates.

- More banks are associated with conservatism. How easy is it to use new in mobile (for example, how does Swift migration look in your case) or non-standard?

Ilya: We’ve been writing Swift for the last year and a half, starting with 2.3, now on the fourth. We look at new and unusual technologies openly, there are no prohibitions. From the curious, you can probably call the fact that we work with the UI only through the code and use SnapKit for this.

Anton: Yes, there are no prohibitions, but there is a common internal developer community. If you prove that your technology is promising, necessary and really useful, then everything starts to use it.

But here we must understand that the Alfa Mobile project is many years old, there is a big tail of functionality and a legacy. Much has been rewritten, of course, but the old one remains. And when a lot of people push the project forward, then ... When you say "your MVP is no longer fashionable today, let's introduce a stylish-fashionable youth MVRx", they ask a logical question: "Dude, now you will apply your new architecture, what will we do with the rest? We will have to support two architectures independently. ” And if everyone continues to carry what he wants, then it will be more and more difficult to live with it.

If you prove, roughly speaking, that the transition from AsyncTask to Rx is worth it, then we develop a plan, how we implement it, how to refactor the old one, so as not to drag out 2-3-4 approaches.

Ilya: That is, everything works through the community. Community accepts - so go.

- Does it happen that the community is split into two camps?

Ilya: It happens. Then the final decision takes the lead.

Anton: We, too, this happened. For example, with writing unit tests. We have two applications, for individuals and legal entities. When we thought how best to write tests, half said “let's write tests for Kotlin” (it was about a year ago), and half said “Kotlin is good, but writing Kotlin in pure JUnit is boring, too much code, let's we will bring Spock and Groovy. "

We looked at Spock and Groovy, half said “great, let's write like that.” And the other half said that the closures in Groovy are something beyond reason, and let's write on Kotlin. As a result, we now have tests written in one application on Kotlin, and in another on Groovy.

- How is the work of iOS and Android synchronized? New features appear simultaneously on both platforms?

Ilya: We are working on a scram, so each team is a small startup with participants on all layers, and it also makes a new feature on all layers at once. Accordingly, usually the functionality is ready about the same. There may be a small rassinhron on the release of versions: for example, the release on Android earlier, and the feature will be released a little earlier. Of course, we make big changes in the type of redesign.

- Your applications are installed on millions of smartphones, what is the impact of such scale? For example, do you have to mess with exotic things like strangely behaving little-known smartphones? Does it happen that even very rare problems cause a negative reaction from someone and need to be corrected?

Ilya: Yes, always, when you think “there will definitely not be such a case,” it will be 100%. When I just got a job, a month later there was such a case, when we thought “there will be no one”, and, of course, on a huge user base it all came out, and I had to edit. Yes, there are always such cases. Therefore, testing is especially important for us: both unit tests in the code that check their business logic (including some boundary cases), and UI tests that automatically check that business scenarios are working, and acceptance testing, where the tester checks that the layout has not got out anywhere and everything is okay, and regression when checking the application for non-deterioration of functionality by hand.

Anton: As for exotic smartphones: everything is clear in iOS, the base of devices is not very big, and Android is a zoo of devices. Despite the fact that the main bugs in the application are fixed, sometimes on Chinese no-name devices some kind of unexplainable space occurs, and the application crashes.

Sometimes Android itself crashes, with this we can do little. Sometimes failing modified firmware device manufacturers. Solving such problems is trivial: we are looking for such a device and find out what the cause of the defect is. “Guys who have such a device in Moscow, let's test it” - frequent messages in our corporate chats.

A couple of years ago there was a case when the same reviews “did not work” were from one device in the Play Store, nothing was clear, and then we went to the store - “Can we see this smartphone?” We got it, we pretended that within 30 minutes we decide whether to buy this device for a conditional thousand rubles, and in fact put up a special assembly of the application, found the cause of the fall, came to the office, fixed it, reloaded it. There, the problem was connected with the resolution: the device was large, and the resolution was somehow very small.

- To “sometimes Android itself”: do you feel any pain from his side? For example, Google can take the Doze mode to limit applications - does it hit you?

Anton: Let's put it this way, it’s worth starting with the fact that Google presents everything in advance: it describes the changes, it talks to I / O, and it releases new versions for developers in advance. And we are trying to close everything critical in advance.

Sometimes it takes effort. When runtime permissions appeared, it caused a lot of pain, I had to sit for a week or even more, catch all cases in the application. But if you follow the news, then you will not have sudden problems at the time of release.

And problems with Android as a whole ... Well, for example, last year we had to give up support for Android 4.0. Why? On so many devices fell WebView. There was no AsyncTask stupid, the system could not find such a class. We looked at what solutions there are, and nothing came up to us; we had important functionality implemented using WebView.

It was necessary to do something, and we decided that it would be better to leave users with a version lower than 4.1 (there were 2-2.5% of them then) on the current version, and further updates came out only for 98%.



- In the presentations of new versions of iOS / Android, you can see spectacular things like ARKit, but augmented reality is clearly not about you. When the new version comes out, how much does it affect you?

Ilya: Well, just the augmented reality is actually about us! Now I’ll launch it on my iPhone and show, we can look for an ATM in augmented reality, driving the smartphone around. This has long been done, not yet on ARKit, of course.

In general, about iOS updates - that's when from iOS 6 to iOS 7, the interface was completely redone and completely broken, then everything was broken. I was still not working at Alpha, but in another project we had two months passed, it was horror. And after that everything is easier. In iOS 11, it seems that nothing drastically changed for us, although Apple did a lot inside, for example, its file system - this is generally cool. By the way, after the update, all the photos from my phone were erased. It's good that the backups remain, then loaded.

So from the innovations of iOS 11 for us, little is relevant. It is clear that we use technical things: we are switching to new versions of Swift, Xcode. This is a normal process, such that everything is broken, not there. Even with the release of the third Swift, when there were many groans in the industry.

Anton: Here is the latest update Android did not have a very strong impact on users, but it really really affected just the developers. They presented a lot of things there, we immediately began to look and think - for example, they decided to do the new functionality on Room, this is the database that Google introduced. And Android Architecture Components also immediately interested, although initially they were too wet for us to be ready to use.

And from the new user - Instant Apps is a cool thing, which we also noticed, but did not rush to introduce it. It would be desirable, that any section of the application could be started through the Instant App, and this requires deep refactoring of the entire application. The scale of the application Alpha Mobile is very difficult and time consuming. I hope in 2018 we will be able to implement it.

- In iOS 11, CoreML was also added, how important is machine learning for you?

Ilya: CoreML in the form in which it now seems to me to be of little relevance. He does not know how to retrain models, only use ready ones. It would be cool if it was possible to train the model for a specific user who uses this particular device. For example, everyone pays for a mobile phone for 500 rubles, and he pays for 50. And we now give him to give 500, because everyone pays for 500. It would be better at 50.

On the back end, this is more relevant to us. For example, predict what transactions the user will have. If he has any regular expenses, for example, he pays utility bills every month, it can be predicted with a certain probability that they will also be in the next month, pre-fill the data, and send a notification. We are now developing this area.

- According to our Mobius conference, we see that there is a lot of talk about architecture in the mobile world. What do you associate with it, and what do you have with it now?

Ilya: It seems to me that mobile projects and startups that have survived and become successful have now grown. They have a lot of legacy and a lot of developers. Therefore, at some point, it became clear to all that at MVC we would no longer survive. Something is going wrong. We can not support it. It is necessary to redo something. And therefore, more and more, it began to flicker.

We have a similar story. Of course, when we have a lot of legacy and a lot of developers on the project, we can no longer write on MVC, because we will be doing an elementary feature for a month. Of course, they began to think about tests, about re-usability, about how to make it all readable and supported.

, MVC , , MVVM. , . , MVVM -, - , . , - , , , . Mobius , « , , , , - , ».

We did just that. They took MVVM, took VIPER, found an article on Clean Swift, thought: "This is also an interesting topic, let's try." They sat down and for the week wrote the same module on different architectures. Then they sat down and discussed together: here, look, we have a piece on MVVM. What do we like and do not like in it? Is there a VIPER piece that is in it? It was the same code, the same functionality.

We decided that in our case it would be good to take Clean Architecture and adapt it for ourselves, and finally we did what we called “Yet another architecture”. And it seems he comes in well. Of course, we immediately went to talkabout him on mitap, because HYIP, another architecture, all such “ooo, and kill VIPER or not.” About "kill", of course, we'll see, we did not set ourselves such a goal. Just offered an alternative.

Anton: Yes, my opinion is similar. Android was introduced in 2008. Began to create small applications. A sharp increase in development - probably 2010. And slowly began to grow teams, applications, mobile-only trends. When a team grows to 5 people, it is necessary to introduce standards so that the application does not fall apart, it can be maintained and effectively refined.

Google had, it seems to me, not a blunder, but a flaw: they did not pay attention to the lack of a pronounced architecture. There were all sorts of tools, IDE, SDK, and there was no architecture.

2010- Google I/O Google , -. , , — - , , . — , . . , , , - . , , , : Java , iOS VIPER.

Now the teams are getting bigger, so they take standard approaches or invent something of their own. And the bigger the team, the more rigorous the architecture is needed. I liked the phrase “The code must be impersonal” from the last meeting of Alfa-Bank.

Ilya: Reuse is also important. This is due to the fact that the business says “faster-faster-faster”, competition is growing and many companies are going into mobile development. If you don't have a mobile app right now, this is weird. It is necessary that it is fast and supported, and this leads to the relevant standards.

- We have questions ended, do you want to add something from yourself about the mobile development in Alpha?

Ilya: . . CI, , Grafana . DevOps-, - . , — , : — .

. , , , -, , , , - . - -CI…

: « » « »?

: … , , CI! That's cool.Not everywhere like that.

Anton: And I'll tell you a little differently. When an Android developer comes for an interview, I always ask him: “Would you be interested in working with us at all? What tasks do you want to solve? ”

Someone says:“ I want to figure out the food features so that I go into the application and immediately see the result of my work ”. Someone says: "I want to cut something root, on C, under Android, so that everything is super-optimal." And here we have to disappoint the second, that we have practically no such tasks. You are sent a sample of JSON, which should come, you insert it in the right place, write tests, do the rest. Much depends on the layout, it can be complicated, it can be simple. But all this on average takes a little time, and rarely comes across some non-trivial task.

We have the most interesting and challenging tasks in another area now - in the area of ​​scaling. We have a growing number of mobile developers. And how to make 20 people work so that the code does not degrade, is supported, the number of bugs does not grow, the speed of development does not decrease? And for this we have done a lot.

Suppose by CI. Previously, we had one Mac Pro, we did builds on it. After some time, we began to miss him. On Friday, everyone finishes sprints, starts a huge number of assemblies, and your assembly can stand in line for an hour, or even more. Therefore, we decided to use the Android team to transfer all the assemblies to the servers in the cloud services. And to do this, wrap the infrastructure in a Docker container. And use the Jenkins Pipeline. In the Android world, DevOps is not spending much time. And we really need it, and a lot of strength was thrown there.

Also a lot of testing tasks. We have the principle “everyone covers their own code with tests”. But there are people who work with tests a little deeper. They are engaged in the study and integration of new frameworks: Spock, Spek, Espresso. They automate the launch of tests and verification of code coverage by tests. In a word, they do everything so that others write tests effectively.

, . ? , , mockup — , , , . , , . , , , - , - .

— !

Mobius , - . , , !