The Most Common Issues I've Caught Reviewing Swift - HackerOne

One effect of this is seen when reviewing Swift code: sometimes developers use conventions that don’t take full advantage of Swift’s capabilities, or they misunderstand how certain language features are meant to be used. In this post, I’ll cover the top three issues I tend to see in code reviews of Swift. ## 1. Misunderstanding reference counting and ownership Swift’s memory management is based around a system known as ARC (automatic reference counting). There is no garbage collection mechanism like those found in other languages and platforms. So a misunderstanding or misuse of the ARC system is a common cause of memory leaks and subsequent crashes. Every object in the Swift runtime keeps a count … eventually finishes, it will attempt to perform methods on the object outside of its intended context, which in a best case scenario is inefficient and could affect performance of the application and in a worst case scenario will cause a crash. There’s a fairly simple solution to a problem like this. When a closure is performing an asynchronous operation with an … ## 2. Unwrapping optionals Another issue I encounter commonly in code reviews is improper handling of optionals. Optionals take a type and wrap it in a special enumeration, which permits it to have a valid value of nil. For instance: ``` var a: Int // Compiler defaults to 0 var b: Int? // Compiler defaults to nil ``` … This is telling the compiler “I know that nil is a valid value for myObject, but I am 100% sure this will never be nil. Or if it is, I’m comfortable with this crashing.” I recommend this technique ONLY be used with IBOutlets in apps. IBOutlets expose properties to the Interface Builder tools inside Xcode. They are almost always references to view objects which will exist alongside a view controller or similar structure. Because of how IB files are inflated and wired to their controller counterparts, it’s not possible to make these outlets non-optional. As such, a common pattern is the following: … Note that this can be cumbersome for large data models and I definitely don’t recommend implementing this unless you absolutely have to. Because of all the messy try syntax, it’s easy to introduce an error that will be painful to debug. The rule to follow with `Codable` should be to setup only as simple as possible; let the Swift compiler do the heavy lifting.