Introduction:

Swiggy, India’s foremost food, grocery, and dining platform, has consistently led the charge in innovation, relentlessly pursuing ways to elevate user experiences and optimize operations. At the heart of this endeavor lies our mobile application, catering to millions of users each day. Recognizing the imperative to evolve our mobile development process to sustain our competitive advantage, this article explores Swiggy’s Mobile team’s transition from an in-house CI/CD setup to Bitrise, a leading CI/CD platform. This shift marked the inception of our Mobile DevOps journey, aimed at fostering efficiency, collaboration, and quality throughout the development lifecycle.

Mobile DevOps — Why it Matters?

1. Speedy Delivery: Mobile DevOps enables rapid development cycles, ensuring swift updates and feature releases to stay ahead of the competition and meet user demands promptly.

2. Collaborative Workflow: By fostering teamwork and breaking down silos between development, operations, and QA teams, Mobile DevOps promotes seamless collaboration towards a common goal of delivering high-quality apps.

3. Enhanced Quality and Reliability: Automated testing and continuous integration practices ensure that code changes are thoroughly validated, resulting in fewer defects and a more reliable user experience.

4. Seamless Deployment: DevOps principles automate deployment processes, facilitating smooth updates to production with minimal downtime and disruption to users.

5. Continuous Improvement: A culture of continuous improvement underpins Mobile DevOps, allowing teams to analyze feedback and performance metrics to refine their processes and deliver better mobile experiences over time.

The Need for Change:

At Swiggy, we employed an in-house CI/CD setup managed through Jenkins

Android: EC2 instance of Jenkins
iOS: On-premise machine of Mac Pro

It effectively supported our operations for numerous years, granting us control and flexibility within the development pipeline. Nevertheless, with the expansion of our mobile application in complexity, user engagement, and team size, we encountered issues regarding scalability and maintenance.

Several significant challenges arose:

• Insufficient concurrency/parallelism resulting in prolonged wait times.
• Frequent instances and machine outages.
• Manual upgrades.
• Integration complexities with third-party extensions.

Manual intervention proved necessary at different junctures throughout the development lifecycle, causing bottlenecks and impeding the timely delivery of updates to users.
The mobile technology landscape at Swiggy has continuously expanded, with support now extended to numerous tech stacks overseen by distinct teams across our diverse app offerings.
Acknowledging this evolution, we identified the necessity for a more resilient, automated solution to expedite our development process and guarantee the delivery of high-quality releases.

Evaluation:

We conducted a comprehensive assessment of various platforms including Bitrise, GitHub Actions, and Dedicated EC2, focusing on the following criteria:

1. Faster builds: Prioritizing speed of execution.
2. Parallelization of builds: Minimizing wait times.
3. Latest Tech Stack support: Ensuring compatibility with M1 for iOS and the latest Android versions.
4. Stability: Aim for negligible downtime.
5. Integrations: Supporting third-party extensions such as Slack, GitHub, and AppstoreConnect.
6. Support, Observability, and Insights: Enhancing overall efficiency through robust support and insights.
7. Cost: Ensuring the platform’s benefits in terms of developer time saved and improved efficiency outweigh the platform’s cost.

Following a thorough evaluation, we opted to integrate Bitrise into our existing infrastructure. Bitrise’s user-friendly interface, extensive feature set, and seamless integrations with popular tools and services rendered it the optimal choice for our requirements.

Integration:

Harnessing Bitrise’s capabilities, we embraced a more agile and efficient development approach. Automated builds, tests, and deployments became standard practice, slashing manual overhead and facilitating expedited delivery of features and bug fixes. With Bitrise handling the heavy lifting, developers reclaimed valuable time to concentrate on coding, enhancing productivity across the board.

Key Benefits Realized:

1. Faster Build Times: Utilizing Bitrise’s latest tech stack resulted in a 40–50% improvement in build pipelines.
2. Increased Efficiency: The parallelization capability reduced waiting time by 70–80%.
3. Improved Quality: Automated testing and continuous integration facilitated the integration of UT and lint checks reports on GitHub, enhancing code quality.
4. Enhanced Maintainability: Over the past year with Bitrise, we’ve experienced minimal downtime, contributing to easier maintenance.
5. Insights: Bitrise’s insightful capabilities allow us to monitor build times, and credit usage, set thresholds, and continually enhance our processes.

Future Outlook:

As we advance on our Mobile DevOps journey with Bitrise, our dedication to innovation and excellence in mobile app development remains unwavering. Our future endeavors include delving into additional features such as build cache, release management, and integrations provided by Bitrise. By harnessing these capabilities, we aim to further optimize our development process and proactively address evolving market demands, ensuring that we stay at the forefront of mobile app development.

Acknowledgments

Mayank Jha Farhan Rasheed Garima Bothra Minal Arora

Mobile DevOps Journey | Evolving Mobile Development at Swiggy with Bitrise | Episode 1 was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A good mobile developer not only does the day-to-day feature building but also takes care of the performance of the app and tech enhancements.

At Swiggy, providing a seamless experience to our end users is our core focus, where we always push ourselves to make the mobile app smooth as butter and give the best possible experience to the end-users.

In this article, we will jot down the various tech and app improvements we have made to the Swiggy iOS app.

1. Measuring User perceived performance.

An improvement of any sort is no good if you don’t have numbers to back it up. Therefore it’s very important, that you always add analytics/instrumentation to see the impact of your changes.

For our app, we already had page load times. But that is not necessarily significant for the end-user as he/she will perceive page load differently.

One example is: When our app is launched, before showing Home Page, we have intermediary screens and logic which also takes some amount of time.
So we came up with a Metric called First Time to be Interactive.
How much time will it take for users to interact with our app?
This is the time taken from the app icon clicked to our Home Page Rendered.

In iOS terms, it starts from AppDelgate to Splash Screen to SDKs Initialization to Location Fetch and then Home Page Rendered after API call.

Another example is: From the moment user clicks on any Restaurant from anywhere to the time its Menu Page is rendered - Menu Screen Load Time

In iOS terms, it starts from didSelectItem to Push View Controller to Menu Page Rendered after API call.

We then started measuring these kinds of metrics over NewRelic and worked on improving those numbers. After our changes below, we were able to clearly see the reduced load times via graphs.

2. Smart API sequencing

Like any other app, we also have our Home Page where we show all our offerings. But this is not the first screen the user sees. First comes Location Screen, where we show the user's current location. After that comes the Home Screen, where we call a home API to fetch the data.

As of now, we were calling all these APIs synchronously, one after another.
Our Home API just needs latitude and longitude to give us the required data.

Then we thought, why not call our Home API as soon as we get the user's location, cache the response in the app, and then when the user lands on Home Screen, use that response to render the page.

This means, that the user doesn't have to wait on the Home Screen for the API call to complete. Instead, that page will be loaded instantly.

Side by side comparison of the app before and after this. Won’t tell which is which. It should be visible :P

Talking about the numbers, these changes have helped us reduce our First Screen Visible time by half (from 6 secs to 3 secs)

3. Prefetching API Response

In cities where we have multiple offerings besides food, we have kept a tab bar where our 1st tab is Home Page which is a landing page that shows all our offerings. And our 2nd tab is the Food Page which shows the collections of restaurants in your area.
As Food is our MSP, we thought why not prefetch the second tab response beforehand only. Thus when the user switches tabs, he/she would not experience any loading state.
This technique helped us reduce our Food Tab Load Time from 2 secs to 0.5 sec

4. Rendering Smaller Images on Bigger Views as placeholders

Swiggy is a content-rich app. For any Restaurant Item, its image appeals a lot to the user. Therefore the quality should be best for that. But a good quality image will be large in size and takes time to download. We faced the same problem on our Menu Detail page where the image takes a lot of time to download as it's large in size.

To fix this problem, we came up with a unique idea. We already had the same image in a different dimension for the in-line menu item. We thought why not use that image as a placeholder till the time, the bigger image gets downloaded.
We expanded the smaller image over the bigger image view, which looked a little blurry but gave a preview of the dish and when the bigger image was downloaded, we safely replace the same.
This gives the user a feel of a progressive image without increasing any network usage.

5. Managing Image Scale Factor

Different devices have different pixel densities. Therefore they can have different DPR(device pixel ratio). Depending on the device, we can accomplish better rendering by multiplying the number of pixels in each image by a specific scale factor. That's why we have 2x and 3x images in our Xcassets file.

For our remote images also, we add the scale factor(image multiplier) to fetch higher resolution images depending upon devices. For eg: If we have an imageView of 50*50 and a device let's say iPhone Xs, we fetch 3x image size(150*150) from our remote server.

Recently we revamped our whole UI. On our Menu page, the dish image size got increased. Bigger dimension images started taking more time to download, therefore increasing our page load time.

What we observed was, that if the images are not that big in a size, for higher density phones, instead of making the dynamic scale factor (3x), we can make it 2x, it won't have any visual difference, but the size decreases significantly.
This has helped us in reducing our page load time significantly.

Note: For our bigger images, we have still kept the dynamic scale factor so that image quality is not compromised.

6. Navigation Bar Smoothening

Navigation is the most important part of the user experience. Our goal is to help users move swiftly in the app. On many screens, our navigation experience was broken. When the user tried to navigate with the swipe gesture, our navigation bars started breaking.

This was happening because we were using a mix of default navbars and custom views. And, hiding/unhiding those navbars was causing the issue.

Thus, to fix it, we came up with our own navigation system, which can act either as a default navigation bar or as a custom view. Each View Controller has a base class through which the VC can initialize Navbar. It can be initialized by passing title, subtitle, and bar button items making it similar to the default navbar or a custom view can be passed.

7. App size Reduction

In addition to making the app smoother and faster, we should also take care of our app size.

Since Swiggy as a company is getting into different offerings, our code, libraries, and assets also keep on increasing. It's very important for us to keep a check on our app size and try to reduce it as much as possible so that a user doesn’t feel that we are taking up too much space on their device.

We did a couple of exercises to help achieve our goal

1. We scanned our app for unused media assets. Removed which were no longer getting used.
2. We scanned our app for unused libraries and removed the same.
3. For our image assets, we ran them over the Tiny PNG tool which optimized our images and reduced the image sizes significantly.

What does TinyPNG do?

TinyPNG uses smart lossy compression techniques to reduce the file size of your WEBP, JPEG and PNG files. By selectively decreasing the number of colors in the image, fewer bytes are required to store the data. The effect is nearly invisible but it makes a very large difference in file size!

All these exercises help in reducing app size by ~8MB.
This is an ongoing exercise and we will continuously optimize our app size.

8. Clear Media Cache

Over the period, any app’s cache keeps on increasing. The main contributor to this is Videos and Images. And, increase in cache means an increase in the user’s storage.

Unlike Android, iOS doesn't give an option to the user to clear a specific app’s cache. We thought why not give an inbuilt setting within the app for users to clear the media cache (accumulated by caching videos and images).

This option gives power to the user to see the run time app consumption and clear the same.

Conclusion

Being a consumer-first organization, we at Swiggy are not just focused on creating an interactive user interface but are also driven to create a high-quality, enhanced, and buttery smooth user experience. 🧈

Credits to the entire iOS team of Swiggy for helping to achieve these performance improvements.
Mitansh Mehrotra, NIHAR RANJAN, Shashwat Mithyantha, Priyam Dutta, Ashirvad Jena, sreekanth m, Hari Krushna Sahu, Garima Bothra, Lunasahil, Mayank Jha

Making Swiggy Buttery Smooth was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our earlier blog post, we shared how we went about identifying the accessibility gaps in Swiggy and our design philosophy to address those gaps. In this one, we will share how we made improvements on iOS for the food ordering flow.

What did we do?

For our iOS app, we have focussed on making the app compatible with two kinds of disabilities

1. Vision: For visually challenged users
2. Physical and Motor: For physically challenged users

How we did it?

Before we get started on the implementation, there are few accessible properties that we have used in iOS

1. Label: This property is used to assign the name to our element.
2. Traits: These describe the element’s state, behavior, or usage. A button trait might be is selected.
3. Hint: Describes the action an element completes. eg: Displays the menu restaurant.
4. Frame: The frame of the element within the screen, in the format of a CGRect.
5. Value: The value of an element. For example, with a progress bar or a slider, the current value might read 5 out of 100.
6. Accessible Element: View or component for which accessibility is enabled.
   You can set accessibility for a Label/Button or you can make a whole view as one accessible element.
7. isAccessibilityElement: This boolean flag is used to enable/disable the accessibility property of any element.
   If it's set to off, OS will not read it.

If you are not familiar with the basic implementation of Accessibility, can go through a starter project on the same. Link

Vision

For people whose vision is impaired, Apple has provided a feature called VoiceOver.
Users can interact and navigate with the app using different hand gestures.

VoiceOver can be enabled in the Accessibility section of Settings.
Once it's enabled, OS will point to the first accessible element in the screen.

Basic hand gestures used for Voice Over

1. Swipe right: It jumps to the next accessible element.
2. Swipe left: It jumps to the previously accessible element.
3. One finger double tap: Clicks the selected accessible element.

For more commands, you can check the VoiceOver settings in the app.

Following are the different handlings we did in our app to smooth the interaction of Accessible User.

Grouping the Views

As many accessibility services function in a linear manner and shift focus from one element to the next. If our UI component is not grouped according to functionality, users may have to perform multiple focus shifts to reach the next item/action item.

This problem can be solved by grouping UI components together which logically represent one unit.

As you can see in the above image, restaurant entities are not grouped together so users can’t hear all the information at once. Users need to change focus every time they need to hear another information.

In the above image, you see all restaurant entities are grouped together so the user will hear all the focused information at once without shifting focus multiple times.

This can be achieved very easily by making the parent view’s isAccessibilityElement property true. OS will treat that view as one property.
Also assigning the Restaurant Name and its info to the Label property of that view

Grouping of the components has been used extensively in our app to make the experience better.

Accessibility Support for Images/Banners

In the Swiggy app, we have a lot of components that only contain images/banners.
So assigning a meaningful Name to each image view was challenging.

We came up with a solution where we added an Alt text with the image response itself from the backend.
Then we used that alt text and assigned it to the Accessibility Label.
This Alt text contains a meaningful description of the image/banner.

Announcements

Whenever something is processing or an asynchronous request is completed, we have to inform the same to the user.
To achieve this we used announcement notifications to let know the user what is happening in the app.

We used these announcement notifications for various use cases
- App launched with which location
- Location changed by the user
- When a screen is loaded (after a successful API call)
- and many more…

Custom Actions Handling

If we want to add multiple actions for a particular view component we can do this by using Custom Actions.

For the Swiggy app, we added multiple actions to each food item on the Menu/Cart page. These actions are
- Add item
- Remove item
- Go to cart

Note: We added go “Go to cart” action to each item so that the user can easily navigate to the cart as soon as he/she has added the desired item.

Modifying Menu Item Cell
For the accessible users, we changed the layout of the item cell, so that users can easily navigate to the cart.
When a user adds a quantity, we added a cart button there itself, which acts as a shortcut to go to Cart Page.

For this, we simply check if it's a voice-over session, we change the layout.

Implementation Video:

Physical and Motor

For people who can’t use their hands to operate phones, Apple has provided a feature called Voice Control.
Users can interact and navigate with the app using his/her voice and call different gestures like tap, scroll, swipe

Voice Control can be enabled in the Accessibility section of Settings

Users can use this Voice Control feature mainly by two types of settings.
This can be changed inside Overlay Section

1. Item Numbers: Here OS will determine the accessible elements in the screen and assign numbers to each element.
   The user will say
   - “Tap 1”
   - “Tap 6”
   Then the particular element will be clicked.

2. Item Names: Here OS will determine the accessible elements in the screen and assign names to each element.
The name will be what we set through code in the Accessibility Label property
The user will say
- “Tap Burger King”
- “Tap McDonalds”
Then the particular element will be clicked.

Other commands which users can use are
- “Scroll down” / “Scroll up”
- “Go Back”

Most of the tasks are achievable using these commands
For more commands and customization, users can add the same in the Voice Control settings.

Implementation Video:

Measure Impact

For every feature implemented, we must add some kind of analytics to measure the impact of that feature.
After these features were rolled out, we saw an increased number of orders completed by Accessible users.

Where to go from here?

• Now after making our food flow Accessible, we will be focusing on other Swiggy offerings also like Instamart/Genie, etc.
• We are also getting in touch with users and getting feedback on our app and doing changes accordingly so they can get the best possible experience.
• For any new features which we add, we will be supporting accessibility then and there.

Acknowledging Sanket Shekhar and sreekanth m , for helping in this implementation.

Designing the Swiggy app to be truly ‘accessible’ | Episode-3 was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The article will teach you how you can show multiple videos in one view as we see in Instagram Stories.
We’ll also learn how to cache the videos in the user’s device to help save that user’s data and network calls and smooth out their experience.
NOTE: This implementation is for iOS, but the same logic can be applied in other codebases as well.

In general, whenever we want to play a video, we get the video URLs and simply present AVPlayerViewController with that URL.

Pretty straightforward right!

But the drawback of this implementation is you can’t do customization, which, if you are working in a good product company, will be every day ask. :D

One can say, we can alternatively use AVPlayerLayer which will do a similar job but the view and other elements we can customize.

But if you say, you want multiple videos to come similar to Instagram stories, then we surely have to deep dive a bit.

Now, Let me tell my use case.

In Swiggy, we want to show multiple videos, where each video should be shown ‘x’ number of times.
On top of it, it should have a Instagram-like stories feature.
- Video-2 should seamlessly autoplay after video-1 and so on
- Jump to corresponding videos whenever the user taps left or right.

If caching is the question you have in your mind, I’ll get to that in a bit.

First thing, how to add multiple videos in one view.
What we can do is create one AVPlayerLayer and assign the first video to it. When the first video gets completed, assign the next video to the same AVPlayerLayer .

For jumping to prev or next video:
- Add tap gesture on the view
- If the touch location ‘x’ is less than half of the screen, then assign prev video, else assign the next video

There we go. We got our own Insta-like Stories Video feature.

But our task is not done yet!!

Now Back to Caching
We don't want that every time user navigates from one video to another, it again starts to download video from start.

Also, if the video comes again in the next session, we should not again do a server call. If we can cache the video, then the user’s internet will be saved, and also load on the server will be reduced.

Also, UX will improve as the user doesn’t have to wait longer to load the video.

As a good developer, reducing user’s internet usage should be our priority.

The first thing we can use to load videos is loadValuesAsynchronously.

According to Apple documentation, loadValuesAsynchronously:

Tells the asset to load the values of all of the specified keys (property names) that are not already loaded.

The advantage of using it is, it saves the video till is rendered. So it will not download the video from the start whenever the user navigates to a previous video. It will only download the part which was not rendered earlier.

Example: Video_1 is of 15 secs and the user saw 10 secs of that video and then jump to Video_2. Now if the user comes back to Video_1 again by tapping the left side, loadValuesAsynchronously will have that 10 secs video saved and will only download the rest of the 5 secs video.

More details on loadValuesAsynchronously can be read on this link.

The Caveat of this is it persists video data only for that session only. If the user kills and comes back to the app, then again video has to be downloaded.

Now comes the Video Caching!

What we can do here is when the video is rendered completely, we can export the video and save it to the user’s device. When the video comes again in the next session, we can pick the video from the device and simply load it.

AVAssetExportSession
According to Apple documentation:

An object that transcodes the contents of an asset source object to create an output of the form described by a specified export preset.

What it means is, AVAssetExportSession acts as an exporter, through which can save the file to the user’s device. We have to give the output URL and output file type.

More details on AVAssetExportSession can be read on this link.

Now the only thing left is to fetch from the cache and load the video.
Before loading, check if the video is present in the cache, fetch that local URL and give it to loadValuesAsynchronously.

Caching will help reduce a lot of user data as well as server load. The impact will be in TBs

What other use cases we can handle while doing the caching. These can be optional based on your use case.

1. Ensure Optimum Storage
Before saving the video in the device, check whether enough storage is present in the device or not.

2. Remove Deprecated Videos
Have a timestamp to each video, so that you can clean videos from device memory after x days.

3. A limited number of Videos
Have only limited videos saved in the file at a time. Let's say 10. When the 11th video comes, delete the least used video and replace it with the new one. This will also help to not consume too much of the user’s device memory.

4. Measure Impact
Don’t forget to add logs, so that you can measure the impact of your feature.
I have used a custom New Relic Log Event.

To convert file size to a readable format, I'm fetching file size and converting it to Mbs.

This is how you can measure your impact.

Total data saved = no of request * video_size = 2.4MB*20.3K ~= 49GB

This is just two weeks of data. You do the math for the whole year. 😁
And this will keep on increasing exponentially over time.

That’s it!!
You have your own caching mechanism.

Wrapping up

To conclude here, we saw how easily we can integrate multiple videos in one view itself, giving an Instagram-like story feature.
Also why and how the caching mechanism plays an important role here. And how it will help the user to save a lot of data besides having a smooth user experience.

Do let me know if I missed something. Or if you can think of any more use cases.
Thanks for your time. :)

Acknowledging NIHAR RANJAN, for helping in this implementation.

Video Stories and Caching Mechanism(iOS) was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

During my initial days with iOS, one thing I used to fear was whenever a designer comes up and says he/she wants an animation in the app.

In my mind, I used to think, it's very easy to come up with the design of animation but to implement is a very difficult task.
I used to take the help of Google/StackOverflow/Peers for the implementation.
I had a phobia using animations and have always tried to avoid it, but this soon changed.

At one instance, I had to animate a sequence of images in a view.
So what would have been my first step? Obviously, StackOverflow!
The first link got the code.

Easy peasy right? Well, if it were that simple, I wouldn’t be writing this article :P

This is the actual requirement.

As it may be clear by now, I was nowhere close to it. In fact, I was stuck. ‘How would I be able to do so many customizations in animation and sync all of them?’

Then my friend told me to try CA Animation(Core Animation). I read about the same and tried on a sample project. To my amazement, it was so easy and powerful to use.

Core Animation provides high frame rates and smooth animations without burdening the CPU and slowing down your app. Most of the work required to draw each frame of an animation is done for you. You configure animation parameters such as the start and endpoints, and Core Animation does the rest, handing off most of the work to dedicated graphics hardware, to accelerate rendering

In a few hours, I was able to do a basic implementation.

For this implementation, I used CABasicAnimation.

CABasicAnimation class animates a layer property between two values, a starting, and an ending value. To move a layer from one point to another in its containing window. For example, we can create a basic animation using the keypath position. We give the animation a start value and an ending value and add the animation to the layer. The animation begins immediately in the next run loop.
You can use CA Basic Animation for animating many things like background color, opacity, position, scale.
More details: https://developer.apple.com/documentation/quartzcore/cabasicanimation

Now, back to our problem.
How did I go about implementing this? I took two image views and added two separate images to them. Then, I kept on animating them one after the other using CA animation.
Full Code implementation: https://gist.github.com/agammahajan1/e9b550f0275418459982246d1ee905d5

If you carefully see my last implementation gif, you will notice that something off. Before the first image goes out of the view, for example, the gift box gets immediately changed to headphones and then it goes up.

Why it is happening?

Because as soon we are adding the animation to the image view, we are adding the next image to that view. (line number 5 and 6)

This is the issue of how to sync both image animations. But there always a solution with CA Animation.

CA Transactions
CATransaction is an often overlooked class by most developers. The job of CATransaction is to group multiple animation-related actions together. It ensures that the desired animation changes are committed to Core Animation at the same time.

You start by writing CATransaction.begin(). Then write all your animations which you want to do in sync. Then call CATransaction.commit() which will start the animation in the block.
Also, you can give a completion block to your animations.

Let's see how our animation looks now.

One last thing was to add the Spring effect in the animation. Thankfully, CA Animation had a solution for it too.

CA Spring Animation
You would typically use a spring animation to animate a layer’s position so that it appears to be pulled towards a target by a spring. The further the layer is from the target, the greater the acceleration towards it is.

It allows control over physically-based attributes such as the spring's damping and stiffness.
Let's implement it then.

My work is done here.

To Conclude, here are some advantages of using CA Animations
- Easy to use and implement
- A lot of customizations available
- Can sync multiple animations
- Almost 0 CPU usage

These are just a few of the advantages. The possibilities are endless.

Now, whenever requirements come for animation, I feel confident to implement the same.
And I hope you also feel the same way after reading this.
Feel free to give any suggestions or feedback.

CA Animation, which took away my fear of Animations was originally published in Swiggy Bytes — Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article is about creating iOS builds through Jenkins BOT, remotely, without the need of a developer.

Before starting, I want to say that this is my first article. So feel free to leave a comment if something can be improved :)

Why is this a good idea?

When a developer makes a feature, they QA test it before pushing it to production. So a build has to be shared with the QA team with some test configurations.

Xcode (the IDE) takes a significant amount of time to compile and generate this build. This means that any person that needs the build would have to install the IDE, clone the repository, create a signing identity and certificate and then create the build themselves. Or depend on the developer to create one for them.

During the build creation process, the IDE is unusable. This severely impacts the productivity of the developer. In my company, the average build time of an .ipa is around 20 mins. On average, a developer makes 2–3 builds daily.
This means 5 working hours a week get wasted.

But what if there was an automated system which could generate the builds on its own? This would free the developers from this responsibility. It would also make it possible for anyone to get a build easily.

Jenkins is one of the solutions to our problem.

Making builds easily available to testers and developers ensures that people are able to test features faster and ship to production more easily. This improves the productivity of development teams. It also improves the quality of products pushed to production.

Let’s get started now.

Prerequisites

You will require:

• macOS Machine (it is better to run it on Mac products)
• 10 GB of drive space (for Jenkins)
• Java 8 installed (either a JRE or Java Development Kit (JDK) is fine)
  http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Additional Plugins to be installed

• homebrew
• wget
• RVM Plugin
  Installation guide
  https://rvm.io/rvm/security

Make one Branch with a file in it with the name Jenkinsfile with sample code:
node {
sh ‘echo HelloWorld’
}
Let's name it jenkins-integration. Will come back to this later.

• Install Xcode on your machine from the App Store
• Install Fastlane on your machine. Jenkins will internally use fastlane commands to generate builds.

Now let’s go through it step by step.

Step 1. Install Jenkins on your machine

You can install on a MacBook or mac-mini. Mac-mini is preferred as it can be kept alive.

Download Jenkins -> https://jenkins.io/

Run java -jar jenkins.war --httpPort=8080 in the command line. If you’re getting an error in the terminal, try a different port (for example, 9090) as sometimes some ports are not available.

Browse to http://localhost:8080 and follow the instructions to complete the installation.

Then add admin credentials and don’t forget them (as did I :P). Later you can go to Jenkins > Manage Jenkins > Manager Users and do your changes if needed.

Step 2. Creating Your first Pipeline

Create a new job and choose Pipeline Project.

To check out your project, under the section Pipeline, in Definition, choose Pipeline Script from SCM and in SCM choose Git

Then add your repo URL and add the credentials if its a private repo. In branches to build , add */jenkins-integration, the branch which we created earlier.

Make sure Script Path is Jenkinsfile which we have created in our new branch. All the scripts will be written in this Jenkinsfile.

Click on Save and Jenkins will automatically scan your repo with the mentioned branch and will run the Jenkinsfile script.

Now we are ready to configure our Jenkinsfile to create builds

Step 3. Add parameters to the Job

User input is required for

• branch
• environment (test or prod)

For that we need to configure our project to take input parameters for a job.

Go to the Configure section and check This project is parameterised.
Then select add parameter and add the same accordingly.

When you click on save, you will see a new section on left side -> Build with Parameters. This will be the user interface to make builds.

These params will be used in our Jenkins script.

Step 3. Configure Jenkins Script

Will create multiple steps in our Jenkinsfile, each having one responsibility, and it will create a nice UI when it is built.

Go to your Jenkinsfile and replace the script with the following:

First, check out the branch through the parameter which we added earlier. Add your repo and GitHub token.

Now the GitHub token should not be visible to others. To do this, go to Manage Jenkins-> Configure System ->Global properties and add githubToken as an environment variable.

Then invoke the script to change the environment.

Next, invoke fastlane to clean (remove derived data, clean, delete .dsym files etc).

If code signing is required, do that next using ad-hoc. You can use development or app store based on your needs.

Next, create builds using the gym command in fastlane.

Step 4. Run the Job

Now our script is ready. Go to Jenkins and open Build with Parameters.

It will start to run the script and will create a nice UI with multiple steps as mentioned in the Jenkinsfile.

When the job is completed, go to the project Users/agammahajan/.jenkins/workspace/iOS_Build_Systems
and you will see that the .ipa has been created. Voilà!

Now you can share this build with others. You can use the Slack plugin to upload the builds to Slack if you want.

Wrapping up

So to conclude here, we can see how easy it is to setup an automated bot which enables any person to trigger builds in just 2 steps: Give Branch->Test Environment-> Done.

This has helped me and my fellow developers improve productivity and ship faster. It has also helped the QA team, so that they don’t have to depend on developers every time they need to test something. I hope it benefits you and your company also.

From here, the possibilities are endless.

1. You can make scheduled jobs to generate nightly builds.
2. Upload builds directly to the App Store.
3. Cache the builds, so builds with the same configuration are not generated again.
4. Distributing the IPA in house for OTA (Over the air) installation.
5. Make a CI-CD pipeline to run automated tests on every commit and make them production ready.

How to make an iOS on-demand build system with Jenkins and Fastlane was originally published in We’ve moved to freeCodeCamp.org/news on Medium, where people are continuing the conversation by highlighting and responding to this story.