Being able to work in projects of the most diverse varieties gave me the chance to be in contact with several types of developers and code bases. Besides their core differences, what stood out to me during this process is that projects with a lower level of maturity will always face similar problems.

Perhaps they choose the wrong architecture, or the lack of unit tests caused a nasty bug to sneak into production, but there's a specific problem that always draws my attention - callback hell. If not treated from the very beginning, these awful pyramids of braces you get when chaining callbacks inside other callbacks or conditions plague code bases with an eternity of impossible code-reviews and distant screams of "what the hell is this method supposed to be doing?". I've shared a few tips on how to avoid them.

The @dynamicMemberLookup attribute was introduced in Swift 4.2 to add a certain degree of dynamism into the language similar to what is seen in languages like Python. I was interested in learning how the attributes worked inside the compiler to know more about how this attribute is able to transform fake expressions into legit ones, so I've once again reverse-engineered the Swift compiler to find these answers - and used this knowledge to create a brand new @swiftRocks attribute.

Added in Swift 3, the Never type allows you to define a method that is guaranteed to crash your app. Although we rarely write methods that use this type directly, we do interact with it constantly given that it is the return type of all forced-crash methods like fatalError(). The advantage this type brings is that a method that calls another Never-returning method does not need to provide a return value, after all, a crash is certain to happen. I investigated how that works.

Metatypes are pretty useful in Swift, and you have certainly used it in multiple occasions. Unfortunately they look pretty weird in code, which can cause some confusion when trying to understand what they really are.

I for one know how these weird suffixes can confuse you, but don't worry, they are actually pretty straightforward once you get to know the differences between each of them.

Siri Shortcuts are definitely my favorite iOS 12 feature. Ever since SiriKit first came out I was very disappointed that you couldn't use it for your own custom commands, but the new Shortcuts app solves this problem. Not only it allows you to create your custom commands, but it also provides a very intuitive UI to allow even non-devs to automate tons of kinds of workflows in their iPhones.

We've all seen how to create a workflow and make your app expose custom actions, but one thing that I haven't seen people mention is that the Shortcuts app exposes several deeplinks for opening and running shortcuts - meaning that you can make an app that runs other apps' Siri Shortcuts. I used this to make an app run my "Take Picture" shortcut every time I tapped my AirPods.

CaseIterable is one of my favorite features in Swift 4.2. Despite being a simple protocol, it solves the common problem (that I personally faced many times) of needing access to an array containing all the cases of a certain enum. But this protocol is special: The requirements are automatically filled by the compiler. I investigated how that works - and as a bonus, modified it to also provide a first property.

I was browsing the Swift forums when I stumbled across a discussion regarding an undocumented feature of Swift (as of this post's date): the ability to give associated types a default value. Here's how they can improve your objects.

Usage of high-order functions like map and filter are very common in Swift projects, as they are simple algorithms that allow you to convert extensive ideas into simple one-liners. Unfortunately, they don't solve every issue - at least not in their default implementations. High-order functions are eager: they use the closure immediately and return a new array, regardless if you need an early return or only going to use specific elements.

Pattern matching is available everywhere in Swift, and you have likely used it tons of times to deconstruct and bind values in things like switch cases. While regular switch cases are the most common use for patterns, Swift has several types of patterns which can be mixed and even used outside of switches to result in really cool and short lines of code. One thing that interests me in particular is that pattern matching can be used for a wide variety of things.

The choice between using Storyboards and writing views programatically is very subjetive. Having dealt with both in the past, I personally vouch for writing projects entirely through view code as it allows multiple people to work in the same class without nasty conflicts, and easier code reviews.

When starting with the practice of writing views programatically, a common problem people face is where to put the code in the first place. If you follow the regular storyboard approach of putting everything view related in your view controller, it's very easy to end up with gigantic classes. However, there's also a very easy way to overcome this problem.

At July 17th, I'll be speaking at The Developer's Conference about how to develop scalable iOS apps - showing how we made an enourmous app like Rapiddo Marketplace be so easy to maintain and improve. There's a lot of code techniques involved, but a scalable app also depends on your team being connected and predictable. Our Style Guide played a big part on that, and we're making it public so that you can use it as inspiration when developing one for your project.

The @inline attribute is one of those obscure things in Swift - it's nowhere to be found in Apple's docs, doesn't help you write cleaner code and has no purpose but to help the compiler make optimization decisions, but it's related to a pretty important aspect of your app's performance.

Competitive programming is a great way to master a specific programming language. Even if you're not interested in competing in world events like the Facebook Hacker Cup, tackling difficult algorithm problems using nothing but the language's bread and butter will expose you to aspects/shortcuts of the language you would otherwise never see, such as how efficient certain methods/operations are and how to code better alternatives.

It's very common to use the weak keyword in order to prevent reference cycles in properties like delegates.

Unfortunately, since it protects you from references being lost, it forces the usage of var and an optional type, which can be quite jarring if you're building something like an UIView that is not supposed to be used without a delegate - much less change delegates suddenly. The unowned keyword allows you to overcome these issues.

It's very likely that you asked yourself at least once in your iOS career what's the difference between a struct and a class. While realistically the choice between using one or another always boils down to value semantics versus reference semantics, the performance differences between the two are expressive and can heavily favor one or another depending on the contents of your object, specially when dealing with value types.

Some people might say that knowledge of memory architecture is irrelevant for application level developers, and I agree partially. Knowing how to save a few bits here and there will make no visible difference on newer iPhones, and premature optimization is a highly shunned practice.

However, both reference and value types can severely slow down your app when misused, and such knowledge will define whether or not you can fix the problem efficiently.

I recently made a pull request to Swift, which inspired me to speak at Campinas's (Brazil) CocoaHeads about how can you do it yourself - and how to leverage the fact that Swift is open source to boost your career. I mixed Jesse Squires's, Mike Choi's and Ole Begemann's articles alongside my own discoveries to create a simple tutorial on how to approach the Swift Community. While the talk is in Brazilian Portuguese, hopefully the contents of the slides are simple enough to guide you through.You can watch it here. (starts at the 39 minute mark)

Understanding how threads operate on the CPU level is the key to writing good concurrent code. This article explains how the CPU executes multithreaded processes, what exactly are iOS's DispatchQueues, what's the point of their "Quality of Services", and why do you have to process UI code in the so called Main Thread.

If you're using TouchID/FaceID as a security measure, chances are you want to protect your user's data in case someone tries to break into his phone. By default, any fingerprint/face is able to validate an user - even if they were added after your app was installed. Learn how to detect system changes in order to stop thieves from accessing your user's data.

In this article, I show how simple is the process of reverse-engineering an App Store's app by using dumped class information and a debugger hooked to a jailbroken device to make Facebook's Messenger allow me to select custom chat bubble colors.