Pillarisation: modular architecture for iOS apps

In a world where geopolitics have gone haywire, the economy appears to be stuck in an ice age, and Snap Inc. raises $3.4 billion during its IPO – we return to the simple pleasures in life including value types and unit testing. Lets talk about architecting iOS apps, the traps you can fall into with Core Data, and the magic of xcconfig files. This is the story of an app, but it is really an adventure with git submodules and lots of coding conventions.

Transcript

1. Pillarisation modular architecture using `pillars` at Hotels.com
2. • Archeology • Today’s architecture • Development & Testing • Lessons learned Pillarisation: modular architecture using `pillars` at Hotels.com
3. http://www.keefmoon.com/blog/shortlisted-for-a-uk-it-industry-award/ 2012
4. Universal Hotels HDC-SDK A new architecture
5. Goals of new app architecture 1. Good old decoupling 2. Testability 3. Fashionable view 4. But also we had no designs Universal Hotels HDC-SDK
8. Started as
9. 2014, Jan
10. Universal Hotels HDC-SDK The new then architecture
11. About those architectural goals 1. Good old decoupling 2. Testability 3. Fashionable view 4. But also we had no designs 1. Core Data coupling everywhere 2. As long as you can spare a Managed Object Context 3. Maybe too fashionable
12. The card system • Data driven UI made from .plist files • Updatable from the network to change UI on the fly • A/B tests • Fast to develop new views* Pros • Baffling for new developers • View layer bound to Core Data • Massive effort to port to new screen sizes Cons
13. 1. Consider cards system tech debt • Isolate it to Universal Hotels • Make Universal Hotels smaller over time 2. Create new `Pillars` • No card system • No Core Data dependency • Provide opportunity to experiment and innovate The new way
14. A pillar emerges!
15. PDP stands for Property Details Page, i.e. view of a single property
17. A pillar emerges!
18. Pillar or Framework?? • Pillar is a .framework • Has UI • Has demo app Pillar • Framework is not a Pillar • Framework is a .framework too • Like a library • Mainly binary code to support Pillars and other .frameworks Framework
19. Architectural benefits • No cards in PDP and SUI; cards all day in Main UI • Isolation • Multi-team development • A/B testing between old and new PDP • Can run separately • VIPER within PDP
20. Raising a 2nd pillar
23. Development Practices
24. Xcode workspace • Every production .framework has its own project • Ensures encapsulation and single responsibility
25. Xcode Configuration Settings File - .xcconfig
26. Xcode Configuration Settings File - .xcconfig
27. Project Structure • Within a project we actually end up with 3 targets: • Main .framework • Demo App • Tests • TestUtilities
28. Demo Apps • less time to compile • you can directly run screen under development • QAs can test a feature that is hidden behind feature flag
29. Test Utilities Architecture is very modular so we end up with loads of Stub classes. Stubs can be used by any other project. TestUtilities - a target present in each project • holds stubs • holds fake data factories
30. Dependency Management and Source Control • Mono repo • No versioning of components within app • No requirement for Cocoapods or Carthage • Third party code is either: • Submoduled • Dropped straight in
31. Testing
32. • Just Test! • mix of TDD and tests after development • business logic has 100% coverage Testing To TDD or not to TDD?
33. Unit Tests • Testing in isolation - using stubs • Small, fast to run Testing
34. Testing Snapshot Tests • Unit Tests for your views • Small, isolated and reproducible
35. Testing Acceptance Tests • Test the integration between classes • Stub only unpredictable things - like Networking
36. Testing UI Automation Tests • Test end-to-end flows with user interaction • Avoid if lower level tests can be easily written
37. Lessons learned
38. • NSManagedObject dependencies • difficult to test • highly tangled Lessons learned CoreData
39. • Avoids inconsistencies • Comments • Simplifies ‘pillar’ creation • Enforces correct name for directories, projects, targets Lessons learned .xcconfig
40. • Pillars are very easy to test • Great separation of concerns • Architecture can evolve without affecting other pillars • Feasibly teams could work in isolation on different pillars • Easier migration to Swift 3 Lessons learned Pillars
41. A final thought
42. • Should we really call them pillars? • Explosion of frameworks • Supposedly there is a limit! • Shared Data Providers, Networking, Persistence and Raw Models • Maybe build a test project that imports hundreds of frameworks? “Pillars are a lie” – A.T.
43. BTW, Hotels.com* is the best place to work in the UK On Glassdoor, for 2016 and 2017 * Part of Expedia https://www.glassdoor.co.uk/Award/Best-Places-to-Work-UK-LST_KQ0,22.htm
44. 40 Hotels.com Tech roles open Including iOS, Web, Data Science, Ops, QA, Java, Scala, and managers too http://www.lifeatexpedia.com/brands/hotels-com/
45. Thanks! Time for questions? @matyjas @WojRutkowski Pillarisation modular architecture using `pillars` at Hotels.com
46. • http://www.keefmoon.com/blog/shortlisted-for-a-uk-it-industry-award/ • https://recombu.com/mobile/article/hotels-com-ios-android-windows-phone-amazon-fire-app-review • https://commons.wikimedia.org/wiki/File:Bothriechis_schlegelii_(La_Selva_Biological_Station).jpg Photo credits