Regardless how you feel about JavaScript as a programming language, there is one simple fact: JavaScript is pretty ubiquitous, and its uses have expanded beyond web scripting. It has become a pretty popular language for a vast array of domains. For this reason, making languages interoperate with it is pretty important, and both Swift and Objective-C are no exception. We can work with JavaScript, not only by executing JavaScript code directly from our Swift code, but we can even expose code from Swift and Objective-C to JavaScript. That’s how important this language is, and these features open a world of possibilities.
As you work on projects, you may notice that there’s one thing that can be really improved: Creating new files. Every single developer has gone to the File > New File screen on Xcode to create files before. Whether to create new view controllers, data models, or whatever else, it is one of the most common places you may use in your day to day life as an iOS developers.
Software development can be an easy thing, as it can be a very complex thing. And one of those complex things is keeping in mind all the different languages, locations, and standards users may use in their daily lives. This makes working with certain information. From different date formats to entirely different measuring system, software is challenging, especially when working with anything that requires localization. The situation is just so bad that a lot of software just make assumptions about their users environment and don’t let you change any settings.
SwiftUI forces us to change our way of thinking when building iOS apps. It makes us change from writing our apps in MVC to MVVM.
In this article, we will explore how SwiftUI can be used with certain frameworks that aren’t “SwiftUI ready”. While this article uses CoreLocation as an example, keep in mind that you can use what you learn from this to integrate almost any other framework with SwiftUI, whether it is provided by Apple or not.
We have reached the point in which computers are really fast. Especially Apple’s, as they have control of both the hardware and software, so, oftentimes, some tasks that could be sped up with multithreading, are not necessary anymore. But, for those cases when you do need multithreading, we have many options available.
On Apple’s platforms there is a surprising amount of concurrency tools. You are likely familiar with the most used one, the Grand Central Dispatch, DispatchQueue, which is pretty good and it covers the vast majority of use cases. But there are some tasks that can be done easier with other tools.
Creating configurable APIs for other developers can be a fun task. But depending on what languages and tools you are using, you may sometimes create customizable APIs that are more pleasant than others.
In today’s article, we will explore a tiny feature in Swift that allows us to create configurable APIs easily that are a joy to use by other developers: OptionSet.
Introducing OptionSet
Like its name implies, an OptionSet gives us a group of options. These options are pre-defined for our users, and when create an OptionSet, our users are constrained to using the values we are providing within.
All programmers are familiar with the concept of nullability. Whether something exists or not. Whether something is there or not.
Objective-C is very dynamic when it comes to dealing with nullability. All Objective-C programmers are familiar with this phrase:
messages can be sent to nil.
Which means that nil itself can call methods, safely enough, without crashing.
In Swift, we have a bit more safety. We can send “messages” to nil, but only if they are the result of a chained optional. nil can only be a thing when we are working with optionals.
Whether you are a seasoned developer with a lot of code out in the wild world, or you started learning programming this week, chances are you hace used (and seen) dictionaries being used in many places. Also known as hashmaps or hash tables, dictionaries allow us to store key-value mappings, from one object to another.
In this article we will study this structure which is known by everyone, and we will also learn about its quirks and unknown features.
I’m introducing a short small series in which we will talk about basic data structures in Swift. My goal is not to show how they are implemented internally, but rather to show when they can be useful.
In truth, unless you have studied Computer Science to some capacity, chances are you are missing on a lot of powerful existing data structures that can help you write better code. I have been studying iOS development for a long time with many resources, and none of the resources ever dive into useful data structures, such as sets. These sources tend to focus on arrays and dictionaries only (as the focus is iOS development, and not necessarily computer science), not teaching other structures that are actually really useful in the iOS Development world. I have never seen an iOS dev resource that covered these structures as deeply as my computer systems engineering courses did.
Swift gives us many interesting features to write cleaner and more obvious code. This code is more readable, and it helps both SDK consumers and code maintainers.
One such feature Swift has is the ExpressibleBy- family of protocols. This is a set of protocols that allow you to instantiate objects by providing some native Swift object. For example, we can instantiate an object providing a Boolean, or a String.
This family of protocols consist of the following protocols (this is not a complete list):
