Performing an iOS audit: 3 key aspects to look at
What should you pay attention to when doing an iOS audit?
When our application starts growing, we need to ensure its scalability.
If we don’t, we will face some big headaches in the future. General speaking, when we talk about an app’s scalability from a developer perspective, we’re seeking to:
- Adding new code to be simpler.
- Improve the debug process to catch bugs.
- Onboard new teammates quickly and easily.
A proper iOS project audit can help us make sure that our app meets quality standards. And if it doesn’t, we'll at least have a clear roadmap on what needs to be fixed.
So, if you plan to do an audit, or just want to perform an extra check on your app’s general health, here are 3 areas you might consider putting focus on.
1. Project organization
How hard, or how easy, is it for someone new to find anything inside the project?
It could be a file, a function, a resource, or even some sort of configuration. A clear structure will help you with maintenance in the future.
Here are some items you can check:
Folder structure
Does the folder hierarchy make sense?
If you create a new file, do you know in which group you need to put it? Having a clear folder structure not only helps to maintain order when we create new files but also to make searching faster.
There are many ways of sorting files and resources in a project. It could be grouped by modules, file types, features, or even a combination of some. The important thing is that the chosen one does not change over time and that all team members follow it.
Schemes & Targets
How many schemes and targets does the project have?
If a backend interacts with the app, there will probably be more than one environment. Maybe dev & prod. How does this reflect in the schemes of the app? A good practice is to have one scheme per environment. This way we can configure specific values and data for each environment.
Code signing
How do you manage certificates and provisioning profiles? Can you build and run the application out of the box?
Depending on how many environments your project handles, you might need to review your code signing strategy. Do you use automatic signing or manual? How do you distribute certificates and provisioning profiles through your team?
This might not seem important but in larger teams it is.
2. Architecture
Moving into the fun stuff, do you notice a defined architecture at first sight?
Having a good architecture is a critical part of every application when it scales. There are several architectures to use, I don’t believe one is better than the other. Each one has its uses given the right circumstances.
You need to have a full understanding of, at least the most common, architectures for an iOS project.
Ask yourself the following questions to assert if the architecture is right for the project:
- What is the build & deploy target time?
- How critical is testing?
- What is the overall seniority of the team?
- Is the project high or low tolerant to unknown changes?
- Do you need to ship features fast or can you take extra time to go through a QA process?
Maybe the project you’re auditing doesn’t have any architecture at all. In this scenario, you could recommend a refactor plan for adopting one.
3. Dependencies
How many third-party dependencies does the project have?
Usually, many dependencies could give you problems in the future. However, this does not necessarily have to be true. It all depends on who is behind those libraries.
For example, if the project uses Firebase, it doesn’t seem to be a problem. On the other hand, if it is using a random developer library, you might need to look deeper to uncover some insights.
Enumerate all the dependencies and for each one check the following:
If it’s an open-source library:
- How many starts does it have on GitHub?
- How many issues does it have open?
- How is the community contribution in general?
- When was the last commit?
When was the last release?
How many users does it have?
This would give you a better picture of whether dependencies could be a potential issue in the future or not.
