• View Extensions

• ViewModifiers

• Custom Views

We can almost produce the same results with the above alternatives, leading to confusion about when to use them. 🤔

TL;DR:

• View Extensions: To apply simple stylings (e.g. colour, padding, etc).

• ViewModifiers: To apply state-based styling or complex styling(multiple modifiers).

• Custom Views: For containers, when composing multiple views.

Let's take a simple example of styling the Text label to be used as Headers.

Approach 1: Using View extension:

public extension View {
    func applyHeaderStyle() -> some View {
        lineLimit(1)
        .font(.largeTitle)
        .fontDesign(Font.Design.serif)
    }
}

Approach 2: Using ViewModifier:

struct HeaderLabel: ViewModifier {
    func body(content: Content) -> some View {
        content
            .lineLimit(1)
            .font(.largeTitle)
            .fontDesign(Font.Design.serif)
    }
}

Both would give the same result visually if you check the following code in the preview:

import SwiftUI

struct ContentView: View {
    var body: some View {
        VStack {
            // Text styled using view extension
            Text("Header Text")
                .applyHeaderStyle()

            // Text styled using view modifier
            Text("Header Text")
                .modifier(HeaderLabel())
        }
    }
}

#Preview {
    ContentView()
}

We can further simply the API for accessing HeaderLabel modifier by extending the View with a function that applies the .modifier() . That is how it is demonstrated in Apple's documentation also.

extension View {
    func headerTextFormat() -> some View {
        modifier(HeaderLabel())
    }
}

// Usage
struct ContentView: View {
    var body: some View {
        VStack {
            // Text styled using view extension
            Text("Header Text")
                .applyHeaderStyle()

            // Text styled using view modifier
            Text("Header Text")
                .headerTextFormat()
        }
    }
}

So, what's the difference between Approach 1 and Approach 2?

Visually, there is no difference for this simple customization which does not involve any states. But, we would notice a difference when you try to print the view if required for debugging as follows:

Type Of TextWithExtension::
 ModifiedContent<ModifiedContent<ModifiedContent<Text, _EnvironmentKeyWritingModifier<Optional<Int>>>, _EnvironmentKeyWritingModifier<Optional<Font>>>, _EnvironmentKeyTransformModifier<Array<AnyFontModifier>>>

Type Of TextWithModifier::
 ModifiedContent<Text, HeaderLabel>

As we can see, when muliple modifiers are applied the view modifier approach encapsulates the internals properly.

I would go for view extensions when applying simple customisation or adding syntactic sugar to existing modifiers as discussed in the previous blog.

ViewModifier is the obvious choice when we want to apply styling based on @State . ViewModifier can have internal @State and it is mostly similar to View . Internal states are not possible with extensions. Note, we can still achieve it by passing the binding to the function in the extension but it would be ideal to use ViewModifier.

Suppose we want to allow the user to be able to drag the Text label and on release it should move back to its original position. We can define our custom ViewModifier in this case as follows:

import SwiftUI

private struct SpringGesture: ViewModifier {
    @State private var offset: CGSize = .zero

    func body(content: Content) -> some View {
        content
            .offset(x: offset.width, y: offset.height)
            .animation(.interactiveSpring(), value: offset)
            .simultaneousGesture(
                DragGesture()
                    .onChanged { gesture in
                        self.offset = gesture.translation
                    }
                    .onEnded { value in
                        offset = CGSize.zero
                    }
            )
    }
}

private extension View {
    func applySpringGesture() -> some View {
        modifier(SpringGesture())
    }
}

// Usage:
struct ContentView: View {
    var body: some View {
        VStack {
            Text("Drag me")
                .applySpringGesture()
        }
    }
}

#Preview {
    ContentView()
}

As we can see in the above example, we need an internal @State variable to keep track of offset.

Now, this can also be achieved by defining a custom View instead of ViewModifier . So, when to use custom views then?

If we take a look at SwiftUI's built-in API, containers such as HStack VStack are views whereas the styling API like padding .background(content:) are implemented as view modifiers.

So, whenever we are creating container views or creating views where defining its own type makes sence, we can use custom views instead of view modifiers.

For example, if we want to define a view that display's icon along with text:

import SwiftUI

public struct TextWithIcon: View {
    let icon: Image
    let text: String

    public init(
        icon: Image,
        text: String
    ) {
        self.icon = icon
        self.text = text
    }

    public var body: some View {
        HStack(alignment: .center, spacing: 4) {
            Text(text)
            icon
                .resizable()
                .renderingMode(.template)
                .frame(width: 16, height: 16)
        }
    }
}

// Usage:
struct ContentView: View {
    var body: some View {
        VStack {
            TextWithIcon(icon: Image(systemName: "swift"), text: "Hello Swift!")
        }
    }
}

#Preview {
    ContentView()
}

I hope this examples were helpful and clears the confusion of when to use view extensions, view modifiers and custom views in SwiftUI

Let me know if you found this helpful. Feel free to tweet me on Twitter if you have any additional tips or feedback.

Thanks

In this blog, I want to talk about how we can make the code we write using the platform's built-in API more straightforward and concise. We often become accustomed to using the platform's native API in a certain way because that's how it's explained in the documentation or tutorials. As a result, we might not realize whether our code is clear or not because it seems obvious to us.

Let's take a look at an example of SwiftUI code below:

var body: some View {
        VStack {
            // some content
        }
        .frame(maxWidth: .infinity)
    }

Can you determine the exact behavior of .frame(maxWidth: .infinity) if you're not familiar with SwiftUI? Does it expand to match the width of the parent container? Will it also change the parent container's width, causing it to expand?

Now, what about the code below:

var body: some View {
        VStack {
            // some content
        }
        .fillMaxWidth()
    }

Isn't .fillMaxWidth() more concise compared to the previous code? The initial code might not be confusing for an iOS developer, but it can be for someone coming from a different platform. I realized this when I was working on both Android and iOS apps, building UI in Jetpack Compose and SwiftUI, respectively. Drawing inspiration from Jetpack Compose, I created syntactic sugar extensions for SwiftUI View. This not only expresses the intent clearly but also reduces verbosity.

import SwiftUI

public extension View {

    func fillMaxSize(alignment: Alignment = .center) -> some View {
        frame(maxWidth: .infinity, maxHeight: .infinity, alignment: alignment)
    }

    func fillMaxWidth(alignment: Alignment = .center) -> some View {
        frame(maxWidth: .infinity, alignment: alignment)
    }

    func fillMaxHeight(alignment: Alignment = .center) -> some View {
        frame(maxHeight: .infinity, alignment: alignment)
    }
}

You can find the extension file with additional extensions here

I hope this example helps you look for areas where you can improve the code for more clarity. Looking at other platforms and frameworks also helps us gain a different perspective and draw inspiration from them.

Let me know if you found this helpful. Feel free to tweet me on Twitter if you have any additional tips or feedback.

Thanks

During the review, reviewers need clear context about the changes being reviewed. Unclear information can lead to back-and-forth discussions, causing delays and unnecessary context switching, ultimately impacting team velocity.

To ensure that contributors provide sufficient information about the changes to be reviewed, it's ideal to use a standard pull request template that prompts them for the necessary details.

Both GitHub and GitLab supports pull request templates. The details can be found at the following links respectively:

• GitHub

• GitLab

Based on what suits your team needs and technology, various check lists and contextual questions can be added to the PR templates for the contributor.

Here is one such sample of the PR template:

<! -- Remove sections that are not relevant to PR --> 
## 🎯 Description, Motivation and Context

## 🔗 Link to the resources (design, issue/feature ticket)

## ✅ How has this been tested?

## 📷/🎥 Screenshots:

## ☑️ Checklist:
You have to check all boxes before merging

[ ] Updated the PR name to follow our PR naming guidelines
[ ] Wrote unit tests and/or ensured the tests suite is passing
[ ] Checked linter on local.
[ ] If needed I updated documentation.

When working on UI: 
[ ] I checked and implemented accessibility (minimum Dynamic Text and VoiceOver)
[ ] I verified the UI on smaller devices
[ ] I verified the UI on devices with notch
[ ] I verified the UI on orientation changes

## 🚉 Which modules have been affected?
<! -- In case of Monorepo --> 
[ ] Core
[ ] UIKit
[ ] Module 1
[ ] Module 2
[ ] CI configuration

## 🧐 Any special note?

The team can continually adjust this template to fit their needs better. They can remove sections that aren't very helpful and add sections that focus on the details important for the review.

There are various benefits of using a pull request template:

1. Standardisation: Pull request templates provide a standardised format for creating pull requests. This consistency ensures that essential information, such as the purpose of the changes, related issues, testing steps, and any necessary context, is included with each pull request. Standardization reduces confusion and ensures that contributors provide the necessary details for efficient code review.

2. Clarity and Context: It helps reviewers understand the changes being proposed and provides them with the necessary context to provide valuable feedback.

3. Efficiency: Templates prompts the contributors to provide essential information upfront. This reduces the back-and-forth communication between contributors and reviewers and speeds up the review process.

4. Saves CI Cost: Many teams use CI integration, which kicks off when a pull request is created. This ensures that all workflow steps pass, such as lint checks and running test suites. If, for example, a lint check fails, it wastes CI credits/build time and adds unnecessary costs to the company. A checklist for contributors ensures they validate all necessary steps before creating pull requests, preventing oversights.

Here are few more resources for the templates:
https://github.com/devspace/awesome-github-templates?tab=readme-ov-file

https://github.com/TalAter/open-source-templates?tab=readme-ov-file

https://github.com/stevemao/github-issue-templates

Let me know if you found this helpful. Feel free to tweet me on Twitter if you have any additional tips or feedback.

Thanks

There are various solutions which you might have come across such as:

var isRunningTests: Bool {
    return ProcessInfo.processInfo.environment["XCTestConfigurationFilePath"] != nil
}

// Usage
if isRunningTests {
} else {
}

Or setting your own environment variable for the test scheme/configuration and check it as below:

var isRunningTests: Bool {
    ProcessInfo.processInfo.environment["isRunningTest"] != nil 
}

While these solutions work fine for unit tests when running tests from Xcode (⌘+ U), it does not work when running tests from command line for a swift package using following command: swift test

Solution:

While running tests from the command line, the name of the process that is getting executed is xctest . So, we can check if the current process is running tests as follows:

var isRunningTests: Bool {
    ProcessInfo.processInfo.processName == "xctest"
}

Let me know if you found this helpful. Feel free to tweet me on Twitter if you have any additional tips or feedback.

Thanks

Package.swift
README.md
.gitignore
Sources/
Sources/SamplePackage/main.swift
Tests/
Tests/LinuxMain.swift
Tests/SamplePackageTests/
Tests/SamplePackageTests/SamplePackageTests.swift
Tests/SamplePackageTests/XCTestManifests.swift

The test target and the basic scaffolding for it were available on the package creation.

With the recent changes to simplify the templating of the package --type , test target is only added to the package --type library and not to --type tool and --type executable.

tool is the newly added type that creates the package of type executable with the dependency for SwiftArgumentParser already added to the package.

The new file structure looks as follows:

// --type executable
./executable
./executable/.gitignore
./executable/Package.swift
./executable/Sources
./executable/Sources/executable.swift

// --type tool
./tool
./tool/.gitignore
./tool/Package.swift
./tool/Sources
./tool/Sources/tool.swift

// --type empty
./empty
./empty/Package.swift

// --type library
./library
./library/Tests
./library/Tests/libraryTests
./library/Tests/libraryTests/libraryTests.swift
./library/.gitignore
./library/Package.swift
./library/Sources
./library/Sources/library
./library/Sources/library/library.swift

You can find more details about the change in this PR.

Now, if you want to add the test target to the package of --type tool or --type executable with newer tool-chain of Swift 5.9.0, you can follow these steps:

1. Create the package:

    $ mkdir SamplePackage
    $ cd SamplePackage
    $ swift package init --type executable
   

    Creating executable package: SamplePackage
    Creating Package.swift
    Creating .gitignore
    Creating Sources/
    Creating Sources/main.swift
   

2. Open Package.swift. It should look like this:

    // swift-tools-version: 5.9
    // The swift-tools-version declares the minimum version of Swift required to build this package.
   
    import PackageDescription
   
    let package = Package(
        name: "SamplePackage",
        targets: [
            // Targets are the basic building blocks of a package, defining a module or a test suite.
            // Targets can depend on other targets in this package and products from dependencies.
            .executableTarget(
                name: "SamplePackage"),
        ]
    )
   

3. Update Package.swift as below:

    // swift-tools-version: 5.9
    // The swift-tools-version declares the minimum version of Swift required to build this package.
   
    import PackageDescription
   
    let package = Package(
        name: "SamplePackage",
        targets: [
            // Targets are the basic building blocks of a package, defining a module or a test suite.
            // Targets can depend on other targets in this package and products from dependencies.
            .executableTarget(
                name: "SamplePackage",
                path: "Sources"
            ),
            .testTarget(
                name: "SamplePackageTests",
                dependencies: ["SamplePackage"],
                path: "Tests"
            )
        ]
    )
   

   Add .testTarget to the array of targets and add the main target SamplePackage to its dependencies list. Also, add the path to the Tests folder.

4. Add a sample test file with @testable import <main module> to validate that the tests can resolve the main module.

   Example test file:

    import XCTest
    @testable import SamplePackage
   
    class ExampleTests: XCTestCase {
        func testExample() {
   
        }
    }
   

   The updated file structure should look as below:

    SamplePackage
    SamplePackage/.gitignore
    SamplePackage/Package.swift
    SamplePackage/Sources
    SamplePackage/Sources/main.swift
    SamplePackage/Tests/ExampleTests.swift
   

5. Validate if tests are running successfully via Xcode ⌘ + U and via the command line swift test

Let me know if you found this helpful. Feel free to tweet me on Twitter if you have any additional tips or feedback.

Thanks.

For developers who are starting out iOS development and yet to explore all the features of Xcode, this article is for you.

Xcode Code Snippet Library is accessible from the second tab beside the Object Library from where we grab all the UI components to drag and drop on Storyboard.

It already has some pre-defined code snippets which you can simply drag and drop on your source code and use it by editing as per your needs. You can search for available snippets from the Filter search bar available at the bottom of the library.

For e.g You can use a predefined snippet for swift for statement from the library as shown below.

predefined code snippet from library

Pretty hand right? But it is not just limited to predefined snippets available in the library. You can define your own code snippet and save it inside this library.

For e.g the most used snippets we might need are table view delegate methods. Let us see how we can add them to a library:

Adding custom code snippet to Xcode snippet library
Edit descriptionscreencast-o-matic.com

As seen in above video, you can simply drag and drop the snippet on Xcode Code Snippet Library and it will prompt a window to add a name for your snippet and there you go. You created your own custom snippet to reuse later.

Wait! There is more to it :] Did you notice there were few other fields when you gave a name for your code snippets?

Double click on the snippet you just created and go to edit mode. You will see the window same as above screenshot. Here you can add more information like the summary, platform(ios, macOS, etc), Completion Shortcut and Completion Scopes.

Completion Shortcut:

This will help you to autocomplete your code snippet without the need of drag and drop from the library. Completion Scopes define where the completion shortcut will work. Let us see this in action based on values I have set as per above screenshot.

snippet auto-completion

As you can see, I defined the completion shortcut within Class Implementations Scope hence it is not available at Top Level scope but can be easily accessed at the class level.

If you find this useful, share with other fellow developers and spread the knowledge 🙂

Happy Coding!

Almost everyone in tech might be familiar with this term IoT (Internet of Things) which is the talk of the town from past few years.

IoT is considered as the future and all most all tech companies are embracing it and providing different solutions using it. If I say it in a better way, few companies are actually working on providing usable solutions for IoT both in terms of hardware and software and rest of the companies are trying to be the part of the race by projecting as IoT application provider which is the client interface part of the IoT hardware, same as any other business application. Which is fine, I am not against that as a user-facing interface is also necessary to connect with IoT hardware and provide necessary info and take actions. But, IoT applications are not the heart of the IoT solutions.

Now, what am I trying to express by the title of this blog? Let me try to explain what I feel with context to various case studies and IoT solution articles I come across every day on LinkedIn and almost every tech blogs.

I would like to take as an example one particular area for which IoT solutions are proposed. That is: IoT is the Future of Farming.

It is definitely the future of farming, I am not against that but I am saddened with the way IoT solutions are provided and I don’t see a way in which farmers of a developing country or an under-developed country can actually use it in near future. And these solutions are actually needed to be applied for them to cut down the cost. I will take an example of India over here in this article to see if it is applicable for our farmers.

Let me list down few points out of one of the IoT solutions available in the market:

The IoT platform can help you:

• Easily collect and manage the explosion of data from sensors, cloud services such as weather or maps, connected equipment and existing systems

• Quickly build and bring to market new innovative IoT applications at 10 times the speed of other approaches with our rapid application development environment and drag and drop mashup builder

• Leverage big data and analytics to provide new insights and recommendations to aid in better decision-making

• Enable farmers to easily visualize data and take action on insights and recommendations

Read the last point of the above IoT solution. As an IoT solution provider company what will be the user interface you are going to provide for the last part? Mostly it will be a mobile application or a web interface.

Now, let us analyze whether Indian farmers can actually use it?

• Average monthly income of India farmer is 6400 INR = 97 USD approx.

• Most of the farmers are illiterate.

• Suicide rates of farmers are increasing due to difficulties in earning a daily wage to feed their families.

Can they afford IoT sensors? Can they buy a smartphone to analyze data? NO!

The real life situation is rich are getting richer and poor are getting poorer. Unless this kind of IoT solutions are not addressed at the level where the poor can benefit from it, it just stays as a tool for a richer audience and luxury homes being automated daily.

I am not writing this to rant about IoT solutions or IoT solution provider companies. I am just trying to express what I see as a real problem that needs to be solved and the better way in which we can think of making IoT solutions affordable and usable for those who can actually benefit from it and improve their lives.

So, what can be the solution for it? I also don’t know the concrete answer to it but it is something we can all collectively think of to start addressing the real life situation where IoT can be useful.

Just when I was researching for any affordable solutions available for farmers, I can across this one which actually connects with any device:

India's Rural Farmers Struggle to Read and Write. Here's How "AgriApps" Might Change That.
*India has the highest adult illiteracy rate in the world. According to the latest report published by UNESCO, there are…*www.good.is

This might resolve the problem but not fully. We need more and more alternatives to affordable solution like this.

Can the Government team up with tech companies and along with smart city plans focus on providing smart farmer schemes also?

If Government agrees to spend for integrating the hardware and sensors for IoT solution to farmers, how can we design the visual part of it?

Can we use digital billboard which is common between say 10 farms which display information from those 10 farms iteratively where a farmer can read in their language?

Since farmers cannot afford smartphones and are even not literate, can we feed the analyzed data to a loud speaker which announces the state of crops, moisture, weather etc? Again this can be common between 10 farms to reduce cost and information can be broadcasted turn by turn.

Can we get rid of visual displays and smartphone connectivity and just use some simple color-coded indication based on which farmer can take action? Has anyone used Pureit Water filter? It indicates to change filter cartridge with a red dot after filtering 1500 liters of water.

I am not sure whether these can be feasible solutions or not but we definitely need to come up with such affordable alternatives and think about broader audience in terms of providing solutions.

Are you an IoT solution provider company? Did any affordable solution struck in your mind while reading this? Then please comment and share your views. Recommend and share this article if you feel it useful and think that it is important to get collective views. Let us all think of reaching a broader audience and provide affordable solutions to those who can benefit from it. I hope that government also teams up to sponsor IoT solutions for farmers in one of their schemes then the rest is on us regarding how to project to content in a farmer-friendly manner.

So, what do I mean here by educating your client? I am trying to stress upon the situation where generally the outcome is simply YES/NO from the either side i.e either you agree with a client or say no OR either client agrees/disagree with you and there is no further engagement to get into a deal.

How can we improve this situation and make it more collaborative approach?

First, let us try to understand the impact of always saying YES to a client.

Most new businesses try to satisfy their client as much as possible and try to get a deal by saying YES to everything that client demands: low budget, tech stack, iterations, design, etc.

This can be harmful to your business, your team and for a client as well in the longer term as follows:

• Agreeing to low budget which is not affordable for your business results in burning hole in your pocket, which will result in allocating affordable junior developers for client’s project or you will tend to keep that project in low priority as soon as you get a good deal from another client where you will try to allocate experience developers. This will eventually affect the quality of your client’s project with a lower budget and result in bad impression for your business. The point is to always give the best quality to a client and not to overcommit or agree to everything which is out of your reach.

• If you agree to develop using tech stack which is not your team’s skill set, you are again putting the project at hand to risk and eventually spoiling relation with your client if you can’t deliver in what you agreed upon. Always know your strength and take up the task which you can properly execute.

• Saying YES to impossible deadlines. This will put your team to stress and affect your company’s culture and the environment in longer run eventually resulting in lower quality and efficiency from the team due to burnouts.

• Allowing a client to override your design teams proposal or your developer’s proposal without reason. Your client can be both technical/non-technical in terms of service he is getting from you, but simply saying yes to what client asks for will demoralize your team members for their creativeness in terms of design or for proposing the right solution in terms of development. It is always advisable to allow your team to be a part of a discussion.

Allowing your team members to put their point forward is more important then concluding who is right or who is wrong.

These are just some of the examples where business tends to simply nod to what client asks for. This is really not advisable and can be risky to both your business and client in a longer run.

Does it mean you simply say no when a client asks something which is not feasible on your side due to whatever reason? No, you should always try to explain and discuss what is feasible and what is not in a constructive way.

Agree, that there are some situation in which you analyze a particular client as a red flag and not fit for long term association with you when you tend to simply close the deal by saying NO. But, in most of the situation things can be discussed and there can be a win-win situation for both the parties.

Here are some of the ways in which you can replace a NO with a more constructive approach:

• Understand that a client is not always familiar with the technologies or services you are offering and that is the reason that client has come to you in request of your service. So, try to explain things in which client can understand in a realistic way instead of using jargons.

• If you give a quotation which a client cannot digest, try to break down your quotation feature wise which can show a clear picture to a client. Show them feature wise efforts in terms in terms of hours/days. Explain to them why your hourly rate is what it is due to the quality or the way you offer your service which justifies your rate.

• When a design or logo is rejected, allow your design team to explain the aspects and thinking behind why they proposed it that way, this will allow client to have a more clear picture of the design thinking that went into the design that was proposed and if they don’t align with that, they will be open to provide their thinking into it resulting in a collaborative outcome.

• Allow your developer to explain the standard way in which things need to be implemented to the client. For e.g it is a common situation in Mobile application development where the client expects to clone behavior of one platform to other even in terms of design but it may not be the standard way proposed by the platform and also their user will not be familiar with it. In this situation, it is always advisable to allow your expert developers to propose the standard guidelines in which things need to be developed.

• If a client is technical and asks you to implement X framework instead of Y, always know the why behind it. It will help both the parties to understand which framework is advisable for your project. It often happens that people just go with the trend to use the latest tech and frameworks even if they don’t need it, resulting in complexing the situation unnecessarily. So, you should always know the why behind using the framework and discuss the same with a client if they have some different solutions.

Even if you don’t get into a deal with a client, having a discussion with them and coming to a collaborative decision will allow both the parties to communicate in future if they close on a sweet note.

What are your experiences and how do you handle such situation? Comment your experiences about the same which can be helpful to others dealing with the similar situations.

Product Flavors is a great way to generate multiple APK with different configurations or flavors(demo/full/staging/production/uat) of your application.

Listing down few scenarios where Product Flavors can be useful:

1. Generate APK with different package name

The most common scenario where Product Flavors can be useful is to maintain different package name for your Staging, UAT and Production builds so that you can install those builds on a single device without overriding different environment builds.

There are two ways to do it either you can set applicationId or you can set applicationIdSuffix. The ideal way would be to use applicationIdSuffix and define applicationId in the defaultConfig block in your build.gradle file

Refer to image below where I have defined two flavors (staging and production) for my application and have applied applicationIdSuffix for staging configuration. I have not set applicationIdSuffix for production configuration as I don’t want my live app on store to have package name ending with .production

As soon as you add productFlavors in your app’s build.gradle file. You will be able to select Build Variants related to productFlavor you defined as observed in image below.

2. Defining different HOST/API URL

You can define different HOST url using productFlavors when you have separate url pointing to staging/dev/uat/product environments.

You can then access this baseUrl in your ServiceGenerator class using BuildConfig.HOST.

3. Defining manifestPlaceholders

Refer to below image where I have applied different values for onesignal_app_id and onesignal_google_project_number for staging and production environment.

4. Applying different app name.

In point 1. we learned how to apply different package name to install different variants of app in same device but we didn’t change the app name which will confuse the user in determining which app is production version and which app is dev/staging version.

We can apply different name based on flavors as below:

These are some of the most common use cases where productFlavors can be useful. Product Flavors is very powerful and you can customize much more than these examples.

You can define all the properties used under defaultConfig for configuration of productFlavors as defaultConfig belongs to ProductFlavor class.

Happy coding fellow developers. If you find this article helpful feel free to spread the info by hitting ♥ below.