iOS System Design Example
In this article, I will explain how to solve the iOS System Design problems with an example
Intro
While searching for “iOS system design articles/tutorials” I didn’t find a lot of resources there. Actually, I found articles talking about the architecture patterns, but not for designing/architecting iOS apps from scratch going through choosing the architecture, API design, UI design, and so on. So I decided to write with an example of how can you solve the iOS system design problems.
In this article, I will use bullets and points to make the solution much easier and simple to understand, but you can add more explanation for each point as you wish.
The design and architecting have no one correct answer, so everyone can solve any design problem in their own way and proof that the solution is suitable for the problem. Also solving the design problems depends on a lot of factors like (business, scale, cost, time, team members experiences, performance, reliability …) so the design can be different from one problem to another.
In this example I tried to make it simple just to explain the steps of the solution and the idea, so feel free to add on it and scale it.
Problem
Design fullscreen stories iOS app to display unseen stories first in a circular view with 24 hours expiration time for each story.
Solution
1️⃣ Requirements gathering
➢ Asking questions
Covered by the solution:
- What is the content of the story? — Image, Username, and time.
- How the user will switch between the stories? — By swiping left and right.
- Should the unseen stories appear first? — Yes.
- Should the user login first? — Yes.
- Does the app have to support offline mode? — Yes.
Not covered by the solution:
- Is the system should support live updates (without manual refresh) for the stories?
➢ Scope features
- Horizontal list of stories
- Swipe left and right
- Circular from the right
- Automatic switch to next story after a specific interval of time (15 seconds)
- Mark story as seen
- The expiration time for each story is 24 hours
- Offline mode — We need to cache stories until their expiration time
2️⃣ UI
- Collection view can be used to display stories with Image view and two labels for the user name and the time
- We can do animation while switching between the stories
- Handle gestures for swiping and dismissing
- For scalability, we can break down the UI into smaller independent components to create reusable UI components which can be reused in other screens. For example here in our UI, we can create a general Collection View Cell with swiping left/right/down gestures handling.
3️⃣ Data Model
The ERD diagram can be used to represent the system models
4️⃣ APIs needed
In the client/server applications type, the collaboration between the Client (Mobile) team and the Server (API) team is very important for the development process. So the iOS team should set together with the API team while designing the API so that the iOS team can request the best way to get/send the data to/from the API and also to raise if there are any mobile restrictions in the proposed design.
API types: (JSON, XML, Protocol Buffers, …).
For our app, we can use JSON APIs as it is light for mobile apps.
1- login
This API will authenticate the user by email and password.
2- register
This API will create a new account for the user by email, username, password.
3- getStories
This API will get stories for the user id and ordered by unseen stories first then by timestamp with pagination.
4- markStoryAsSeen
This API will mark a story as seen for userid to update the order of fetching stories in the next times.
5️⃣ High-Level Solution
➢ iOS Architecture
There are multiple architectures for the iOS apps for example VIPER, MVVM, MVP, …etc
We will choose VIPER for our app here.
Why?
- It’s a large-scale project and VIPER is proper architecture for large-scale projects.
- VIPER is a proper architecture for code testability as VIPER has good separation between code layers
- VIPER is a Modular architecture
- View Controller: responsible for the visual designer
- Presenter: responsible for presentation logic to drive the UI
- Interactor: responsible for handling business logic for every use case
- Wireframe: responsible for navigation logic between modules
➢ Modules
➢ Components and Layers
➢ Libraries
Here we should mention if we will use for the solution black box Libraries/Frameworks (either native (ex: Core Location, Core Animation, …)or third party) or not.
In this app we can use:
- SDWebImage: to download and auto caches the images in memory with custom memory cache policy.
- Core Animation: to add a nice animation while swiping left/right to switch between stories and for the auto-switching after the defined interval of time mentioned above.
➢ Class Diagram
➢ Activity Diagram
6️⃣ Design aspects need to be considered
- Availability and offline mode (Caching (Memory/Disk))
We should use a suitable cache policy to avoid wasting memory/disk spaces. Here maybe we can flush the stories from the app local cache after its expiry time.
There are many ways to save data locally in the iOS apps for example:
SQLite DB, Core Data, Realm, User Defaults, PLIST files, Archiving models, …etc
We can use SQLite or Core Data for our app here. Think about why?
- Battery life
What strategies can be used to minimize battery and data usage?
- Response time
We should define the accepted response time for each API and track the responses times for each API. If one response exceeded the defined time for it, then investigate this issue.
- Reducing network requests
- Scalability
Break UI into reusable components and Modularize the app
- Performance
Are there any UI-intensive operations (e.g. infinite list scrolling, heavy animations, or complex transitions)? How would you support this? For example, you could pre-fetch data and create a buffer.
- Security
Authentication, authorization, storing sensitive data (should we use Keychain?), and secure communications (all requests follow the HTTPS protocol and are encrypted with TLS, certificate pinning, …etc).
- Monitoring
Crash reporting, data logging, and Analytics.
- What about live updates?
Thanks for reading this article! Leave a comment below if you have any questions. Please feel free to add comments for your thoughts/mistakes, or feel free to contact me directly.
Finally, This article can help you succeed in the system design interviews but always Practice is Key so try it by yourself.
