Vikas Salian

I have worked as a developer for five plus years, with experience that includes working on ARKit. I have developed six applications, and have been responsible for developing and deploying those applications to the App Store. I have tackled challenging tasks, including the integration of CICD and creating multiple schema applications using a single code base. I have also created a private repository using a private CocoaPod, and have worked with ARKit to create a virtual experience.

What approach would you take to handle asynchronous task in Swift? So asynchronous tasks are basically used to deploy anything to the background thread. There is something called GCD, Grand Central Dispatch Queue. So we can use basically DispatchQueue.global and set the priority which we want to set anything to the background thread. Or if you want to update some UI stuff, we can use DispatchQueue.main.async. But when we use asynchronous threads, we should be aware of the closure which can capture self.

Can you describe the scenario where you will use code data for persistent storage instead of user defaults? So code data is basically a table or form format. For example, if you want to save offline storage, like we have an ecommerce website application, and we want to store the products or some search queries, whatever the user has been done. And it's a big amount of data. So we will basically store it in Core Data instead of user defaults because user defaults are generally useful for storing small chunks of data that are not user sensitive. So in Core Data, we can store large forms of data like user search queries, recent histories, or something in that way.

An app requires a new feature for secure financial transaction. How will you design and implement this feature while ensuring high security? NAP requires a new feature for secure financial transaction. How will you design and implement this feature while ensuring high security? First, I will investigate it. My question is, are we developing it from scratch or integrating a third-party library like Razorpay? If we are integrating a third-party library like Razorpay, most of the security implementation is handled by them. However, if we are handling security in-house, we will need to check. Our HTTP request is secure. Next, we will develop the modules with a clean architecture. This includes creating a repository, use case, and injecting dependencies in the ViewModel. This will be the basic architecture for the application. We can also segregate the financial transaction module separately, so it is not directly dependent on the UI. For security purposes, we can have binary vulnerability checks done by the security department and try to minimize sharing important security information. For example, user tokens or authentication passwords should be stored in a secured keychain instead of being stored normally.

How do you ensure thread safety when reading and writing data to a shared resource in a multithreaded environment? You ensure thread safety when reading and writing data to a shared resource in a multi-threaded iOS app. So, basically, we use closures. We will, basically, make it a weak self, so we don't capture the object. And, we have to look into it. Like, for example, one thread is reading and one thread is writing. So, we have to use dispatch barriers. A dispatch barrier can prevent one thread from updating while another thread is accessing, or vice versa. We can use dispatch barriers whenever the update process is on, so that the process goes in a synchronous manner and there is no deadlock situation, and the app doesn't crash.

When deciding whether to use a storyboard versus including an interface in code for an iOS app, it depends on several factors. Whenever we're faced with this highly debatable question, it's essential to consider our preferences and the specific requirements of our project. Using a storyboard is quite easy for understanding the UI and getting familiar with the layout. It creates a NIB file, which allows us to see the user interface layout. However, when it comes to reusing views in multiple locations or achieving high customizability, code becomes more beneficial. With code, we have modularity control, making it easier to reuse views. In contrast, using a storyboard to reuse a view can be a lengthy process. We have to create a separate new file and include that class, which is not as straightforward as using code. For this reason, code is often preferred for usability purposes, as it's easier to reuse views.

Slow code snippet that meant to load images asynchronously in iOS application. There seems to be an issue with memory management. Can you spot it and suggest a solution? Okay. So this is a method for Image Loader, which So basically has a URL and a completional block. Okay. So, Dispatchqe.global. Async which tries to get the data from the URL. Okay. There's no issue still now. Then we have a Image, UI Image. And then, we get the data. And over here is again like Image. We stand for the completion. And Okay. Explain the potential memory management problem, and how will you address? Okay. So there are 2 completion blocks over here, which can basically trap. So looking into it, the data part we are creating over here, it won't be ramped. URL maybe URL can be getting trapped over here. so URL is basically we are getting from the Function, there is most self. So quite confused over here. Function. We are getting it from the function. Right? Let's write data image main. Sync. We're just dispatching it to the main thread. Okay. And image part. So we can basically have, like, big to the self. So, we don't capture URL over here. And this Should basically, like, break the cycle because I feel the URL is basically getting captured from the Dispatch Global QR Sync. So making it a week may break a cycle.

Given this shift code snippet that applies a filter to an array integer, please identify the bug and explain how it might affect the functionality. 1, 2, 3, 4, 5. Okay. Symbol that applies a filter to an array. Please identify the bug and explain how it might affect the functionality. What do you think the output will be, and what will be the actual result if there's a bug? So we have 1 to 5 and we are filtering it with mod 2 where it is equal to 0. So, it will basically return the even number. Filtered. Okay. So this case doesn't handle for, like, zeros. And if we have a 0, it may crash over here. So we will basically have to, like, have a condition for 0 where the filter is like dollar 0 is basically equal to equal to 0. We shouldn't return it over there or else like normally we can do the operation over

Discuss my approach to apply SOLID principle in IS architecture, and it's important in the core base. So SOLID stands for Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Whenever we create a class, let's say a Printer class, it should not depend on, it should not implement, be responsible for doing downloading or uploading operations. For example, a class should be open for changes, but closed from being modified. We can achieve this by using an interface, and implementing it in the class. This way, the class is open for changes, but we shouldn't make any extra properties to do that. The L is for Liskov Substitution Principle, which means that whenever you have a Superview, you can basically replace it with a Subview. This is like an Interface Aggregation. Every method you create should be separated out to a protocol. This makes testing easier, and these dependency inversions. Instead of all your code being returned to a class or something, the dependency should be returned down into a protocol. This way, the implementation and part is being separated out. So testing and code reusability and maintainability get increased over time.

Your latest update has caused a 50% of 50% upload and increase reported by analytics. What will be the steps to diagnose and fix it? First, I will look into what libraries I have recently integrated, because libraries can increase the start time of the application. I will investigate those things. Then I will check if there are any network calls that are taking a long time to get the response. So we can check in the production apps if the network calls are making any changes. That way, we can check if we have integrated Firebase and check how much time it is taking. Then third, I will check if any logic was introduced in the AppDelegate file that is taking a long time to process stuff. So the application is getting stuck over there. Or we will check if anything is being called from a background thread, it can also cause a delay in app starts. I will check if my launch tab of the application is being slowed down and we will also check for memory leaks. If any memory leaks are causing the launch time to be increased, we can do it using the memory graph debugger or leak instruments.

In what scenario will you choose RxSwift or Combine? And how will you justify the choice? So, Apple introduced Combine for reactive programming, same as RxSwift. So, if your deployment target is lower than iOS 12, you will target RxSwift, because Combine can't support over that. And if you have flexibility in iOS deployment versions, you should go for Combine. Because Combine is Apple's priority framework. We will have more support and future support for Combine. Combine has multiple publishers like RxSwift. So, Combine will be a greater solution because it directly integrates with Swift 2 UIs. So, whenever the state changes, Combine has a direct sync to it. With Direct Swift, we would have to monitor changes and do it manually.

Explain your experience with g r gRPC framework and the advantages of using protocol buffer data format in client server communication for iOS apps. Okay. This is a good to have question answering. Won't affect this connection. so I haven't used with like gRPC Framework I don't actually have any idea about it, but for, like, client server communication, we use, REST APIs. but, like, advantages of using protocol buffer data, I don't know.