A few Swift tricks that you might not know

Mike Pesate
Nov 26, 2018 · 4 min read

Over the years we all come across that one article, post or even video that shows us a couple of neat tricks that we love and continue to use from that point onwards. This is why I’ve decided to write down some of my favourites ones.

1. Avoiding Type Repetition:

If you are like me, and you like your code to be strong typed and avoid having the compiler infer what a property should be based on what’s being assigned to it. Then you will like this tip, since it will help you avoid having to type the class twice.

As you can see from the example above. We are able to still declare the type of the property but we don’t need to rewrite it during the instantiation. This tip also comes in very helpful if during a refactor we need to change the class of a property for, lets say, a subclass. If the init is the same, then all we need to do is just change the type and that will be all. The compiler will know the context and adjust the init correctly.

2. Swift Errors

One of the more tedious things I have found in life is having to come up with names for new errors in Swift. But recently I found a way around this and it has become one of my favourite things to use.

Did you see the trick? Well, the gist of this is that we are now saying that Error implements the Error protocol inside the Swift module. The only way to make this trick better is if we combine it with the next one.

3. Namespaces

Wikipedia defines namespace as:

A namespace is a set of symbols that are used to organise objects of various kinds, so that these objects may be referred to by name.

In lamer terms, a namespace is just the name of the structure under which we will define more objects, methods, constants, etc….

Namespacing in swift has become one of the most useful things a developer can use to make the code more structured, clear and allows us to not have to break our brain every time we want to give a name to something that might collide with another.

To create a namespace we can use an enum, a struct or even a class. But the most efficient way (and also safer) is to use an enum since it does not have a init method that would prompt someone to create an instance of it. Though this will depend on what you are trying to achieve. For example: let's say that we have an object that has some methods that can throw. Normally we would define the enum implementing the error protocol and give it a tedious name that contains the word error in it, but combining namespaces with the previous tips we can do as follows:

4. Moulds

A mould is a container that you use to make replicas of something that needs to be mass produced. In code we can do something similar. We can define the basic structure that a specific component needs to have and use that as our starting point.

For instance, something that happens very often when coding is having to define a UI element that is going to be used across the whole app in that same style multiple times. Lets take UILabel, most likely we will have headings, bodies, captions, legends and such and if we are not careful then we can have the same styling code across the app multiple times. This will be a pain to maintain and even harder to refactor if something in the design changes for that component.

The solution that I propose here is to make moulds that can be reused and because every-time we use this label it is based on this mould, if the mould definition changes, it spreads across the whole app wherever it is used.

If you are now asking yourself. “OK, this sounds cool and all. But how do we make moulds?” — Here’s an example:

5. Class Vars

If you paid close attention to the previous example, you noticed that the moulds were defined as class var. Why? — Because of simplicity really, there’s nothing blocking you from making a static func instead. The only difference is that by being a var it takes no arguments. By using class vars we can take advantage of compiler type inference like we normally do for UIColor. It’s rare when I see a developer nowadays writing UIColor.black instead of just .black. In the end, this is only a coding preference.

Now it is up to you to decide if this is useful or not, and if it’s something that you like and would start (or even keep) using.

If you have some useful tips or tricks that you would like to share with the community you can do it in the comments below. Because, as they say:

Sharing is caring.

If you enjoyed this article consider giving it some claps. Also, if you feel like it, you can follow me on twitter at: MikePT28.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store