All posts by Roohul Khan

Unsure if your Enterprise needs a Website or a Mobile App?

IT Outsourcing, Mobile App Development, Web Application DevelopmentRoohul Khan

The remark “There is an app for that” is so common nowadays and underlines the deep influence of mobile apps in our lives. But, when Apple went on to register a trademark for it, you knew it was more than that. 

So, you have decided to go digital and create an online identity for your business. But, you are stuck with the difficulty of choosing between a mobile app and a website. Eager to get a quick solution? Turns out, in most of the cases, both mobile app and website are not mutually exclusive but are complementary, with each serving a different purpose and target segment. So, there isn’t an answer that is universally correct. It depends on various different things.

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

App First

Some cases are better served with mobile apps, especially the ones that need frequent or repeated use. For instance, e-commerce, food ordering, social media, chat, news, travel, productivity-related applications, utility apps, real-time tracking like stock apps.

App Only

Then there are those which, because of their dependency on the underlying hardware, can only be served through mobile apps. For instance, home automation, alarm, games, navigation apps, mobile wallets, AR(Augmented Reality) & VR(Virtual Reality) apps and games.

Website or Mobile App?

For the sake of this article, the above two categories need not be considered, for the obvious reason that the mobile app seems to be the default choice for them. However, for categories that can be served equally well by both the mediums, there are certain inherent advantages of using either an app or a website. Let’s understand them from the perspectives of a user and a business.

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

User’s point of view, what really matters.

1. Convenience

Websites are convenient for informative and non-frequent use like finding details about a business, exploring a place, looking for services, R&D for projects, and yes, deciding the best app to download for a particular need. Basically, all the Google searches we do can be better served by a website. Mobile apps seem to be more convenient for activities that are performed more frequently. The initial hurdles of downloading and setting things up might seem daunting. But things ease out subsequently, and users get pulled into a more convenient, personalized, and engaging experience.

2. Data Consumption and Offline Mode

To use a mobile app one needs to download it first, an act pulls into the mobile resources that the app will need to function -images, icons, layout inbuilt, etc. Once done, there isn’t much left to download during consumption, which results in quicker loading and sometimes offline access too. In contrary to this, you can’t even load the website without an internet connection.

For mobile apps, during the offline mode, tasks can be queued up in batches and then be pushed to the server when online. Such a sophisticated way of dealing with the offline mode isn’t just possible in case of a website.

3. Performance

For CPU intensive tasks such as games, heavy graphics layouts, complex lists, mobile app scores way higher than a website for its close proximity to the device hardware.

4. Updates

Whether it’s an app or a website, it gets developed alongside. Hence the user expects updates. Pushing an update to the website is easy, you do it on the server-side and users get a brand new look and feel next time they check you out. If you can strategically manage the downtime, there is not much that bothers the user. On the other hand, the whole app needs to be downloaded all over again to get the update. Not to mention, the review process apps go through to be live in the app store which takes time.

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

Business’s point of view

1. Customer base – Existing & Potential

Initial acquisition cost is high for mobile apps. You need to get the user to download your app first, to be able to use it. In contrary to this, anyone can visit your website through any browser and from any device having a browser. People can even find your website through Google search. This opens up a lot of possibilities for your business. In short, you can serve both existing and potential customers through a website. Whereas, mobile apps can only serve the existing user base.

2. User Engagement

Re-engaging with users using rich and powerful notifications and getting meaningful insights through analytics is better done with mobile apps than websites.

3. Learning Curve and Cost of Development

Mobile apps are highly customizable. In terms of features and capabilities, they can do a whole lot of stuff that a website can’t do, thanks to the close hardware integration. This, combined with the tons of possible unique use cases, helps create an ever-increasing range of UI/UX and feature possibilities. Thus, you have a steep learning curve even if you need to build a basic app. In other words, there is no such thing called an ‘App builder’. Even if you can find one, chances are, it will let you create a basic HTML type webpage app or an app functioning as a container of your website. In that case, you are better off creating a responsive website instead. Not to mention the whole point of creating an app is to create a tool for your users and you want it to be fully customizable in the first place.

On the other hand, a single screen website with some basic viewable features can be made using website builders needing almost no technical skills. A few examples would include blogging sites, personal/resume type websites, a website showing just the details of your business. However, to create a customized and full-featured website, you need a lot of technical skills.

4. Multiple platform support

Because of the way they have been distributed around the globe, you can’t ignore any of the 2 major platforms of the mobile OS- iOS & Android. People in the US, Canada, Australia, and European nations prefer iOS, whereas, Android is the global leader in terms of market share. Apart from this, iOS users are generally high paying customers in any region. This essentially means, to get high ARPU(Average Revenue Per User) you need to support iOS and to get to the masses, you need to support Android.

Mobile OS preference across the world

 

 

 

 

 

 

 

 

(credit: https://deviceatlas.com/blog/android-v-ios-market-share)

Supporting 2 completely independent OS will result in higher development and maintenance costs. On the other hand, a single set of code will result in a website which works universally for every device with a browser.

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

Website vis-à-vis Mobile Apps! Can one replace the other?

No matter how tightly websites and apps are attached, they are uniquely placed with each serving a purpose different from the other. However, the matter of the fact is that they cannot replace each other. We might see things in the future that will bridge the gap between them both from the business and the user’s point of view. In fact, we already have things like Progressive Web Apps and tools like Flutter and React which are trying to bring websites and apps closer in terms of use and development.

Even Technologies like AR which is by far better served by mobile apps are finding their way to websites. By creating a new file type USDZ, Apple has made it possible for websites to enable users to try 3D virtual objects in their Physical space. This creates a compelling possibility for E-Commerce websites. Of course, for this to work, the website needs to be viewed on a mobile phone/iPad with a camera supporting AR.

To draw an analogy, mobile app and website are like parallel lines, they remain close to each other without overlapping in terms of their existence. We might speculate about their getting merged in the distant future but that distant future might just never come.

Final Thoughts?

Your website is your online identity. As businesses have an office address in the physical world, they have a website in the digital one. And, a mobile app is like a tool you provide to the user to get things done with ease, as well as engage. In most of the cases, you will need to have both.

Depending upon the nature and the stage a business is in, one medium might find itself positioned more favorably than the other. But, when the cost is not a deterrent, it has become customary to embrace both the website and the mobile app, almost as if they were an obligation. It gives a business the chance to meander seamlessly into the mental realms of its target customers, the users, and unleash many possibilities.

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

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?

iOS App Development, Mobile App DevelopmentRoohul Khan

‘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- Challenges & Solution

Mobile App Development, , , , , , Roohul Khan
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
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •