Opaque Return Types is a feature added in Swift 5.1 that is a big part of the new SwiftUI framework's functionality. It comes to finally fix a fundamental problem of the usage of protocols and the design of Swift APIs, opening new possibilities for the creation and usage of public APIs. Let's see the compiler magic behind it and why SwiftUI uses it to return the some View type.

Announced in WWDC 2019, SwiftUI is an incredible UI building framework that might forever change how iOS apps are made. For years we've engaged in the war of writing views via Storyboard or View Code, and SwiftUI seems to finally end this. With its release, not only Storyboards are now pretty much irrelevant, but the old fashioned View Code is also very threatened as SwiftUI mixes the best of both worlds.

The thing is, it looks very different from the Swift we're used to, and the reason is because it empowers a few new "unreleased" compiler features. Let's see how this works.

Foundation's NSAutoreleasePool type, later abstracted to the @autoreleasepool block, is a very old concept in iOS development. During the Obj-C era of iOS, usage of this type was important to prevent your app's memory from blowing up in specific cases. As ARC and Swift came around and evolved, very few people still have to manually play around with memory, making seeing it become a rare occurrence.

Having developed tools that need to allocate enourmous amounts of memory, I asked myself if there's still a case where @autoreleasepool is useful in Swift 5. Here are the answers.

When teams start to grow, it becomes to difficult to track what everyone is doing. If the team has different ideas on what a specific piece of code should look like, you can very quickly end up with a project where nobody wanders outside the things they coded themselves. Style guides can be seen as an anti-pattern when the subject is speed and there is often resistence from developers that haven't been part of large projects, and indeed having a traditional bureaucratic process in this modern tech world seems very odd, but a strict style guide is critical to have a project scale to the point where you can have hundreds of developers like Uber.

When deadlines are tight and the product faces considerable changes, it's common for developers to make concessions in the project's quality to make sure it gets shipped in time. This leads to release anxiety - that stressful feeling where you're unsure if you're shipping something that actually works. As a result, teams resort to heavy amounts of manual testing, staying overtime to make sure nothing fell apart and an unhappy environment in general. Avoiding Release Anxiety is a series of posts where I show the things I do to develop durable Swift apps that allow me and my team to sleep worry-free at night.

In this edition, I show why I like UI Tests and how I build them to make my projects reliable.

In iOS, the Responder Chain is the name given to an UIKit-generated linked list of UIResponder objects, and is the foundation for everything regarding events (like touch and motion) in iOS.

The Responder Chain is something that you constantly deal with in the world of iOS development, and although you rarely have to directly deal with it outside of UITextField keyboard shenanigans, knowledge of how it works allows you to solve event-related problems in very easy/creative ways - you can even build architectures that rely on Responder Chains.

iOS already allows you to add "shortcuts" to an app in the shape of 3D Touch Quick Actions, but they are very limited, hidden from the user, and let's be honest - it's one of these features that nobody remembers. You can also use Siri Extensions, but then you have to deal with Siri, and the regular Siri Shortcuts relies on the Shortcuts app, so it's not something that you can provide to your users. Wouldn't it be great if you could give your users the ability to add shortcuts to things like ordering their favorite coffee in the shape of a home icon - just like the app itself?

Well, after reverse engineering Apple's Shortcuts app, it turns out that you can! That's exactly what it does when you add a system shortcut to the home screen, and we're going to replicate it in order to give users the ability to add home icons that directly open a specific part of an app.

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.