Building a large scale iOS application from scratch without any plan in place may have you end up with creating a complex application tied with an unwieldy overtime. Some developers are fortunate enough to find their answers online on sites like Stack Overflow and Hacking with Swift, etc. However, if the app is aimed at being multi-featured, there are only a handful of other apps that can be compared to your use case in terms of scale. The size of such a project file alone takes its toll on your machine, not to mention the build time and overall workload.

So, what’s the solution to this predicament? This is where you need to work smart. Don’t develop unnecessary components! When it comes to auxiliary components like a modal that can be used to add images or notes, a drop-down menu providing the user with various actions, a pop-up with a collection of options out of which you can have multiple selections or other similar components – it’s better to make them reusable. Multiple features of your application will use them so treat them as such by making them generic without any concern for a specific feature’s visual model. Here are a few examples depicting the use of such generic reusable components in example applications:

[rev_slider alias=”reusability-1″][/rev_slider]

Reusability in itself is a broad term and may mean something entirely different to different developers. In this article, reusability refers to a concept in application development in which, where possible, you design components that are reusable and customizable, thereby, future-proofing your code.

In order to make a reusable component whose bare-bones structure may be used across multiple apps as well as across multiple features within a single app, you have to map out and design the structure of your component before starting the actual implementation in such a way that if in the future, the need arises, you can customize the component further and add more options depending upon the particular use case.

Let’s take a look at an example of an app in which the user can upload the pre and post images of their room transformation. For this, a custom UIView called AttachmentsListView has been created. This can be used as a component in any controller. In this example app, AttachmentsListView is used in the following two ways:

[rev_slider alias=”reusability-“][/rev_slider]

1. Pre-transformation
   • Workflow: Clicking on the Add Image button opens up a pop-up modal. The user is required to upload images from the modal.
   • Implementation: For this purpose AttachmentsListView is embedded within this modal. To communicate between the modal and then calling the view controller, a delegate can be used.
2. Post-transformation
   • Workflow: Clicking on Add Attachment opens up a context-menu to choose from the relevant option.
   • Implementation: The custom view has been embedded in the screen so the user can directly add images or other files.

You might have observed that the scope of attachments has been extended from just allowing the images to be uploaded in pre-transformation section to allowing the user to upload all kinds of attachments such as DOCX, PDF, etc. for post-transformation. This is where the concept of reusability comes into play. All you have to do is add just another AttachmentsListView to allow uploading these files. And for this particular option, you can replace the text of the button from Add Image to Add Attachment by adding a simple check of supportedTypes.contains(.file)

For the context menu, AttachmentsListView contains a UICollectionView section. This collection view further contains two different types of cells:

1. One that contains a button which opens up a context menu with available upload options for the user to choose from. This can either be:
   • Open camera
   • Choose from Gallery
   • Choose from Files
2. The other which represents a thumbnail of the attachment

[gist id=”736ebd0d9a41576fe86b6960d9322a21″]

What we see above is the initialization of the function supportedTypes, and the values in this array are further specified in their relevant calling class.

[gist id=”789f3756df8321ce99c2d98b6552fd1e”]

In this example, the user can upload files only for the post-transformation section, hence reusing the context menu with various options as per the use case.

As the above example illustrates, the reusable component AttachmentsListView has been used in 3 similar yet slightly different ways in this one project. It’s not hard to imagine that another app may also need a view that allows users to upload images/files, so it can be reused there as well and can be further customized depending upon the particular use case. Want to dig into the code part? Click here to access the source files on GitHub.

While this solution may look pretty simple, but the fact is, it is important to be able to identify the basic structures that can be used over and over again. Doing so, will prevent the developers from entangling themselves in the web of endless possibilities of defining what components can go generic, and be specific in identifying these components. All major websites and apps across the world take advantage of this concept of reusability to save development time and effort and reduce redundancy in code as well. This not only ensures that their code is efficient but also decreases file sizes and build times overall by having premade components that can be reused throughout the app.

Serverless Applications and Serverless Computing are some of the terms that you will come across frequently when trying to choose from  various options being offered by cloud service providers like Amazon Web Services (AWS) and Microsoft Azure (Azure). The term serverless accompanied with the word application could be confusing, as it is contradictory to the conventional methods of developing and deploying applications. In this blogpost, we will attempt to explain what serverless applications are and what exciting benefits they bring to the world of cloud technologies.

Serverless applications are built using the services provided by cloud service providers like AWS or Azure, without having the developer to worry about the underlying infrastructure. The core of serverless applications is made from cloud-native services such as AWS Lambda or Azure Functions, which offer Functions as a Service (FaaS). These services provide the ability to write event driven code functions in any of the supported languages. The functions are executed automatically when the associated events are triggered, creating an automated chain of events which can range from an API being called, uploading a file to the cloud or even invoking other serverless functions.

Serverless is the fastest-growing cloud service model right now, with an annual growth rate of 75%.

Source: RightScale’s 2018 State of the Cloud report.

One might wonder what benefits serverless applications provide or why are they getting so much traction these days. The answer to that question is in the pricing model of all of these services which is based on the philosophy that you only have to pay for what you use. Let’s consider Lambda as an example, the price of using Lambda is primarily based on how many times a function is triggered along with some other factors like the function execution time and the resources it utilizes. In contrast to non serverless services that are charged by the number of hours the service was up for.

If a business or developer runs an application on an instance or virtual machine hosted by a service that charges by the hour, they would essentially get charged for the total uptime of the instance, irrespective of whether there are any users using the application or not. If the same application is deployed using serverless services, it will be available all the time, but the account will only be charged whenever an end-user makes a request or uses the application.

Building applications through serverless architecture can be very effective for use cases where you want an application that is always up and available, but does not have continuous and constant incoming requests. The application can have a large number of incoming requests at certain times and then have large periods of stagnation with little activity. Other than that, asynchronous or event based tasks like CI/CD pipelines, multimedia processing, and scheduled batch jobs are well suited for  serverless model. A couple of other benefits tied to adopting the serverless computing approach are mentioned in the figure below:

While serverless applications are bundled with various benefits, it is important to understand their core limitations that are often tied to the type use-cases and application models. From the pricing model of serverless services, it is pretty obvious that if the incoming events are large in number you would get charged more based on every input trigger. Services like Lambda or FaaS have  limitations such as the amount of available RAM and accessible disk space  being fixed for a Lambda function. Hosted functions also suffer from an issue known as Cold Starts, which means that every time a function has been dormant for a while it will take more time to spin up on the next request and thus cause a slight performance penalty. This issue can be minimized by using a runtime which suffers less from the cold-start penalty like Python or Node.js. It can also be minimized by reducing the overall function size.

Cloud computing also brings some limitations for serverless applications like vendor lock-in, where the switching cost to a different vendor is pretty high. If you are building a serverless application, you are committing to a specific cloud service provider and building your application around their infrastructure making switching across-platforms very difficult.

With all things considered, serverless is an interesting and in many cases a beneficial approach to building applications on the cloud efficiently in an agile manner, without worrying about managing the underlying infrastructure. It provides additional choices to solution architects while designing application architectures with minimal cost implications for their organizations.