After the announcements Apple made during its WWDC 2019, we immediately dove into the range of new features and updates. Most importantly, we love to see that Apple is working hard to make developers save time and effort when writing UI code, thanks to its new SwiftUI.


The quest for better apps, with less code.


apple swiftUI


There is an upcoming need for more efficient programming frameworks that make developers' lives easier. We all want to build better apps, with less code. Because of this, we recently have been exploring the possibilities of cross-platform technology Flutter. (Read more on Flutter in our blog post Flutter, not your ordinary cross-platform framework.) Since Flutter answers that need, we’ve already welcomed this technology to our stack. However, we don’t believe Flutter is ready for the big projects just yet.

A large part of the bigger iOS apps we are building is written in Swift. Swift is a compiled programming language for macOS, iOS, watchOS, tvOS etc. Unlike Flutter, at this point Swift is not suited for user interface code sharing yet. Because this results in unnecessary complex development flows, writing in Swift can look a bit messy.


Out of the box

In view of this, we were very pleased to hear Apple came with a solution: SwiftUI. This language uses the power of Swift to build exceptionally simple user interfaces across all Apple platforms. With its declarative syntax, SwiftUI makes it a lot easier for developers to write and review UI code.

Thanks to Previews, similar to hot reloading in Flutter, it’s now possible in Swift to immediately see the changes out of Xcode. Aligning data structure with the visual layers of the code has never been so smooth and easy.

For example: when you want to build a simple UIview we are used to writing the following in Swift:



Which is equivalent to the next few lines of code in SwiftUI:




As you can see, Apple is thinking out of the box here. They have put a lot of thought into the architectural picture so that, once you have passed the learning stage, you can make things work with little effort.


So, icapps goes SwiftUI?

Let’s not get too excited here. We are not in a rush. SwiftUI offers a lot of opportunities, which we will closely monitor. However, we prefer to start writing parts of code in SwiftUI to discover its possibilities step by step, depending on the project.

We must also bear in mind that Apple’s UIKit, the tool we use today for writing UI for iOS and tvOS apps, will evolve with new functionalities too. So we remain critical and keep weighing all our possibilities carefully before starting a project.

Interested in learning more about the technologies we use and our ways of working? Check out our services.