2. AnchorFree in Numbers
● 50M MAU, 650M total active
● Two Apps in Top 10 at US App Store
● 1 Petabyte of traffic per day
● 6+ Cross-platform Apps (iOS, Android, Desktop)
● 2+ acquired competitors
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
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
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
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
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
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