Swift/SwiftUI: Apple’s Native Language

Swift is the programming language launched by Apple. It can be used to develop iOS, Mac, Apple TV, and Apple Watch applications. Apple first introduced it at the 2014 Worldwide Developers Conference (WWDC). Despite remaining the main contributor, Apple announced that Swift would be made open source one year later.

In 2019, Apple made the release of SwiftUI, a framework to supplement the language that permits the construction of its graphic interfaces in Swift based on the declarative programming paradigm, official while presenting iOS 13.

First, let’s look at the pros and cons of the Swift/SwiftUI combination.

The Benefits of Swift/SwiftUI

The Benefits of Swift

Since its creation, the Swift programming language has demonstrated many benefits that have contributed to its popularity among mobile developers. These include:

A simpler language: Swift is easier to use and more user-friendly than Objective-C. Since it is more recent, it boasts the capabilities of newer languages. It is also faster: the “syntactic sugar” means the developer has less to write to achieve the same result: the time saved and improved application performance are real.
An open source language: like all open source languages, Swift is free (no need to purchase a license). There is extensive documentation available, and while Apple remains the primary contributor, the community also contributes to the development of the language.
Compatibility with Apple’s ecosystem: Swift was created by Apple and is therefore compatible with all of the brand’s platforms:
- iOS (phone)
- iPadOS (tablet)
- watchOS (smartwatch)
- tvOS (TV box)
- macOS (computer)

The Benefits of SwiftUI

SwiftUI provides additional benefits, particularly in terms of code and simplicity for the developer:

Declarative programming which allows developers to build user interfaces by describing “what they want” rather than “how to build it.” To use a more familiar example, when you order a burger at a restaurant, you tell the waiter what you want (“a cheeseburger with extra bacon and ketchup”) and not how to make it (“place a beef patty and a lettuce leaf between two pieces of bread…”).
A more lightweight code: SwiftUI makes it easier for developers to write code with significant time savings because it is based on a “less boilerplate” code logic.
Live preview: SwiftUI allows you to preview the interface rendering without running the application.
Easier interface sharing: previously, the user interface (UI) was primarily created using the Xcode Interface Builder, which automatically generated the XML file from the screen. This made it difficult for multiple people to work on it simultaneously. Now that the code is generated by the developer rather than the tool, it is easier for multiple developers to create interfaces and resolve potential conflicts because the code is controlled.

The Disadvantages of Swift/SwiftUI

However, as with all technologies, Swift and SwiftUI do still have some disadvantages to consider.

Swift is still a relatively new language so some long-awaited changes and improvements are needed (for example, the addition of integrated async/await from version 5.5, bearing in mind the current version is 5.5.3). SwiftUI’s use is still limited because it is only supported by the latest versions of Apple’s operating systems:

iOS, iPadOS, and tvOS 13 and later versions
watchOS 6 and later
macOS 10.15 and later

Cellenza’s Recommendations for Using Swift/SwiftUI

If you want to develop native apps, you have several options, but Objective-C is increasingly being abandoned in favor of Swift.

The development of applications for the Apple ecosystem was still in a transitional phase at the time of writing this post. This is particularly true for the user interface.

You can still build your screens using the classic UIKit/Interface Builder version, but we now recommend using SwiftUI instead where the technical constraints allow. Older versions (not supported by SwiftUI) of operating systems will become rarer and rarer. The Swift/SwiftUI duo will become the standard for developing native Apple applications in two to three years.

Case Study: Swift/SwiftUI Application Development Feedback

Today, we’re going to share our feedback from a foreign language vocabulary learning mobile application project developed by Cellenza’s experts using Swift/SwiftUI. The application is based on repeating words to be memorized using a specific rhythm to help users learn and remember them. Statistics screens monitor progress: number of words being learned, number of words remembered, number of successes and fails, etc. Secondly, the application will feature challenges between users, rewards, vocabulary sharing, and the ability to create themed word lists.

In technical terms, the application took four weeks to develop.

Choice of Technology for the Mobile Application Development

How did we choose the technology? Above all, the security aspect won us over. In fact, unlike Flutter, a community-supported framework, we opted for a native language, removing any risk of it disappearing by ensuring that the language will not be abandoned.

We ultimately chose Swift/SwiftUI (on iOS) over Kotlin (on Android) because it offers greater simplicity when developing certain elements. Since iOS has a limited device fleet, the UI rendering is optimal on all end devices. The fact that there are so many Android devices (due to the large number of developers worldwide) makes testing and adapting the rendering for all screen types extremely difficult.

What Difficulties Did We Face?

A familiarization period was necessary, as with any new or recent technology. In this particular case, coming from the world of Xamarin, we were used to designing screens using the UIKit/ViewController classic combination. Using this technology, we had to find a new way that required us to ask questions that we knew how to answer with a different technology (for example, this was the case for navigation).

As a result, someone just starting out with mobile app development would not have to break their usual habits. A more seasoned developer used to the old way of working will require some personal investment to change their mindset and get used to working with this new tool.