Recently two friends and I were participating in a SwiftUI Jam. Over one weekend we were developing a little application in SwiftUI, which was a lot of fun.

The dashboard of the application shows multiple statistics, one of them presented as a pie chart.

In the following I want to show you the approach we took to make a simple reusable pie chart in SwiftUI.

At first I’m going to show you how to make a pie chart with fixed values to get the hang on how the slices are drawn. Further into the article I will show you our approach on making the pie chart easier to use and responsive in its size.

Drawing a circle

Drawing a circle in SwiftUI could not be easier.

Circle()

That’s it, but this will not take us far, so what we really need is drawing a slice of a pie in every size we want. So first, let’s take a look on how to draw for example a half circle. For this we are going to use paths.

I’m not going to show you how paths in general work, but with paths and arcs you can draw much more complex forms than circles.

Draw a half circle

The following code creates a half circle with a radius of 100 from degree 0 to degree 180.

.move moves the path to the correct starting point. .addArc draws an arc around the given center between the two angles with the given radius.

This is all you need to draw a half circle.

Path { path in
    path.move(to: CGPoint(x: 200, y: 200))
    path.addArc(center: CGPoint(x: 200, y: 200), 
                radius: 100, 
                startAngle: Angle(degrees: 0), 
                endAngle: Angle(degrees: 180), 
                clockwise: false)
}
.fill(Color.red)

What sometimes can be a little bit tricky, at least it was for me, is the meaning of clockwise.

In the official Apple Documentation you can see an image of a circle to understand which degree is at which position of the circle. Clockwise is defined as ‘The direction in which to draw the arc’. So one, like me, would think of a clock we all know and would expect the code in the example above with clockwise false to draw an half circle with the top half filled red, but it is the complete opposite, you will get the lower half of the circle. It is a little bit confusing and might clash with the way SwiftUI handles coordinate systems as explained in this answer by rob-mayoff.

For the following this will not be relevant because we will just work with what is given to us. I will choose clockwise as false, I’m sure this can also be done with clockwise true, but you will have to adjust the calculation later on.

Draw a Pie Chart with fixed values

But before we get to fancy calculations let’s draw our first pie chart.

ZStack(alignment: .center) {
    Path { path in
        path.addArc(center: CGPoint(x: 200, y: 200), 
                    radius: 100,
                    startAngle: Angle(degrees: 0), 
                    endAngle: Angle(degrees: 180), 
                    clockwise: false)
    }
    .fill(Color.red)

    Path { path in
        path.addArc(center: CGPoint(x: 200, y: 200), 
                    radius: 100, 
                    startAngle: Angle(degrees: 180), 
                    endAngle: Angle(degrees: 360), 
                    clockwise: false)
    }
    .fill(Color.blue)
}

We put the Path from the example in a ZStack to place multiple elements above each other and adjusted the start and end Angle for the second Path, this results in a pie chart with two halfs.

For fixed values this is all you would need, but in most cases the values shown are not fixed so let’s have a look at how we can handle this.

Simplify the UI

Our pie chart will exist of multiple slices, I ended up calling them a PieSlice. In the example above each Path is one PieSlice, so we will wrap this in a struct:

private struct PieSlice : Hashable {
    var start: Angle
    var end: Angle
    var color: Color
}

In the body of the view, we can now iterate (that’s why we need the PieSlice to perform to Hashable) the pie slices, remove the fixed angles and the color.

struct PieChart: View {
    private var slices = [
        PieSlice(start: Angle(degrees: 0), 
                 end: Angle(degrees: 180), 
                 color: .red),
        PieSlice(start: Angle(degrees: 180), 
                 end: Angle(degrees: 360), 
                 color: .blue)
    ]

    var body: some View {
        ZStack(alignment: .center) {
            ForEach(slices, id: \.self) { slice in
                Path { path in
                    path.move(to: CGPoint(x: 200, y: 200))
                    path.addArc(center: CGPoint(x: 200, y: 200),              
                                radius: 100, 
                                startAngle: slice.start, 
                                endAngle: slice.end, 
                                clockwise: false
                    )
                }
                .fill(slice.color)
            }
        }
    }
}

private struct PieSlice : Hashable {
    var start: Angle
    var end: Angle
    var color: Color
}

The pie chart can now easily be extended with more slices. The fixed values of radius and the center point will removed later on, we will now do some calculations to get rid off the fixed angles.

Calculation

When creating some kind of reusable component the saying of ‘Eat your own dog food’ always comes up to my mind. So I want to make my pie charts as easy to use as possible. The minimum of information we have to provide are the values and the color in which a value should be displayed (if the colors can be random you could also come up with some predefined colors or a RandomColorGenerator).

init(_ values: [(Color, Double)]) {
    slices = calculateSlices(from: values)
}

// Usage for the example above

PieChart([
    (.red, 50),
    (.blue, 50)
])

This is where our calculation has to come in. We have the given values that should be displayed and we need to convert these values into our slices. This will be done in the calculateSlices function.

private func calculateSlices(from inputValues: [(color: Color, value: Double)]) -> [PieSlice] {

    // 1
    let sumOfAllValues = inputValues.reduce(0) { $0 + $1.value }

    guard sumOfAllValues > 0 else {
        return []
    }

    let degreeForOneValue = 360.0 / sumOfAllValues

    // 2
    var slices = [PieSlice]()
    var currentStartAngle = 0.0
    inputValues.forEach { inputValue in
        let endAngle = degreeForOneValue * inputValue.value + 
                       currentStartAngle

        slices.append(
                 PieSlice(
                     start: Angle(degrees: currentStartAngle),  
                     end: Angle(degrees: endAngle), 
                     color: inputValue.color
                 )
        )

        currentStartAngle = endAngle
    }
    return slices
}

This might seem a bit complex at first but let’s break it down.
In the first section two calculations are done.

First we get the sum of all values. We will then devide 360.0 degrees by this sum.
This will give us the degrees which are needed to display a single value.

For example the input values are 20, 30 and 50. The sum of this values are 100.

let degreeForOneValue = 360.0 / 100
// Will be 3.6

In this example we will need 3.6 degrees to display the value 1. For 50 we will need 3,6 * 50 which is 180 this will take half of the circle.

In the second section of the calculation we iterate the input values and map them to pie slices. Additional to the conversion of value to degree we have to handle the start of each angle. Each PieSlice should start at the end angle of the previous PieSlice, this is handled with the currentStartAngle which will be added to each calculated end angle. At the end of each iteration the currentStartAngle will be set to the endAngle of the calculated PieSlice.

This is all we have to do to create a pie chart which is pretty simple to use. The example above with two half circles can now be achieved like this:

PieChart([
    (.red, 50),
    (.blue, 50),
])

// or this

PieChart([
    (.red, 1),
    (.blue, 1),
])

We can now create any pie chart. But we are not finished yet, our pie chart is dynamic in values but it is pretty fixed in its size with a hard coded center point and a radius which is fixed to 100.

Responsive size for the Pie Chart

We can get the size of the parent view by wrapping the ZStack into a GeometryReader. Our pie chart will be placed in some view, so it will be some kind of rectangle. This rectangle can have a different height and width in which we want to use as much space without overlapping.

So what do we need? First the center of the rectangle. Second the radius the pie chart can have to fit into the rectangle.

The center is the half of the width for x and the half of the height for y. These values can be accessed on the GeometryReader.

The height and width of the rectangle are most likely not the same value, except a square, we have to use the smaller of both values as radius, the pie chart then has the biggest size possible without overlapping.

GeometryReader { reader in
    let halfWidth = (reader.size.width / 2)
    let halfHeight = (reader.size.height / 2)
    let radius = min(halfWidth, halfHeight)
    let center = CGPoint(x: halfWidth, y: halfHeight)

    ZStack(alignment: .center) {
        ForEach(slices, id: \.self) { slice in
            Path { path in
                path.move(to: center)
                path.addArc(center: center, 
                            radius: radius, 
                            startAngle: slice.start, 
                            endAngle: slice.end, 
                            clockwise: false
                )
            }
            .fill(slice.color)
        }
    }
}

And that’s it. I’d love to hear any kind of feedback.

The example project can be found on GitHub. Show me what kind of reusable Views have you done with SwiftUI?

I hope you liked the article, the approach we chose and the way the pie chart can be used.

Feel free to contact me Twitter.

Happy coding!

Pie Chart in SwiftUI was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Did you ever switch from a project for work to a private project and in the rush of coding you committed and pushed your code with the wrong user? Keep reading how to avoid this situation by setting up different users for different repositories.

So we are not going to start in a cage but let’s pretend we are Tony Stark and we are working on a private project and on the side we do commit for a little iron suit we are building. Let’s create the following structure of folders and files in our root directory. The .gitconfig file in the root directory might already exist. If not create it as well.

├── Root/
│   ├── .gitconfig
│   ├── Private/
│   │   ├── .gitconfig
│   ├── IronMan/
│   │   ├── .gitconfig

Let’s start with the the config files in our subfolders.

In the Private folder ~/Private/.gitconfig, add the following:

[user]
    name = Tony Stark
    email = stark.tony@starkindustries.com

In the IronMan folder ~/IronMan/.gitconfig, add the following:

[user]
    name = Iron Man
    email = stark.tony@starkindustries.com

Finally, in the .gitconfig in the root folder we will put all the things together.

[user]
    name = Default Name
    email = default@mail.com

[includeIf "gitdir:~/Private/"]
    path = ~/Private/.gitconfig

[includeIf "gitdir:~/IronMan/"]
    path = ~/IronMan/.gitconfig

The user here is your default user for all git configs. For all projects in IronMan the ~/IronMan/.gitconfig will be applied and the user will be overwritten.

That’s it. You do not have to worry about commiting with the wrong user anymore. If you have any other ideas that simplify working with git let us know and give us feedback if you like to.

Enjoy coding.

How to use multiple users with git was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Even though SwiftUI is the new shiny tool to develop user interfaces for applications on all Apple platforms, UIKit will not be gone anytime soon. This also means, Interface Builder alongside Auto Layout will keep being the primary choice for many developers when designing user interfaces for iOS, macOS, tvOS and watchOS. This article mainly focuses on iOS, but most of it will generally be portable to the other aforementioned platforms.

UIStackView to the rescue

Since its introduction with the release of iOS 9 and especially in the last few years, UIStackView became my default choice when designing UI components in Interface Builder. To me, its main advantage is the fact that we can get rid of so many constraints which simplifies the layout extremely. I wrote about how I use UIStackView with Instagram‘s login screen as an example in my last article.

In my experience I‘ve noticed that some developers decide to not use UIStackView when the screen design has a lot of different margins between the design elements. Since iOS 11, there’s an API that addresses exactly this issue, as Apple enhanced UIStackView with an instance method setCustomSpacing. The method accepts two parameters, the specific spacing value and the arranged subview after which the custom spacing should be applied. Unfortunately there’s no way to configure custom spacing in Interface Builder, which would improve discoverability for this kind of feature.

A huge benefit of UIStackView that I take advantage of a lot, is the fact that subviews that are being hidden, do not take up any space, just as setting the visibility of views to GONE in Android. This is especially useful when dealing with dynamic user interfaces which is extremely common since almost every app in 2021 deals with some kind of network requests.
There are some instances, though, where I would need a hidden arranged subview to not give up its space. The easiest fix, which sounds a little bit hacky, is to set the alpha value to 0, which to the user effectively looks like the view is being hidden.

I also love to use UIStackView within the layout of UITableViewCell or UICollectionViewCell instances. Since most of the time, I need the cells to determine their size themselves due to different text length, images, etc., configuring the layout with UIStackView helps achieving just that.

There has been a pretty significant change with the release of iOS 14. Previously Apple called UIStackView a non-rendering View, which was their way of saying the background color was being ignored. This changed with iOS 14, so if you accidentally set a background color on a UIStackView, this color is now being reflected in the UI.

Sizes, widths and heights

When designing custom views with Xibs, the default size that is shown in Interface Builder is the size of a specific device. In some cases however, we want to design small components, nowhere near the size of an entire screen. Sure, as I mentioned before, the actual size at runtime is being determined through constraints, but when designing smaller views, I prefer setting the Size in Simulated Metrics within the Attributes Inspector to Freeform and reduce the view‘s size in Interface Builder. With Freeform, you can basically set the view‘s size in Interface Builder to any size you want.

Be careful when setting fixed font sizes in Interface Builder, as they will not react to the system text size the user has chosen. More on this topic with a real example can be found in the Accessibility part of my last article.

More smaller tips

Due to the fact that localizable keys cannot be set in Interface Builder, I prefer only setting placeholder text like „Lorem Ipsum“ for text rendering views in Xibs or Storyboards and set the localizable key programmatically instead. This has the benefit at runtime, that it is immediately visible that a localizable key was not set in code, when you see a placeholder text.
You could also translate entire Xib files, which means you have the same Xib file for each language. I do not think this is particularly useful, especially in larger apps or apps which support many different languages, as you would need to maintain the same Xib file multiple times.

When connecting views from Interface Builder to your code, Xcode defaults to the IBOutlets being weak. That is pretty strange as they should actually be strong, which Apple also encourages. You can read more on that in this Twitter discussion. When you control+drag a view into your code and change from weak to strong in the little overlay that pops up, Xcode will remember your setting.

If you ever used UIScrollView in a Xib or Storyboard, chances are, Interface Builder always had something to complain. Since Xcode 11, I have less issues with that, as Apple made it possible to use Content and Frame Layout Guides in Interface Builder. But still, there are times when I do not want to set a specific size for my content and Interface Builder is complaining. This happens a lot, when I design the content of my UIScrollView and I set a Greater Than or Equal constraint to the bottom of the scroll view‘s Content Layout Guide.

At runtime, my constraints are perfectly fine, so I could just leave Interface Builder alone. I want to get rid of that red error icon, though, so there is a small trick to do that. I add a normal Equal to bottom constraint and remove said constraint at build time. This means, it will only be active at design time and Interface Builder will stop complaining.

The last tip I want to share is simple: Just do not use IBDesignables. They were meant to make working with custom views in Interface Builder easier, but from my experience they seem broken and do not work reliably.

It is pretty rare that they are getting rendered properly, which lead to me not using them anymore at all.

Wrapping up

I really like working with Interface Builder, but I think it takes some time to get used to it. Hopefully, I could point out some things you did not know about. What tips and tricks help you the most when working with Xibs or Storyboards? I would love to hear from you. You can reach out in the comments or contact me on Twitter.

Thanks for reading!

Interface Builder tips and tricks was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git is a version control system used by many developers all around the globe. It has a lot of functionalities and you might, like me, not always remember everything you can do with it.

Create a remote branch

Let’s dive into it with an example that shows how to create and work with branches.

$ git branch feature/stepup-blog

The branch command will create a local branch only and not push it to the remote. This is pretty straightforward and the syntax is not very hard to remember.
But when I do create a new branch most of the times I want to switch to this branch immediately, so I have to checkout the branch I just created.

$ git checkout feature/stepup-blog

Next you are writing some code and it comes to the point you commit and push your changes. Remember, we are just working locally, so if you want to push your changes, git will tell you the following.

fatal: The current branch feature/stepup-blog has no upstream branch.
To push the current branch and set the remote as upstream, use

git push --set-upstream origin feature/stepup-blog

This basically speaks for itself, your branch has no upstream branch and it even tells you how to set this upstream branch.
Of course this is not the hardest git workflow that exists but it still annoys me after several times. What I like to do is create a little custom git command which execute these steps in one command, so I do not have to do all of these steps each time I create a new branch.

To maintain your git commands I suggest you create your own git repository where you can place your commands in. This enables you to track changes and share your custom commands.

I am using zsh so in my .zshrc file in my home directory, I added the following line to add the path to my repository to the PATH variable.

PATH="$PATH:/Users/mkunz/Private/git-commands"

Now let’s create our first custom git command

We are going to create a command which creates a branch, switches to this branch and pushes the branch to the remote.
Later we want to use this command like any other git command and call it like this.

$ git rbranch feature/stepup-blog

In this case rbranch stands for remote branch but you can name the command whatever you like. So we need to create a file and make it executable. Make sure you are at the root directory of your repository and create the file git-<commandName>. I choose rbranch as the command name so I have to name the file git-rbranch.

$ touch git-rbranch
$ chmod +x git-rbranch

To find out if this works, open the file and add the following lines.

#!/bin/bash
echo "Hello world"

The first line tells Unix that the file is to be executed by /bin/bash. The following command will print Hello World.

Save it and now you can call your git command like the standard git commands you know.

$ git rbranch
// Hello World

This is all you need for your setup.

Add functionality to the command

And now let’s get back to the workflow we had in the beginning and create a new remote branch.
A git command is similar to a shell script so we can pass arguments to it and access these arguments.
So we just take the steps we have and place them in our command, the parameter can be accessed by $1 referring to the first parameter ($0 points to the location of the command).

#!/bin/bash

git branch $1
git checkout $1
git push --set-upstream origin $1

And that is pretty much all you have to do.

I really like to make even simple workflows a little bit simpler. For example a git command that deletes local branches which are no longer available on the remote. Maybe a git command which automatically adds your commit message to your changelog?
I have a repository on GitHub with, at the moment, just a few git commands.
Feel free to contribute to the repository and share your custom git commands that you like to use. Also feel free to reach out to me on Twitter if you have any feedback about this post.

Happy coding.

Write and maintain custom git commands was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are many things to consider when implementing user interfaces in iOS. It starts with the basic UI, but there are many more things to think of, from dark mode to accessibility. In this blog post I want to show you my approach of implementing a design in iOS with Instagram‘s login screen as an example. If you want to follow along or have a look at my example project, you can check out the code on GitHub. Notice that this article does not cover SwiftUI. I will follow up this article with another post about general tips and tricks when using Interface Builder.

Analyzing the design

Before I go to work in Xcode, I always analyze the given design and ask myself some questions. What elements does the screen consist of? Does it make sense to split up the screen into multiple UIViewControllers? How to display error states and loading animations?

Looking at Instagram‘s login screen, the first thing that comes to my mind are the two text fields. This means, that we have to deal with a keyboard being shown, which means we might have to adjust the UI once the keyboard is visible. All the views in the center of the screen scream UIStackView to me as they all are aligned above each other. I think one UIViewController instance should be enough in this case, but you could also use a child view controller for the bottom part of the screen, if you would want to.

Starting off in Interface Builder

I generally prefer using Xibs over Storyboards to avoid merge conflicts. I am also not a huge fan of segues as it sort of hurts the flexibility of creating each screen from every part of the app. There is some UI code I am doing only programmatically, but generally I am way faster when designing the main components in Interface Builder. However this discussion should not be the topic of this article, enough posts have been written about this subject and I don‘t think what suits me best necessarily has to be the best workflow for other developers. For the login screen start off by dragging two UITextFields into Interface Builder and embed those in a UIStackView using the Embed In button on the bottom right. As the main part of the screen seems to be perfectly centered, constrain the UIStackView vertically and horizontally in the center of the view controller‘s view.

To make the stack view cover (almost) the entire width, it gets a leading and trailing constraint with a standard margin of 16.
Now the stack view just needs to be populated with all the subviews it needs. The UIStackView‘s Fill alignment and distribution are perfectly fine for this kind of design. The Forgotten password? button‘s alignment can be set to Right, every other view can just remain centered. For the separating view with the OR label, add another UIStackView containing two 1Pt high UIViews and the label in the center. This stack view needs to have the alignment set to Center, otherwise, the label would get truncated.
The Facebook SDK ships with a login button that can be used in your design, but as I did not want to include the sdk in my example project, the same can be done with a single UIButton. Setting the button‘s text and image lead to the desired design. Using this approach over e.g. another UIStackView with an image and a label, has the main benefit, that UIButton already has built in highlighting when the user interacts with it. To achieve the required margin between the button‘s image and text, just play around with the Image insets in the view‘s size inspector.
UIStackView enables us to use a bare minimum of constraints. We still need to make use of them sometimes, especially when we need views to have a specific width or height, e.g. the separator views in this example. You should also constrain the text field’s height to 45, since the default UITextField is a lot smaller. To match the text fields‘ height, the login button is being constrained to their height, which gives the UI a more consistent look.
With the main UI done, add another UIStackView for the bottom elements constraining it to the bottom of the screen as well as the leading and trailing edges using the same standard margin of 16. I decided to not include the separator above the elements inside the stack view as it should not have the margin and instead reach all the way to the screen‘s edges.

Having done all that, our design already looks pretty good. But for some tweaks we now have to head over to the editor and write some code!

Tweaking elements in code

I wanted to challenge myself to make my design look as close to the original Instagram app as possible. There are four things that need to be done to improve the current prototype. First, the two text fields‘ placeholder‘s and text input need to have more padding than the default UITextField‘s insets. Therefore, we need to adjust the text fields‘ insets in code. Unfortunately adjusting a UITextField‘s insets is not as easy as one would imagine, the easiest way this can be done is through subclassing UITextField.

class TextField: UITextField {

        let padding = UIEdgeInsets(top: 8, left: 12, bottom: 8, right: 12)
    
    override func textRect(forBounds bounds: CGRect) -> CGRect {
        bounds.inset(by: padding)
    }

    override func placeholderRect(forBounds bounds: CGRect) -> CGRect {
        bounds.inset(by: padding)
    }

    override func editingRect(forBounds bounds: CGRect) -> CGRect {
        bounds.inset(by: padding)
    }

}

Changing the two text fields‘ class names in the Identity Inspector of Interface Builder now leads to the increased padding at runtime.
The second thing that needs to be done in code, is changing the text fields‘ placeholder text color which is not the default one in the Instagram app. This can be done by setting an attributedPlaceholder, which can be extracted into a private extension.

private extension UITextField {

    func setPlaceholder(_ placeholder: String) {
        attributedPlaceholder = NSAttributedString(string: placeholder,
                attributes: [NSAttributedString.Key.foregroundColor: UIColor.systemGray])
    }

}

After that, just call this method on the two text fields with their placeholder texts.

usernameTextField.setPlaceholder("Phone number, username or email address")
passwordTextField.setPlaceholder("Password")

In a real project you would of course move those strings into a Localizable.strings file. But sure you were already aware of that, weren‘t you? ;)

The third thing that is still missing, are the rounded corners of the login button. There actually is a way to do this with user defined runtime attributes in the Size Inspector of Interface Builder. But I prefer doing this in code since that is much easier to maintain and discover. In order for the button to be adjusted in code, it first needs to be connected as an IBOutlet. If you‘re following along this article in Xcode, you can already connect all the other views as well, you are going to need those later in the accessibility section.
Once the button has been connected, its corners can be rounded by adjusting the corner radius.

loginButton.layer.cornerRadius = 5

You might guess the last thing that needs to be done to match the original design as closely as possible when you look at the margins between the individual views. The current spacing that is being set for the central stack view does not represent the margins in the original design. This means, we need to make use of UIStackView‘s setCustomSpacing method, that enables us to adjust the standard spacing after a specific view. Having configured the default spacing to 16, requires an alternate spacing after four subviews. Calling this method in viewDidLoad now leads to a pretty close result at runtime resembling the actual Instagram app.

private func setupCustomSpacing(keyboardVisible: Bool) {
    mainStackView.setCustomSpacing(keyboardVisible ? 8 : 12, after: passwordTextField)
    mainStackView.setCustomSpacing(keyboardVisible ? 16 : 24, after: forgotPasswordButton)
    mainStackView.setCustomSpacing(keyboardVisible ? 16 : 24, after: loginButton)
    mainStackView.setCustomSpacing(keyboardVisible ? 16 : 40, after: separatorStackView)
}

With the app looking nice at runtime, you might be tempted to call it a day and consider the design being fully implemented. However, there is still a lot of things that can be improved that are not obvious at first. So let‘s start finetuning by supporting dark mode!

Supporting dark mode

Implementing dark mode support is pretty easy in this example. There are actually only two things that need to be adjusted. First, the Instagram logo has to get a white counterpart that is going to be displayed in dark mode. Selecting the Instagram logo in Assets.xcassets, just change the Appearances dropdown from None to Any, Dark, which enables us to add a different image for its dark appearance.

To already finish supporting dark mode, just add a color asset in Asssets.xcassets for the background color of the two text fields. Adding two different colors for light and dark mode works the same as the way it works with icons. Changing the Appearances to Any, Dark enables us to set a light background (#F9F9F9) for light mode and a dark background (#111211) for dark mode. That‘s it! Since the screen‘s background was already automatically set to System Background in Interface Builder, the app looks great in dark mode. Debugging dark mode is especially easy since it can simply be toggled in the Environment Overrides menu in Xcode alongside other options for Text and Accessibility.

React to the keyboard being shown

When analyzing the design earlier, I mentioned potentially adjusting the UI when the keyboard is being shown. Since the main elements are centered on screen, this is unavoidable here to prevent key elements from being hidden by the keyboard.
In this case, the most logical way to address this problem, would be through constraining the main stack view to the top of the screen instead of centering it once the keyboard is being shown. So let‘s head back to the editor and start listening to the system‘s notification for the keyboard being shown or hidden.

NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillShow),
        name: UIResponder.keyboardWillShowNotification, object: nil)
NotificationCenter.default.addObserver(self, selector: #selector(keyboardWillHide),
        name: UIResponder.keyboardWillHideNotification, object: nil)

Additionally, the main stack view‘s centerY constraint needs to be connected as an IBOutlet, which enables us to activate or deactivate when needed. Moreover, add another private variable mainStackViewTopConstraint which is being initialized in viewDidLoad but not yet activated.

mainStackViewTopConstraint = mainStackView.topAnchor.constraint(
            equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16
        )

With this preparation being done, we can finally implement keyboardWillShow and keyboardWillHide which we defined as the selectors being called once the system’s notifications are fired.

@objc private func keyboardWillShow() {
    mainStackViewCenterYConstraint.isActive = false
    mainStackViewTopConstraint.isActive = true
    UIView.animate(withDuration: 0.3) { [weak self] in
        self?.view.layoutIfNeeded()
    }
}

@objc private func keyboardWillHide() {
    mainStackViewCenterYConstraint.isActive = true
    mainStackViewTopConstraint.isActive = false
    UIView.animate(withDuration: 0.3) { [weak self] in
        self?.view.layoutIfNeeded()
    }
}

We just need to toggle the constraint‘s isActive property and call layoutIfNeeded() in an animation block to make the stack view being animated to the top nicely. To further improve the two methods, consider adjusting the setupCustomSpacing method with a keyboardVisible parameter to decrease the stack view’s custom spacing we configured before for the time the keyboard is being shown.

private func setupCustomSpacing(keyboardVisible: Bool) {
        mainStackView.setCustomSpacing(keyboardVisible ? 8 : 12, after: passwordTextField)
        mainStackView.setCustomSpacing(keyboardVisible ? 16 : 24, after: forgotPasswordButton)
        mainStackView.setCustomSpacing(keyboardVisible ? 16 : 24, after: loginButton)
        mainStackView.setCustomSpacing(keyboardVisible ? 16 : 40, after: separatorStackView)
    }

To further improve the user experience, add another method which hides the keyboard when the user taps somewhere else on the screen.

private func setupDismissKeyboardGesture() {
    let tapGestureRecognizer = UITapGestureRecognizer(target: self,
            action: #selector(dismissKeyboard))
    view.addGestureRecognizer(tapGestureRecognizer)
}

@objc private func dismissKeyboard() {
    view.endEditing(true)
}

You could also consider hiding the Instagram logo once the keyboard is visible to make sure the UI looks good on smaller devices. The actual Instagram app does not hide the logo when moving the elements to the top, but I think it could make sense, so I included it in my example project.

Improving accessibility using Dynamic Type

The last thing I want to showcase in this article, is a thing you should always keep in mind when designing and implementing user interfaces: Accessibility. Of course this topic is way too big to cover in one article. But at least I want to show you how you can support Dynamic Type in this prototype. Supporting Dynamic Type means that your app‘s labels, buttons, etc. react to the system text size being customized. Many older users tend to adjust the system font to a larger size since their visibility is often impaired. But there are also some folks that use a smaller size than the default font to fit more content on screen.
With Dynamic Type you can respect the user‘s preference also in your app. The easiest way to support it is being done in using the standard Text Styles Apple has defined, e.g. Body, Caption 1, Headline or Large Title. They adjust their size automatically and you do not have to do anything else.
However, often those predefined text styles are not enough to implement a specific design. Consequently, we often just set a custom text size, which we can also do in Interface Builder. Those custom text sizes set in Interface Builder do not react to the system settings the user configured, though.
Therefore, this needs to be done in code. I like to use a simple extension on UIFont when setting the font of a specific view.

extension UIFont {

    static func scaledSystemFont(size: CGFloat, weight: UIFont.Weight = .regular) -> UIFont {
        .systemFont(ofSize: UIFontMetrics.default.scaledValue(for: size), weight: weight)
    }

}

Having added the extension, we can set the scaled font for all text displaying views, e.g. the login button.

loginButton.titleLabel?.font = .scaledSystemFont(size: 15, weight: .medium)

To prevent the text of some labels or buttons from being truncated, when the user has a really large text size configured, the adjustsFontSizeToFitWidth property can be set to true. This setting shrinks the font size in case it cannot fit the entire text in the available space.

facebookButton.titleLabel?.adjustsFontSizeToFitWidth = true

After setting the font size for all labels, buttons and text fields in code, the UI now respects the system settings by the user.

Points of improvement and conclusion

There are many more things than just the actual design when implementing a user interface, which I wanted to show you with this prototype. Accessibility, dark mode and reacting to the keyboard being displayed, are just a few examples to consider.

If you would like to further improve the prototype, feel free to do so, here are just a few areas you could work on: The prototype currently does not have the eye icon on the password text field to toggle the password visibility. You could also react to the done button being tapped when a text field is being focused, and jump to the next one or trigger the actual login process. While this process is running, the original Instagram app shows a UIActivityIndicatorView on the login button, to make the process visible to the user. Finally, you could dig into Combine and disable the login button until a username and password have been entered by the user.
How do you approach implementing a UI design in iOS? I am curious to find out whether you have different techniques or workflows. You can reach out in the comments or contact me on Twitter.

Thanks for reading!

Prototyping Instagram‘s login screen using UIStackView was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

"main_hero_name" = "Hercules";
<string name="main_hero_name">Hercules</string>

If you have ever seen this, you are probably an app developer, you have at least developed for Android and iOS and at some point you dealt with assets like localizables.

Keeping your iOS and Android localizables in sync can be hard, especially when you work in a team and your project grows. Your localizables end up being different on both platforms and it just keeps getting harder to maintain. It would be simple if you could just copy and paste those strings from one platform to the other and you could be sure that every key and value is the same. One way to do this is to use tools other people have already written for us. One of these tools is Boop.

You can use Boop for your daily routine of developing, e.g. format and validate your JSON file, decode and encode data, count words, sort lines and so much more. With Boop you can use one offline tool instead of 5 online tools you have to keep switching between to get your results. The best part is, you can add custom scripts easily.

For the Localizable handling between iOS and Android you could use two simple scripts to convert Android to iOS Localizables and conversely.

Android to iOS

/**
  {
    "api":1,
    "name":"Android Strings to iOS Localizables",
    "description":"Converts Android Strings to iOS Localizables",
    "author":"Manuel Kunz",
    "icon":"quote",
    "tags":"string, android, ios"
  }
**/

function main(input) {
    let lines = input.fullText.split('\n')
    var result = []
    lines.forEach(element => {
      var temp = element
      temp = temp.replace("<string name=", "")
      temp = temp.replace("</string>", "\";")
      temp = temp.replace(">", " = \"")
      result.push(temp)      
    })
  
    input.fullText = result.join('\n')
}

iOS to Android

/**
  {
    "api":1,
    "name":"iOS Localizables to Android Strings",
    "description":"Converts iOS Localizables to Android Strings",
    "author":"Manuel Kunz",
    "icon":"quote",
    "tags":"string, android, ios"
  }
**/

function main(input) {
    let lines = input.fullText.split('\n')
    var result = []
    lines.forEach(element => {
      if(element !== "") {
        var regex = /"(.*?)"/g
        var matches = [];
        var match = regex.exec(element);
        while (match != null) {
            matches.push(match[1]);
            match = regex.exec(element);
        }
        result.push("<string name=\"" + matches[0] + "\">" + matches[1] + "</string>")
      }      
    })   
    input.fullText = result.join('\n')
}

Tools like this just help you get your work done in one place and make your developer life easier. If you have any ideas of scripts you could imagine to write and include to Boop, feel free to share your ideas. We would like to hear from you.

Simplify your developer life with Boop was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

In order for a view to be displayed modally in SwiftUI, the sheet modifier can be used. In its simplest form a sheet is being presented if a given condition is true.

struct ContentView: View {

@State var presentSheet = false

var body: some View {
        VStack {
            Button("Show Settings") {
                self.presentSheet = true
            }
        }.sheet(isPresented: $presentSheet) {
            SettingsView()
        }
    }
}

In this example, the sheet modifier is applied to the VStack. However, it could also be applied to the Button directly.

What if we wanted to display more than one sheet from a specific view, though?

The most logical choice would be to just place another sheet modifier below the existing one, since it is possible to chain modifiers as we please. Unfortunately this does not work. In order for us to be able to use multiple sheets, each modifier has to be applied to the button directly. Using two or more consecutive sheet modifiers does not work in SwiftUI, only the last sheet modifier will be applied and can be used. As a result, we could design our view like this.

@State var showSettingsView = false
@State var showProfileView = false

var body: some View {
    VStack {
        Button("Show Settings") {
            self.showSettingsView = true
        }.sheet(isPresented: $showSettingsView) {
            SettingsView()
        }
        Button("Show Profile") {
            self.showProfileView = true
        }.sheet(isPresented: $showProfileView) {
            ProfileView()
        }
    }
}

But as you can imagine in a working app, this view won’t be as compact. If you need to handle multiple different sheets, the code gets blown up very quickly. Additionally, each sheet needs its own @State to be presented.

To avoid massive Views, it would be great if there was a way to separate this navigation logic from our view into a dedicated file. There are different alternatives that simplify the handling of multiple sheet modifiers. This article shows one of them.

Moving the presentation logic into an observable ViewModel

First of all we are going to separate the logic of which sheet will be shown to a separate view model.

class SheetNavigator: ObservableObject {
    @Published var showSettingsView = false
    @Published var showProfileView = false
}

This SheetNavigator class has to conform to the ObservableObject protocol and will be observed by the view itself using the @ObservedObject property wrapper.

@ObservedObject var sheetNavigator = SheetNavigator()
var body: some View {
    VStack {
        Button("Show Settings") {
            self.sheetNavigator.showSettingsView = true
        }.sheet(isPresented: self.$sheetNavigator.showSettingsView) {
      SettingsView()
        }
        Button("Show Profile") {
            self.sheetNavigator.showProfileView = true
        }.sheet(isPresented: self.$sheetNavigator.showProfileView) {
            ProfileView()
        }
    }
}

After we moved our presentation state variables into the view model, the code did not really improve. The state handling is not scalable and we still have multiple sheet modifiers cluttering our view. Let‘s reduce those at first to just one sheet modifier.

VStack {
    Button("Show Settings") {
        self.sheetNavigator.showSettingsView = true
    }
    Button("Show Profile") {
        self.sheetNavigator.showProfileView = true
    }
}.sheet(isPresented: ???) {
    ???
}

At this point we only have one sheet modifier, but which view should be shown and to which state variable should we bind the sheet? The answer is our SheetNavigator.

class SheetNavigator: ObservableObject {
    var showSettingsView = false
    var showProfileView = false
    @Published var showSheet = false
    
    func sheetView() -> AnyView {
        if showFirstView {
            return Text("SettingsView").eraseToAnyView()
        } else if showSecondView {
            return Text("ProfileView").eraseToAnyView()
        }
        return Text("Empty").eraseToAnyView()        
    }
}

extension View {
    func eraseToAnyView() -> AnyView {
        AnyView(self)
    }
}

We add an additional bool state to handle the binding for all sheets. The function sheetView returns the View we want to show for the selected button. All this logic happens in the navigator and our view is way simpler than before.

Since we are dealing with different views that are displayed in our sheets, we have to type erase said views to AnyView. For the sake of readability, we added a little View extension to simplify wrapping a view inside of AnyView.

As there might be performance implications when using AnyView, you could also consider wrapping your views inside a Group.

VStack {
    Button("Show Settings") {
        self.sheetNavigator.showSettingsView = true
        self.sheetNavigator.showSheet = true
    }
    Button("Show Profile") {
        self.sheetNavigator.showProfileView = true
        self.sheetNavigator.showSheet = true
    }    
}.sheet(isPresented: self.$sheetNavigator.showSheet) {
    self.sheetNavigator.sheetView()
}

But it’s not perfect, since we need to set two different booleans in the action of a button, one for the sheet that should be shown and one for the state that is bound to the sheet modifier. Additionally, the amount of state variables required, will grow for each new sheet we want to show. Let‘s use a different approach, that is more scalable and also improves readability: Enums.

Enums to the rescue!

Now there is only one published parameter left, the showSheet state that is bound to the sheet modifier. For the different sheet views we want to present, we added a SheetDestination enum.

class SheetNavigator: ObservableObject {

@Published var showSheet = false
    var sheetDestination: SheetDestination = .none
    
    enum SheetDestination {
        case none
        case settings
        case profile
    }
    
  func sheetView() -> AnyView {
      switch sheetDestination {
      case .none:
          return Text("None").eraseToAnyView()
      case .settings:
          return SettingsView().eraseToAnyView()
      case .profile:
          return ProfileView().eraseToAnyView()
      }
  }
}

With these changes the View will now look like this.

@ObservedObject var sheetNavigator = SheetNavigator()
var body: some View {
    VStack {
        Button("Show Settings") {
            self.sheetNavigator.sheetDestination = .settings
            self.sheetNavigator.showSheet = true
        }
        Button("Show Profile") {
            self.sheetNavigator.sheetDestination = .profile
            self.sheetNavigator.showSheet = true
        }
    }.sheet(isPresented: self.$sheetNavigator.showSheet) {
        self.sheetNavigator.sheetView()
    }
}

At this point, we are still calling showSheet ourselves. Actually, setting the sheetDestination should really be enough. So we remove setting showSheet to true from the view and handle this with a property observer.

var sheetDestination: SheetDestination = .none {
    didSet {
        showSheet = true
    }
}

Every time the sheetDestination is being set, we set showModal to true.

VStack {
    Button("Show Settings") {
        self.sheetNavigator.sheetDestination = .settings
    }
    Button("Show Profile") {
        self.sheetNavigator.sheetDestination = .profile
    }
}.sheet(isPresented: self.$sheetNavigator.showSheet) {
    self.sheetNavigator.sheetView()
}

What‘s next?

In using our navigator, we managed to condense our view and moved most of our navigation logic out of it. But there is still room for improvement. We can take advantage of the fact that Swift enums support associated values and pass additional data to the presented sheet views.

For instance, we can make the profile enum case accept a String as parameter, if we want to pass the name of the user to the profile view.

enum SheetDestination {
    case none
    case settings
    case profile(name: String)
}

When setting the sheetDestination to the profile case, our call site would look like this.

Button("Show Profile") {
   self.sheetNavigator.sheetDestination = .profile(name: "Christoph")
}

The profile case of the switch statement within the sheetView function, has to be adjusted as well. Here, we can use the given parameter and pass it to the ProfileView.

case .profile(name: let userName):
         return ProfileView(name: userName).eraseToAnyView()

Keep in mind to avoid too many destinations in one Navigator class. In fact, each view you are using should have its own Navigator.

To establish a consistent style, you could use a Navigator Protocol each Navigator can confirm to.

protocol NavigatorProtocol: ObservableObject {
    associatedtype SheetDestination
    func sheetView() -> AnyView
}

I hope you enjoyed this little concept of handling multiple sheets. How do you handle navigating to different views in SwiftUI? Do you have similar approaches? Let us know! We‘d love to hear your ideas and hope this article helped to StepUp your developer game.

Handling multiple sheets in SwiftUI was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bitrise is a really nice Continuous Integration service with a great user interface. Setting up a CI build for an iOS app is a matter of minutes. However, if you want to use Bitrise to build an iOS framework, it gets a bit trickier. Ideally, we’d want Bitrise to build our framework and — in the case of success — attach the built framework as an artifact.

Setting up a custom script

Since there is no pre configured workflow step for building a framework, we need to do this in form of a custom script. What helped us in the first place, was a thread on the Bitrise forums.

The script has to be placed into the Script content window of the workflow editor and consists of two parts. In the first step, we want to create our framework twice, once for the simulator architecture x86 and once for the arm architecture which is required for the framework to run on a real device.

xcodebuild -project FrameworkName.xcodeproj -scheme SchemeName -configuration Release -derivedDataPath $BITRISE_DEPLOY_DIR/iphoneos -sdk iphoneos clean build xcodebuild -project FrameworkName/FrameworkName.xcodeproj -scheme SchemeName -configuration Release -derivedDataPath $BITRISE_DEPLOY_DIR/iphonesimulator -sdk iphonesimulator clean build

Notice that the script runs from the root directory of your git repository. Hence, if your Xcode project is not located in the root directory, you need to consider this for the project command.

Piece the frameworks together

Now that we have written our script for creating the framework for each architecture, we can piece them together, so we have one final framework. In the past, we would have used the lipo terminal command to bundle the two frameworks together into one so called fat lib. However, with the introduction of Xcode 11, there is a new way to package frameworks, called XCFramework, which has several advantages. For instance, we no longer need to slice the simulator architecture from our fat lib when uploading our apps to the AppStore. You can find more info on XCFrameworks in general in this article.

Creating the XCFramework

As you would expect, with the introduction of XCFrameworks, Apple also enhanced the xcodebuild command line tool. We can use the -create-xcframework command to finalize our custom script. To improve the structure of the deploy directory, we first create a new directory, which will contain the final .xcframework file.

mkdir $BITRISE_DEPLOY_DIR/xcframework xcodebuild -create-xcframework -framework $BITRISE_DEPLOY_DIR/iphoneos/Build/Products/Release-iphoneos/FrameworkName.framework -framework $BITRISE_DEPLOY_DIR/iphonesimulator/Build/Products/Release-iphonesimulator/FrameworkName.framework -output $BITRISE_DEPLOY_DIR/xcframework/FrameworkName.xcframework

Final steps

Now that we finished our custom script, there are just a couple of smaller things we need to do. In the workflow editor, we need to have a Deploy to bitrise workflow step after our custom script step. It is important to set the Compress the artifacts into one file option to true, which makes sure, that the configured Deploy directory or file path (also in the Deploy to bitrise step) and all its subdirectories are deployed.

By default, it does not deploy files recursively. Lastly, in order for an XCFramework to be built, we have to specify the Build libraries for Distribution build setting within our Xcode project to Yes. That’s it! Each of our Bitrise build now has a .zip file attached, containing our created XCFramework.

Have you used custom scripts in Bitrise? If yes, we’re curious to find out which purpose you used it for. Thanks for reading this article!

Building iOS frameworks with bitrise was originally published in StepUp Development on Medium, where people are continuing the conversation by highlighting and responding to this story.