Hey everyone,

As software developers/engineers when we want to write on something we primarily focus on technical challenges since they are easy to describe and do not have many grey areas. For this post, I want to change this a little bit and focus on more human interaction side. I will try to talk about the etiquette & good manners of a pull request.

Creating, reviewing, and handling pull requests is a subjective topic, every development team should find their own best practices about it. So in this article, I’m gonna walk you through some of the ways we are using in Yemeksepeti to make our pull requests better.

Some of them can be considered global and some of them are not, some of them may apply to only crowded teams and some of them may not be helpful to you. While reading please consider how would these ways fit your team.

Single Responsibility Principle of a Pull Request

Applying the single responsibility principle to pull requests is always a good idea.

Try not to include some additional stuff into the PR. For example, do not fix any typos other than your current context or do not add a tiny bug fix to a feature. In this way, you can easily describe your aim and prevent confusion. You can also eliminate the possibility of one change waiting for the other.

Title and Description of a Pull Request & Pull Request Templates

Title and description is the first place where you can inform your teammates about the changes. PR titles can be traced via searching so adding some key information on the title would be useful.

Description of a PR should always be prepared with the same attention, whether the PR has a small or huge change. Reviewing the pull request requires changing the context for the reviewer. One minute ago you were focusing on apples and now you are looking at oranges. In order to ease this context change, the description of a PR is our first weapon. You can include anything in the description like Jira tasks, crash logs, design visuals, etc. Do not restrict your imagination for the description, every detail matters.

Always think that anybody could read your PR anytime. So do not assume this PR is only for the current situation and for the current reviewers. You are leaving some piece to your codebase history. Describe everything with these attitudes.

There are lots of teams in Yemeksepeti, in our team we are using Github. Github lets you create Pull Request Templates (even though it is still primitive 😄) which can help you with the PR descriptions. I suggest you take a look at this feature, it can be very helpful 🚀

By using pull request templates you can define guidelines for your team for creating descriptions for the pull request.

There is an example pull request description below which was created with our template. You can create your pull request template by looking at the official documentation. These templates are actually markdown documents. You can set it as default or you can create multiple templates and use it via query params while creating your PR.

Possible ways to make your Pull Request more understandable

• For a long time running, big codebases (like we have in Yemeksepeti 😄) you probably have a modular project structure, and lots of common codes are being used on the entire project. If you have changed some code pieces that affect the entire project it would be nice to talk about why you have made this decision and warn reviewers to be more careful. Crowded teams probably people have their domains and mostly they work on related parts. So maybe they haven’t gone through the parts you are changing on the PR. It is the author’s responsibility to notify reviewers and keep the project safe.
• Commenting for the lines on your PR is another best practice to help your teammates. I like putting official documentation, Stackoverflow, and article links to the related lines which solve some strange bug or bring a brand new concept to the codebase.
• Another good practice is to arrange a meeting (probably an online one thanks to remote working 👨🏻‍💻 ) after creating the PR to tell your teammates about the PR content. Be humble and do not fall for quotes like best codes speak for themselves 😄. For long PRs this can really be helpful for directing your teammates for possible code pieces that you want to be looked at. Also while your teammates review the PR you can apply some small suggested changes on the fly. I think this approach is a really good way for everyone to express their opinions and also show your trust in them doing the changes live. This practice reminds me of pair programming and while remotely working I deeply understand the value of pair programming 💪🏻.
• It is the author’s duty to test the code before PR. Do not present not working code to your teammates. As I mentioned in the second topic, reviewing PRs requires context changing for the reviewers. Show some respect to them and give the best possible PR experience both with codes and the execution.
• A small but important thing, if you’ve changed something important with the PR after some reviewers have accepted it please do not forget to warn already accepted teammates to review again.

Language and attitude tips

• Both reviewers and the author should be polite in the comments. Naturally, we may state some disagreements in the PR and it can bring unintentional tension between the reviewers and the author. Being polite is the best way to prevent it. Do not hesitate to use emojis and reactions to lighten the mood 🙂.
• Our pull requests’ quality can be different from time to time according to different things like the subject of the PR, our mood, time limitation, etc. so keep in mind that nothing is personal in the PRs. Do not take comments personally. The comments are not judging your personality or your abilities, they are just focusing on the current code.
• Try not to use only a few words when leaving or answering comments. Try to use sentences as much as possible. Also when you disagree with something please come up with an alternative approach in order to avoid an unproductive loop.
• When you’re a reviewer and your suggestion is too complex to tell by sentences, consider creating a pull request to an existing pull request. You should embrace it as a good habit. With this approach, you become in the same shoes as the author and you can provide better ways to tell about your solution.
• Let's talk about Language literally 😄. In my opinion code reviews should be in English as the software literature is. Using the team’s native language can be helpful to ramp up understandability but does not work in multinational teams. (Even if they are closed, PRs can be reviewed in the future. So if you have non-native language speaking people in the future your older PRs will be useless for them). Plus if you are a non-native English speaker doing pull requests in English can help you to improve your level.

BONUS: Some technical approaches to improve pull requests

Even though I’ve told you at the start I will focus on more human interaction I couldn’t leave this part out 😄.

• You should run your unit test before creating the PR. Even better the team should have a continuous integration step that runs unit tests when a PR is created. By doing this you can save every reviewers time who will try to run unit tests. Also when the build step is running the PR gets blocked from being merged faulty.
• You should use lint tools (static code analysis) to keep your code in line with the team's preferred styles. A similar step that runs lint checks on the PR when it is created can be formed. This way you can fix style errors before your teammates point them out.

Since every team has its own ways of creating and reviewing their pull requests lots of advice, opinions can be found in other articles which I left some of them below. I briefly told about our team’s practices.

Also, there are lots of stuff about the technical side of the pull requests so please read about them in order to make the best pull requests for your team 🙂.

• https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/
• https://medium.com/google-developer-experts/how-to-pull-request-d75ac81449a5
• https://github.com/thoughtbot/guides/tree/main/code-review
• https://gist.github.com/mikepea/863f63d6e37281e329f8
• https://github.community/t/best-practices-for-pull-requests/10195
• https://developers.google.com/blockly/guides/modify/contribute/write_a_good_pr

Thanks for reading.
Please feel free to comment and share it if you like it. Also if you want to talk about your best practices please leave a response, I would be appreciated to hear them.
See ya! 👋🏻

Good manners of a Pull Request & Some best practices was originally published in Delivery Hero Tech Hub on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi everyone,

In this article, I’m gonna talk about Enums in Swift. At Plus Minus One we love using enums.

Enums are mostly used as a basic type defining structure by most of the developers, but actually, they can be used in a very wide range.

You can see official documentation here. As you can see Enums are much more capable than you think.

I will be presenting some of the use cases of Enums from our team below.

Enums can conform to protocols

Yes, enums can conform protocols. You can use Swift’s own protocols or custom protocols. By using protocols with Enums you can add more capabilities.

Sometimes we need to use similar but different object types in the same place. For this, we need to define a generic type for these objects. For example, we can append different FilterType and SizeType enums to the same [BaseSelectionType] array and checking theirs selectionType fields we can safely cast to the desired type.

Enums with Switch Cases

This is the most common usage of enums. Instead of if-clauses, we can use switch-case statements which make our codebase more readable.

A switch-case statement can be used inside the enum with self keyword also. With the next topic, you’ll see the related example.

Enums with Computed Properties

We can not use stored properties with enums but we can use computed properties.

In this example by using a switch statement with self keyword, we are getting a string to display it on the screen for the related FilterType.

let text = FilterType.colorDocument.getDisplayText

We can use methods for these kinds of operations also.

We can add multiple computed properties and methods to our enum cases. By using them we can customize our enums and get all the related info inside them.

Enums with associated values

Creating our custom endpoints is one of the use cases where we use enums a lot. As you can see with this example we are using all the things we have talked about above.

By giving .getInfo(perPage: 100) to our method, we provide that request() method will get the path variable from enum with the associated value given.

You can not define associated values with raw values. This is because raw values are predefined uniquely and static but associated values are given while initialization, thus they are dynamic.

Enums with CaseIterable

By conforming CaseIterable we gain access for using allCases property, in this way we do not need to deal with adding all of the enum cases to an array. We are getting all of the cases of our enum type instantly.

Enums with Raw Values & Initialization with Raw Values

Instead of associated values, we can define our Enum cases with Raw Values in an old fashioned way.

Also, we can create enums by initializing them with raw values.

Enums with Custom Initialization

We can create our enum types by using custom init methods also. Let’s explain this with an example. Assume that we’re getting our filter types from the backend with integer ids. Also, our app supports multi-language.

Considering these cases, let’s define localization id of each case to their raw values and define a custom init method which takes an integer value and returns related enum case.

With this approach whenever we get FilterType ‘s from backend we can initialize them with our custom init method. By using predefined raw values we can get localized strings easily.

These kinds of little tricks would make your codebase more readable and understandable.

I’ve shown some usage of Swift Enums, but they offer more than those. You can use them recursively, they can also have extensions, subscripts, etc.

To learn more about our development experiences you can look at our medium page. At Plus Minus One, we love to learn and share our experiences. We hope this article makes your life easier 🙏🏻

Extensive Swift Enums Guide was originally published in Plus Minus One on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everyone,

Before Auto Layout and before iPhone had only one device size, everything was defined by pixels. Because you have one device size and because there is no such thing as Auto Layout generally everything was static.

In 2012 Apple introduced us iPhone 5 with a brand new 4-inch device size. Also that year they released Auto Layout because things were changing. Our views had to be responsive since we have two different device sizes.

Did you ever feel the lack of proper container view when using Auto Layout in those dark days? Or if you’re familiar with Android programming did you ever think I wish there is something like LinearLayout?

Evenly space multiple views within a container view, please look at this stack overflow thread from 2012. Go on look at the ugly answers before UIStackView.

Finally, in 2015 (after 3 years) Apple presented us UIStackView with the release of iOS 9 and saved us from the trouble 😄.

Nearly for 5 years we are using UIStackView but do we know what it is really capable of? In this article, I’m going to give you some tips and how to use hidden gems of UIStackView .

Hiding and Reordering of views

Why do we need to hide or reorder our views, let’s start with a use case. These days A/B tests are very important to apps that are used by a wide range of users. You have to think A/B testing even with small changes in your views. In Dolap we are using it very much and believe me some times it can be challenging. But should these changes bug you that much? In order to prevent these, we are using UIStackView as much as possible.

Consider hiding an inner view in a container view or changing your view’s order with Auto Layout , think about all the constraints you have to delete and create again when changing the order. Or think about calculating and setting height constraint of the container view when hiding a subview.

With the help of UIStackView these operations are too easy on the storyboard. Just change the order by dragging your view to the desired order or hide your view just setting it to hidden.

Or you can do the reordering in the code via using UIStackView ‘s arrangedSubviews property. This array gives you the current subviews in the stack view and by using insertArrangedSubview and removeArrangedSubview every items’ order can be manipulated. Pretty easy right 👍🏻

Using UIStackView as layout manager for custom views with help of Placeholders

At Dolap we are using storyboards to see our UIViewController with their general view hierarchy. Stack views contain inner customs views. These custom views are defined in their own Xibs so you can see only their definition in the storyboard. In this way we are preventing conflicts in the storyboards.

But there is a problem with this approach. If you put your views in aUIScrollView or you let’s say you want to see relative heights of your custom views (larger views should be seen large and smaller views are small) you can not achieve this with the default settings.

To make it possible you can usePlaceholder in Intrinsic Size attribute. Placeholders are only visible in Storyboard and will be removed in runtime. Custom views’ height will be automatically set in runtime according to the height of the views they contain.

As you can see in the gif below, those inner views are empty and no constraints are set. Yet there aren’t any auto layout errors. Views get their height from their placeholders.

Bye Bye CONSTRAINTS and CALCULATIONS!

This the part I like the most about the UIStackView. You can ditch most of the auto layout constraints with UIStackView.

Let assume you have two labels one under the other.

• One is a static text label as title
• Other label’s content can have multiple lines but first, you have to show only the first 2 lines of the content.
• When the user taps Read More button, label expands and shows remaining content and vice versa. (You can see the example visual below)

With the help of UIStackView and number of lines attribute of UILabel we can achieve desired behavior without setting any constraints to title and expanding label. In order to show how stack view can expand I put it in a container view. (You don’t need the container view actually)

This container view has constant leading, trailing, top constraints which will never change. Stack view has constant constraints to fill the container view.

So changing number of lines from 2 to 0 (zero) expands the label, then stack view and container view enlarge accordingly.

As you can see without any calculations and constraint changes we have implemented an expanding label.

Quick Tip: Use stack view’s fixed margins instead of using stack view constraints. This will save you from the trouble changing constraints one by one for margins.

The gif below shows everything needs to be done to achieve what we have talked about above. Also, you see that you don’t need to run your app to test the expanding label. You can see the changes in the storyboard also. It’s a long gif I know 😄 but sometimes images speak louder than words.

How to use UIStackView Alignment & Distribution

Even though we are trying to avoid setting constant constraints, sometimes we need to set constant height or width to our views in stack view. Again let’s go over on an example.

Let’s say we need a custom profile view with a profile image and a bio.

• This view has a square UIImageView with a width of 50.
• Images going to be set to profile image view will be square but their resolution can be changed.
• The profile image view should be rounded and vertically centered.
• There is a label right to the image.

It’s not that hard, right? But what if the label has so many lines, how does the image stay in the center vertically, how does the view enlarge with the label? For what we learned by now, stack view helps us with the enlarging of container view according to the label’s height.

But there is a problem? If stack view’s height increases image’s height increases also. Since we want to keep the ratio and we want to round the image this makes it impossible with the current Alignment and Distribution settings.

• Alignment: The alignment of the arranged subviews perpendicular to the stack view’s axis. In our case stack view’s axis is horizontal so Alignment property changes alignment of all arranged subviews in the vertical orientation.
• Distribution: The distribution of the arranged views along the stack view’s axis. In our case stack view’s axis is horizontal so Distribution property distributes all of the arranged subviews in the horizontal orientation.

I’ve prepared a visual which shows both storyboard and simulator. In the simulator at the bottom, you can see the desired profile view.

By looking at the info on the labels you can see the differences between the inner stack view’s alignment and distribution properties.

How to adapt orientation changes

Orientation change can be a scary concept 😄. Most of the time we go along with the portrait orientation. But what if your product team needs a landscape screen for the new feature of your app?

Let’s say we’re dealing with a simple screen just showing some ordered views. Of course, we are going to use UIStackView. Stack view will equally space the views for us after rotating the device, but is it the best way to display?

What happens if our designer wants to keep the same amount of area for the views after orientation change. If we were not using stack view, we would deal with constraints changes or creating new views for orientation change and hiding the old ones.

As you can see from the code above, stack view’s axis can be changed during runtime. Upon detecting orientation change, we can change the axis of the stack view and then inner views will be laid out accordingly. Views will keep having the same amount of area as they had in other orientations.

We have covered some usages of UIStackView but it has much more to offer. You can work on content hugging and content compression resistance priorities for changing the views’ distributions, you can add variations for different size classes, etc.

Of course, stack view can make you angry from time to time. Like not being able to set a background color to it, UIStackView is a non-rendering view so it doesn’t have background-color property. Sometimes UIStackView can show errors in interface builders but works well in runtime 😄. But believe me, UIStackView is a good friend of yours when you’re dealing with responsive design.

You can checkout and play with the sample project I created while writing this article.

mkeremkeskin/GemsOfUIStackView

Thanks for reading the article.
Please feel free to comment and share it if you like it.
See ya! 👋🏻

Hidden gems of UIStackView was originally published in Dolap Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

App transfer is fairly simple process but it’s not well known since we rarely transfer our apps. You can not find enough tutorials about the process because once we are done with it probably we won’t ever need it again. 😄

Dolap has been founded in 2016 and joined to Trendyol in 2018. Till last week we were operating on our own Apple Developer Account and App Store Connect account. Last week we have transferred Dolap iOS App to Trendyol’s account. In this article I’m going to tell you about some hidden secrets of app transfer which are not documented or you can only see along the process which I observed.

The official page for app transfer is this. Overview page gives you some important information about the process. We can finish transferring an app in 5 steps (although overview show 4 steps, I added one step to fix your development and app management issues 😂). I will add some inner steps to these main steps to walk you along the process.

Step 1: Verify that the app can be transferred

The app must meet specific criteria to be transferable. For example, at least one version of the app must have been released to the App Store. For more criteria, go to App transfer criteria.

• If you are using or have used any iCloud or Passbook entitlement you are free to be mad. You can not transfer your app. https://stackoverflow.com/a/19559979/697467.
• Anything related to TestFlight section in App Store Connect should be removed.
• Some tricky things can happen if you are using in-app purchase. If so please investigate it more. Since we don’t have in-app purchase I do not have valuable information about it.

Step 2: Back up all app information

Because an app is removed from your account after an app transfer, you should back up all information about the app before you transfer it.

I’ve backed up everything, screenshots(lots of 😄), keywords, description etc. But in the process I see that you do not need backup that much. You should be ok if you backup the things below. 🤞🏻

• You have to back up your reports. Because they will be lost when app is transferred.
• Support Url
• General App Information and App Review Information sections.

Step 3: Initiate the app transfer

The Account Holder user in your organization initiates the app transfer. Go to Initiate an app transfer.

For initiating app transfer you have login to App Store Connect with Account Holder role. Otherwise you can not see transfer option.

To start app transfer you need Apple ID and Team ID of the transferee account.

When starting app transfer you will see a screen something like above. You see that we have some information left on TestFlight section, so all the criteria was not met. After this screen you will enter Apple ID and Team ID. Process is done for the transferor account.

Step 4: Accept the app transfer

The Account Holder in the recipient organization accepts the app transfer. Go to Accept an app transfer.

This is an easy step, transferee account just accepts the request and fills the metadata with information provided by the transferor. (Backed up information in Step 3)

Although documentation says it can take up two business days, transfer completed in 15 minutes for our case.

Step 5: Some related changes about development and app management

Yes finally, I hope this step can provide some answers to your questions and solve your tricky problems.

I will go over a list of unrelated items. Some of these items can happen in your case and some of not.

- Devices are lost

Your test devices will not be transferred to your transferee account so you have add it manually again.

- Push Notifications

Push notifications will work as it is for your Production app. You don’t have to worry about it.

But if you are using build configurations like QA, Stage, etc. things are getting a little messy here. Because bundle ids for configurations other than Prod are not being transferred obviously. So you have delete to them from old account and create them again in the transferee account. A small hint; if you are using Automatically Manage Signing you can go over this process more smoothly.

Also you have to create new APNS certificates for this newly created bundle ids, give them to your backend guys and to third party push services to keep your push notifications working. 😥

- App Group (App Groups Entitlement)

We are using app groups because we have an iMessage app also. This was the hardest part for me in this whole process because I couldn’t find crumb of information about app groups and app transfer.

App groups are not transferred. In earlier versions of Apple Developer page you there was option for deleting app group as you can see in this stackoverflow thread. Right now there isn’t such option available.

So I had to create new app group name in Xcode’s capabilities section and uncheck the old one. In my case this solves my question. If you are facing the same thing please investigate more for better solutions.

- Developer Accounts, App Store Connect User

After transfer, all related developer accounts and App Store Connect accounts should be defined with same roles in the transferee account also.

- Universal Links (Deeplink) 🤦🏼‍♂️

If you are using Universal Links in your app you know about apple-app-site-association(AASA). In this file accepted url’s are defined as<TEAM ID><URL>.

When transfer completed, your TEAM ID is changed to transferee account’s TEAM ID. So you have to change your TEAM ID in your AASA file also if you are using services line Branch.io you have to change it there too.

A strange note: Even though our deeplinks for our QA has stopped working. Somehow Production application is working fine. After I changed team id for QA app in AASA and Branch dashboard, problem is solved for QA.

For the Production app I’m thinking maybe deeplinks are working because current app in store is signed with the old apple developer account so it has the old team id. So now I’m waiting for next update. Will the deeplinks stop working?

This was my journey on app transfer. Different apps can have slight differences in transferring processes because of their capabilities. But overall this is how you transfer your app.

If you want contribute to my article please feel free to leave a response. I hope my experiences will be useful to you. Thanks for the reading.

How Transfer an iOS App to Other Developer Account was originally published in Dolap Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello everybody, in this post I will talk about a custom component we are using in Dolap.

IBDesignable customizable, gradient bordered label view written in Swift.

In Dolap, we have different types for our merchants. They can be designer, second hand store, boutique etc. We are showing these merchant types in product details below merchants’ logo.

Our designer wants to show it in a cool gradient bordered label. You can see them in the screenshots from our iOS app.

These merchant types can increase and vary in the future. What if new merchant type comes from backend and let’s assume we have chosen to use images to represent these types?

Then we will need to update our app for every new merchant type.

To prevent updates we chose to go along with custom view getting its text from backend.

So we need to create our custom label YAY!

I like seeing instant updates in interface builder. We app developers don’t always get chance to create custom components, so this custom label is a perfect place to use IBInspectable properties with IBDesignable class and dust off our coding skills.

For this component we have one swift file which has two classes and an extension in it. Everything is done in approx. 200 lines. I will explain every method in detail. But first you can see our file’s structure below.

• IBDesignable variables gives you chance to edit your view on the fly. These will be available on the storyboard and effect of changing values will be seen immediately.
• Private variables are properties are used while configuring the view.
• String Extension
• CenteredTextLayer
• Init Methods
• Configure Method

Now let’s go over the last 4 items on the list with some explanation.

String Extension

We have added two methods to String for getting accurate height and width values. According to given height or width we can calculate both height and width. This methods will be used both in CenteredTextLayer and configure() method.

CenteredTextLayer

Simple subclass of CATextLayer which helps us to center the text both horizontally and vertically. Alignment mode takes care only horizontal alignment. By overriding draw() method, we calculate the height of the given string and position the label according the calculated y-axis difference.

Init Methods

Init methods are pretty simple actually. We are just calling configure() method to prepare views.

One trick to consider here is: overriding prepareForInterfaceBuilder() to see changes on the storyboard instantly.

Configure Method

Now we are where the real stuff is happening. You can see what we are trying to do from the graphic below.

• We will prepare a text layer which have rounded corners, border and transparent background with either given font or default font.
• A gradient layer will be created with desired color set.
• This text layer will mask gradient layer.

As result we have a label;

• has gradient color borders
• has rounded corners
• has transparent background
• has text with gradient colors

Lastly we will add this masked gradient layer to our background view created with desired color as a sublayer. At the end we end up with the label.

You can see full configure() method below. One trick to consider here is in order to position text to center and follow Auto Layout changes we have to calculate font size. If height of the text surpasses the view frame we’re gonna decrement it iteratively till it fits in the frame.

You can see full source code from my GitHub page.

mkeremkeskin/GradientBorderedLabelView

Also GradientBorderedLabelView is available through CocoaPods.

GradientBorderedLabelView

Thanks for reading the article.
Please feel free to comment and share it if you like it.
See ya! 👋🏻

Gradient Bordered Label View on iOS was originally published in Dolap Tech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey guys,

Some time ago our designer wanted an approval page with a vertical slider. This page is coming after some form screens (where user fills some info) and by sliding down the slider you can see the page beneath it. Also by sliding the slider to bottom end, user is approving the info he has filled.

You can see a ugly demo of it at top. (Purely designed by me 😅)

For this task, I’ve chosen to create IBDesignable custom slider which uses a xib file for reusing it in other projects via storyboards. My main aim was to be able to see my custom slider on storyboard. I like to have getting instant visual feedbacks about the custom views instead of compiling & running projects.

By using IBDesignable you can live edit your custom view created via xib from your storyboard, which is kind a cool I guess 😎.

In this post we have 2 chapters:

• Chapter 1: How to create custom vertical slider which uses xib
• Chapter 2: How to make an IBDesignable custom view which includes IBInspectable elements

Beware there will be lots of code in this post and I didn’t want to make separate posts to keep the integrity. So here you are with kinda long post. I hope you can find something useful for you.

Chapter 1: How to create custom vertical slider which uses xib

1. Creating the xib
2. Implementing the pan gesture action & communication with parent view via protocol functions
3. Implementing methods which creates the view

These are the steps we’re gonna take. Let’s start working on our slider:

1. Creating the xib

For this step I’ve added some screenshots which would be more helpful for you to understand. Also you can check the project on Github to see it for yourself. You can find the link at the end of the post.

You can see view hierarchy and their IBOutlets in the screenshots.

• sliderPath: Where all the items take place. Pan gesture uses this view to get coordinate feedbacks.
• thumbView: The view that you slide with your finger. this is connected to gesture recognizer also.
• destinationView: Hidden view to check whether thumb has reached destination. You can see this view at the first screenshot at the bottom as selected.
• I’ve chosen to add pan gesture on xib and connected its actions and outlets as you can see on the related screenshot.

2. Implementing the pan gesture

Related IBOutlets and variables

var delegate: KKVerticalSliderDelegate?
@IBOutlet weak fileprivate var sliderPath: UIView!
@IBOutlet weak fileprivate var thumb: UIView!
@IBOutlet weak fileprivate var destination: UIView!
@IBOutlet weak fileprivate var thumbTopConstraint: NSLayoutConstraint!
@IBOutlet fileprivate var panGesture: UIPanGestureRecognizer!

Protocol for communicating to parent view. You can understand what these methods do from their names.

protocol KKVerticalSliderDelegate {
    func thumbReachedDestination()
    func thumbCurrentPosition(_ position:CGFloat)
}

This computed property checks if thumb has reached to bottom of slider.

var isDestinationReached: Bool {
    get {    
        let distanceFromDestination: CGFloat = self.destination.center.y - self.thumb.center.y
        return distanceFromDestination < 1
    }
}

Calculates translation of the thumb. Then changes the top constraint of thumb to set its new position.

After getting translation we are setting a new values to original translation considering top and bottom boundaries and also thumb size.

Because the constraint changing constantly with AutoLayout, layoutIfNeeded() is called with UIView.animate() with a tiny duration to give smooth sliding effect.

func slideThumb() {

    let minY = CGFloat(0)
    let maxY = sliderPath.bounds.size.height - thumb.bounds.size.height

    var translation =  panGesture.translation(in: sliderPath)
    var draggedDistance = thumbTopConstraint.constant + translation.y

    // to prevent going up from path bounds
    if draggedDistance < 0 {
        draggedDistance = minY
        translation.y += thumbTopConstraint.constant - minY
    }
    // to prevent going down from path bounds
    else if draggedDistance > maxY {
        draggedDistance = maxY
        translation.y += thumbTopConstraint.constant - maxY
    }
    else {
        translation.y = 0
    }

    self.thumbTopConstraint.constant = draggedDistance
    self.panGesture.setTranslation(translation, in: sliderPath)

    UIView.animate( withDuration: 0.05, delay: 0, options: .beginFromCurrentState, animations: {
    self.layoutIfNeeded()
    }, completion: nil)
}

Returns thumb to initial location by changing its top constraint.

func returnInitialLocationAnimated(_ animated: Bool) {
    thumbTopConstraint.constant = initialTopConstraint
    if (animated) {
        UIView.animate( withDuration: 0.3, delay: 0, options: .beginFromCurrentState, animations: {
        self.layoutIfNeeded()
        self.delegate?.thumbCurrentPosition(self.thumb.center.y)
        }, completion: nil)
    }
}

panAction() method connected in xib. Pan gesture recognizer triggers this function, this function decide what to do by checking states.

If state is .changed , move the thumb and communicate with the parent view.
If state is .ended , first check for if thumb is at the bottom then notify parent view. If not return thumb to its initial position.

@IBAction func panAction() {
    if panGesture.state == .changed {
        slideThumb()
        delegate?.thumbCurrentPosition(self.thumb.center.y)
    }
    else if panGesture.state == .ended {
        if isDestinationReached {
            delegate?.thumbReachedDestination()
        }
        else {
            returnInitialLocationAnimated(true)
        }
    }
}

3. Implementing methods which creates the view

In this step I will show the methods which prepares the view via getting it from xib.

Related variables

var contentView: UIView?
var initialTopConstraint: CGFloat = 0.0

These are the methods which will get the view from xib and apply it to the screen. First awakeFromNib() gets called by system. loadViewFromNib() gets the container view from xib and arrangeView() sets this view’s AutoLayout properties then adds as a subview. didMoveToWindows() is a place where I set some initial properties.

override func awakeFromNib() {
    super.awakeFromNib()
    arrangeView()
}

func arrangeView() {
    guard let view = loadViewFromNib() else { return }
    view.frame = bounds
    view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
    self.addSubview(view)
    contentView = view
}

func loadViewFromNib() -> UIView? {
    let bundle = Bundle(for: type(of: self))
    let nib = UINib(nibName: String(describing: KKVerticalSlider.self), bundle: bundle)
    return nib.instantiate(withOwner: self, options: nil).first as? UIView
}

override func didMoveToWindow() {
    //ensure thumb always start from top
    self.thumbTopConstraint.constant = 0
    self.initialTopConstraint = self.thumbTopConstraint.constant;
}

Chapter 2: How to make an IBDesignable custom view which includes IBInspectable elements

First of all we need to add @IBDesignable to beginning of our class.

@IBDesignable
class KKVerticalSlider: UIView  {
    //your code ...
}

As you can see from the official documentation prepareForInterfaceBuilder makes our custom view alive. This method doesn’t get called in runtime it’s called only by Interface Builder. Isn’t that cool?

For interface builder we arrange our view as we are doing it for the device. contentView which is being set in arrangeView() is the container view. You can see it in 3rd step of 1st chapter. These codes makes our view visible in storyboard.

override func prepareForInterfaceBuilder() {
    super.prepareForInterfaceBuilder()
    arrangeView()
    contentView?.prepareForInterfaceBuilder()
}

Gather around. I have two important tricks to show you !!!

When you are overriding the methods below you should be careful. init(frame: CGRect) method helps us creating our custom view programmatically. For example I’m using it like below. If you’re getting rendering issues on storyboard check these methods first.

override init(frame: CGRect) {
    arrangeView()
}

required init?(coder aDecoder: NSCoder) {
    super.init(coder: aDecoder)
}

Also when loading your view use correct bundle. You can see the related discussion in the StackOverflow thread below. This can save you from lots of headaches.

Failed to render instance of ClassName: The agent threw an exception loading nib in bundle

I’m using IBInspectable to make my slider corners rounded. It is very simple to implement. You can see the code below also screenshots for how to use it.

@IBInspectable var cornerRadius: CGFloat = 0 {
    didSet {
        layer.cornerRadius = cornerRadius
        layer.masksToBounds = cornerRadius > 0
    }
}

In screenshots you can see corner radius variable is available on Attributes Inspector on the right menu. You can live change it. You can see the differences when corner radius is changed from 20 to 35. That’s it, easy right?

Conclusion

I hope this loooooooong tutorial gives you enough information about IBDesignable and how to prepare a custom view. If you want to dive into the code and also see how this custom slider is applied to a view controller which can be dismissed with the action on slider, you can check out the project on my Github page.

mkeremkeskin/SliderForDismissing

Thank you for reading this article.
Please add a comment if you want to add something or if you need help.
See ya!

Every developer works on hard things from time to time. To achieve what we want, we read from blogs, books, Github pages (source codes, gists, issues - btw reading Github issues can be very helpful), stack overflow threads etc. We collect little information from all the source above and gather them to find a solution.

For most of us, after dealing with our problem we are done with it. But what happens if we forget, or we are not present to do it again? It’s a good practice to write about the challenges we have in the process, however how many of us does it? Most of the time we choose the lazy way 😄. Meeh I’ll remember it or I’ll find the related stuff again.

This time I will change my attitude and write the challenges I’ve had when distributing our framework as a closed source project with CocoaPods and Carthage. I hope this post will help somebody to save their time and keep their nerve 😄

Let’s start with listing what we are working on:

1. We are building a simple framework (payment checkout service in my case). For now we are doing everything by ourselves, which means our framework has no inner dependencies. (Well, if you have nested dependencies this article will not go over them, so you’ll have dig some more 😅 but believe me they are not that hard.)
2. Framework is written in Objective-C to support both languages. Although we are fan of Swift we have chosen to go along with Obj-C regarding some considerations. (If you have Swift framework everything can be applied as the same in this article, so no worries 👊🏻 )
3. We want to distribute our code as closed source. So we will be distributing our universal binary (.framework file). Universal means this baby will work on every architectures for both physical devices and simulators.
4. We are using Github as our host for our framework.

I’m hearing that enough with the chit-chat give the real stuff, before we start I assume you all have CocoaPods and Carthage installed on your mac and familiar with them and some terminal commands (Actually I’m sure since you want to distribute your framework with some dependency manager 😄 ).

Carthage

https://github.com/Carthage/Carthage/pull/1760 till this pull request you couldn’t be able to publish your framework as closed source. It’s relatively new since it is pushed to repo on 14th of February ❤️ this year. (such a bad day to code 😂)

Carthage manual names this process archiving prebuilt frameworks into one zip file which is lacking some info about how to read the log etc. We will go through it now.

Carthage can automatically use prebuilt frameworks, instead of building from scratch, if they are attached to a GitHub Release on your project’s repository or via a binary project definition file.

To offer prebuilt frameworks for a specific tag, the binaries for all supported platforms should be zipped up together into one archive, and that archive should be attached to a published Release corresponding to that tag. The attachment should include .framework in its name (e.g., ReactiveCocoa.framework.zip), to indicate to Carthage that it contains binaries.

You can perform the archiving operation above with the carthage archive command as follows:

carthage build --no-skip-current
carthage archive YourFrameworkName

• Before starting, open your framework project on Xcode and clean build your project via Command+Option+Shift+K. (Clean building your folder will save your from evil things most of the time)
• Open a terminal and navigate to your project folder.
• Type carthage build --no-skip-current to terminal. (First I will show failed build and what to do. Then we will continue)

As you can see from the screenshot, this build has failed and created a .log file to somewhere. The message shown in the terminal is not enough to understand what the actual error is. To see the .log file you can use

open -e /var/folders/db/7hhdsv416kq6693n6s5dds8m0000gn/T/carthage-xcodebuild.DsjNvZ.log

After figuring out and solving problem build it again. (in my case it was about a build script I was using which I will mention in CocoaPods section.)

If you see this in your terminal that means you have successfully build your framework. YAY! Now we can go to other step.

• Type carthage archive YourFrameWorkName to terminal.

That means Carthage have archived our framework and created a .zip file which will be used to fetch our framework from Github.

• These .zip files are distributed using Github release attachments. Create a release with your framework version and add this .zip file as an attachment.
• From now on your framework can be fetched by using

github “YourCompany/YourFramework” >= YourReleaseNumber

CocoaPods

In CocoaPods for archiving the framework you need to make some changes to your project. Carthage does this operation by itself as you can see in previous section.

• First set Skip Install setting to NO in Build Settings of the project.

• If you try to archive right now the output framework will not work on iOS simulators. We have to add binaries for iOS simulators too. It is called fat framework. There is no easy way in Xcode to archive framework for all architectures and devices. We need to show our magic with external scripts. (External scripts is one the most annoying things about iOS development in my opinion 😄)

At the earlier stages of developing our framework I was using external build script as a Run Script in Build Phases. But this script requires building while selecting simulator as target. Carthage is using Generic iOS Device as target. So my script was failing. You can see the script in the gist below.

Instead of using Build Phases I’ve found Post Actions Scripts. You can open post actions via Edit Scheme -> Archive -> Open Archive Settings ->Post-actions. You can see the script and where you can set it below. Add the script below to your post action as in screenshot.

Update: Few months later after this post I couldn’t be able to archive my framework with simulator architectures (i386 & x86_64). After some digging I found out that I was trying to build it with iPhone 6 which you can find in the script in step 2. And iPhone 6 was not available in my XCode (I remember I deleted it). Then I’ve changed it to an available one (which is iPhone 8 in my case). Now it is working. If you are dealing with such case please consider this update.

• Finally you can archive your framework. Select a real device then click Product -> Archive. After archiving, the script will open a Finder window to your framework directory.
• Now you can start configuring your Pod. First zip your framework with the license to use it in your .podspec . Add your license file to directory where your framework sits. Then open a terminal window in this directory. Prompt the line below to terminal.

zip -r YourFrameWork.zip LICENSE YourFramework.framework

• Your .zip file is ready. As we have done it in Carthage, put this .zip file to your Github release as an attachment.
• Lets modify your .podspecfile.

Pod::Spec.new do |s|  
    s.name              = 'YourFrameworkName'
    s.version           = '0.0.1'
    s.summary           = 'Your framework summary'
    s.homepage          = 'https://yourcompany.com/'

    s.author            = { 'Name' => 'you@yourcompany.com' }
    s.license           = { :type => 'MIT', :file => 'LICENSE' }

    s.platform          = :ios
    s.source            = { :http => 'link to your cocoapods .zip attachment' }
    s.source_files      = "add your header files which would be public"
    s.ios.deployment_target = 'Your deployment target e.g. 8.0'
    s.ios.vendored_frameworks = 'YourFramework.framework'
end

s.source: link to your .zip file. In this article we are using Github so it is a link to .zip file which is inside your Github release.

s.ios.vendored_frameworks: path to your framework in .zip file pointed by the s.source

s.source_files: header files for the framework for developers to use

• Last thing to do is to registering to CocoaPods trunk and publishing the pod.

pod trunk register yourname@yourcompany.com 'Your Name'

After this you will receive an confirmation e-mail from CocoaPods. Confirm it.

Open terminal and navigate to your framework directory where your .podspec file sits. Type the command below.

pod trunk push YourFramework.podspec

That’s it. Framework is published to CocoaPods 🎉.

So you have your framework both publish to CocoaPods and Carthage as closed source. You can maybe think what we have done is complex or maybe boring but this is the way it’s done 🙂.

I know It’s kind of a long post but I’ve tried to be as much as clear. I hope this helps somebody and makes his/her life easy.

Thanks for reading.