How we updated and rewrote the Otkrytie Bank's iOS application: case
In the life cycle of a mobile product, sooner or later there comes a time when you need to radically upgrade. Because over the time since the launch, business requirements and customer expectations have increased, platform capabilities and development tools have changed - and it becomes impossible to implement updates by “redecorating”. In the world of mobile applications, the software life cycle is 2-3 years versus 10-15 years in the regular Enterprise segment. For us, with the “Discovery Digital” team, the moment of a radical update of the mobile bank came at the end of last year.
The Otkritie Bank mobile app appeared in the AppStore in the fall of 2014, when users had iPhones of the 4th and 5th models with iOS 7 and 8, and fairly simple functionality was required - transfer between accounts, payments, conversion, review statements, information about cards and deposits, search for branches and ATMs. It was believed that for more complex operations, customers conveniently contact the Internet bank or go to the branch.
')
Now, two years later, mobile banking has become a full-fledged channel of remote banking services, and users perform certain types of operations here more often than on the web. This, for example, payment of mobile communication, and in general all payments.
Mobile users are more active - the visiting curve of a mobile bank is distributed quite evenly throughout the workday, whereas the Internet bank has a morning peak and then the activity drops.
In 2010, well-known web designer Luke Wroblewski put forward the concept of developing “mobile first”. For that time, it was a revolutionary idea - first developing UX and UI for mobile devices, and then adapting the project for the web and desktop applications. But this is already yesterday: there was a category of users for whom the mobile device is the only channel of communication, including communicating with the bank.
Thinking about the redesign, we set a goal: to create a platform on which we will build a truly smart mobile bank in the future. Looking ahead - we started to implement this concept with a new communication unit on the main screen and a “Profile” - the center of communication with the user. So far, through it, you can manage your account settings and receive personal offers from the bank, and in the future it will become completely personalized, and all the information there will appear solely in context; Also, customers will be able to change their personal data in the Profile without contacting a bank branch.
The Discovery app did not remain static compared to the first release. The functionality with which we started is constantly evolving. Business set new tasks, new devices came out, the OS was updated, and users entered into the taste of mobile banking - in a year and a half we added over thirty new features to the application.
Alexander Nesterov, product owner, “Discovery Digital”
“Even at the design stage of our first application, we thought about how to make it as user friendly as possible and therefore chose the path of constant improvements. At first we walked with quite long iterations, the first big update happened a few months later when we added the possibility of opening deposits. The bank then lived according to the standard waterfall and still did not know how to split up large features and introduce them in parts, but gradually the length of the iterations began to decrease - we switched to Agile and now we are releasing every two or three weeks. This greatly helps us to grope the right vector of development and at the same time insures against serious mistakes. ”
We, Redmadrobot, develop the application in a superdense interaction with the client, “Discovery Digital”, at all levels: from the server team and the security service to the products and top management (we will tell you more about the work process in one of our future posts). For the past two months, we have been working on two project groups on the project. One was engaged in the development and support of the current application, and the other - in developing a new one (full two iOS developers, analyst, designer and project administrator). And the core team in the person of the team leader, the design team and the project managers was busy in both directions at once. To meet the planned release date, the tasks of each team member were planned for each day two months in advance and were constantly adjusted during the course of work.
An example of an Agile approach to our project is the implementation of ordering cards through the application. In the previous version of the mobile bank, on the login screen, we made a showcase for ordering cards, but for the order itself, the user was redirected to Safari. This functionality turned out to be highly demanded, and then we made the card order completely through the application. Plans to coordinate the delivery of the card via chat.
This kaizen is a way of constant small improvements. But at some point there comes the need to carry out a radical change in the system in order to reach a new level - in Japanese business terminology it is called kaikka. In our case, this moment came at the end of last year, when two factors coincided: from the business and users side, there was a need for a serious expansion of the functionality, which was cramped in the previous design, and from the technical side, it was necessary to “cut off the tails” - to stop supporting the old versions iOS and go to Swift to create a platform for future development. Tasks at the start of the project were as follows.
From business:
On the technical side:
In November 2015, we began to discuss the logic of the Discovery application: we made up our vision of the product development, received a road map from the bank, and then work began on bringing them into line with each other. By January, we presented the client with a design concept - our own vision of an ideal mobile bank - what should be the banking application, if we imagine that there are no restrictions on resources and integration with the customer's systems. But then, of course, I had to prioritize.
In March, a native prototype was ready, and in early April, colleagues from the Usability Lab conducted usability testing and provided us with a report, based on which we made some adjustments. For example, in the application there is a function “replenishment from the card of another bank”, which was initially hidden in the section “transfer between your cards and accounts” - in the drop-down list of client cards at the bottom there appeared a plus sign “add another bank card”. But when the users were given a specific task - you have a card of another bank, and you want to replenish your Discovery card, do it - they did not find this function, and therefore we moved it to another section.
And in mid-April, we began to develop, which took 2.5 months.
“We were faced with the task of optimizing the user workflow for the most frequent actions - reducing the number of steps in the scenarios, making content delivery more convenient and starting to move towards the personalization of the service.”
The payment functionality on the main screen and in the payments section itself - the one that customers of the bank use most often - underwent the most processing. Of the main changes:
We reworked the prelogin-zone — the unauthorized mode ceased to be history exclusively for the customers of Otkritie. You can view information about ATMs and offices without authorization, and besides, now in the login area there is P2P transfer functionality from card to card (earlier, in order to make a transfer, the user was redirected to the bank’s website in Safari).
Pavel Usachev, Business Analyst, Redmadrobot
“Personalization of service is one of the main focuses of redesign. In terms of personalization of banking products, our task was to learn how to display the necessary data on the card, corresponding only to its type, tariff plan and loyalty program. The work on collecting all this data together was done together with the bank team, through the study of backend system specifications. Based on the information collected, design layouts were refined, functional requirements and specifications for the application were described.
As a result, we were able to realize a completely new understanding of the banking product in the digital version, which does not differ at all from the “offline” user card. In addition to visual design, we have enriched the product with useful information that is always at hand and does not have to be found in large files with a description of the tariff conditions. ”
Egor Taflanidi ( BepTep ), Redmadrobot Architect
“The task of the architect is to ensure that the same solutions are used from project to project — it’s easier to work with such projects and easier to maintain. In the case of "Discovery", of course, there were no exceptions, the code design and ideology of RESTful interaction with the server remained unchanged, but the project was rewritten using the new programming language, which resulted in updating (often, rewriting from scratch) the old libraries written on Objective-C. In fact, the data processing and server interaction layer was completely rethought and reassembled. ”
The mobile application is designed with an eye to the principles of SOA (service-oriented architecture), with the division of logic into layers of Presentation / Business Logic / Persistency). You can read more about this approach in the articles ( one , two ) by our architect Egor Taflanidi. Depending on the complexity of the scenarios and the number of data types, a part of user stories is written in the style of MVVM in conjunction with RxSwift and our own binding library (thanks to Roma Churkin firmach ). And in part of the scenarios, the “favorite” MVC with lightweight (lighter) view controllers and dedicated delegates, data source and other auxiliary objects (like the principle S of SOLID) is used. We still use reactive programming with great care and use it only for simple subscriptions and data stream conversions. First of all, it is connected with the ease of support, debag and development of such code.
Since this application is a mobile bank, we have paid paramount attention to adhering to the best practices and security standards. The code is regularly checked personally by the responsible security specialists from the bank, by static analyzers, and an external audit and research is carried out periodically. 0 (zero) critical security vulnerabilities are about the Otkritie mobile bank application. At one time this project served as a pioneer and driver for the development of security practices in Redmadrobot. And now, no project can do without such basic things as SSL-pinning, protection from debugger connections, from launching on jailbreak devices, disabling caching of web-requests, very careful attitude to the data stored in the database, and many much more.
We continue to actively use the practice of code reuse, which allows us to adhere to a single architecture and reduce development time on several projects, as well as improve reliability. We reuse a single framework of business logic: the service layer, transport, DAO and now we are working on the code generation of parsers, translators and database models. I use the general developments in colors and fonts at all, while the enumerations (enum) from Swift allow us to fully develop the use of styles. Extensions and custom UI elements are often reused on different projects.
The “Discovery” project is primarily written in Swift 2.2.1. Presented two years ago at WWDC, the Swift language, though young by traditional standards, has already experienced several releases and has moved from proprietary to open source. Despite the fact that the entire iOS ecosystem has not yet been rebuilt on new rails, it is impossible to name the risky decision to port the development of a mobile bank to Swift. The main thing - we saw that Swift can comply with all safety requirements, and this was the starting point. The initiative came from the developers. Slowly, we began to use this language on projects for quite some time (we told about this in a case about the development of AlfaStrakhovaniya Mobile ). At first, they began to make one or two screens on Swift, leaving the business logic on Objective-C, and then a team of enthusiasts gathered inside the company, which in a few weeks rewrote our entire template framework for iOS applications to Swift, including a wide layer of server interaction logic .
It was not a “translation” from one language to another, it was a “statement”. As in school, when you first need to remember the text, and then write again. Perhaps in other words. From the point of view of development methodology, there is generally no particular difference in which language to write. In the project “Discoveries” there are only a few modules, the implementation of which did not affect the transition to a new programming language. For example, inside the application, in the amount field, when you make a transfer, there is a calculator to calculate how much everyone should, say, pay for a restaurant — you can write down the total amount and divide it into three. Most likely, we will take and simply embed it in a new application. In general, today we almost abandoned Objective-C and are writing new projects in a new language.
Anton Poderechin, Redmadrobot iOS Developer
“In Swift, there is more syntactic sugar, it is more pleasant to write on it, it is easier to format it, and the code ends up being more readable. Yes, not everything is perfect - debugger is a bit lame, refactoring is not working yet, sometimes syntax highlighting in IDE falls off. By and large, if we compare it with Objective-C, then Swift in some sense has even fewer possibilities, for example, it does not have dynamic typing, so there are no things that can be done on Swift, but it could not be done on ObjC. Of course, static typing is, on the one hand, a plus, and on the other, even a little minus because the compiler always highlights type mismatch errors and does not allow freedom as before. But Objective-C dynamism sometimes helped us a lot - for example, it was more convenient to parse JSON. But one cannot say that it is such a terrible pain that we want to return to Objective-C. ”
It was clear that the release of the application will take place in the summer, and in September iOS 10 will appear, and we managed to convince the bank to limit support for iOS 9 only - many things are more convenient in it than in earlier versions: working with table animations, Stack View, WebKit, Layout Guides, Layout Anchors, Touch ID Reuse Duration, Contacts Framework and so on. But this, of course, was not just our whim - the decision was dictated by analytics: the iOS version below 8 or 9 is installed in 13% of users, and all devices that support iOS 8 may well be updated to version 9. The only exceptions are iPhone 4 with iOS 7, but there are very few of them left in the client base (and they can all use the previous version of the mobile bank).
Grigory Matvievich ( fountainhead ), tmlid iOS Redmadrobot team
“Previously, we stored all the data only for the current session, and did not save anything in the database, as there were objections from bank security officers. In preparing the redesign, we have worked through this question, and all information not related to personal banking data is stored in the database. Thanks to our architecture, caching took off at the click of fingers - we only needed to write data models for the database and translators . Now we use Realm, but we are not dependent on the implementation and, if we wish, we can quickly switch to CoreData or any other technology. ”
We work with the server team of the mobile bank on the “Discovery” side. All customer data, their accounts and orders are stored in numerous internal bank systems. We met with the analysts of “Discovery” to understand what opportunities we have, and helped the team of the mobile bank's server with integration in the part of the data model. There were difficulties when the data that were presented to us as part of the same entity were stored in different systems. For each such case, it was necessary to test and make a separate decision, which is better: make several requests from the application or one request and combine the data on the server. ”
Thus, data on tariffs and loyalty are stored in very different places. Parts of data on deposits, for example, do not exist at all, but they can be calculated on the basis of other data. We had to investigate all this, and then broadcast on both parts of the team - ours in Redmadrobot and the server in “Discovery”.
Faster and more convenient payment, as well as repetition of operations were extremely important for us when processing the application. We have added recent operations, templates and context buttons for various banking products.
From the simple from the point of view of implementation, but pleasant for the user, we actively used the capabilities of the platform, adding 3D Touch and Spotlight Search to the application — in iOS 9 it allows you to search not only for contacts and notes, but also for application objects if they are published . Thus, even without entering the application, through Spotlight, a person can find the desired template and, by clicking on it, immediately get to the screen of the corresponding payment in the mobile bank.
During the implementation of repeated operations on the back, difficulties arose in determining the payment scheme for which it was made and filling it out. As soon as these problems were solved, both the replay of the operations and the templates took off (there were similar problems with the payment templates). In order for everything to work correctly with a search through Spotlight, counters that calculate the most frequent templates were introduced on the back. Some of the difficulties were in determining which templates we can carry out through a quick payment (modal window) and which are not, and how to correctly calculate those fields in the template that the user can change and only show them.
There are dozens or even hundreds of payment providers; there are many types of transfers, so it is impossible to make a unique screen for each of them. A long time ago, a special protocol was invented in the application: payment schemes, in accordance with which the server sends a set of fields necessary for making a payment. These fields may have restrictions: input mask, set of valid values, regular expressions for testing, dependencies on other fields, and others. In addition, each field has a type that defines the interface in the application. This protocol was significantly improved to meet new needs: the design of bank cards from other banks, the definition of a bank and the correspondent account by the BIC, the definition of a bank customer by phone number. Another example - before, the commission was shown only in the alert after pressing the “Pay” button. At the time of payment, the user did not know the size of the commission, now the protocol immediately comes the fields on which the commission depends, which allows it to be calculated on the fly.
Working on embedding the functionality of P2P translations, we assembled a base of bins to identify the bank by card number and show the user the corporate colors and logo. This database is not in the public domain, and in fact we compiled it manually.
We began work on updating JSON of ATMs and offices, this allowed us to remove the duplicates displayed earlier on the map. Thanks to the online banking team! And here we have big plans: add a subway, descriptions, where they don't exist yet, a button “complain about an ATM”.
We have built in the new application of Otkritie Bank a chat for customer support in order to relieve the call center and give people a channel of communication with the bank they are used to in everyday life. Since the chat is available in the authorized zone of the application, the client is spared the need to go through the identification procedure in the call center - call passport data, a code word, etc. Without spending time on this ritual, you can go straight to the point.
As usual, all the cool ideas did not fit into a fresh release :) So what do we want to add?
There are also plans to add money to transfer cards of other banks, pay for housing and public utilities by a bar code, pay for parking lots and much more. At the last WWDC, the Siri Kit was introduced, Apple opened an API for communicating with its smart assistant, and this provides tremendous prospects for new user scenarios, including for the Otkrytie mobile bank.
Users whose devices are running iOS 9 or higher can download the updated application . For those who have iOS 8 and earlier versions, the latest version in the old design is available, which we also updated to the maximum - there appeared renaming of products, creating templates, early repayment of loans. The old application will continue to work and be supported, but will cease to develop.
So we made a new "Discovery". As all the cool ideas didn’t fit into the application, so this article didn’t include everything we wanted to tell about the project, so we planned several more posts about how we worked on MVP and made chat in the application. Stay tuned :)
Gash!
Thank you for the help in the preparation of the material of Stanislav Makarov .
From mobile first to mobile only
The Otkritie Bank mobile app appeared in the AppStore in the fall of 2014, when users had iPhones of the 4th and 5th models with iOS 7 and 8, and fairly simple functionality was required - transfer between accounts, payments, conversion, review statements, information about cards and deposits, search for branches and ATMs. It was believed that for more complex operations, customers conveniently contact the Internet bank or go to the branch.
')
Now, two years later, mobile banking has become a full-fledged channel of remote banking services, and users perform certain types of operations here more often than on the web. This, for example, payment of mobile communication, and in general all payments.
Mobile users are more active - the visiting curve of a mobile bank is distributed quite evenly throughout the workday, whereas the Internet bank has a morning peak and then the activity drops.
In 2010, well-known web designer Luke Wroblewski put forward the concept of developing “mobile first”. For that time, it was a revolutionary idea - first developing UX and UI for mobile devices, and then adapting the project for the web and desktop applications. But this is already yesterday: there was a category of users for whom the mobile device is the only channel of communication, including communicating with the bank.
Thinking about the redesign, we set a goal: to create a platform on which we will build a truly smart mobile bank in the future. Looking ahead - we started to implement this concept with a new communication unit on the main screen and a “Profile” - the center of communication with the user. So far, through it, you can manage your account settings and receive personal offers from the bank, and in the future it will become completely personalized, and all the information there will appear solely in context; Also, customers will be able to change their personal data in the Profile without contacting a bank branch.
Agile, kaizen and kaikka
The Discovery app did not remain static compared to the first release. The functionality with which we started is constantly evolving. Business set new tasks, new devices came out, the OS was updated, and users entered into the taste of mobile banking - in a year and a half we added over thirty new features to the application.
Alexander Nesterov, product owner, “Discovery Digital”
“Even at the design stage of our first application, we thought about how to make it as user friendly as possible and therefore chose the path of constant improvements. At first we walked with quite long iterations, the first big update happened a few months later when we added the possibility of opening deposits. The bank then lived according to the standard waterfall and still did not know how to split up large features and introduce them in parts, but gradually the length of the iterations began to decrease - we switched to Agile and now we are releasing every two or three weeks. This greatly helps us to grope the right vector of development and at the same time insures against serious mistakes. ”
We, Redmadrobot, develop the application in a superdense interaction with the client, “Discovery Digital”, at all levels: from the server team and the security service to the products and top management (we will tell you more about the work process in one of our future posts). For the past two months, we have been working on two project groups on the project. One was engaged in the development and support of the current application, and the other - in developing a new one (full two iOS developers, analyst, designer and project administrator). And the core team in the person of the team leader, the design team and the project managers was busy in both directions at once. To meet the planned release date, the tasks of each team member were planned for each day two months in advance and were constantly adjusted during the course of work.
An example of an Agile approach to our project is the implementation of ordering cards through the application. In the previous version of the mobile bank, on the login screen, we made a showcase for ordering cards, but for the order itself, the user was redirected to Safari. This functionality turned out to be highly demanded, and then we made the card order completely through the application. Plans to coordinate the delivery of the card via chat.
This kaizen is a way of constant small improvements. But at some point there comes the need to carry out a radical change in the system in order to reach a new level - in Japanese business terminology it is called kaikka. In our case, this moment came at the end of last year, when two factors coincided: from the business and users side, there was a need for a serious expansion of the functionality, which was cramped in the previous design, and from the technical side, it was necessary to “cut off the tails” - to stop supporting the old versions iOS and go to Swift to create a platform for future development. Tasks at the start of the project were as follows.
From business:
- Personalization of the service;
- Improving usability;
- Increase transactional income;
- Building customer base;
On the technical side:
- Discontinuing support for older iOS versions (only 9 and up);
- Translation development from Objective C to Swift;
- Maximum increase in comfortable use of the application at the expense of the platform (quick access to functions via 3D Touch, Spotlight Search, etc.)
Timeline of the project, organization of work and usability testing
In November 2015, we began to discuss the logic of the Discovery application: we made up our vision of the product development, received a road map from the bank, and then work began on bringing them into line with each other. By January, we presented the client with a design concept - our own vision of an ideal mobile bank - what should be the banking application, if we imagine that there are no restrictions on resources and integration with the customer's systems. But then, of course, I had to prioritize.
In March, a native prototype was ready, and in early April, colleagues from the Usability Lab conducted usability testing and provided us with a report, based on which we made some adjustments. For example, in the application there is a function “replenishment from the card of another bank”, which was initially hidden in the section “transfer between your cards and accounts” - in the drop-down list of client cards at the bottom there appeared a plus sign “add another bank card”. But when the users were given a specific task - you have a card of another bank, and you want to replenish your Discovery card, do it - they did not find this function, and therefore we moved it to another section.
And in mid-April, we began to develop, which took 2.5 months.
Design, Design and Usability
Leonid Borisov ( leonid_borisov ), art director of Redmadrobot
“We were faced with the task of optimizing the user workflow for the most frequent actions - reducing the number of steps in the scenarios, making content delivery more convenient and starting to move towards the personalization of the service.”
Payment functionality
The payment functionality on the main screen and in the payments section itself - the one that customers of the bank use most often - underwent the most processing. Of the main changes:
- Templates with popular operations are displayed at the top of the main screen and can be created directly through the application.
- Payment for services and transfer of funds is now carried out in a couple of touches.
- In the field of payment, there appeared quick replenishment buttons with the amount
- Quick access to currency exchange
- Redesigned service catalog
- Quick transfer of funds by phone number for customers of "Opening"
Empowerment of the login area
We reworked the prelogin-zone — the unauthorized mode ceased to be history exclusively for the customers of Otkritie. You can view information about ATMs and offices without authorization, and besides, now in the login area there is P2P transfer functionality from card to card (earlier, in order to make a transfer, the user was redirected to the bank’s website in Safari).
Personalization and “smart bank”
- The new section "Profile" we conceived as a center for managing account settings and communication with the user.
- Personal contextual offers from the bank in the “Profile”
- Communication unit with the user on the main screen with personalized offers
- Contextual call-to-action buttons for all key bank products
- Personalization for banking products - for example, if a user has an “Discovery” card with “Game of Thrones”, then a picture with it will be on the main screen, and on the product page - a stylized background image
Pavel Usachev, Business Analyst, Redmadrobot
“Personalization of service is one of the main focuses of redesign. In terms of personalization of banking products, our task was to learn how to display the necessary data on the card, corresponding only to its type, tariff plan and loyalty program. The work on collecting all this data together was done together with the bank team, through the study of backend system specifications. Based on the information collected, design layouts were refined, functional requirements and specifications for the application were described.
As a result, we were able to realize a completely new understanding of the banking product in the digital version, which does not differ at all from the “offline” user card. In addition to visual design, we have enriched the product with useful information that is always at hand and does not have to be found in large files with a description of the tariff conditions. ”
Development
Full Swift project
Egor Taflanidi ( BepTep ), Redmadrobot Architect
“The task of the architect is to ensure that the same solutions are used from project to project — it’s easier to work with such projects and easier to maintain. In the case of "Discovery", of course, there were no exceptions, the code design and ideology of RESTful interaction with the server remained unchanged, but the project was rewritten using the new programming language, which resulted in updating (often, rewriting from scratch) the old libraries written on Objective-C. In fact, the data processing and server interaction layer was completely rethought and reassembled. ”
The mobile application is designed with an eye to the principles of SOA (service-oriented architecture), with the division of logic into layers of Presentation / Business Logic / Persistency). You can read more about this approach in the articles ( one , two ) by our architect Egor Taflanidi. Depending on the complexity of the scenarios and the number of data types, a part of user stories is written in the style of MVVM in conjunction with RxSwift and our own binding library (thanks to Roma Churkin firmach ). And in part of the scenarios, the “favorite” MVC with lightweight (lighter) view controllers and dedicated delegates, data source and other auxiliary objects (like the principle S of SOLID) is used. We still use reactive programming with great care and use it only for simple subscriptions and data stream conversions. First of all, it is connected with the ease of support, debag and development of such code.
Since this application is a mobile bank, we have paid paramount attention to adhering to the best practices and security standards. The code is regularly checked personally by the responsible security specialists from the bank, by static analyzers, and an external audit and research is carried out periodically. 0 (zero) critical security vulnerabilities are about the Otkritie mobile bank application. At one time this project served as a pioneer and driver for the development of security practices in Redmadrobot. And now, no project can do without such basic things as SSL-pinning, protection from debugger connections, from launching on jailbreak devices, disabling caching of web-requests, very careful attitude to the data stored in the database, and many much more.
We continue to actively use the practice of code reuse, which allows us to adhere to a single architecture and reduce development time on several projects, as well as improve reliability. We reuse a single framework of business logic: the service layer, transport, DAO and now we are working on the code generation of parsers, translators and database models. I use the general developments in colors and fonts at all, while the enumerations (enum) from Swift allow us to fully develop the use of styles. Extensions and custom UI elements are often reused on different projects.
The “Discovery” project is primarily written in Swift 2.2.1. Presented two years ago at WWDC, the Swift language, though young by traditional standards, has already experienced several releases and has moved from proprietary to open source. Despite the fact that the entire iOS ecosystem has not yet been rebuilt on new rails, it is impossible to name the risky decision to port the development of a mobile bank to Swift. The main thing - we saw that Swift can comply with all safety requirements, and this was the starting point. The initiative came from the developers. Slowly, we began to use this language on projects for quite some time (we told about this in a case about the development of AlfaStrakhovaniya Mobile ). At first, they began to make one or two screens on Swift, leaving the business logic on Objective-C, and then a team of enthusiasts gathered inside the company, which in a few weeks rewrote our entire template framework for iOS applications to Swift, including a wide layer of server interaction logic .
It was not a “translation” from one language to another, it was a “statement”. As in school, when you first need to remember the text, and then write again. Perhaps in other words. From the point of view of development methodology, there is generally no particular difference in which language to write. In the project “Discoveries” there are only a few modules, the implementation of which did not affect the transition to a new programming language. For example, inside the application, in the amount field, when you make a transfer, there is a calculator to calculate how much everyone should, say, pay for a restaurant — you can write down the total amount and divide it into three. Most likely, we will take and simply embed it in a new application. In general, today we almost abandoned Objective-C and are writing new projects in a new language.
Anton Poderechin, Redmadrobot iOS Developer
“In Swift, there is more syntactic sugar, it is more pleasant to write on it, it is easier to format it, and the code ends up being more readable. Yes, not everything is perfect - debugger is a bit lame, refactoring is not working yet, sometimes syntax highlighting in IDE falls off. By and large, if we compare it with Objective-C, then Swift in some sense has even fewer possibilities, for example, it does not have dynamic typing, so there are no things that can be done on Swift, but it could not be done on ObjC. Of course, static typing is, on the one hand, a plus, and on the other, even a little minus because the compiler always highlights type mismatch errors and does not allow freedom as before. But Objective-C dynamism sometimes helped us a lot - for example, it was more convenient to parse JSON. But one cannot say that it is such a terrible pain that we want to return to Objective-C. ”
It was clear that the release of the application will take place in the summer, and in September iOS 10 will appear, and we managed to convince the bank to limit support for iOS 9 only - many things are more convenient in it than in earlier versions: working with table animations, Stack View, WebKit, Layout Guides, Layout Anchors, Touch ID Reuse Duration, Contacts Framework and so on. But this, of course, was not just our whim - the decision was dictated by analytics: the iOS version below 8 or 9 is installed in 13% of users, and all devices that support iOS 8 may well be updated to version 9. The only exceptions are iPhone 4 with iOS 7, but there are very few of them left in the client base (and they can all use the previous version of the mobile bank).
Data caching
Grigory Matvievich ( fountainhead ), tmlid iOS Redmadrobot team
“Previously, we stored all the data only for the current session, and did not save anything in the database, as there were objections from bank security officers. In preparing the redesign, we have worked through this question, and all information not related to personal banking data is stored in the database. Thanks to our architecture, caching took off at the click of fingers - we only needed to write data models for the database and translators . Now we use Realm, but we are not dependent on the implementation and, if we wish, we can quickly switch to CoreData or any other technology. ”
Integration with banking systems
We work with the server team of the mobile bank on the “Discovery” side. All customer data, their accounts and orders are stored in numerous internal bank systems. We met with the analysts of “Discovery” to understand what opportunities we have, and helped the team of the mobile bank's server with integration in the part of the data model. There were difficulties when the data that were presented to us as part of the same entity were stored in different systems. For each such case, it was necessary to test and make a separate decision, which is better: make several requests from the application or one request and combine the data on the server. ”
Thus, data on tariffs and loyalty are stored in very different places. Parts of data on deposits, for example, do not exist at all, but they can be calculated on the basis of other data. We had to investigate all this, and then broadcast on both parts of the team - ours in Redmadrobot and the server in “Discovery”.
Repeated operations, patterns and platform features
Faster and more convenient payment, as well as repetition of operations were extremely important for us when processing the application. We have added recent operations, templates and context buttons for various banking products.
From the simple from the point of view of implementation, but pleasant for the user, we actively used the capabilities of the platform, adding 3D Touch and Spotlight Search to the application — in iOS 9 it allows you to search not only for contacts and notes, but also for application objects if they are published . Thus, even without entering the application, through Spotlight, a person can find the desired template and, by clicking on it, immediately get to the screen of the corresponding payment in the mobile bank.
During the implementation of repeated operations on the back, difficulties arose in determining the payment scheme for which it was made and filling it out. As soon as these problems were solved, both the replay of the operations and the templates took off (there were similar problems with the payment templates). In order for everything to work correctly with a search through Spotlight, counters that calculate the most frequent templates were introduced on the back. Some of the difficulties were in determining which templates we can carry out through a quick payment (modal window) and which are not, and how to correctly calculate those fields in the template that the user can change and only show them.
Payment scheme and instant commission calculation
There are dozens or even hundreds of payment providers; there are many types of transfers, so it is impossible to make a unique screen for each of them. A long time ago, a special protocol was invented in the application: payment schemes, in accordance with which the server sends a set of fields necessary for making a payment. These fields may have restrictions: input mask, set of valid values, regular expressions for testing, dependencies on other fields, and others. In addition, each field has a type that defines the interface in the application. This protocol was significantly improved to meet new needs: the design of bank cards from other banks, the definition of a bank and the correspondent account by the BIC, the definition of a bank customer by phone number. Another example - before, the commission was shown only in the alert after pressing the “Pay” button. At the time of payment, the user did not know the size of the commission, now the protocol immediately comes the fields on which the commission depends, which allows it to be calculated on the fly.
Other improvements
Working on embedding the functionality of P2P translations, we assembled a base of bins to identify the bank by card number and show the user the corporate colors and logo. This database is not in the public domain, and in fact we compiled it manually.
We began work on updating JSON of ATMs and offices, this allowed us to remove the duplicates displayed earlier on the map. Thanks to the online banking team! And here we have big plans: add a subway, descriptions, where they don't exist yet, a button “complain about an ATM”.
Chat
We have built in the new application of Otkritie Bank a chat for customer support in order to relieve the call center and give people a channel of communication with the bank they are used to in everyday life. Since the chat is available in the authorized zone of the application, the client is spared the need to go through the identification procedure in the call center - call passport data, a code word, etc. Without spending time on this ritual, you can go straight to the point.
What we have in backlog
As usual, all the cool ideas did not fit into a fresh release :) So what do we want to add?
- Tighter integration with the bank's CRM systems — what we have now done as part of personal offers — is only the first step.
- Discount and loyalty programs and recommendations to friends.
- Further expansion of the payment functionality: for example, payment of traffic police fines. It is quite difficult to make this functionality really convenient, you need to be able to search by a flexible set of details - driver's license number, car number and brand, PTS. Taking into account all the nuances you need to do such a search, by which no fine will pass.
- Payment service by mobile phone number with automatic identification of the operator. It would be convenient for customers not to fill in the extra field, and indeed, when we are asked to throw money at the telephone, we do not always remember the operator. But the bank should definitely know the service provider to make the payment. There is a simple code base of mobile operators, but after the law on the abolition of “mobile slavery” entered into force, 4 million people appeared, whose operators cannot be determined by code, additional integration with third-party services is needed.
- Informative graphs on deposits and account status.
There are also plans to add money to transfer cards of other banks, pay for housing and public utilities by a bar code, pay for parking lots and much more. At the last WWDC, the Siri Kit was introduced, Apple opened an API for communicating with its smart assistant, and this provides tremendous prospects for new user scenarios, including for the Otkrytie mobile bank.
Instead of conclusion
Users whose devices are running iOS 9 or higher can download the updated application . For those who have iOS 8 and earlier versions, the latest version in the old design is available, which we also updated to the maximum - there appeared renaming of products, creating templates, early repayment of loans. The old application will continue to work and be supported, but will cease to develop.
So we made a new "Discovery". As all the cool ideas didn’t fit into the application, so this article didn’t include everything we wanted to tell about the project, so we planned several more posts about how we worked on MVP and made chat in the application. Stay tuned :)
Gash!
Thank you for the help in the preparation of the material of Stanislav Makarov .
Source: https://habr.com/ru/post/306116/
All Articles