Category Archives: iOS App Development

VoIP Call Image

CallKit integration for VoIP Apps

Most of us by now are accustomed to using the services of a third-party provider to make VoIP calls over desktops, laptops, and smartphones. But making VoIP over Native iOS apps was never a convenient task. In-fact Apple has completely restricted the use of VoIP push for any kind of background processing from iOS-13. Earlier developers were using VoIP push for making call (audio/video) notifications or some other processing in the background. Apple took this decision to avoid the overbearing process that was happening in the background. It was not only leading to disproportionately high consumption of resources but also a significant drain of battery capacity.

A typical VoIP call usually comes as a notification on one’s screen, and in order to receive it, the user needs to slide the notification and also type a passcode to receive, if locked. Burdensome! Isn’t it? Especially if compared to how a native app eases the same experience.

The solution to this comes with CallKit, which is a framework that is capable of elevating your third party VoIP app experience to a very intuitive one. You get the same rich, full- screen native call UI to accept and attend the calls. Once a call is accepted you also get a “Callback “option to initiate the same function (WebRTC) which you have used earlier. You can also set custom ringtones for your app that would be different from native calls ringtone.

VoIP Image1

VoIP Image2

Besides, if you are on a call in your app and you start getting native calls, you will be able to hold and swap the calls. It could be an audio call, facetime call or even another VoIP call. Even your call history will be stored in the call directory (missed, received, dialed calls and add in favorites). You can also make the call from Siri, Bluetooth and access the “Do not disturb” functionality.

VoIP Artitecture

……………………………………………………………………………………………………

The views and opinions expressed in this article are those of the author. To know more about our company, please click on Mindfire Solutions.  For over 20+ years now, we have been the preferred Software Development Partner of over 1000+ Small and Medium-sized enterprises across the globe.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Swift 5 Vs ObjC

Is Swift the Objective Choice now?

‘Swift Vs Objective-C’– It is one of the first Google searches every iOS developer does before beginning their journey into the world of app development. At a broader level, choosing between Objective-C and Swift is also one of the fundamental and crucial decisions every business makes before beginning any iOS app development work.

So if the question is Swift or Objective-C? The answer cannot be in binary. If you have an existing application already written in Objective-C, then you can weigh the benefits of switching over to Swift vs sticking to Objective-C. However, if you are planning a new app, then Swift should be your default choice.

Why so? Well, read on to know…

……………………………………………………………………………………………………

The Story so far

Apple launched a new programming language called Swift in WWDC in October 2014. It came as a surprise to every developer as it was intended to replace Objective-C as the main programming language on Apple’s platforms, which by all means was stable, proven and had been around for more than two decades, powering millions of apps.

The goal was far-sighted. Swift was designed to be safer, faster, and easier to maintain. Though initially built for Apple platforms, it was aimed to be able to support all platforms. Before becoming Open Source, Swift was designed ground up by Apple using decades of Objective-C experience adding a modern touch derived from the latest programming trends and good practices. It was designed to have all the goodness of a modern-day programming language. Though a descendant of Objective-C, it is fundamentally different in terms of design, syntax, programming style and memory management.

But replacing a decades’ long programming language with a new one cannot be an overnight affair. There were thousands of libraries and hundreds of frameworks already written and working with Objective-C, as they were supposed to. Rewriting them using an infant language did not seem logical. Thus, Objective-C runtime continues to access Apple platform frameworks like UIKit, WatchKit, and AppKit. And Swift has the capability to interface seamlessly and work on top of it.

From the very beginning, Swift is fully compatible with Objective-C, as it should be. Both languages can still co-exist on all Apple platforms. And Apple isn’t likely to change this in the foreseeable future unless it has any strong reason to do that.

Support for interactive programming using Playground enables developers to test their idea live without building and running applications.

In terms of programming capabilities and flexibility, Swift has a lot to offer. Its functional programming style, and strongly typed language makes it impossible to have run time crashes resulting from out-of-bound or type-related issues. It has features like closures, tuples, generics, Structs and enums supporting methods, extensions and protocols, computed properties, powerful extensions, and the list just goes on…

Design-wise factors such as safety, readability, code size, less error-prone, efficient and fast iteration over collections, and other platform support make Swift fundamentally better than Objective-C.

……………………………………………………………………………………………………

Why Objective-C then?

Despite being so much powerful, Swift lacked just one thing that triggered Swift vs Objective-C debate, and that is ‘Maturity’. In the earlier years, deciding between Swift and Objective-C was like choosing between a fledgling with a lot of promise and a veteran with proven credentials.

Those who had rushed to develop production apps using Swift version 1 & 2, had to refactor the whole codebase, or just rewrite it again. It wasn’t matured, evolving rapidly, and syntaxes were completely changing in the early iterations. Hence, it was difficult to maintain Swift Apps compared to Objective-C, which was matured, trusted and possessed a huge developer base.

However, after Swift3, syntaxes became relatively stable and some minor refactoring that was needed was taken care of by the Xcode itself. And then Swift4 seemed to be more stable in terms of design and syntaxes, but, it still lacked ABI stability. Then came Swift 5.

 ……………………………………………………………………………………………………

What makes Swift 5 different?

So far, every version of Swift has been better than earlier. But what makes Swift5 so special is ABI stability.

Starting with version 4.2, Swift codes from one version have been compatible with another. However, the application binary, which can be considered as the machine level code for the sake of this argument, wasn’t compatible with that from a different version of Swift. That is, Swift wasn’t ABI stable until recently before version 5 was launched.

With Swift now being ABI stable for all Apple platforms like iOS, WatchOS, macOS and tvOS, all future versions of Swift including Swift5 will be compatible with each other at the binary level. True that Swift will continue to evolve in future releases, but the application written in the current version of Swift will no longer need to be refactored or rewritten to be able to support future versions of OS. In fact, libraries written now will seamlessly coexist and communicate at the binary level with code written in future versions of Swift and vice versa. And the reduction in app size is the immediate benefit it provides to the users now.

……………………………………………………………………………………………………

Conclusion

True Objective-C is here to stay. There are millions of applications already running using this. But, it isn’t getting any major updates, most of the updates are just to make it compatible with Swift. As a language, Swift is way superior. And above all, developers with expertise in Objective-C and practicing it will dwindle in years to come.

……………………………………………………………………………………………………

If you have any queries in this field, talk to Mindfire Solutions. For over 20+ years now, we have been the preferred Software Development Partner of over 1000+ Small and Medium-sized enterprises across the globe.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Banner Universal link

Adding a Universal link to iOS Apps- The Challenge & the Hidden Solution

In this blog, I am going to explain how to, without considerable effort, add Universal link and Deep linking capabilities to an iOS app 

We are going to cover this in 3 sections

  • Understanding deep link, URL scheme, and Universal link
  • The issues with a universal link and the difficulty in incorporating it
  • A nice workaround to get rid of the complexity of universal links.

If you are aware of the universal link and the challenges in having it up and running, feel free to jump to the 3rd section straight away.

Understanding deep link, URL scheme, and Universal link

– As opposed to a common belief, a URL scheme is not the same as a deep link.

Then what exactly is a deep link?

Well, the term “deep link” is the route to a specific spot on a website or a native app. So, for a mobile app, “deep link” is a link that contains all the information required to navigate the user deep into a section of the app instead of just launching the app.

What is a URL scheme and how it works?

A URL scheme can be treated as a specially designed URL just to open a particular app.
For instance, any iOS app can open WhatsApp with “WhatsApp://” URI using the URL scheme. This is possible because WhatsApp has registered itself with the app store with “WhatsApp” as a URL scheme.

However, to send a “Hello” to a particular number in Whatsapp, the URI needs to be like “WhatsApp://send?phone=(actual phone number)&text=Hello”. This, in turn, will open chat for the given number with the supplied text pre-filled. This is an example of a deep link in action.

So, what exactly is a Universal link? and why at all so we need it?

The URL scheme works just fine as long as the app is installed on the user’s phone. In the above example for instance, if WhatsApp is not available, then “whatsapp://” URI will just not work and so as the deep link to send a message to a user.

In this case, a nice solution would have been to

  • Send the user to the website on the mobile browser, then, either redirect to the app, if available or show a prompt to download it from the app store if not.
  • A more elegant way is to directly open the app, if available on phone, without redirecting through the website or in case the app is not installed, open the website with a prompt to get it downloaded from the store. This is exactly how the universal link works.

The same universal link can be used to open the Android app as well.

……………………………………………………………………………………………………

The issues with Universal link and the difficulty in incorporating it.

Is Universal link difficult to incorporate?

The elegance and ease that universal link provides to your users come at the cost of having to deal with the complexity of implementing it.

Implementation of a universal link requires a guided approach. If you want to learn about the process in details, click here.

Unfortunately, there are a whole bunch of issues and bugs you will encounter after implementing it. As it deals with iOS, Android and the Web, there needs to be a great deal of coordination and support between them all.

Even for iOS itself, there are multiple ways and factors which are likely to affect how a user interacts with the link. Measures have to be taken to address them. To name a few, you are going to need to support previous versions of iOS, it should be possible for the link to open in SafariViewController for some apps like Skype and Facebook, the user may get redirected to the link instead of reaching there by clicking it, there may be a tracking need on the link. Given the default behavior of the universal link, which is to either open the app, if available or the web if not, it is going to break at some point for one of the above cases.

Unless you are hell-bent on having the universal link with all its properties and willing to put all the resources and time it needs to address the accompanying issues, you should consider the alternate, and the more basic solution available, to get the task done.

……………………………………………………………………………………………………

So, what is the hidden solution that can be used as a workaround?

The idea here is that the web URL, the actual HTTP link of the website, will work as a universal link.

But, how?

For Android, it’s easier to connect an HTTP link to the app, with the assumption that the user will be taken to your app on tapping the link if it’s available or fallback to the website if not. At most, you will need to verify the domain ownership. More on this is available here.

For iOS, unfortunately, you can’t use an HTTP link i.e. link to a real website to open the app without using Universal link.

Smart Banners in iOS is the workaround we have been looking for.

Safari has a “Smart App Banner” feature to promote app from the website. Your website can include a meta tag containing the app id of the app, and the Safari mobile browser will show a smart banner. On being tapped, it will open the app if it’s installed or take the user to the app store if the app is not there in the phone.

Here is how smart banner looks for the LinkedIn website.

 

LinkedIn Image1

When the app is not installed on the phone.

 

When the app is installed

 

The meta tag format is :
<meta name=”apple-itunes-app” content=”app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL”>

Both “affiliate-data” and “app-argument” are optional.

For more information on adding a smart banner to your app, click here.

……………………………………………………………………………………………………

The views and opinions expressed in this article are those of the author.
To know more about our company, please click on Mindfire Solutions. 

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Face ID vs Touch ID

Face ID vs Touch ID

In 2013, Apple introduced iPhone 5S with a new finger print recognition system –Touch ID. Apple subsequently made Touch ID available on iPad Air 2 in 2015. Hence, all iPhone launched model since 2013 and all iPad models launched since 2015 feature Touch ID. Touch ID is designed to scan, read, and recognize fingerprint through a fingerprint sensor embedded into the Home button. While using his iPhone or iPad, a user can take advantage of Touch ID to unlock his device, authenticate Apple Pay payments, and purchase digital content simply by touching the home button. Continue reading Face ID vs Touch ID

Spread the love
  • 4
  • 2
  •  
  •  
  •  
  • 1
  •  
  •  
  •  
    7
    Shares