7 iOS Tips that Will Save You Hours of Time
It is always better to be investing our time on creative tasks and avoid doing repetitive work as much as we can.
This article is written to provide you with seven iOS development tips towards writing better and easily extendable code that will contribute to saving a lot of time.
Creating a Theme Manager
Even if your app does not support multiple themes it is always a good idea to bring together all the application style related logic into a manageable object that gets shared across the app.
Constructing the same colors or fonts over and over again its always a bad idea.
In case of a simple change, you would have to go to all over your code just to change a shade of the primary color or decrease the body font size for one point.
Managing Styles in one place gives us several benefits
- You can easily access and be aware of all the colors or styles that your app uses.
- You can provide multiple themes for your app.
- In the future, if you want to change anything style related you can do it from a single place.
Let us give a simple example of how we could implement this in iOS.
We will create a Theme protocol that concrete NightTheme and DefaultTheme objects can conform to.
Our Theme will consist of a ColorPalette and TextStyles and can be extended depending on specific app use cases.
Our Concrete themes and our ThemeManager can look as following.
This type of style management will make the code much cleaner and us save lots of time when changes are needed.
Subclassing Default Objects
It is always a good idea to create custom objects for UILabel, UITextView, UISwitch etc. and use them instead of the default objects even if at the moment they won't have any custom implementation.
Suppose that our app configures all of its Header Labels with some specific font color, line spacing, font weight, and other attributes.
In these cases is much better to create a HeaderLabel subclass of UILabel and provide the custom implementation.
After that use the HeaderLabel throughout the app whenever we need to configure a Header Label.
This might seem obvious at first but I have seen too many iOS Apps where objects get created either from code and storyboards and get configured over and over again instead of just assigning our custom class and getting all the configuration done.
Even if no custom implementation is being given at the moment its much better to use our objects instead of default ones, so just in case if in future we decide to make a simple change to all of the Body Text Labels we can do it from a single place.
Testing Network Edge Cases
Testing Network edge cases it is really important for our app. It is hard to get all the errors from the server while we are developing.
To avoid unexpected behaviors of our app when something goes wrong it is easiest to mock error cases and provide handling for them.
In this article, we will be using the help of a really nice open-source library called OHHTTPStubs.
OHHTTPStubs is a library designed to stub your network requests very easily. And can help us with test apps with fake network data and simulate networks to check application behavior in bad network conditions.
The good thing about this library is that it works great with the famous iOS networking library Alamofire.
Stubbing Network request is really easy, with OHHTTPStubs you can replace any response for a specific path or host by giving a custom response.
We can easily test if error and edge cases are handled correctly by simply returning an error in a specific response.
We can also return a specific error for all the network request that go from our app and test in example if no internet connection case gets handled correctly
Using Code Snippets
Writing boilerplate code isn’t a favorite task of the software developers.
Unfortunately, that is something that cannot be avoided at all times, but using code snippets available from Xcode can make it something easy and fast to do.
To create a code snippet you can simply drag a piece of code and move it to snippets library. After that reuse it in any file by simply dragging and dropping to the editor
This can save us lots of time when we must write boilerplate code.
Also, we can create a rich snippet library of functions that can be reused in multiple apps.
Wrapping Complex API-s Using Facade Pattern
The facade design pattern is used to define a simplified interface to a more complex subsystem.
Creating a facade for default API-s can create much simpler code and saves us lots of time when interacting with them.
In this article, we will start by creating a facade over UserDefaults since lots times we end up writing lots of repetitive code just to fetch or save an item from/to the UserDefaults.
and use it as following
Wrapping the default API with a custom class is always a good idea for the following reasons
- It makes it easy to know what interactions are you making to a specific API from your app by just looking at the functions in your wrapper class.
- It decouples you from the underlying API that is being used, say if you want to replace i.e core data with any other database in the future you’ll have to make changes only in one class and leave the same code throughout the app.
- You can easily change the source of data when you want to do testing of some kind say i.e saving and fetching data from a temporary database rather than the real one.
for more about the last case you can view the following article
Testing With Custom Picked Responses
Suppose that we are working on a social networking app that displays a feed of users and the order of them will be based on the number of followers that they have.
Suppose that we want to reorder them to test a specific case. Going ahead and increasing the number of followers for the user that we want to have on top can be overkill and waste us hours of time.
On the other hand, modifying our code just to test a specific case can mess up our code and may lead to the creation of an accidental bug.
The best thing would be to alter the network response.
The easiest way will be to use the OHHTTPStubs library that we used for stubbing error cases from the earlier tip.
Stubbing Network request is really easy with OHHTTPStubs you can replace any response for a specific path or host by giving a custom response with a dictionary.
After this, every request that goes from the app to the following URL will return our custom response instead.
let tasksURL = URL(string: “https://jsonplaceholder.typicode.com/todos")!
Manually building the dictionary for response is a great feature, but when we want to return a large JSON data with lots of properties it can become messy and hardly maintainable in our test classes.
In those cases, we can use a JSON file to stub the response like following.
Now everytime our app sends the request we will get the response from the file myResponse.json that we saved in our files.
We should remember though to avoid saving sensitive information in these JSON files because if we ship these files together with the application they can be viewed easily.
You can check my article on the security topic for more.
Creating Navigator Class for Routing
Our apps can have different entry points, like Deeplinking, ShortcutItem, Push Notification redirects etc.
Creating clear navigation logic for routing for these cases avoids repetitive code and allows us to easily know all of the available app entry points and where will they be redirecting.
When our application handles redirection from multiple points we can easily create repetitive code and lose the track of which URL routes to where and the list of URL-s our app handles.
Unifying this logic can save us hours of time in the future.
Suppose that our app has a tab bar controller with following
- Home
- Discover
- Profile
From our discover tab you can move modally to other routes as well.
Initially, We create our Route enum
Also, the DiscoveryRoute enum
We can create another enum that represents the route together with its presentation style
We can create multiple initializers depending on the redirection.
This allows us easily to know how can an AppRoute be initialized therefore telling us what kind of redirecting we support.
Our navigation manager then can look something like follows
And get called like following
Also NavigationManager can get called the same way from the other parts of app entry points.
In Conclusion
In this article, we have discussed several tips that help us to write better code and save lots of time when trying to make changes in the future.
We have discussed the benefits of network testing, wrapping up complex API-s, routing and many other points that can help us towards the goal of writing better and easily understandable code.
If you enjoyed this article make sure to clap to show your support.
Follow me to view many more articles that can take your iOS Developer skills to the next level.
If you have any questions or comments feel free to leave a note here or email me at arlindaliu.dev@gmail.com.
