When you test your app, you may miss one of the important parts of the localisation: Right to Left(RTL) languages! There are a couple of languages that the direction of the text is from right to left such as Persian, Arabic, Hebrew, and more. Here we’re going to review some of the important points that by considering them you can easily have the RTL language support in your app and make your app usage even wider.

First of all, we need to know how to test the app in right to left(RTL) conditions. Before going to that matter, let’s create a sample iOS app to use as a sandbox.

The whole sample project is also available at the following Github repository:
https://github.com/novinfard/iOSRTLSample

Create a sample Sandbox for testing

Follow these steps:

File > New > Project > iOS tab > App > Interface: StoryBoard

After creating a new project, go to main.storyboard add a label and with 16 point margin from the top, left, and right in constraints:

In the label attributes, change the number of lines to 0, have natural as text alignment, and add the following text as a sample:

این یک متن تست است. در این متن به بررسی عملکرد زبان های راست به چپ می‌پردازیم.

Add an imageView below the text with 16 points margin from left and top, and 100 points for width and height constraints:

In the image attributes, use one of the system icons like pencil.circle.fill .

In addition, add a new SwiftUI view to the project with ContentView name with the following code:

The preview of this view would be as the below picture:

Now we’re ready to test the app in RTL.

Display and also Test the app in RTL

There are a couple of different ways to see your app (or part of your app) in right to left semantic.

Launch Argument

One of the solutions is to set it as a launch argument. For doing so, choose the current scheme from the top bar of Xcode and press “Edit Scheme ...” :

After opening the scheme window, go to the options tab, and in the “App Language” section, choose Right-to-Left Pseudolanguage instead of System Language :

If you run the application now, you would see the layout has been changed to a right-to-left layout:

Open the preview of the SwiftUI view and you will see a similar result:

We will come back to this layout automatic changing in the next section, but let’s now see what are the other options for testing in RTL.

Force all or some of the views in the application to RTL mode

For the testing purposes or in some scenarios based on the design requirement, you can force all the views in the application to use the right-to-left direction. To do so in UIKit you need to add this somewhere in AppDelegate:

If we want to force some specific views to change to the right-to-left direction in UIKit, just change semanticContentAttribute of that view in the app.

For having a similar approach and force all SwiftUI views to use right-to-left direction we can use the environment key named layoutDirection at topmost view of the application, somewhere in SceneDelegate for instance:

If we want to force some specific views to change to the right-to-left direction in SwiftUI, we can change layoutDirection environment key on that view (including all sub-views of that view)

After exploring the different ways to update the app and view’s logic in the right-to-left direction, now let’s analyse the changes applied in iOS by this update.

SwiftUI Previews for RTL direction

We can easily display the SwiftUI previews in right-to-left and left-to-right by the following code using layoutDirection environment value:

We used the previewLayout to just have more space for previewing, so you can remove it if you want to see it fully. The result would be as follows with a neat preview in both language directions:

Automatic changes by iOS for Right-to-Left languages

The first important thing to note is that when we set the labels to have natural alignment, the OS itself changes the alignment based on the language. In our example, we can see this clearly:

The second thing to notice is the update on auto-layout constraints. It changed the leading constraint to trailing one automatically (and of course visually):

Rotate images based on language direction

The next thing you may want in right to left languages is to rotate the images themselves in these languages. To achieve this, we can use imageFlippedForRightToLeftLayoutDirection attribute of UIImage in UIKit.

To see it in action, in our example app, connect the imageView to ViewController class add the following code:

Now if we compare the result, we can see the image flipped horizontally:

For having the same result in the SwiftUI view, we can use rotationEffect modifier with 90-degree value:

The result is similar to UIKit one:

A point to consider here is that the general signs or trademarks should not be flipped based on language direction.

Detect the language direction in the app

In the previous example, we changed the rotation of the image, but we need to do this operation only when the direction is right-to-left. In this case and similar scenarios, we need to detect the language direction.

Since iOS 10, the view has the property effectiveUserInterfaceLayoutDirection that indicates the language direction. So by using it, we can update our UIKit example as follows:

In SwiftUI, we can define the layoutDirection environment value and read it for checking the language direction:

Now we can see the language direction-based image rotation in the SwiftUI previews:

Avoid the anti-pattern in the design to support Right-to-Left

One of the simple, but important point to keep an eye on that in the design to make the application compatible with RTL languages is to avoid using element alignment as much as possible and keep the element natural alignment and behaviour.

For instance, let’s say we want to add the date in our blog view, in the right bottom corner of it. One way to do so is to having the equal leading and trailing constraint for the label and set the label alignment to right. So we’ll have the view setup as follows:

With the above layout setup, If we run the application in an RTL environment, the result would be the below picture:

As you might realise, it’s not a desirable layout. Because we want the date to be shown in the left bottom corner when the user uses a Right-to-Left language.

To fix this, we can have only a trailing constraint for the label, and keep the label alignment natural :

Now if we run the application again, we would see that the date label in the correct position for RTL direction:

With this small adjustment, now the layout is correct to Right-to-Left languages as well.

The same technique applies to SwiftUI. For instance, In the same scenario as above, we should try to use “Horizontal Stack” with “Label” and “Spacer” instead of set strict alignment for the label:

If we preview the above view in both direction environments, we will see the correct layouts:

Beyond the layout

There are some consideration in right-to-left languages which are not related to layouts.

One of these considerations is about the numbers. The numbers in Persian and Arabic are different from English counterparts. Thus, the users can write with these localise versions of numbers both in normal keyboard mode and number pad:

So what if the user enters the number in localised keyboard for the verification code or as a mobile number? In order to avoid further issues in the system and the client or server-side logic, we should detect these cases in our app and update the numbers with the English equivalent. To achieve this, we can use number formatter in Swift. By the use of the following small helper we can convert numbers in any languages to English for integer types:

To see how it works, we can update our SwiftUI app as below:

We can see the converted number in the preview:

Conclusion

In this article, we covered how can support the right-to-left languages in our apps using UIKit or SwiftUI. we first made a sandbox to be able to test the right-to-left languages there. Then we talked about different ways we can display and test our app or some parts of it in RTL languages. In the following section, we analysed how iOS works in RTL and we made sure that we understand its automatic right-to-left behaviour. Then we reviewed how can detect the language direction in our code and use that to rotate the image for different language directions. Finally, we covered some cases where we need to consider the right-to-left languages beyond the layouts.

Further Reading

Apple’s Human Interface Guideline for Right-to-Left languages
https://developer.apple.com/design/human-interface-guidelines/right-to-left/overview/introduction/

Supporting Right-to-Left Languages by Apple
https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/SupportingRight-To-LeftLanguages/SupportingRight-To-LeftLanguages.html

Having a reliable and durable iOS app or framework depends on many things, but no one can deny the necessity of unit testing and UI testing for this purpose. The question comes up here is that are all codes tastable? No, unfortunately!

In this article, we review an example of improper code for testing and try to suggest some ways to solve the issue by applying various software techniques.

We start with an example of inappropriate code for testing purposes. After reviewing the scenario, we are going to look at how we can make it testable. The code is abstracted to focus on the main subject. You need to be familiar with CoreData beforehand to get the most of the example. But even if not, the description is sufficient to picture the problem.

We have a class named StandingsDatasource which is responsible for requesting the data from the network and load the parsed data in dataController (dataController is a sort of fetchResultController which can give you an array of data objects). We persist in CoreData in this scenario.

Here, getEntityName defines which data object type (CoreData entity name) will be returned and getPredicate determines which objects of that type should be filtered and returned in the dataController.

The Standing data object is defined as follows:

And the request class is defined as follows:

We want to write some unit tests by which we parsed the data correctly. As the output of the datasource, we can fetch the desired objects in our dataController.

To start writing our tests here, we need to subclass StandingsDatasource to have our local datasource. Our local datasource is going to read its data from a JSON file rather than network response. The reason behind this is that we may have a different response (result in different parsed standing objects) as the endpoint updates time by time.

By looking at StandingsDatasource , we found the first issue: We don’t have access to request object to be able to change it to local request, because StandingsRequest is initiated inside the requestData method.

We can use the dependency injection technique to overcome the issue. Dependency injection means one object supplies the dependencies of another object. The “injection” refers to the passing of a dependency (a service) into the object (a client) that would use it [1].

There are three common types of dependency injection:

Method Injection

We can pass the request to our method by one of its parameters.

We call this method injection, as we injected our dependency in the method declaration.

This is not the desired behavior here, because the requestData is called internally in the base class ManagedDataSource . So the only way to inject our request is the same, by overriding the method in our local datasource class.

Property Injection

We can pass the request as one of the class properties.

Here, we inject the request into the StandingsDatasource class. So after initializing the object, we can pass the request. The benefit of this way is we don’t have to change anything related to requestData when we subclass our local datasource. All the logic is encapsulated inside the method. However, it’s still not good enough. Because we have to define it as optional property, while we can’t imagine a correct datasource without a request dependency.

Constructor Injection

We can pass the request to the initializer of class:

The request is assigned inside the class initializer, thus, every instance of StandingsDatasource and its subclasses would have the initiated request property.

We chose constructor for the dependency injection, but based on the case it can be different.

Now let’s look at the second issue. We have a single data type for our datasource request, StandingsRequest , but we have two types of requests: One of them gets the data from the endpoint and the other one fetches the data from our persistent module, CoreData.

These are two different concerns and can be encapsulated. We call this design principle in software architecture as “Separation of Concerns”. It asks us to separate the computer program into distinct sections such that each section addresses a separate concern. Each concern can be a set of information that affects the software [2].

Endpoint Request

For defining our endpoint request, let’s review the StandingsRequest implementation.

As we can see, the only element needed for defining the URL is tournamentId. So any data structure has tournamentId and conforms to RequestProtocol is enough and no other constraint is needed, in other words, we have a protocol here. Now we can re-define our Endpoint request as follows:

We added default implementation for parser(parseDelegate:parentContext:) method because it is common among all implementation of the protocol, although it’s not necessary to be the same.

We declare an implementation of StandingsEndpointRequest which works with network requests.

Entity Request

The second concern is about requesting the entity from our persistent module. We saw the footprint of this request inside the datasource class in two places:

For requesting an entity in our persistent module (Core Data) we need to know of the entity’s name and related predicate of type NSPredicate. Thus, we can define our EntityRequest protocol for any entity request in the persistent module as below:

For making a standing entity’s request, we need a predicate on Standing entity by using the groupName and tournamentId. Let’s define it as follows:

Now it’s time to come back to our datasource and refactor it with new StandingsEndpointRequest and StandingsEntityRequest :

Unit Testing

We have refactored our code to testable version. In this section, we are going to write some unit tests to see how our changes eased the testing purpose.

We got a sample of the JSON response and saved that in a file named tournamentStandingsSample.json :

It returns 4 Standing entities. Three of them are in the tournament with id 10 and the last is in the tournament with id 21 . Two of the three standings of the tournament 10’s are in Group A, and the other one is in Group B.

We write three unit test for checking the parsing, duplicate parsing, and group filtering:

First, we have defined StandingsEndpointLocalRequest which looks for local JSON files for endpoint requests.

We created a factory method named testDatasourceFetchStandings that has a default value for reading from our stored JSON file and tournament with id number10 without filtering groups as passed nil for it. The MemoryCoreDataController is a class that helps us create in-memory core data storage as part of our persistent module. It is a good idea to have this setting to avoid collision between the main app and the testing app’s object storage in unit tests.

Conclusion

New StandingsEndpointLocalRequest class can easily create a request with a local file that lets us focus on data source functionality with sample constant JSON file. If you check our initial request class, we couldn’t test it this way unless we subclass StandingsRequest.

Additionally, we didn’t subclass our datasource. Instead, we passed our local request injected in the initializer. So our implementation encapsulated and remained intact there.

References

• [1] Dependency injection https://en.wikipedia.org/wiki/Dependency_injection
• [2] Separation of concerns
  https://en.wikipedia.org/wiki/Separation_of_concerns

Here I’m going to give you some tips about how to use SwiftLint in existing or new projects with four steps helping you to setup SwiftLint in your projects.

What is SwiftLint?

SwiftLint is a tool that can be used for enforcing Swift style and conventions in projects written in Swift. You can install it in many different ways such as installing in your machine or add it to your CocoaPods repo. Check the following link to see how do you want to install it:
https://github.com/realm/SwiftLint#installation

Adding to your project

After installing the SwiftLint, you can add it to your project by adding a shell script to the build phases. So go to Project > Build Phases > Press + > New Run Script, and add the below code:

Try to have this phase in the very first phases of building the project. If SwiftLint has not been installed correctly you get a warning message, otherwise, it uses the configuration file you mentioned (.swiftlint.yml) and runs the tool. It is now located at the root of your project, in the same folder of your project configuration file (.xcodeproj), although it can be anywhere that you like. But what is this configuration file?

Configuration file, the heart of SwiftLint tuning

In the configuration, file you can add, disable or update the linting rules. You can see a sample of this file’s structure at below:

Don’t worry about it for now! I’m going to explain each bit in more detail in the next sections. Just have this as a reference.

The indentation in this file is important, so have the same indentation as you see in the above sample file.

Some rules are enabled by default. you can disable them in disabled_rules section of your configuration file. There are some other rules which are not activated by default, but you can activate them by adding to opt_in_rules section. To find out about all available rules briefly, type lint rules in the command line (Terminal).

You can also find out about the rules in more detail at the following link:
https://github.com/realm/SwiftLint/blob/master/Rules.md

By following these 4 steps you can gracefully setup SwiftLint in your existing or new projects:

1 — Exclude the code you don’t want to lint

Some codes in your project can be added by third-party libraries that should be skipped in the linting process. In addition, you may borrow some code from an old code base that you don’t want to lint it. In these cases, you can remove a path or a specific file from the linting process in SwiftLint configuration:

One of the good examples is Pods directory which can contain the libraries or frameworks written by third-party developers.

2 — Correct some linting issues automatically!

There is a built-in feature in SwiftLint by which can correct some type of violations automatically. So it is better to first run the related command to solve any issues can be fixed by SwiftLint itself:

swiftlint autocorrect

Just remember to have nothing in your disabled_rules section of configuration file before running this command, rather than those rules will be escaped from correcting.

If you want to see which ruled can be corrected by this feature, run swiftlint rules and see the “correctable” column.

3 — Find rules which are not followed currently

In the next step, we’re going to find out which rules are not followed in your project. To see violated rules run the swiftlint lint by command line in your project directory.

In the output, you can see the rules not followed as warnings such as:

/MyProject/Scenes/MyScene/MyViewController.swift:103:64: warning: Redundant Void Return Violation: Returning Void in a function declaration is redundant. (redundant_void_return)

At the end of each warning, rule identifier is written inside the parentheses (`redundant_void_return` in the example), copy them somewhere until you find all of them.

If your project has a lot of warnings, just run the following command to collect all rules:

At the end of the command, you will find all violated rules with number of occurrences. If you want to see only the list of rules run this command instead:

Add these rules to disabled_rules section for now. If you run the SwiftLint you will find no warnings as you disabled all problematic lint rules in your project.

If you work in a team or want to have neat git history, now it’s time to make your very first commit and create a pull request for SwiftLint works.

4 — Decide about disabled rules

At this stage, you have a list of rules which are violated based on SwiftLint default rules and couldn’t be corrected automatically. When you remove them from your disabled list, you can see the warnings in Xcode.

You have four options here:

a) Correct the lint issue for the rule

If you think the rule is useful for you, you can check the lint issues; resolve them in the entire project and then remove it from the disabled list.

b) Disable the rule generally in the project

If the rule is not suited your project, you can keep it on the disabled list.

c) Disable the rule in specific file or usage

There are times that the rule is useful, but the code base is old and you should change a lot of files which doesn’t worth the time you should spend on. In addition, it’s possible that SwiftLint shows the error where actually no lint error happened (false positive). Moreover, there are times when you prefer to keep that special case breaking the lint rule. In this situation, you can disable the rule in the entire file or just for that special case.

In order to disable it you can use the following comment:
// swiftlint:disable rule_identifier
After this comment to the end of the file, all checking for that rule becomes disabled.

if you want to disable the rule only in the next line of code use the below comment:
// swiftlint:disable:next rule_identifier

Likewise, you can disable the rule in the current line and previous line with swiftlint:disable:this and swiftlint:disable:previous respectively.

d) Change the rule setting

Some of the rules have some setting that you can change it in the configuration to adapt your need. For example, you can set the line length in your configuration file as follows:

The above example overrides the default acceptable line_length from 120 to 140 characters. It also changes the error threshold (when SwiftLint stops the project of getting compiled and raises an error) to 160 characters. You can see the list of these configurable rules in the sample configuration file.

Which rule should be resolved first?

You can start with any of the rules and choose any order you like. There is only one point to consider, it is better to resolve line_length, function_body_length, and file_length respectively. The reason is that while you update your project for having the right balance of line length, it probably increases the body of type length and then file length too. Thus, it can make your work double if you do not keep this order for resolving the lint issues.

Now I’m going to add more tips related to using SwiftLint.

Strict mode

If you violate some linting rule, in most cases it raises warnings by default. Practically, there is a possibility that you don’t see the warnings, because they’re being raised after the project built again, not while you write your code! You can change the behaviour to raise errors by adding --strict argument when running the tool. So you can change the SwiftLint script in Xcode to the following one:

By changing the script, you get a build error like the below picture in Xcode next time a rule is being violated:

Enable Xcode auto trim and white-space removal feature

One of the lint rules which can be seen as annoying is trailing_whitespace. By removing whitespaces you stop having extra unused spaces in your files which result in clean commits focused on main changes in your code. The good news is that there is a feature in Xcode that can help you to avoid whitespaces and keep in line with the rule. To enable it, go to preferences > Text Editing > Editing, and tick “Automatically trim trailing whitespace” and “Including whitespace-only lines” options.

Add SwiftLint to CI /CD process

To make sure that the code written by all team members is in the right place with linting, you should setup SwiftLint in your continues integration tools.

Use a style guide with SwiftLint

By using SwiftLint you can keep your code clean at some level by formatting it and enforcing some basic style rules, but it doesn’t ensure you that it follows the desired style until you follow a style guide with and keep an eye on it manually. You can have your own style guide and follow that in your code. Another option is to start using some currently trusted swift style guide and change them with your own needs. Here is a list of some common Swift style guides:

• Apple API Design Guidelines
• Raywenderlich Swift style guide
• Google’s Swift style guide
• LinkedIn’s Official Swift Style Guide
• Airbnb’s Swift Style Guide

Are there any other tips or ideas that you find it useful while using SwiftLint? Please share them in the comments.

Thank you for reading! If you find it useful please share it via Twitter or LinkedIn to help the others as well.

Getting feedback from the users is one of the most important parts of every mobile application with a business plan. The app users in iOS can provide their feedback in the form of ratings and reviews at AppStore. In this article, we are presenting an easy and effective solution to get feedback from users.

Before the arrival of iOS 10.3, developers used a create a button with a link to AppStore to provide a way for users to rate the application. The link could be created as follows:

If you do not know your app id follow these steps [1]:

1. Log into AppStore Connect
2. Click My Apps
3. Click on the App Icon you are interested in
4. Make sure you are on the App Store page
5. Go toApp Information section (it should automatically take you there)
6. At the bottom of that page, there is a blue link that says View on App Store. Click it and it will open to a blank page. Copy what is in the URL bar at the top of the page and that's your app reviews link. It will be live once the app is live.

But this led to a lot of ugly-faced rating views. Additionally, it was not easy to use and user-friendly. As a result, iOS provided a built-in view for this purpose in StoreKit Framework [2]. To call this view you only need to call requestReview method:

The result will be arising of the rating view in Figure 2:

However, there are some vital facts about this method:

First of all, you should not call this method in a button press action or anything which triggers casually. The reason is the number of times that your app can call this method is limited to 3 times per year (365 days) [3]

Secondly, the action triggered after calling this method is different based on where it happens:

a) In Simulator

Every time you will see the feedback view.

b) In Test Flight mode:

You never see the feedback view

c) In production mode:

It is based on OS decision to show or not show the feedback UI which as we described above is only happens 3 times annually.

Thus, we should have a strategy when and where to prompt the rating view. We should not interrupt the user while they are doing an action. You do not tend to get negative feedbacks of angry users, do you? :D

The other fact is that we should bear in mind is that we should not ask the users to rate before they spend a reasonable time in the app. Moreover, we should not waste our limited opportunity of showing the review feedback by triggering it repeatedly or without enough gap between request times.

To have an easy and suitable solution for review requests, I created the following helper:

As can be seen, there are two methods that you should call in your application:

Increase Engaging Count (incrementAppOpenedCount)
You should call this method whenever the user engaging factor of your application is increased. One of the easiest ways is to call this when the application is opened by the user. You can set this in AppDelegate :

Ask for Review (checkAndAskForReview)
This method should get called when the user is ready for submitting their review. For instance, I called this method when users opened their dashboard page of the application:

When will review be triggered?

By the default setting, it will be called firstly after 10 times (or more) engaging of the user with the app. The next time would be after 20, 60, 240 times and so on.

You can see an example of the above implementation in Smart Wallet open source app:

novinfard/SmartWallet

https://github.com/novinfard/SmartWallet/commit/e0c039316a8c5ac5c92859757465fb1355ddb44e

As a final notice, users can opt out of appStore rating and reviews by changing the option in iOS Settings .

References

1. https://stackoverflow.com/a/52614442/3477974

2. https://developer.apple.com/documentation/storekit/skstorereviewcontroller/2851536-requestreview

3. https://developer.apple.com/design/human-interface-guidelines/ios/system-capabilities/ratings-and-reviews

As a common case, you may need to store the results of multiple network requests first and then display the proper data to the user.

Indeed if you have to request many network resources for performing a feature of your application, it may consume more energy of the device and you may think twice about, but it is out of this article’s interest.

Let’s say we have a sample network request function as follows:

And there are some network requests that we want to fulfill via the network:

In the above example, baseUrl indicates our base endpoint URL and the endpoints are different requests from the web server.

Multiple Independent Tasks (Concurrent Queue)

We can have different async tasks which are independent of each other. It means we can run them in any order and the result of one is not related to the other task.

DispatchGroup

Grand Central Dispatch or GCD automatically manages the thread creation and balances them based on available device resources in iOS.

We can create a bunch of asynchronous tasks with DispatchGroup and continue our job when all of them is completed:

We have notified the main thread when tasks are done but it could be any other threads. The following output could be the result (or any arbitrary order of completion of sub-tasks):

Task albums is done

Task posts is done

Task todos is done

Task comments is done

Task users is done

Task photos is done

All Tasks are done

As you can see, when all the tasks are processed we received the “All Tasks are done” message.

Promises

There is a pattern which is highly recommended to solve this issue: Promises.

Generally speaking, a promise represents the eventual result of an asynchronous task, respectively the error reason when the task fails. Similar concepts are also called futures (see this wiki article for more information Futures and promises).

We can suppose 3 different states of a promise:

Pending : unresolved task and the result is not yet available

Fulfilled : resolved task with some value (successful response)

Rejected : resolved task with error

There are a bunch of Cocoapods libraries to provide promises. One of the best implementations in Swift is Google Promises:

google/promises

Now we can update the solution using Promises:

As can be seen, promises ease the async task process. In performNetworkPromise we first created a pending process that some data will be returned. It is like an empty async request container that we have initialized. The type Data in the promise determines what type of data it would be fulfilled with. Then we performed the network request. As a result, when we have a response we fill the promise with the data from that response.

We created an array of network requests in promiseSolution named networkPromises . The all class method waits for all the provided promises , here the network requests, to be fulfilled. Once all of them have been fulfilled with proper data, it will an array of all fulfilled values, [Data] .

The other promise implementation which is so popular in Swift community is PromiseKit.

GitHub - mxcl/PromiseKit: Promises for Swift & ObjC.

They are so similar to each other (the keywords are almost the same). You can check it out yourself. Just keep in mind that you should not use both of them in a single scope.

You can find the source code of this article at below repository:

novinfard/SyncAsyncTasks

You can use shape layers for creating UI elements. The shape layers are vector-based, so the quality doesn’t change with changing resolution. It is possible to animate the shape layers with Core Animation libraries which is another advantage of shaper layers. Additionally, the process of rendering the CAShapeLayer optimises by hardware.

Before starting to create a shape, let’s see the axis of drawing. Because UIBezierPaths uses Quartz coordinate systems, the y-axis is flipped vertically as follows:

The custom shape we want to draw in this example is an arrow shape which is shown in figure 2.

To simplifies drawing this shape using bezier paths, we can think of edge points of the shape as the main points and then our job is to draw lines between these points. Figure 3 shows this shape according to its main points:

The “Leading edge width” and “Trailing edge width” are two points in x-axis which indicates the shape of our arrow. If we consider the custom shape inside a rectangle as our view, leading and trailing edge width can be calculated a the percentage of the view’s width.

We want to create the whole arrow shape inside a UIView. The following code could draw our custom shape inside an instance of UIView :

import UIKit

class ArrowView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        self.initialConfig()
    }
    
    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        self.initialConfig()
    }
    
    let shapeLayer = CAShapeLayer()
    
    private var fillColor: UIColor = .black
    
    /// width percentage of space between view leading and edge leading
    ///
    /// The value should be between 0 and 100
    private var leadingEdgeWidthPercentage: Int8 = 20
    
    /// width percentage of space between view trailing and edge trailing
    ///
    /// The value should be between 0 and 100
    private var trailingEdgeWidthPercentage: Int8 = 20
    
    func initialConfig() {
        self.backgroundColor = .clear
        self.layer.addSublayer(self.shapeLayer)
        self.setup()
    }
    
    func setup(fillColor: UIColor? = nil,
               leadingPercentage: Int8? = nil,
               trailingPercentage: Int8? = nil) {
        
        if let fillColor = fillColor {
            self.fillColor = fillColor
        }
        
        if let leading = leadingPercentage,
            isValidPercentageRange(leading) {
            self.leadingEdgeWidthPercentage = leading
        }
        
        if let trailing = trailingPercentage,
            isValidPercentageRange(trailing) {
            self.trailingEdgeWidthPercentage = trailing
        }
    }
    
    private func changeShape() {
        self.shapeLayer.path = arrowShapePath().cgPath
        self.shapeLayer.fillColor = self.fillColor.cgColor
    }
    
    private func isValidPercentageRange(_ percentage: Int8) -> Bool {
        return 0 ... 100 ~= percentage
    }
    
    override func layoutSubviews() {
        super.layoutSubviews()
        
        self.changeShape()
    }
    
    private func arrowShapePath() -> UIBezierPath {
        let size = self.bounds.size
        let leadingEdgeWidth = size.width * CGFloat(self.leadingEdgeWidthPercentage) / 100
        let trailingEdgeWidth = size.width * (1 - CGFloat(self.trailingEdgeWidthPercentage) / 100)
        
        let path = UIBezierPath()
        
        // move to zero point (top-right corner)
        path.move(to: CGPoint(x: 0, y: 0))
        
        // move to right inner edge point
        path.addLine(to: CGPoint(x: leadingEdgeWidth, y: size.height/2))
        
        // move to bottom-left corner
        path.addLine(to: CGPoint(x: 0, y: size.height))
        
        // move to bottom-right side
        path.addLine(to: CGPoint(x: trailingEdgeWidth, y: size.height))
        
        // move to left outer edge point
        path.addLine(to: CGPoint(x: size.width, y: size.height/2))
        
        // move to top-right side
        path.addLine(to: CGPoint(x: trailingEdgeWidth, y: 0))
        
        // close the path. This will create the last line automatically.
        path.close()
        
        return path
    }
}

As you can see, we have a shape layer which our custom shape is drawing on it. The FillColor indicates the color of the shape.

The arrowShapePath is responsible for creating the bezier path. As you can see, by using the close function of UIBezierPath it draws the last line between the first and last drawn point.

Now it’s time for the animation part. We want to change the path of the arrow every time we change the edge percentage in setup of the view. To do this, we cannot use default UIView animations. Instead, we can animate the shape with CABasicAnimation . We modify our initial code to add the animation:

import UIKit

class ArrowView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        self.initialConfig()
    }
    
    required init?(coder aDecoder: NSCoder) {
        super.init(coder: aDecoder)
        self.initialConfig()
    }
    
    let shapeLayer = CAShapeLayer()
    
    private var fillColor: UIColor = .black
    
    /// width percentage of space between view leading and edge leading
    ///
    /// The value should be between 0 and 100
    private var leadingEdgeWidthPercentage: Int8 = 20
    
    /// width percentage of space between view trailing and edge trailing
    ///
    /// The value should be between 0 and 100
    private var trailingEdgeWidthPercentage: Int8 = 20
    
    func initialConfig() {
        self.backgroundColor = .clear
        self.layer.addSublayer(self.shapeLayer)
        self.setup()
    }
    
    func setup(fillColor: UIColor? = nil,
               leadingPercentage: Int8? = nil,
               trailingPercentage: Int8? = nil,
               animate: Bool = false) {
        
        if let fillColor = fillColor {
            self.fillColor = fillColor
        }
        
        if let leading = leadingPercentage,
            isValidPercentageRange(leading) {
            self.leadingEdgeWidthPercentage = leading
        }
        
        if let trailing = trailingPercentage,
            isValidPercentageRange(trailing) {
            self.trailingEdgeWidthPercentage = trailing
        }
        
        if animate {
            self.animateShape()
        } else {
            self.changeShape()
        }
    }
    
    private func changeShape() {
        self.shapeLayer.path = arrowShapePath().cgPath
        self.shapeLayer.fillColor = self.fillColor.cgColor
    }
    
    private func isValidPercentageRange(_ percentage: Int8) -> Bool {
        return 0 ... 100 ~= percentage
    }
    
    override func layoutSubviews() {
        super.layoutSubviews()
        
        self.shapeLayer.removeAllAnimations()
        self.changeShape()
    }

private func animateShape() {
        let newShapePath = arrowShapePath().cgPath
        
        let animation = CABasicAnimation(keyPath: "path")
        animation.duration = 2
        animation.toValue = newShapePath
        animation.timingFunction = CAMediaTimingFunction(name: CAMediaTimingFunctionName.easeOut)
        
        self.shapeLayer.add(animation, forKey: "path")
    }
    
    private func arrowShapePath() -> UIBezierPath {
        let size = self.bounds.size
        let leadingEdgeWidth = size.width * CGFloat(self.leadingEdgeWidthPercentage) / 100
        let trailingEdgeWidth = size.width * (1 - CGFloat(self.trailingEdgeWidthPercentage) / 100)
        
        let path = UIBezierPath()
        
        // move to zero point (top-right corner)
        path.move(to: CGPoint(x: 0, y: 0))
        
        // move to right inner edge point
        path.addLine(to: CGPoint(x: leadingEdgeWidth, y: size.height/2))
        
        // move to bottom-left corner
        path.addLine(to: CGPoint(x: 0, y: size.height))
        
        // move to bottom-right side
        path.addLine(to: CGPoint(x: trailingEdgeWidth, y: size.height))
        
        // move to left outer edge point
        path.addLine(to: CGPoint(x: size.width, y: size.height/2))
        
        // move to top-right side
        path.addLine(to: CGPoint(x: trailingEdgeWidth, y: 0))
        
        // close the path. This will create the last line automatically.
        path.close()
        
        return path
    }
}

After animation happened, the shape does not change its path. To apply our changes we have two options in animateShape method:

1. Freezing the animated path:

animation.fillMode = CAMediaTimingFillMode.forwards animation.isRemovedOnCompletion = false

This solution leads to further problems. For instance, it disables the auto-layout for redrawing the shape layer which in turn results in incorrect shape size after device rotation.

2. Using the animation ending delegate:

By using the CAAnimationDelegate , we could change the shape’s path when the animation has ended. The below code demonstrates how we can handle it:

private func animateShape() {
        let newShapePath = arrowShapePath().cgPath
        
        let animation = CABasicAnimation(keyPath: "path")
        animation.duration = 2
        animation.toValue = newShapePath
        animation.timingFunction = CAMediaTimingFunction(name: CAMediaTimingFunctionName.easeOut)
        animation.delegate = self
        
        self.shapeLayer.add(animation, forKey: "path")
    }

extension ArrowView: CAAnimationDelegate {
    func animationDidStop(_ anim: CAAnimation, finished flag: Bool) {
        if flag {
            self.changeShape()
        }
    }
}

To wrap-up the solution, we are going to use our arrow in a view controller with a button to trigger the animation action as follows:

import UIKit

class ViewController: UIViewController {
    @IBOutlet weak var arrowView: ArrowView!
    private var reverseAnimation = true
    
    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    @IBAction func AnimatePressed(_ sender: AnyObject) {
        self.reverseAnimation.toggle()
        let (leadingPercentage, trailingPercentage) = self.reverseAnimation ? (Int8(0), Int8(0)) : (Int8(50), Int8(50))
        
        self.arrowView.setup(leadingPercentage: leadingPercentage,
                             trailingPercentage: trailingPercentage,
                             animate: true)
    }
}

In this example controller, we animate the edge path percentage between 0 and 50. The result is shown in the below demo:

If you tend to create complex custom shapes, you can use some tools such as PaintCode.

You can check the source code and fork it in the following Github repository:

novinfard/BezierPath

References:

1. Apple Quartz 2D Programming Guide