DEV Community: Nabil Kazi

Mocking APIs while Development using Mockoon

Nabil Kazi — Mon, 17 Feb 2020 17:19:54 +0000

This article was originally shared on InstaMobile

Are you a mobile app developer? Do you work in a team along with Web developers? Does your app depend on APIs provided by the Web team? Have you ever faced issues with the unavailability of APIs to develop or test a certain feature in your app? If your answer to all the above questions was yes, then this article is for you.

Hello everyone, It’s been a while since I wrote my last article where I talked about easing off your App distribution process via Firebase App Distribution. You can find it here.

Now let’s move to the topic which we would be discussing in this article. I would be touching in on a topic or rather we can call it as a difficulty which almost every mobile app developer regardless of the domain, be it Android, iOS or Hybrid faces when working with APIs. Let’s break this article into the 3 parts –

The Problem
The Solution
The Solution - Demonstrated

So let’s begin…

The Problem

While working in a fast-paced environment where everyone is rushing towards completing their tasks & features, we often encounter a dependency on web teams for providing us with APIs. It can be a certain feature like login or getting a list of items from the web to display them in List View or post something on the web, it can be anything.

Let’s take an example of building a List-View which is powered by content from API. To implement List-Views, Recycler Views or Table Views, we need data to simulate and test our development. If the APIs are not ready by that time, we end up creating mock functions which returns an array and pass that as a data source to our views. While this may help you test your flow or views, below are some downsides of this approach –

Unnecessary Code – Adds unnecessary code which we would have to clean up when connecting to actual APIs.
Incomplete Code – We don’t write our actual Networking code: the API methods & functions that would be fetching us the data and hence a lot of code remains to be actually written when we are to connect with the actual APIs.
Incomplete features – Since your features depend on the API and you just mocked it in your code to test, your actual feature implementation is incomplete and you would have to come back at a later stage to pick up where you left and start developing the remaining part again.
2x Lost Effort – Both the Android and iOS teams would have to do this in their respective codebases and hence when you look from a Lead’s perspective, the time lost is actually 2x.

The Solution

What if..? What If..? What If I told you there is a way to avoid all the above. A way wherein you can write all your networking code – the actual production level networking code in the app. A way wherein you can write your exact functions to fetch you the data from API. Write your entire API Models, DB Models exactly the way it should have been written. A way where you don’t have to write mock functions to get you the data.

Yes! You heard it right, you can mock the APIs and this would not be in your app’s code-base. We would be utilising a 3rd party tool to create these APIs and provide us with the data and we would be doing it only once and the same can be accessed by both our Android and iOS teams.

Now there are a lot of Mock API service providers, some are paid, some are free, maximum is online while some are offline apps. To name a few – Mockoon, Postman, Swagger, TestAPI, Mocky etc.

I wouldn’t be comparing these services in this article, that would have to be a separate article in itself & I would like to know if you, the readers would be interested in that. For now, I’ll just use what I have been using for a while and really like – Mockoon. I’ll go ahead and demonstrate how easy it is to set up, create Endpoints, enter your response and start using them in your app.

The Solution - Demonstrated

The tool I would be using to demonstrate building your API and connecting it with your app is Mockoon. It is a free app available for all the platforms – Mac, Linux and Windows with unlimited Mocking. Also yes it ain’t an online web app so your data and API structure remains to yourself. That’s great right?

So let’s begin by installing Mockoon from https://mockoon.com/

Open the app and start creating your first mock API. I’ll be creating a sample Login API wherein I’ll set up both success and failure response for our login flow.

Creating your first Mock API :

Add your Environment

Your Environment is your single Project. So if you are working on 2 different apps/projects, you would be creating a separate environment for that other project.

In short : 1 Environment = 1 Project
Add your Environment route

This is that part of URL which goes after your base URL and before your API Endpoint. Example: https://www.sampleapp.com/api/v1/loginThe api/v1 would be your environment route over here. You can add a custom route to your base URL to keep your mock API structure as close to your actual API URLs. I usually keep it similar to our backend route structure so when I actually have to replace my mockoon API endpoint with our actual APIs, I just have to update the host URL.
Add your API route

This is your actual API Endpoint. Examples of this would be /login, /movies etc. Over here I would be creating an API endpoint named — login
Set your API method

This would be your API method — GET, POST, PUT, DELETE.
Add your header

You can add custom headers for your API. The most common is setting the content type for the response. It can easily be set by clicking on Headers -> Add Header -> Add Header Name (Eg. Content-Type) -> Set Value (Eg. application/json)
Add your response

Type your response JSON here that you would want to return from the API. I am returning a sample Login Success Response with a User object and Access Token. This can also be an array of JSON objects if the API is, for example, GET/Movies.
Start Mockoon server to access your API

All that remains is to start your server and start hitting the APIs and accessing the response. To quickly test if my API works and returns the intended response, I'll change the API method from POST to GET and try accessing it from the browser.

VOILA! It worked!

Now I’ll change it back to POST to connect this with my App and start working.

Note: For this API to be accessible from your mobile app while developing/testing, your Mockoon server and your mobile should be connected to the same network. I had connected both my Macbook and iPhone to the same WiFi network to make this work.

But wait! What about testing your error workflow? How can you test your error conditions and validate your UIs for certain workflows when your API fails? What happens when your Login fails? What happens when your GET API returns an empty array? You definitely would have to handle those scenarios in-app and there would be appropriate UIs & functionalities developed to handle the same. Thanks to Mockoon’s latest update (v1.5.0 at the time of writing this article) we can now add rules to API routes and return different responses for the same API endpoint. How cool is that??

Setting Rules in your API :

Let's add a rule to this same API wherein if I send password = demo in my POST request, it will return an HTTPS Status - 401 (Unauthorized Access) response.

Although it would have been better had Mockoon provided an option to change the operator in Rule from “=” to “!=” or “>” or “<”. That would have added more power to rules and also made it more closer to actual scenarios. I could have set my success response only if username=demo & password=demo else return 401-Unauthorized Access. But for now lets go ahead with the flow, hope this feature would be available in the future releases.

I would be sending the below POST request to the same /login API -

{
    "username" : "nabil",
    "password" : "demo"
}

Lets go through the steps to setup the trigger rules and vary responses based on the same -

Click on Add Response
Add your Rule
This the place where you would be actually adding your Rule. I won’t go into much detail about the possibilities here. Mockoon’s official feature page does a wonderful job of explaining that in depth. You can find it here
Here I am adding a Rule to check if the value of API request parameter “password” is set as “demo”. Basically, we are setting the Trigger Condition here. The Action would be set up in the subsequent steps.
Update the response HTTP status code
This is the first part of setting the Action to our Rule i.e If the above rule is met, what should be the Status code of API Response?
You can change the HTTP status code of the response and test them accordingly in your app. Over here I would be keeping it to 401 for invalid password rule to return an Unauthorized Access error in the API.
Add JSON response
This is the second part of setting the Action to our Rule i.e If the above rule is met, what should be the Body of API Response? This is optional, but would be extremely helpful for setting up HTTP Status 200 Success responses like an empty list, returning different API objects based on certain criteria, etc.

Now test these Conditions and Rules by varying your Request parameters from your app and see the magic happen!

Final Notes…

I have barely scratched the surface here. You can do a lot with Dynamic Variables, Templating, Latency, HTTPS, CORS etc with Mockoon. You can find a list of all its features here - https://mockoon.com/features/

Also, Guillaume has done a great job by providing a series of tutorials for you to learn these features and easily get started with them. You can access them here - https://mockoon.com/tutorials/

I am certain this article would have given you a fair idea of mocking your own APIs and a realization that there is no need to depend on web APIs anymore to develop and test our API dependent functionalities.

Tip: In cross-domain teams, it is always advisable to decide on an API structure with the Web team before even developing your Mock APIs. This can be done by aligning yourself with the web team on the API structure, finalizing the basics and then start Mocking them. This can be a small task before the actual development but would save a huge amount of rework in the code at a later stage. Trust me on this one!

If you enjoyed reading this article and learned something, share it amongst your developer friends/colleagues and spread the love! If you have anything to discuss regarding Mocking APIs or any other topic related to Mobile Apps, Development, Designing, Engineering… Drop a comment below or DM me on Twitter :)

If you find this interesting, chances are you’ll find my twitter feed too! I keep sharing articles and stuff related to development, design and productivity on a daily basis. So hop on, follow me on Twitter and enjoy the learning ride!

Till the next Article…

Managing your App Distribution using Firebase

Nabil Kazi — Tue, 10 Dec 2019 15:54:10 +0000

Now before I actually start blabbering about all the praises of the newly released Firebase App Distribution, I would like to give you all some context here.
App Distribution..., well we develop apps to be distributed right? Apart from those side projects which are looming around in some folder buried deep inside a stack or other folders, I assume rest all the apps are meant to be distributed, right? So let's talk about it.

Distribution comes in phases, you don't just build an app and make it live to the public? At least I hope not! Your app goes through various other users before it actually reaches its intended audience. Now these can be your fellow developers from your own team, or from QA, or these can be your early beta testers, or users from your Client's team identified for UAT.
As you can see I am talking about distributing the apps before it is actually published on Appstore or PlayStore. We call it Pre-release distributions. In this article, I would be covering the distribution of both Android and iOS apps using one single unified platform, Firebase App Distribution.

The focus of this article would be to highlight the available options other than firebase, the ones which we were using until now, how I used to manage the distributions in my Team, the difficulties we faced and how we can avoid all of that by switching to Firebase App Distribution. If you are still interested, which I am sure you would be, let's get started...

Distributing Android App Vs an iOS App

Now this is a section where iOS people would wanna know how Android apps are shared and Android devs would wanna know a little something of iOS.

To distribute Android apps, you create a key-store file right from Android studio and generate a signed APK using that key-store.
Now you host this APK file anywhere on the web and any user with the link would be able to download and install this app.

Reaction of iOS Developers right now... WWhhaaaaattt???? That's it? And their reaction is valid, let's go through the steps to distribute iOS apps.

You would first need to get the UDIDs (Unique Device Identifier) of all the users on whose device the app is going to be installed. Then you add these UDIDs on your Apple Developer Portal, create a provisioning profile and generate an IPA using this Profile.

Now unlike Android you cannot just host this IPA anywhere, well you can, but the users cannot install that IPA on their devices. First you would have to create an over the air install Manifest file where you specify the URL where the IPA is hosted. You then need to host this Manifest file on the internet and then your users would be able to install the IPA. Note that only those users would be able to install the app whose UDIDs were added in the provisioning profile you used to generate the IPA.

Well this was the standard way to just get you that link which you can share with the User's & distribute your app. Now for a project with very few pre-release distributions, you can manage like this (Even though I wouldn't recommend it). But when you constantly develop loads of apps and would need to keep a track of all them along with their distributions, you need some system in place. So let's have a look at various other Free Platforms which we can leverage to distribute our apps.

App Distribution Platforms & Their Shortcomings

Default Options : Google Play Internal Test Platform & iOS TestFlight

The major drawback of these default options is the setup required. Since they are the platform default options, the setup required is very close to the actual publishing of your app. Usually at this stage we want something simple like just upload your file, get the link and share.

With respect to TestFlight, the Builds have to go through an approval process before being available to the users, thats something huge which developers would like to avoid specifically at this stage.

Apart from the above points, from a Team's perspective, Managing both your Android and iOS apps require looking over these 2 platforms which is again not so good.

Firebase App Distribution

We talked enough about the problems in not just distributing the apps, but managing them ones they are distributed, maintaining a list of versions, their URLs, your testers, your Clients etc. etc. The list just doesn't end.

Firebase is known for its developer-friendly tools from Analytics, Cloud Messaging to Crashlytics. Here it comes again as our Saviour with the latest Firebase App Distribution.
Let's first see what they themselves say about this feature -

Watch The Intro to Firebase App Distribution here

Cross-platform

Manage both your iOS and Android pre-release distributions from the same place.

Fast distributions

Get early releases into your testers' hands quickly, with fast onboarding, no SDK to install, and instant app delivery.

Fits into your workflow

Distribute builds using the Firebase console, the Firebase Command Line Interface (CLI) tool, or Gradle (Android). Automate distribution by integrating the CLI into CI jobs.

Tester management

Manage your testing teams by organizing them into groups. Easily add new testers with email invitations that walk them through the onboarding process. See the status of each tester for specific versions of your app: view who has accepted a testing invitation and downloaded the app.

Works with Crashlytics

When combined with Crashlytics, get insights into the stability of your test distributions.

Gain valuable pre-release insights

App Distribution gives you a centralized dashboard to view insights on pre-release versions of your app. Testers are able to provide you with timely feedback on usability and pairing App Distribution with Crashlytics gives you real-time crash reporting for your app.

I would leave explaining the setup of Firebase out of this article since Firebase itself does a good job with its detailed documentation. Instead, I would walk you through the steps in brief -

Sign in to Firebase using your Google Account.
Create your Project.
Add your Android and iOS Apps.
Add Firebase SDK to your iOS / Android App [This would help in Analytics].
Go to App Distribution and add your Users/Testers.
You can also group your testers based on Teams like QA / Clients etc.
Upload your IPA / APK and publish it.
Your Users would get a nice professional-looking email with steps to download your app.
Don't have emails of all your testers / Users? Don't worry, Firebase got you covered. Generate an app invite link and share it across with anyone.
They would have to sign in via their Google account and then the download would initiate.

Where Does Firebase App Distribution Stand Out Amongst others?

Its Free!!!
No limitation on App Upload size
Manage both your Android and iOS apps using a single console.
Manage all your testers / Users from a single platform.
Get to know how many of your users have accepted the invite and how many of them have downloaded the app.
Maintain various versions of your App distribution.
Access Control over the download link. Consider a scenario where you have shared a link with your testers and your Clients and now for some reason, you don't want your Clients to be able to download the app. With Firebase app distribution you can disable this access to particular Users using the Firebase Console.
Ability to get the stability of your App Distributions when combined with Firebase Crashlytics.

Register Tester / Client Devices by getting their UDIDs [iOS]

If anyone has worked with a varied set of Clients you would have noticed that not all Client's / Users are tech savvy. To just get their UDIDs, we have to walk them through "n" number of steps. Well, Firebase App Distribution comes to the rescue here again -

When testers accept an invitation to test a build not signed with an Enterprise profile, they are asked for permission to share their device's UDID with you. If they agree, App Distribution collects the UDID from the device and notifies you by email of the newly-shared UDID.

When you receive one of these emails, update your provisioning profile with the UDID and distribute a new build to your testers.

Combine Firebase App Distribution with CI/CD

With almost everyone moving towards CI/CD you would be wondering how do we leverage Firebase App Distribution in our CI/CD workflow. Well hopefully these guides may help you get started -

Firebase App Distribution with Codemagic

Firebase App Distribution, Fastlane, Docker, Bitbucket Pipelines, Telegram, and all that jazz

This article was originally published on InstaMobile

If you enjoyed reading this article and learnt something, share it amongst your developer friends and colleagues and spread the love!

If you have anything to discuss regarding App Distribution or any other topic related to Mobile Apps, Development, Designing, Engineering... Drop a comment below or DM me on Twitter :)

Till next Article...

Managing White Label Solutions

Nabil Kazi — Mon, 21 Oct 2019 11:34:02 +0000

A little bit about White Labeled Solutions

Don’t worry I am not going to mention any definition or something like that. I’ll try to explain in a way that I have understood and I myself interpret it.

So.. You have a product which you feel can be used by various companies, for example, an ERP system, or an HRMS system or something on similar lines. Just that, these companies would love to have their branding on it to have a personal touch for their users. So you change the logo, the colors, and the fonts as per company’s branding and give the exact same (or with a few customizations) product to that company.

Voila! That product is a White Labeled Solution. Congrats buddy, you are a creator & an owner of a White Labeled Solution!

Now that you have a pretty good idea about what it is. I would like to share my experience of building one. I’ll share issues I came across, solutions I implemented. Also, I’ll show you how to generate a new app for a new client with completely customized branding within minutes and all this while maintaining a single structured codebase.

It all started a few hundred years ago…

I had developed Android and iOS apps for one of our company’s product. We delivered it to our first client. It was a huge success!

Then we had our second client for the same product. They needed some slight modifications in the app, branding was obvious. Apart from branding, there were also some minor changes that they required. So I did what every new developer would do, created a clone of this project and made changes in the new project, changed the branding and delivered it. Voila, Success!!

Then came the third… Story repeated… Success repeated!!

Now came the Nightmare…

I got a crash report from one of the client’s app. But the code was same across all clients apps, so that meant the issue would exist in all of them. I had to quickly fix the issue, copy-paste the same in all the projects, push all of them to production and create APKs and IPAs for all of them. All these while switching from one project to another. Ufff… Somehow managed to remain sane throughout the day :D

Then came a feature request from one of our client. Again as a smart new developer, I jumped right into that client’s repository, Implemented the feature, pushed it to production. Done and dusted, right?

Nope. Not quite. After a while, that same feature request came from a different client. I had to dabble around the earlier implemented code, copy-paste this in current client’s project and release new updates. Also, don’t forget to count in the double efforts as we had to update both Android and iOS apps.

Now it was becoming a headache to maintain all these different projects for each client. Keeping track of bug fixes and new features over the period of time was a nightmare.

Product Flavors — some light in this dark world!

Now, what is Product Flavors? In a very small gist, It helps us create multiple variants of an app from a single code base. You can configure the resources, branding, hell even the working of an app.

Now for all the iOS developers reading this and wondering why didn’t we came across this yet? Well because it's not in iOS, it’s an Android feature. What a bummer! Well, if it gives any hope, people have replicated this manually in iOS using the Build Configurations, but that’s another post in itself. You can find it here.

Coming back to Flavors in Android, I would quote a line from Android developer documentation itself here, which can sum up Product flavors for you:

“You can define basic functionality in the main/ source set and use product flavor source sets to change the branding of your app for different clients.”

For developers wanting to know more, you can find it here and for a small realistic example here.

Hell Yeah! This is what we were looking for, right?

Well, it gets a little bit tricky managing for a large number of clients.

See Android goes on adding flavors as folders in your source code so that you can separate the custom code/resources for each flavors here. Also, if you have to just change a little bit of functionality, you can use If Else in your class to separate client wise functionalities. This sounds great at first, but as your clientele will increase managing and reading this code later with a lot of If and Else throughout your codebase will be a headache.

Also, on a higher level, if at any point you would want separate developers to handle separate clients parallelly, It wouldn’t be possible.

Same goes for iOS, even if you manage to replicate the working of Flavors using the Build Configurations, you would end up in the same place as our fellow Android Developers.

GitFlow Workflow (A bit modified one!)

https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

When I was facing all this on Earth-1, my doppelgänger from Earth-88 was researching on implementing a Git workflow for the team. He comes across various Git workflows here and emails me the link. Yeah, emails work across the multiverse!

There were these 2 workflows which I could implement for my scenario — GitFlow Workflow and Forking Workflow. You can read about the workflows on the Atlassian link.

In Forking workflow, you can fork out the repo for each client from your base project, but since I wanted to keep the Codebase same and wanted to manage a single repository since it was a single product, I chose to stay with GitFlow Workflow.

Now for those who know GitFlow workflow or those who did go through the above link might be wondering there is no such thing about managing multiple clients with GitFlow workflow out there.

And you are right! That’s something I came up by modifying the workflow a bit and setting some rules!

Types of Branches in the app :

Master Branch: Will always contain the latest stable code.
Development Branch: Will contain the latest merged code from Developer Branches / Feature Branches.
Developer Branch: Every Developer’s Individual Branch
Release Branch: Will be created at the time of Release and will be deleted once the code is merged into Master and Development.
Feature Branch: A Specific Feature Branch. There will be multiple feature branches, each for the individual feature.
Hotfix Branch: Will be created from master when an issue appears in production code.

When a new client comes into the picture :

A new branch will be created from master Branch => ClientName-master
A new branch will be created from ClientName-master => ClientName-development.
All the branding and client-specific customizations will take place in ClientName-development branch.
Once a release date is fixed, we will plan “Submit to QA” Date and create a ClientName-release Branch from ClientName-development on that date and APK and IPA will be generated from ClientName-release Branch.
If there are a list of issues to be fixed, we will plan next release date, all bug fixes will be done in ClientName-release Branch and then new APK and IPA will be created and given to QA again.
Once a release is good to go live, we will merge ClientName-release into ClientName-master and ClientName-development and delete the ClientName-release Branch. We will tag the commit in ClientName-master branch to the specific version number and create the APK and IPA and submit it to client.

If an issue is found out in live app:

If it is an issue in client-specific customization, we will create a new branch from ClientName-master => ClientName-hotfix and fix the issue in this and after testing merge this branch back into ClientName-master and ClientName-development and then delete this ClientName-hotfix branch.
If the issue is not client-specific i.e. it is in base code, we will create a new branch from master => hotfix and fix the issue in this and after testing merge this branch back into master, development, ClientName-master, ClientName-development and then delete this Hotfix branch.

Specific to each client these will be the branches:

ClientName-master
ClientName-development
ClientName-release
ClientName-feature Name
ClientName-hotfix

NEVER EVER will changes be merged FROM Client Branches TO Main Branches. The flow will always be from Main Branches to Client Branches.

That little problem…

Sounded all good? Yeah! It’s just this little tiny problem in Android. It’s the Application ID or in iOS development terms, it is the Bundle ID. Application ID in Android looks like the package name. For those who have worked in Android might know that unlike iOS where Bundle ID is just a parameter in .plist file, here its actually the folder structure of the app. So when we say package name is “com.company.product”, there is a folder “com” inside which there is another folder called “company” inside which there is another one “product”.

But how is this a problem?

Well, when we create client branches from the master branch, the package name remains the same. With their branding, they might also wanna have their package name or signing configurations, etc. Also, you might want to have multiple APKs installed on your device for different clients for testing/ debugging purpose which requires unique Application ID for each APK.

Doppelgänger to the rescue!

Do I sense a dead end here? No, not really. Remember my doppelgänger from Earth-88? He emails me this link about a feature in Android Product Flavors where you can define the Application ID in each product flavors. Hell Yeah!!

So I created a single Flavor named “client” (Not the client name) in the base codebase. Now when I Checkout and create new Client branches, I just go into the flavor block and update the application ID parameter.

Also, as I said above, in iOS, this can be handled pretty straightforwardly by updating the Bundle ID in each client’s branches.

Now all the customizations specific to particular clients were in their own branches while also allowing me to keep a singular codebase updated with all my features and handling crashes and bugs across multiple apps like a pro.

Take it to the next level with Firebase Remote Config!

https://firebase.google.com

Guess what? My doppelgänger is always one step ahead! This time he emails me about Firebase Remote Config.

You can update your app’s look and feel, enable disable some features remotely without pushing an update to your app. Really? We can do that?

Yeah, as it turns out, we can remotely manage all this stuff using Firebase Remote Config. So if you are planning for a white label solution, there might be some features that you feel may depend on the client to whether take it or not. Or you might want to have some premium features or whatever your reason might be. There are always such set of features. You just have to think and jot down these features first hand. Make a config like “feature name: true” where keys can be your feature names and value can be a Boolean flag to determine the availability of that feature in the app. Now, while developing your app, check for these flags and appropriately display/hide these features.

Time for the conclusion!

Before setting up a workflow about how you are going to architect your codebase, there are some questions that you might want to answer first.

How big customizations are you ready to accommodate per client?

Will these changes turn my app or product into something like a whole new customised solution?

If that’s the case, I would rather go with Git Forking workflow and maintain a whole another repository for such clients.

Also, try and find out the dynamic features of your product which can change client wise. Implement these using Firebase remote config or you can create a remote configuration framework of your own too with the help of your Backend team.

Also, if you plan on keeping your clientele to bare minimum, which I am sure no one would want. But still, if that’s the case, I would suggest going with Product Flavors only without the client wise GitFlow.

That’s all for this one. If you liked this article and if it helped in any way, then like and share with your Friends and Colleagues. Also, I would love to hear how you handle such scenarios and also if you have any suggestions please shoot them.

Till next article…

This article was originally written & published on Medium

Will Storyboards still be alive?

Nabil Kazi — Mon, 07 Oct 2019 15:56:21 +0000

The introduction of SwiftUI at Apple WWDC 2019 has raised many questions. The major one being — “Will Storyboards still be alive?”. Let’s have a quick look at what some people are saying about it on Twitter:

If you have read about SwiftUI, the latest framework that Apple has released to build User Interfaces, you would be aware of its powers. Just to mention a few: the declaration syntax, ease of adding animations, drag & drop interface editor like in code, property editor in code, hot reload or as you may call it live refresh, etc. For those of you who want to learn more about SwiftUI, you can start here — https://developer.apple.com/xcode/swiftui/.

I’ll answer a question about the future of Storyboards by going through a personal experience of my last 4 years in iOS development.

Even before the introduction of SwiftUI, there was a question that every iOS developer would ask himself at some point in life — Storyboards or No Storyboards? The real question was WHEN? It actually depends on what kind of project the developer is working on — short term app or long term product.

In this article, I am going to take you through my journey in iOS development to the point where I asked myself… Storyboards or No Storyboards?

Prior to developing iOS apps, I was an Android developer (I still am 😄). Shifting to iOS, Storyboards were the first thing that grabbed my interest. In Android, I hardly ever used the drag and drop tool to design UI. It was always me and the XML playing together. So looking at storyboard and seeing all those options at once was a bit overwhelming, but once I got a hang of it, there was no looking back. I started developing UIs faster than I ever developed in Android. Everything was so cool. I quickly started designing UIs, creating prototypes and developing apps.

At this point, I was the sole iOS developer and these were small to medium sized apps.

First Taste…

With time the app size started to increase, new features started to pour in and the number of view controllers eventually increased.

My Storyboard grew in size and this had a direct effect on the performance of loading Storyboards. Which was obvious since the storyboard is nothing but xml code behind the scene. The more lines of code, the more time it’ll take to load. Also, to scroll through such a huge storyboard to find and fix a small thing had become a headache now. The thing which I liked was now the pain point. At this point, I started designing view cells and other views in separate nib files. This took off some load from storyboards and kept its size in check. Still, this wasn’t a good solution.

The Saviour.

I came across an article — “Clean Code for Multiple Storyboards”.

Our apps usually have different modules or different user flows. We can group these view controllers either as per ‘User Flows’ or ‘Modules’ and create separate storyboards for each user flow / module. It was now much easier to navigate through the Storyboards. Also, it kept the sizes of Storyboard files in check thus reducing its load time.

Saviour? Not for long.

Soon, multiple developers joined me on the app and whoever has worked on GIT with storyboards would know this… It Just Doesn’t work! The Merge conflicts here just cannot be resolved. The way Xcode displays the merge conflicts for Storyboards is another story in itself. After going through a lot of merge conflicts, my fellow colleagues were now scared hearing the word ‘Merge’.

Plan your development

Thankfully I was able to resolve this by planing the development in such a way that each developer had his own module to work on. Hence Say Developer-1 was working on Module-1 which had its own Storyboard-1. I was working on another module which had its own storyboard. This reduced merge conflicts in storyboards to a great extent since no two developers were working on the same storyboard at the same time.

Phew, life was sorted over here.

Unless…

iOS had different plans for me. Now came the point wherein we were tasked to develop features which would be available in some releases while absent in others. Obviously, we could not keep on copy-pasting these features whenever required and remove whenever not required. To solve this problem, Feature branches came to the rescue. We started to develop these additional features or change requests in their own branches. Now theoretically everything was fine until… we had to merge our feature branches into our development branch. Merge Conflicts came back saying “Missed me?”

Finally, the time arrived…

Now this was the time when I had to ask myself…. Storyboards or No Storyboards? With all due respect to the benefits that storyboard gives, It just fails to go hand in hand with Git. This was the biggest drawback for our team which was currently working on a large product with tons of features and multiple developers. So we started to develop new UIs, especially in feature branches programmatically without using Storyboards.

Trust me it will be difficult at the start, especially if you had never designed UIs programatically, but it becomes a lot easier. And with the long term benefits that it gives, its definitely a better option. To summarise, here are Pros and Cons of using Storyboards:

Pros: Simplifies Prototyping, Faster User Interface Development, Live Feedback in Interface Builder, Attributes at disposal.

Cons: No proper reusability, Lacks Collaboration, Merge conflicts with Git, Load time of Storyboard directly proportional to Size of Storyboard.

Conclusion — Prior SwiftUI

When can we use Storyboards?

Lifespan — Short-lived
App size — Small or Medium
Number of Developers — 1!

Some tips around that —

Go with the approach of having multiple storyboards from the start.
Architect your app into logical modules and split the storyboards accordingly.
Also to keep the sizes of storyboards in check, use separate nib files to design TableView and CollectionView Cells and also other reusable views wherever possible.

When should we avoid Storyboards?

Lifespan — Short-lived!
App size — Large
Number of Developers — 2 and more

Some tips around that —

Use a hybrid approach with Multiple Storyboards, Custom Views and View Cells in NIBs and creating views programatically.
To work with Version control and to avoid headaches of Merge Conflicts, Plan your development in such a way that no 2 developers would work on a single storyboard at one time.

Conclusion — Post SwiftUI

I mean seriously? Is there any need to use Storyboards and not SwiftUI? For all the power, the ease, the reactiveness etc. etc. that it offers?

It turns out YES!!! If you want your apps to support < iOS13 you cannot use SwiftUI.

So I guess, The ‘when to’ and ‘when not to’ just boils down to a single point now. Do you want your app to support OS version below iOS 13? With this, we can also say that the future of Storyboards will depend on — “Till when apps are willing to support iOS 12 and below.”

If you liked this article, like and share it with your fellow iOS developers. If you have your own **Story-Board-Story, do share it in comments. If you have anything to discuss regarding Storyboards or any other topic related to Mobile App Development, Designing, Engineering… Drop a comment below or DM me on Twitter :)

Till the next Article…

This article was originally written & published on Medium

7 things to keep in mind during your initial days in Software Development.

Nabil Kazi — Sun, 06 Oct 2019 14:20:10 +0000

It’s been more than 4 years working in Software Industry designing and developing web, android & iOS applications. During this period I have come across various people and companies and have seen the way people work. Based on my experience and a lot of reading, I would like to share some piece of advice for people who are aspiring to join this industry or are new and want to get better at what they do.
This article is mainly focused on software engineers and developers but can also be aligned with other domains. Please feel free to add your thoughts & experiences at the end.

THE MINDSET

I urge every one of you to set your mindset right. The mindset to “Learn, & Improve”.

No one is born a master.

Try to keep learning new things, reading articles, reviewing your work and improving on it. If your code from 6 months back and today is the same, you my friend are not improving. There are tons of resources out there which will help you learn as well as improve in your work. If you have written a piece of code and it worked, now’s the time to research & see if there is a better way to achieve the same results.

Everyone improves, even the companies who develop programming languages improve over time. Why else would you think there are versions of languages and frameworks out there??

LEARN & GROW

The start of your career is not just about making money, it’s about learning. I would recommend against joining a company which has a multi-tier hierarchical structure where you would be assigned a work and you would have to just complete and submit it without having the whole idea of the project or the impact of your work.
A Startup or a company with flat hierarchical structure offers you the opportunity to see the whole picture of the project, understand it and you could see the impact of your work in real world.

Why are these things important?

Seeing the impact of your own work drives you to do better and the experience & knowledge you gain by working on projects where you have the whole idea & insights about them is invaluable.

UNDERSTAND THE PROBLEM

We as software developers or engineers are constantly designing and building new software. This cycle goes on and on. The clients change, the users change, the requirements change, day on day you’ll be building new software.
But before you design or start building one, have you ever tried to understand why are you designing or building this? Who are your users? What impact will this have on the users? What problem are you actually trying to solve with this software?
This is very important to understand for us as a developer. Knowing what problem we are trying to solve will bring out your inputs on the problem and in turn help in building better solutions. This will help you grow a lot faster than to just sit and code whatever is asked form you.

CARE ABOUT YOUR CLIENTS & USERS

Whatever we are developing, these applications are going to be used by its intended end-users. Try to put yourself into their shoes and picture yourself using the application. If we don’t see the solution from their perspective, we may not be able to build something that they’ll like.
Caring about the end-users would drive you to develop the application in the best possible way.
Also, be open to feedbacks. Every software & design out there has improved from the feedbacks of its users. Taking user feedbacks seriously, builds a sense of trust in the users.
Note this — An appreciation from a single user would make your day!

OWN YOUR WORK

Your work defines you. Whatever you do, try to complete it in the best possible way. At times you’ll fail, but doesn’t every failure teach us something? If not what to do, it at least teaches us what NOT to do.
At times you would be asked to do something different from your usual work. Maybe you don’t know how to do it, maybe you are not good at it, but why not give it a try? Try researching and you’ll find tons of ideas and then do it.

With ownership comes accountability — With accountability comes confidence.

DON’T GET OVERWHELMED

At times there are too many projects/tasks going around simultaneously. This means a lot of work on the plate. Every one of us gets overwhelmed by the amount of work which is pending. This decreases productivity since you spend most of the time thinking about all the pending work. This also takes a toll on your mind causing stress and also decreases the efficiency of your work.
Instead, Plan them. Let the tasks come as they may…
Make a TODO list of all the tasks that you have to complete. Break down each todo item from that list into a checklist. Your Todo item is your specific task you want to accomplish & your checklist should be the steps that would help you accomplish that task. Now, arrange this TODO list as per your priority and focus on one todo item at a time. This would make you more efficient and ease off your stress.
I suggest to use some tool on a daily basis to help you plan and keep you on track. I use Microsoft Todo for personal use and Trello for project management.

TAKE A BREAK!

Every once in a while take a break from your work and chill. Burning out from work takes a toll on your mind and decreases its creativity. Not thinking about work for sometime refreshes & rejuvenates your mind and helps you see a problem from a different angle.

What are your thoughts on the above? Do let me know in the comments below. Also if you liked the article, Don’t forget to Share it with your friends and colleagues!

This article was originally published on my Medium account