Matteo

Monolithic views are the most common issue in SwiftUI codebases, especially among inexperienced developers.

While the declarative nature of SwiftUI makes it possible to quickly put together complex user interfaces, it also makes it easy to create massive view bodies that soon become unmaintainable.

In this article, we will see how to modularize your code to make SwiftUI views more reusable.

Since the introduction of SwiftUI, the MV pattern has been discussed in online forums about SwiftUI architecture.

Its proponents sell it as a new pattern that aligns with how SwiftUI is intended to be used, while patterns like MVVM are allegedly at odds with the framework.

In this article, I will show how the MV pattern is just a rehash of MVC, and ideological adherence to this so-called new pattern only leads to violating fundamental design principles.

Architectural design patterns like VIPER might seem radically different from common ones like MVVM.

However, upon deeper inspection, it turns out that these patterns share the same constitutive components.

In this article, we will compare the MVVM and VIPER design patterns in SwiftUI and show how they follow the same principles.

SwiftUI provides several tools for managing navigation, and the introduction of NavigationStack and value-destination links improved programmatic navigation.

However, in larger applications, vanilla SwiftUI navigation can pose challenges for testability, maintainability, and modularity. Navigation logic is distributed across views, introducing coupling and making the navigation code hard to locate.

These problems can be addressed by integrating coordinators into the MVVM pattern.

Some developers claim that MVVM is incompatible with SwiftUI.

However, with a proper understanding of SwiftUI, it is possible to address any criticism and remove the boilerplate code shown in many online blogs.

In this article, we will explore some fundamental yet ignored SwiftUI features to understand how to replicate its integration with SwiftData inside our view models.

If you've been working with SwiftUI, you've likely noticed that your views start pretty simple but then balloon into large, unmaintainable monoliths that are hard to preview and test.

While there are several techniques to keep SwiftUI views modular and reusable, some problems are architectural in nature and can only be addressed by following proven software design principles.

As you create increasingly complex SwiftUI views, you may feel your code is turning into a tangled mess of nested stacks, layout view modifiers, and conditionals.

In this article, we’ll explore how to leverage SwiftUI’s full toolkit—beyond just stacks—to build configurable views. You’ll learn to use built-in specialized views, view styles, and view builders for idiomatic code that’s easier to customize.

Plenty of SwiftUI tutorials dive straight into building user interfaces without much consideration for architectural principles. These often lead to a common pitfall: massive SwiftUI views.

In this article, I introduce a robust approach to building modular SwiftUI views that are more reusable, easier to understand, and instantly previewable in Xcode.

Since the introduction of SwiftUI, the MVVM pattern has become more relevant than ever. Many developers believe this particular pattern aligns well with the SwiftUI data flow.

MVVM incorporates good ideas but also introduces problems due to varying interpretations of the pattern and its perceived rigidity.

In this article, we’ll explore how MVVM fits into SwiftUI, how to leverage its advantages, and how to navigate its challenges

AsyncImage is a convenient SwiftUI view that loads remote images using a URL. It's especially useful in apps that interact with REST APIs since images are usually referenced using URLs in JSON data.

While Apple's documentation might lead you to believe that AsyncImage caches the downloaded images, that is not the case. If you need image caching, you must implement your own custom solution.

Parsing JSON data is fundamental to any iOS app that performs remote REST API calls.

Thanks to the Codable protocols introduced in Swift 4, Swift has a native and idiomatic way to parse JSON data.

Paired with the JSONDecoder class, the Decodable protocol allows straightforward JSON decoding in a few lines of code and more sophisticated techniques to handle all the possible data formats and edge cases.

JSON data is not always homogenous. There are instances in which a JSON object field can contain objects containing different information.

In such cases, the Swift type for the decoding must be determined dynamically.

JSON data is rarely flat and often contains nested objects.

Nested JSON data can be decoded in Swift using the `Decodable` protocol and the `JSONDecoder` class.

However, how you decode nested JSON objects depends on the final result you want to obtain.

JSON object with dynamic keys presents a specific challenge when decoding data in Swift because stored properties cannot represent dynamic keys.

However, it’s still possible to decode JSON with dynamic keys using the Decodable protocol into dictionaries or arrays by implementing structures that conform to the CodingKey protocol.

You can easily parse JSON data in Swift by creating a `Decodable` type that matches the structure of a JSON object.

However, we often need to decode JSON data that does not match the model types of our apps. In those cases, we need to control the decoding using coding keys.

Fetching and parsing the JSON data returned by a URL is straightforward in Swift, thanks to the JSONDecoder and URLSession classes of the Foundation framework.

Since Swift 4, the recommended way to parse JSON data is to use the `Codable` protocols with the `JSONEncoder` and `JSONDecoder` classes.

However, this method requires creating Swift model types that match the JSON data structure you need to decode.

Sometimes, you might want to avoid creating extra Swift types if you only need to read some of the information in the JSON data locally.

Apps often need to read the content of JSON files for different reasons.

You can save static JSON data inside an Xcode project to populate your app or use it in SwiftUI previews.

Apps can also save data inside the device’s documents directory.

JSON data is often not human-readable because web servers strip all white space to save bandwidth.

Converting JSON data into a formatted string helps build decodable Swift types and is useful when debugging and testing an app’s code.

The Date type is a Codable type in Swift. However, dates are not straightforward to decode, like other types conforming to the Codable protocol, because the default format used by JSONDecoder is not standard in JSON.

Dates can be encoded using different formats in JSON data. To handle all these formats, the JSONDecoder class has a dateDecodingStrategy property, which can be configured with several decoding strategies according to the date format you must decode.

Becoming an iOS developer is a great career choice that allows you to demand a high salary and work on interesting projects at top companies.

Learning iOS development can take time, but you can speed up the process and optimize your learning following the steps I outline in this article.

You can make a REST API call in Swift in just three lines of code thanks to URLSession and async/await.

However, implementing a networking layer in a full-fledged app presents several architectural pitfalls.

In this article we will see how REST works, how to perform API calls in a SwiftUI app, and the best way to architect the networking layer of an iOS app.

A Swift dictionary stores and access data with logical relationships, holding any number of key-value pairs as long as the keys are unique.

Many modern iOS apps are connected to the internet.

When you need to download or upload data, URLSession is the solution.

Together with other types, URLSession not only transfers data over a network but also groups transfers together.

Conditionals are a fundamental part of programming in Swift.

The first conditional statement you learn is the if statement. It’s not the only one, though, nor is it the most used.

Another example is a guard statement. Guard statements are often much more common than if statements.

URLs are omnipresent in today’s world, and iOS apps are no exception.

The URLs you use in Swift can identify different resources. The most common examples are web content, local files, and REST API endpoints.

The way you handle a URL in Swift depends on two things. The resource it identifies and how you manage the resource in the architecture of your app.

Arrays are the most commonly used data type in Swift and other programming languages. You will often use arrays to organize your app’s data as they are the most versatile data structure.

The easiest way to install Xcode is using the Mac App Store.

But that’s not necessarily the best way.

While you can install Xcode with a simple click, using the Mac App Store is very slow, and the download might hang indefinitely or return cryptic errors.

The ternary operator is a conditional operator that you can use to write complex conditions using just one line of code. It is straightforward to use and powerful.

In this article, I will highlight the most common use cases of the ternary operator in Swift. I will also review the advantages and disadvantages of writing conditions using the ternary operator instead of if-else statements.

Switch statements compare specific values against different cases and execute the block of code associated with the first matching case. You can achieve the same result using an if statement with multiple else clauses, but switch statements are easier to read and understand at a glance.