Skip to Content
Technical Articles
Author's profile photo Kevin Riedelsheimer

An Introduction to the Fiori SwiftUI Open Source project

During WWDC 2019, Apple introduced a completely new way of building UI for Apples devices. SwiftUI is a declarative UI framework which makes it easy to create platform conform User Experience, the great thing is that you get a clean UI without much change for the devices Apple is offering.

With the current project I am working on I was wondering if I could use the SwiftUI technology in combination with the SAP BTP SDK for iOS. The short answer is yes with some limitations.

In this blog post I want to quickly introduce you to the SwiftUI implementation of the SAP Fiori for iOS Design Language and my approach of building a SwiftUI based business application.

Before we get started, if you haven’t had the chance to get an introduction to SwiftUI you can go ahead and use the following links to get started:


Current State of the SAP BTP SDK for iOS

At the moment the SDK doesn’t provide complete SwiftUI implementation of the UIKit based controls within SAPFiori. What is possible, realised through Apples implementation is that you can run SwiftUI and UIKit within the same app. Both frameworks have a different approach on the app lifecycle and how Views are managed, but with protocols provided by Apple you can run SwiftUI inside UIKit and vice versa. What does this tell us? First of all it allows us to build complete screens based on SAPFiori and combine them with your own views from SwiftUI. Also it is possible to use the other SAP provided frameworks within your SwiftUI app like SAPFoundation, SAPCommon, SAPOData and others. You can also wrap SAPFiori controls with the UIViewRepresentable and/or UIViewControllerRepresantable depending of the type the control represents. In example a table view cell would need to be wrapped with the UIViewRepresentable protocol as it is based on UIView. This is the Apple provided way of wrapping controls and make them available within SwiftUI.

With these options you can build up a SwiftUI/UIKit app using the SAP provided frameworks within for data loading, onboarding, security and so on.

But SAP is not sleeping and wants to provide and support Apples new technology stacks as fast and reliable as possible. For that reason the team behind the SAP BTP SDK for iOS decided to provide an Open Source project on GitHub for the SwiftUI integration of the SAP Fiori for iOS Design Language. At the moment we got a really solid implementation of the Charting library in SwiftUI called FioriCharts. For other controls I will talk about them a bit later.

As mentioned the team is working on bringing the SAPFiori controls to SwiftUI with the open source repository. These controls get currently developed in a separate branch to the main branch called migration. These are experimental implementations and ideas on how to realize the available SAPFiori controls. Within the migration branch we got different things we can look at, but before I introduce these to you I want to highlight: The repository, especially the migration branch, are not only open source but also experimental and just first ideas on how a SwiftUI migration could look like and therefore not ready for productive usage. See them more as a preview for you as a developer to try out this technology and get an idea on how you could use them.

The Migration Branch

The migration branch is used for experimental development of the UIKit based SAPFiori controls. In here you will find a nice documentation on how you can use the already existing experimental controls, how you can build your own Fiori controls and sample apps for you to look at.

Let’s talk about how you would use these controls. There are two different approaches on how you can use these controls, one would be over a view initializier and the other is view builder based.

Initializer based approach

The initializer based approach would be similiar to creating a Text in SwiftUI or any other SwiftUI base control. A good example would be the KPIViewExample where the initialization of an KPIItem looks like this at the moment:


KPIItem(data: .components([
                   .icon(Image(systemName: "heart.fill")), 
                   .icon(Image(systemName: "hand.thumbsup")), 
         subtitle: "Likes & Thumbs-Up")

You’re basically initializing the KPIItem with passing in the needed arguments for the control to work. The control itself decides on how it looks like and what controls it uses from within like the distinction between Text or Image, Font, Text Color, … .

ViewBuilder approach

With the View Builder approach you got another SwiftUI paradigm introduced when it comes to building UI. The View Builder approach lets you create the control you need and modify it over dot notation.

KPIHeader {
                KPIItem(kpi: {
                }, subtitle: {
                    if #available(iOS 14.0, *) {
                        Text(Image(systemName: "square.and.pencil"))
                    } else {
                        Image(systemName: "square.and.pencil")
                KPIItem(kpi: {
                }, subtitle: {
                    if #available(iOS 14.0, *) {
                        Text(Image(systemName: "square.and.pencil"))
                    } else {
                        Image(systemName: "square.and.pencil")
        .environment(\.horizontalSizeClass, .regular)

This approach gives you a bit more flexibility on how you want your control to look like as you can change for example a text to an image, or change the font and text color.

Mix both of the approaches

If we take the same example as above you can mix both approaches to get a nice way to define your UI in a simple but still flexible way. For some you might want to go with the standard implementation of the control and for others you want to modify a bit more like changing the font and text color.

VStack(spacing: 16) {
            KPIItem(data: .components([.unit("$"), .metric("121.98"), .unit("USD")]), subtitle: "Average Spending")
                .subtitleModifier { content in
            KPIItem(data: .components([.unit("$"), .metric("999,999.98"), .unit("USD")]), subtitle: "Very Very Very Very Very Very Very Very Very Very Long Subtitle")
            KPIItem(data: .measure(Measurement(value: 200.50, unit: UnitMass.kilograms), mf), subtitle: "Current Weight")
            KPIItem(data: .percent(0.695), subtitle: "Acceptance Rate")
            KPIItem(data: .duration(92000, df), subtitle: "Working Hours")
            KPIItem(data: .components([.metric("888,888"), .unit("mi")]), subtitle: "In Store Purchase With a Label That is Two Lines")
            KPIItem(data: .components([.icon(Image(systemName: "heart.fill")), .metric("2K"), .icon(Image(systemName: "hand.thumbsup")), .metric("7.5K")]), subtitle: "Likes & Thumbs-Up")


In case you want to actively contribute to the success of the open source repository you can do this using the Sourcery approach on building UI controls. Sourcery allows the SDK team to define rules on how the controls should look like, with that they achieve that controls build with this approach to have the same API paradigms which is important for the developer who uses the framework controls. If you want to build controls and contribute them to the repository or if you just simply want to build your own Fiori conform controls you can use this technology.

Sourcery is an open source project by krzysztofzablocki and is a meta-programming approach for Swift.

If you want to learn more about how to contribute you can read through the readme chapter FioriSwiftUICore.


SwiftUI is a great piece of technology to create innovative user experience, it plays well together with the SAP BTP SDK for iOS and the efforts or porting the UIKit SAPFiori controls to SwiftUI are great!

We’re not quite there yet to say that SwiftUI is completely replacing UIKit but in my personal opinion this will happen eventually in the future. It is definitely an interesting and exciting journey and with the open source project by the SAP BTP SDK for iOS Team we get direct insight on what is happening. Also contribution is possible which is great for those of us who want to be an active part on the evolution of the SwiftUI based framework of the SAP Fiori for iOS Design Language!

I would encourage you, if you want to try out SwiftUI, to go over to the repository and give it a star to stay up-to-date with the newest changes. Don’t be afraid to realize a great idea you’re having and creating a pull request on GitHub.

If you want to see how I am creating a small iOS app based on SwiftUI and the SAP BTP SDK for iOS, head over to YouTube and check out my latest SAP TechBytes video!

Feel free to shoot questions in the comment section or let me know your opinion 🙂.

With that Happy Coding! 🧑‍💻

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.