Skip to main content
Contributions of all kinds are welcome — bug reports, feedback, and code. This guide covers setting up the development environment, the component generation workflow, and the pull request process.

​
Ways to contribute

  • Analyze issues — Browse open issues and comment on those that affect you. Triage feedback helps the team prioritize work.
  • Report a bug — File a new issue with as much detail as possible.
  • Submit a pull request — All code contributions are handled via PRs targeting the main branch.
  • Improve documentation — If the README or API docs are unclear, let the team know.

​
Setting up the development environment

1

Check prerequisites

Make sure you have the following installed:
  • Xcode 26.0 or later
  • Swift Package Manager (included with Xcode)
  • Homebrew (brew)
  • Python 3.7+ with pip (use pyenv to manage versions)
  • npm 5.2+ (includes npx)
2

Clone the repository

git clone https://github.com/SAP/cloud-sdk-ios-fiori.git
cd cloud-sdk-ios-fiori
3

Run the setup script

Run the collaborator setup script from the repository root. This installs git hooks, SwiftFormat, SwiftLint, Sourcery, and commitizen:
./setupForCollaborators.sh
The script installs:
  • A pre-commit hook that runs SwiftFormat automatically.
  • A pre-push hook that runs SwiftLint before your code reaches remote.
  • A commit-msg hook that guides you through Conventional Commits format when you run git commit.
  • Sourcery for component code generation.
4

Open the package in Xcode

Open Package.swift in Xcode, or open the example app at Apps/Examples/Examples.xcodeproj.

​
Running tests

Run the full test suite for iOS: 
make test_ios
For watchOS (only FioriThemeManager is supported on watchOS): 
make test_watch
You can also use xcodebuild directly with the FioriSwiftUI-Package scheme.

​
Component generation with Sourcery

FioriSwiftUICore components follow a consistent initialization pattern that is generated using Sourcery. If you are contributing a new component, use the generation workflow rather than writing boilerplate by hand.
1

Define the protocol

Add your component protocol to BaseComponentProtocols.swift or CompositeComponentProtocols.swift with the appropriate Sourcery annotation:
// sourcery: BaseComponent
protocol _OptionsComponent {
    var options: [AttributedString] { get }
}

// sourcery: CompositeComponent
protocol _SegmentedControlPickerComponent: _OptionsComponent {
    // sourcery: @Binding
    var selectedIndex: Int { get }
}
2

Run code generation

sourcery/GenerateComponent.sh
3

Implement the style

Move the generated style file from _generated/FioriStyleTemplates to _FioriStyles and remove .generated from the filename. Implement BaseStyle (layout) and FioriStyle (Fiori-specific styling, colors, fonts) in that file.Only edit the style files — all other generated files are managed by Sourcery.
4

Add example and tests

Add test cases in the corresponding folder under Examples/FioriSwiftUICore and register them in CoreContentView so they appear in the example app.
For a full walkthrough with a concrete example, see CoreComponentGeneration.md.

​
Commit messages

This project follows Conventional Commits. After running setupForCollaborators.sh, running git commit launches an interactive commitizen prompt that guides you through the format. Examples of valid commit messages: 
feat: add DurationPicker component
fix: correct color variant resolution in dark mode
refactor: simplify ObjectItem initializer overloads
docs: update contributing guide
The pre-push hook runs SwiftLint. Fix any violations before pushing, or the push will be rejected.

​
Pull request checklist

Before opening a PR:
  • Add or update tests to cover your changes.
  • Verify all tests pass (make test_ios).
  • Confirm there are no SwiftLint violations.
  • Check that your commit messages follow Conventional Commits format.
  • Target the main branch.

​
Legal

First-time contributors are asked to accept the Developer Certificate of Origin (DCO) via an automated process during PR submission. This is a standard Linux Foundation requirement and confirms you have the right to submit the code.

Build docs developers (and LLMs) love

Get started for freeTalk to us