Swift UI: interface development made easier?

Swift UI: interface development made easier?

during WWDC 2019, several new features were announced: dark mode , iPadOS, the Catalyst project, etc. But Apple has also and above all put the emphasis on a brand new framework: SwiftUI .

Designed with the aim of offering a simpler and faster way to develop native applications, this new kid has the particularity, like some modern frameworks such as Flutter or React, of being based on a declarative approach. Web Development Agency Dubai UAE

What is SwiftUI?

SwiftUI is a new framework that allows you to create interfaces for iOS but also for all other Apple devices: watchOS, iPadOS, macOS and tvOS.

In addition to its declarative syntax, SwiftUI also provides, with the latest versions of Xcode, the live preview of the interface and the possibility of modifying the latter by code or directly via the preview.

A declarative approach
SwiftUI’s approach is declarative, and that’s probably the biggest difference this framework has from the ones iOS developers are used to. Until then, they were more familiar with so-called imperative programming, with the UIKit, AppKit or WatchKit frameworks in particular.

To explain very simply, imperative programming requires developers to write detailed and precise instructions to configure the interface and control its various states. Conversely, declarative programming with SwiftUI allows developers to simply describe the rendering of the interface based on its state and the framework does the rest. Web Development Agency Dubai UAE

Live preview and optimal system integration


Long overdue in Xcode, developers are finally getting a glimpse of what their app looks like as they write the code. As with Interface Builder until today, you can drag and drop components directly into the preview screen, and the code is directly modified. It is no longer, as with Interface Builder, an XML file that is generated, but indeed the SwiftUI code.

Beyond the purely code aspect, SwiftUI also makes it possible to automatically apply many behaviors specific to Apple environments. Developers can then adopt features such as Dark Mode or Dynamic Type for example without writing additional code.

An example of an interface created in SwiftUI with preview in light mode and dark mode
An example of an interface created in SwiftUI with preview in light mode and dark mode

The replacement potential

Since its release, SwiftUI has been talked about a lot and many developers have already taken the plunge by creating applications with this framework.

It must be said that its advantages are numerous:

Code easier to read and natural to write
Compared with existing frameworks like UIKit, the same interface can be written with much less code
Teamwork made easier compared to Storyboards
End of the endless debate on UI development in code or via Interface Builder: Apple’s answer on this point is simply SwiftUI, which gives us both at the same time

Undeniably very promising, it represents the future of interface development on Apple’s platforms. However, this should not be seen as the end of the current frameworks, SwiftUI is – for the moment – not yet ready to replace them completely.

Gaps to fill
The first obstacle to its adoption are the versions necessary for its operation: iOS 13, macOS 10.15, tvOS 13 and watchOS 6. In a professional context, even despite the high adoption rate of updates among users of Apple products, cases where an application only supports the latest version of the OS are quite rare.

Another point that can be problematic is the fact that there are still some things missing from SwiftUI to be fully equivalent to current frameworks. If we compare it to UIKit for example, components that are widely used in current interfaces are missing such as UISearchBar or UICollectionView for example. For a developer used to using UIKit, this can quickly become frustrating, especially when you know that sometimes it takes a single line of code (little thought for the expensive separatorInset of a UITableView , still unavailable with SwiftUI).

Of course, solutions exist to overcome these concerns, but it is either to create bridges with UIKit, or to go through workarounds .

From Devlinks
Within the mobile team, we tested the new SwiftUI framework in the week of its release. Like many iOS developers, our first tutorials were those provided by Apple ( link ).

It is true that for those who have never experienced declarative programming, a little extra effort had to be made, but, overall, this way of coding remains practical, and above all faster than what we are used to.

Obviously, the first times were a bit laborious, since you have to constantly look for information in Apple’s documentation or on the internet, but we quickly take the fold.

Example of a nested list in a NavigationController in SwiftUI. Everything is written in a lot less lines than with UIKit

Our first steps were largely convincing: the creation of aesthetic, functional interfaces, supporting dark mode and with animations is done extremely quickly. SwiftUI seems to us today ideal for the creation of personal applications, side projects , prototypes or if only out of curiosity and to test the novelties of Apple. However, for several reasons, we cannot afford to adopt it for our clients’ projects today.

The main reason for this impossibility concerns the minimum versions imposed by the framework. Indeed, at Devlinks , we usually offer our customers to support at least two versions lower than the current version of iOS. Currently, we are therefore developing applications compatible with iOS 11, 12 and 13 and this prevents us from using SwiftUI.

The other blocking point, as mentioned previously, concerns the components still with absent subscribers. In the case of complex UI realizations, one quickly finds oneself limited, and the fact of having to tinker to obtain the expected result is far from ideal or even risky for applications intended for our customers.

Finally, we have the impression of reliving the release of Swift in 2014: the new way of programming seems more modern and attractive, like Swift with the Objective-C. However, just like with Swift’s announcement at the time, it’s still too early to take the leap headlong. This is also a point that slows down its adoption, because we remember the many breaking changes that successive Swift updates have brought, and it could be that SwiftUI takes the same path.

The final word
If there is one thing we can take away, it’s that the question we see a lot coming back to this topic -  is SwiftUI ready for production use? – , ultimately does not have a ready-made answer and depends above all on the application to be developed. If it is to be maintained over time or if it has to support old versions, we will have to wait a little longer and stay on the current frameworks (UIKit, AppKit, etc.). If, conversely, it is a POC, a demo or an application that will only be used internally for example, SwiftUI can be considered. The advantage is that it is possible to use it in conjunction with current frameworks and gradually integrate views or components written with SwiftUI.

At Devlinks , SwiftUI has won us over with its potential, but we are a little bit unsatisfied and we regret not being able to really push its use to its maximum. We expect a lot from its next evolutions and we hope that this framework will gain in maturity quickly. See what Apple will announce to us in a few weeks during WWDC 2020 🤞 (which, for the first time, will take place online).

Custom Website Development in UAE

Online Marketing