У якийсь момент найпростішим способом залучити нових користувачів стає придбання конкурента. Йтиметься про технічні челенджі, з якими ми зіткнулися при міграції кількох VPN-додатків від куплених компаній, у проект з єдиною інфраструктурою та різними користувальницькими інтерфейсами, використовуючи VIPER. В рамках доповіді будуть розглянуті наступні питання: - стандартизація архітектури для всіх проектів; - переваги та недоліки моно-репозиторіїв та наш підхід до міграції мобільних додатків від сторонніх компаній на наші рейки. http://uamobile.org/uk/topics/pobudova-arhitektury-dodatku-dlya-650-milyoniv-korystuvachiv

1. Creating An App for 650
million customers

2. AnchorFree in Numbers
● 20M DAU, 650M total active
● Two Apps in Top 10 at US App Store
● 6+ Cross-platform Apps (iOS, Android, Desktop)
● 2+ acquired competitors

3. Different UI – similar features

4. What we had previously?
● The Good
○ Split repos per application
● The Bad
○ Dependency Hell
○ No Unified Architectural Approach (but mainly MVC)
● The Ugly
○ Low unit test coverage
○ Huge code duplication between repos
○ Broken CI for months in some repos

5. The Master Plan

6. The Master Plan
● Monorepo
● Unified architectural approach
● Stable CI
● Unit-test coverage
● Automated testing

7. Repositories

8. Split repos
● The Good
○ Bugs are isolated in application repo
○ Fast & Secure
● The Bad
○ Hard to reuse code
○ Hard to do a large-scale refactoring
● The Ugly
○ Dependency hell on large project
○ Same bugs in every single app

9. Monorepo
● The Good
○ Great code reuse & large-scale refactoring
○ Manageable dependencies
○ Easy release management
○ Cross-team collaboration
● The Ugly
○ Scalability challenges in CI & VCS
○ Tooling

10. Our Approach to VCS
● Git as VCS
● GitHub for repo management and
code-reviews
● Pull request naming policy
● Tags naming policy
● Squash-merge to keep git history clean

11. Our Approach to CI
● CircleCI as CI
● Tests on every PR
● Regular AdHoc releases of all apps
● Release-candidate builds from tags
● An eternal battle to keep builds fast

12. What we achieved with the monorepo?
● Consistent CI builds of all apps
● Lower regression rate
● Shorter release cycles due to code sharing

13. When a monorepo may work for you?
● Multiple similar projects in organization
● Poor code reuse between them
● Dependency hell

14. Unified Architecture

15. Our Goals
● Different UI design in different apps
● Easily replace system components per application
● Keep new architecture compatible with MVC
● Scale team easily
● Support macOS later

16. Common Approaches
● MVC
● MVVM (+Coordinator)
● VIPER

17. MVC
● The Good
○ Simple when the project is small
● The Bad
○ Learning curve for new team member when MVC becomes MVC+whatever
● The Ugly
○ Massive view controllers
○ Hard to unit-test view and controller
○ Team reinvents the wheel all the time
○ A/B tests are undoable

18. MVVM (+Coordinator)
● The Good:
○ Testability
○ Easy of use
● The Bad:
○ Massive ViewModels
○ Possible God-Object Coordinator
○ A/B testing
● The Ugly:
○ Call Stack during debugging
○ No standard approach to routing

19. VIPER
● The Good
○ Isolated modules → isolated bugs
○ Short learning curve → easy scale of the team
○ Unit testing is trivial
○ A/B testing of every app component is trivial
○ Standardized architectural approach → no reinvented wheels
● The Bad
○ Heavily missed deadlines at first
○ Lots of boilerplate code

20. Deadlines With VIPER

21. High Level Design of our Approach

22. Lessons Learned with VIPER
● Every VIPER is different
● It’s hard to make VIPER right from scratch
● Use codegen to avoid rewriting of boilerplate code

23. What we have now?
● The Good
○ Unified architectural approach
○ Low code duplication
○ CI builds of all apps
● The Bad
○ Monorepo with few apps
○ Latest versions of dependencies from git submodules
● The Ugly
○ Low Unit test coverage

24. Next Steps
1. Achieve better unit test coverage
2. Automate testing process
3. Update apps every 4-6 weeks
4. Build cross-functional teams based on functional blocks
5. Run tens of A/B tests in every release
6. Find the next big (product) thing
7. File the IPO

25. Let’s stay in touch
/dosipa
dima.osipa@gmail.com
bomjkolyadun

26. Q&A
https://anchorfree.com/openings/
Yes, we are hiring:

27. Backup Slides (VIPER)

28. Assembly
● PONSO – plain old NSObject
● Responsible for injecting dependencies into the module

29. View
● UIViewController (or NSViewController) subclass
● VIPER’s module facade (to achieve compatibility with MVC)
● Sends events to Presenter
● Receives ViewModels from Presenter
● Receives UIControls style from Theme

30. Theme
● Swift Enum / PONSO
● Contains styles of all UI Components of the app

31. Presenter
● PONSO
● Receives events from View
● Sends ViewModels to View
● Sends events to Interactor
● Receives data and events from Interactor
● Sends events to Router

32. Interactor
● PONSO
● Handles one use-case
● Presenter may contain few interactors
● Receives events from Presenter
● Sends events to Services
● Receives Entities and events from Services

33. Service
● PONSO
● Interacts with backend
● Manipulates with Entities
● Interactor may interact with one or more services

34. View Controller Extension
● Method to open ViewController – VIPER Module and inject dependencies
● Method to close ViewController – VIPER module

35. Why VIPER?
● Great component interchangeability
● Module Isolation
● Trivial Unit-tests
● Short learning curve for new team members

36. Typical Startup Problems
● How to attract new customers
● How to increase revenue per customer
● How to respond to the competition
● How to build a constant change culture

37. Let’s stay in touch
/dosipa
dima.osipa@gmail.com
bomjkolyadun