iOS Development at Scale @Chegg

iOS Development
at Scale
Gal Orlanczyk

How we Overcome
our Challenges

What will you gain?
> Concepts and tools for handling scale
> Ways to write higher standard code
5

Who is this for?
> Teams starting to expand.
> Individuals looking to write better code.
> Large teams looking to improve their workflows.
> Teams looking to iterate fast while still writing high
quality code.
So basically almost everyone 😎
6

About Me
iOS Developer for 5 years, and a big Apple fan boy 🤓
Works at:Married and Father to: A Passionate:
Playing Destiny 2 these days
Soon borderlands 3 😎

1500+
Employees
80+
Employees
in Israel
2.5M
Paying
Subscribers
1 of 4
Students
Uses Chegg
4B$
Public
Company

Chegg
Our mission is to help students
study smarter!
Our main services:
Study Math Prep

Today
Study Books PrepMath
Multiple teams working in verticals

In the Beginning…
We started out as one team.
AndroidiOS

• Dynamic/Static Framework or library
• Each module has its own dependencies
• Some dependencies are shared across modules
Modules!

Each App uses several modules, directly and indirectly (via
other module dependencies)

Networking
Authentication
More…
(Analytics, UI, etc.)

It Doesn’t Scale!
With 3-4 people it might work…
3-4 independent teams, not so much…

The Scaling Pains
• Tightly coupled code
• Changes affects multiple apps

What we Needed
The Pains:
• Loosely coupled architecture
• New features with legacy code
• High standard shared components
• Shared components safety
• Ownership and knowledge sharing

What we Needed
The Pains:

Abstractions For the Rescue
We have this protocol on our foundation.
One of our apps uses `isLoggedIn` and `userUUID` only
protocol UserContextProviderProtocol {
var isLoggedIn: Bool { get }
var hasValidCredentials: Bool { get }
var userUUID: String { get }
var sessionId: String { get }
var authType: AuthenticationType { get }
// more info on user...
}

Why bring all foundation when we can just use:
How to continue?
protocol SignInContextProtocol {
}

Implement on the original protocol.
protocol UserContextProviderProtocol: SignInContextProtocol
{}

Small wrappers class UserContextProviderWrapper: SignInContextProtocol {
let userContextProvider: UserContextProviderProtocol
init(userContextProvider: UserContextProviderProtocol) {
self.userContextProvider = userContextProvider
}
var isLoggedIn: Bool {
return self.userContextProvider.isLoggedIn
}
var userUUID: String {
return self.userContextProvider.userUUID
}
}

Abstractions For testing!
protocol SignInContextProtocol {
}
class ViewModel {
init(signInContext: SignInContextProtocol, manyMoreDependencies: …) {…}
}

class SignInContextMock: SignInContextProtocol {
var isLoggedIn: Bool { … }
var userUUID: String { … }
}

class ViewModelTests: XCTestCase {
let viewModel = ViewModel(signInContext: SignInContextMock(),
manyMoreDependencies: …)
func testFlow() {
viewModel.doSomething()
XCTAssert(viewModel.something == 🔥)
}
}

High Standard
Shared Components

A Possible Approach
“MicroServices are a software development technique that
structures an application as a collection of loosely coupled
services.” (Wikipedia)

MicroServices Benefits
• Improves modularity
• Makes it easier to:
• Develop
• Test
• Resilient to changes
• Helps parallelize development between teams

Self Contained Frameworks 💪
• Loosely coupled code (less dependencies)
• Tests
• Isolated build process
• Example app
• Great documentation

Free Benefits
• Think twice before adding code
• Better encapsulation
• Smaller scope for our unit tests

Planning the Next Steps
• What is a good candidate for this approach?
• What will give us the best impact?

Planning the Next Steps
We received a requirement from design:
Keep our UI according to the company style guide on all apps.

Sounds like a job for…
Self contained
framework!
🤓🤓♂️

UIComponents
One design language across ALL teams

Style Guide as Code
let label = Styleguide.Label(type: .h1)
label.textColor = Styleguide.Colors.coral
myView.addSubview(label)

API Examples - Code
let label = Styleguide.Label(type: .title1)
let button = Styleguide.Button(kind: .link, dimension: .large)
Label.textColor = Styleguide.Colors.teal
let specialView = SpecialView()
specialView.titleFont = Styleguide.font(forType: .title2)

API Examples - Interface Builder
@IBOutlet private weak var label: Styleguide.Label!
class Label {
…
@IBInspectable var typography: String
}

API Guidelines
There is no specific solution for creating your components.
make sure the API is clear and extensible.
Should always be as easy as:
let label = Label(type: .h1)
label.textColor = Styleguide.Colors.coral

UIComponents Decoupling
Should be decoupled from our code base entirely!
Decoupled UI
components
• Easy support for multiple apps
• Less bugs - Components are
‘dumb’

Decoupling Guidelines
protocol SuperButtonDelegate: class {
func didSuperTouch(_ superButton: SuperButton)
}
class SuperButton {…}

Decoupling
Guidelines
class OrderButtonInteractor: SuperButtonDelegate {
// some properties definitions…
func didSuperTouch(_ superButton: SuperButton) {
self.makeOrder()
}
func makeOrder() {
self.orderApiClient.sendOrder { (succeeded) in
if succeeded {
orderDb.saveOrder(orderName:
self.orderName)
self.delegate?.orderDidFinish()
}
}
}

Example App
Every good shared
component should have
an example app
especially UI ones.

Documentation
Helps other people to
get quickly into the
action 😎

UIComponents Recap
• One source of truth for developers.
• Super easy for new hires to use.
• Reduces iterations/bugs with UI/UX.

Worthy Mentions
• Utilities
• Persistence
• Networking
• Authentication
• More…

What we Needed
The Pains:
💪 💪 💪 💪 💪

What we Needed
The Pains:

Shared Components Safety
We were looking for a mechanism to help us make sure code
changes are safe.

Fortunately, we’re heavily invested in our
tests coverage

Each feature is written with a fare
amount of:
• Unit tests
• Integration tests
• UI tests
UI Tests
Integration Tests
Unit Tests

Shared Components Safety
Compile Code
Master
Build Pass?
No
🚫
Yes
Prevents pushing breaking changes

Prevent Pushing Breaking Changes
Unit / Integration / UI - Tests
(Automations)
❤️

Prevent Pushing Breaking Changes

Ownership and
knowledge sharing

Tech Design
• Explains how I plan to
develop the feature
• Tech design per feature
• Allows syncing on
changes
• Allows getting ideas from
others

Round Table
• Allows to sync between
teams
• Opportunity to talk about
issues we have
• Get help from others

Cross Team
Communication
Ground rules:
• Decide as a team
• Share, share share

What we Needed
The Pains:
💪 💪 💪 💪 💪 💪 💪 💪 💪 💪

The Challenges
• Short vs. long term time investment
• CI/CD – scripts/tools sharing between self-contained
frameworks
• Dependency Injection, may introduce challenges.

Recap
Spaghetti is a delicious dinner but, less optimal for code
dependencies – Use abstractions
(with balance in mind)

Recap
Build smaller independent
components, it will allow you to work
in parallel and achieve greater
heights!

Recap
Grow as a team and not individuals!

UIComponents Tips
• If you want to include custom font, use `CTFontManager` to
load fonts at runtime.
• If you are going to use @IBInspectable, make sure not to
use a pre-build version of the framework.

On-Boarding
Document
The first days are always
hard for new devs.
Why not make it easier?

Technical Documentation
UIComponents cool docs were generated using “jazzy” by this
small script:

Useful Links
Jazzy
Scaling with easeCreating private pods
GitHub Status
Checks

iOS Development at Scale @Chegg

More Related Content

What's hot (19)

Similar to iOS Development at Scale @Chegg (20)

Recently uploaded (20)

iOS Development at Scale @Chegg

Editor's Notes