Mobile Application Development Paradigm

Mobile Application Market Overview:

App Downloads: As the mobile devices will increase, so the mobile applications will rise, and the app
market will encounter a massive shift in app downloads. As per AppAnnie by 2022, the annual
worldwide app downloads will go over 250 billion downloads.

Therefore, the increases in the number of mobile devices demand the need for mobile applications to
operate and perform functions smoothly.
Types of Mobile Application Development Frameworks:

While exploring the programming languages, frameworks, and a suitable platform for mobile application
development, you also have to explore the front-end development environment. If we look from the
coding perspective, you can choose to create your app in these three types of mobile apps;

Native Mobile App:

A native app is written in a language that is natively supported by the device Operating System vendor.
Native app development is done by using the framework owned by mobile platforms. The platform APIs
are available entirely to the app code, and the OS provides the UI component library.

For instance, in iOS, we have the iOS Software Development Kit (SDK) usually used with Xcode, an
IDE, and for native Android app development, Android SDK is used with Android Studio.

Native App Development

Native app development is what most people think of when it comes to smartphone apps, and for good
reason. The majority of apps available today are native. That is, they are developed using platform-
specific languages and tools such as Objective-C and Xcode (for iOS), and Java and Eclipse (for Android).
Targeting multiple platforms through native app development can be challenging due to the multi-faceted
expertise required, and also because you have to build and maintain multiple codebases at once. But it
also allows you to give your end users the experiences they expect from their platform of choice.
Additionally, native apps almost always exhibit better performance – especially when it comes to gaming,
which can require rendering complex graphics and user interface (UI) elements. Therefore, if native UI
integration and performance are high on your list of requirements, then building a native app is what will
deliver those results.

Web-Based App Development

Web-based apps are applications or websites that run within the mobile web browser, rather than the
platform’s native UI framework. The difference between an “app” and a “website” in this context is
purely semantic: basically, an app enables users to complete a task (e.g. finding movie times), whereas a
website is broader in scope and is used mainly for accessing information (e.g. finding out about a movie
theater chain).
While I hope at this point that every website you build is responsive or adaptive to multiple screen sizes,
if you are building an app you could do it with HTML5, CSS3 and JavaScript and deploy it purely over
the web. Libraries such as jQuery Mobile and Sencha Touch make this incredibly easy. The big
advantage is that you can bypass each platform’s store to deliver your product directly to your customer.
Unfortunately, the downside to this is also what makes web-based apps unique – that they run inside the
web browser. As a result, they can be perceived as being harder to use and less intuitive than a native app.
This perception is not always true, however. It is in fact possible to develop web-based apps that are on-
par with native apps. Take Facebook, for example. In September 2012, Facebook CEO Mark Zuckerberg
said the following at the Disrupt SF conference:
“When I’m introspective about the last few years I think the biggest mistake that we made, as a company,
is betting too much on HTML5 as opposed to native… because it just wasn’t there. And it’s not that
HTML5 is bad. I’m actually, on long-term, really excited about it. One of the things that’s interesting is
we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS
or Android apps combined. So mobile Web is a big thing for us.”

While he didn’t dismiss HTML5 entirely, it was pretty clear that he believes that, for now, the Facebook
iOS and Android native apps are superior. In response, the folks at Sencha cloned the native Facebook
app within their HTML5 mobile app framework. They then posted a video showing them side-by-side,
pointing out how in many ways the HTML5 app running inside the mobile browser outperformed the
native app, and was equally (if not more) usable. And this was all done nearly a year ago.
Therefore, if done right, it is possible to build great experiences that live within a mobile web browser.
Web-based apps are completely platform-agnostic, and the HTML5/CSS3/Javascript codebase is one that
is accessible by many developers and offers a very streamlined approach to app development.

Hybrid App Development

So, web-based HTML5 apps can keep up with, or even outperform, some native apps in most respects.
So, what’s the catch? The catch is that, contrary to Mr. Zuckerberg’s above statement, a recent Nielsen
study showed that (as of March 2013) smartphone users spent 87% of their time using mobile apps as
opposed to using the mobile web. People simply expect the ease and convenience of navigating through
an app that utilizes their platform’s native UI rather than the inconsistency found from one website or
web-based app to another.
Enter hybrid app development. Like web-based apps, hybrid apps are built using HTML5, CSS3 and
JavaScript, rather than native languages such as Java or Objective-C. Development occurs within mobile
frameworks such as PhoneGap or Titanium (along with many others), which encapsulate the code in such
a way that it is deployable just like a native app to various mobile platforms. They are designated “hybrid”
because they are not purely native (since they do not run within the platform’s native UI), nor are they
web-based (because they do not run inside the mobile browser). Rather, the rendering for most hybrid
apps is done using web views within each platform, which is basically a web browser (minus all the
browser window decoration) that fills 100% of the device screen’s width and height.
One of the biggest drawbacks to hybrid apps is their performance…or rather lack thereof. Web views
simply do not have the rendering power afforded by a native UI, and performance can vary from one
platform to another. The frameworks that don’t utilize web views (such as Titanium) instead use
JavaScript interpreters that evaluate the code at runtime and insert it alongside native objects within the
environment (sort of like the relationship between inline Javascript and HTML).
This approach has its own set of difficulties: the varying performance of interpreters from one platform
to another, increased app load times due to the need to load the interpreter and all its associated libraries,
and the inability of the “translated” Javascript to produce results that mimic every single piece of a native
UI perfectly. As a result, if you have a complex, resource-intensive app such as a game, natively-built
apps will almost always have the edge. On the other hand, information-heavy apps such as those that
offer news and other information might be a great fit for hybrid development.

Cross-Platform Mobile App:

Applications that are written in one language but can run on all the platforms. In cross-platform mobile
apps, the language you use to write the code may not be the native language of the platform. This means
that the code might be included, connected, or cross-compiled to the bytecode that can execute directly
on the Operating System with the help of some libraries.
Programming Language

These languages have been in the market for the past many years and have become standard languages
for mobile application development companies.

Kotlin:
Google announced in 2017 that it would support Kotlin as the alternative for Android programming.
Kotlin is a comparatively young native Android language that has the potential to replace Java. It has so
many features that Java doesn’t have and is considered as a perfect language to create Android apps. It
resolves many problems that Java has. Kotlin is one of the fastest-growing languages. Kotlin is 96%
used for new projects, and only 38% use it for pre-existing projects. More than a third of developers are
migrating their existing projects to Kotlin.

Swift:
Swift is now considered as the next generation iOS language. It was introduced by Apple in 2014 and
was available for mobile app development in 2015.

This language is outpacing Objective-C because it offers a more concise and clearer code. Currently,
Swift usage is 2.1 million developers globally. Swift is considered as an easier, simpler, and more
compact language for iOS app development. It’s really easy for Objective-C developers to move over
Swift. In Swift, you require fewer lines of code than to complete the same task in Objective-C. Swift’s
memory management system enables developers to focus on the logic rather than bothering about the
memory of each object.

If someone is looking for an iOS-specific development platform, then turn to Swift because Apple is
going to continue with it. So it’s going to be a must-know programming language for iOS developers.

React Native and JavaScript:

React Native is famous for crafting a cross-platform mobile app. This platform uses ReactJS and
Javascript. React Native is a javascript framework built upon the React library. Facebook created both of
these.

React Native enables developers to deliver iOS and Android apps with the same code base. It uses native
components of Android and iOS internally.
A lot of entrepreneurs are using React Native for their business to make world-class applications. It’s
used by Facebook, Instagram, Bloomberg, Pinterest, Skype, Uber, Tesla, Walmart, Vogue, Wix, and many
others.

According to Stackoverflow, 66.7% of developers use Javascript in their work. This indicated that React
native is going to stay with us in 2020 as one of the most preferred cross-platform app development
languages.

Flutter and Dart:

Flutter is a free and open-source platform based on Dart language that enables continuous cross-platform
app development. The tech giant Google supports Flutter. It uses Dart, a simple and responsive, Object-
Oriented Programming Language, which is easy to learn.

Flutter is the only framework that provides reactive styles without using any Javascript bridge. This
framework is considered best for developing high-quality native interfaces for iOS and Android app in
minimal time.

Flutter is amongst the top preference of the Top mobile app development companies in India and
developers around the world.

Xamarin and C#:

Microsoft acquired Xamarin, and since then, it is an open-source framework. It’s a cross-platform
framework that enables developers to program in C# language. It’s a versatile platform that is used by
over 1.6 million developers from around the globe. Xamarin’s performance is excellent in comparison to
native mobile applications. This makes it a go-to option for many developers for the development of a
high-performance app with the native look and feel.
Thick / Thin Clients

The thickness of a client refers to how much processing is done and how much data is stored on the cli-
ent device versus the servers it interacts with. The more data and processing done, the thicker the client
becomes. For example, take two different calendar applications.

The first is a calendar “app” that lives on a smart phone. Most all the functions of the application, like
the interface, the search functions and the storage of events are all performed by the device itself. Only
occasionally does it go and check with the server to sync the data up. If the phone loses its Internet con-
nection, the app soldiers on. This is a thick client.

Our second calendar application is a web app. Most of the functions of the application are actually re-
quests made by the client, but performed on the server. Search, editing an event, sending an email re-
minder, these are all done in the cloud somewhere, and the results are sent to the device. The device
itself only handles a few key elements like displaying the interface and sending instructions. It works
fine with slow phones because the speed of the server is what matters most, but if the phone loses the
Internet, it’s game over. This is a thin client.

The most popular applications are often those that integrate with device hardware features such as GPS,
cameras, accelerometers, gyroscopes, sensors, and other fun bells and whistles. Generally speaking, mo-
bile devices will only grant use of these features to applications that live on the device. Given this, one
would think the inertia is swinging in the direction of mobile thick clients, and the explosion in app
popularity would seem to support that premise.

Enter HTML 5. It offers interoperability among browsers without using plug-ins like Microsoft Silver-
light or Adobe Flash. Among its many capabilities are some specific to mobile devices, such as:

• Geo-location support
• Client-side database storage
• Native support for audio and video (no more Flash)
• Offline application caching

These features will offer thin client mobile applications the ability to act more like thick client apps. Most
smartphone operating systems have native Webkit-based browsers with strong support for HTML 5. Mi-
crosoft just recently announced support for HTML 5 in the upcoming version of IE 9 Mobile, so support
for the as yet unfinished standard is on the rise. However, the W3C announced only last month that
the HTML 5 standard won’t be ready until 2014, so we may be a few more years away from thin clients
dominating the mobile landscape.

Questions and Considerations:

Here are some things to consider when devising your own plan for going mobile:

Thin Client

• Multi-platform-compatible
• Uses standard web technologies
• More cost-effective to develop (see previous point)
Thick Client

• Access to features in a device’s hardware

• Can be used offline

So, when building your own mobile or web-based app, ask yourself these questions:

• Is your target audience using smartphones with Webkit-based browsers?

• Will users need to access hardware features such as camera, compass, etc.?
• Will they always have an Internet connection when using your app?

If the answer to any of the above questions is no, start thinking about contingency plans for situations
wherein the mobile user’s experience may be less than optimal or they don’t have the hardware neces-
sary to run your app. No one likes an app—thick or thin—with usability and performance issues.

Mobile App Design Key Considerations:

The difference between a good app and a bad app is usually the quality of its user experience (UX). A
good UX is what separates successful apps from unsuccessful ones. Today, mobile users expect a lot
from an app: fast loading time, ease of use and delight during interaction. If you want your app to be
successful, you must consider UX to be not just a minor aspect of design, but an essential component of
product strategy. There are many things to consider when designing for mobile.
Minimize Cognitive Load

Cognitive load refers here to the amount of brain power required to use the app. The human brain has a
limited amount of processing power, and when an app provides too much information at once, it might
overwhelm the user and make them abandon the task.
Decluttering

Cutting out the clutter is one of the major recommendations. Clutter is one of the worst enemies of good
design. By cluttering your interface, you overload users with too much information: Every added button,
image and icon makes the screen more complicated.

Clutter is terrible on desktop, but it’s far worse on mobile (simply because we don’t have as much real
estate on mobile devices as we do on desktops and laptops). It’s essential to get rid of anything in a
mobile design that isn’t absolutely necessary because reducing clutter will improve comprehension.

Points to solve the problem of cluttering:

• Keep content to a minimum (present the user with only what they need to know).
• Keep interface elements to a minimum. A simple design will keep the user at ease with the prod-
uct.
• Use the technique of progressive disclosure to show more options.

Offload Tasks

Look for anything in the design that requires user effort (this might be entering data, making a decision,
etc.), and look for alternatives. For example, in some cases you can reuse previously entered data instead
of asking the user to type more or use already available information to set a smart default.

Break Tasks Into Bite-Sized Chunks

If a task contains a lot of steps and actions required from the user’s side, it’s better to divide such tasks
into a number of subtasks. This principle is extremely important in mobile design because you don’t want
to create too much complexity for the user at one time. One good example is a step-by-step checkout
flow in an e-commerce app, where the designer breaks down a complex checkout task into bite-sized
chunks, each requiring user action.

Chunking can also help to connect two different activities (such as browsing and purchasing). When a
flow is presented as a number of steps logically connected to each other, the user can more easily proceed
through it.

Use Familiar Screens

Familiar screens are screens that users see in many apps. Screens such as “Gettings started,” “What’s
new” and “Search results” have become de facto standards for mobile apps. They don’t require additional
explanation because users are already familiar with them. This allows users to use prior experience to
interact with the app, with no learning curve.
Minimize User Input

Typing on a small mobile screen isn’t the most comfortable experience. In fact, it’s often error-prone.
And the most common case of user input is filling out a form. Here are a few practical recommendations
to make this process easy:

• Keep forms as short as possible by removing any unnecessary fields. The app should ask for only
the bare minimum of information from the user.
• Provide input masks. Field masking is a technique that helps users format inputted text. A mask
appears once a user focuses on a field, and it formats the text automatically as the field is being
filled out, helping users to focus on the required data and to more easily notice errors.
• Use smart features such as autocomplete. For example, filling out an address field is often the
most problematic part of any registration form. Using tools like Place Autocomplete Address
Form (which uses both geo-location and address prefilling to provide accurate suggestions based
on the user’s exact location) enables users to enter their address with fewer keystrokes than they
would have to with a regular input field.
• Dynamically validate field values. It’s frustrating when, after submitting data, you have to go
back and correct mistakes. Whenever possible, check field values immediately after entry so that
users can correct them right away.
• Customize the keyboard for the type of query. Display a numeric keyboard when asking for phone
number and include the @ button when asking for an email address. Ensure that this feature is
implemented consistently throughout the app, rather than only for certain forms.

Anticipate Users Needs

Proactively look for steps in the user journey where users might need help. For example, the screenshot
below shows a part where users need to provide specific information.

Use Visual Weight to Convey Importance

The most important element on the screen should have the most visual weight. Adding more weight to
an element is possible with font weight, size and color.

Avoid Jargon

Clear communication should always be a top priority in any mobile app. Use what you know about your
target audience to determine whether certain words or phrases are appropriate.

Make The Design Consistent

Consistency is a fundamental principle of design. Consistency eliminates confusion. Maintaining an

overall consistent appearance throughout an app is essential. Regarding mobile app, consistency means
the following:

• Visual consistency
Typefaces, buttons and labels need to be consistent across the app.
• Functional consistency
Interactive elements should work similarly in all parts of your app.
 • External consistency
Design should be consistent across multiple products. This way, the user can apply prior
knowledge when using another product.

Here are a few practical recommendations on how to make a design consistent:

• Respect platform guidelines.

Each mobile OS has standard guidelines for interface design: Apple’s Human Interface Guide-
lines and Google’s Material Design Guidelines. When designing for native platforms, follow
the OS’ design guidelines for maximum quality. The reason why following design guidelines is
important is simple: Users become familiar with the interaction patterns of each OS, and any-
thing that contradicts the guidelines will create friction.
• Don’t mimic UI elements from other platforms.
As you build your app for Android or iOS, don’t carry over UI elements from other platforms.
Icons, functional elements (input fields, checkboxes, switches) and typefaces should have a na-
tive feel. Use native components as much as possible, so that people trust your app.
• Keep the mobile app consistent with the website.
This is an example of external consistency. If you have a web service and a mobile app, make
sure that both share similar characteristics. This will allow users to make frictionless transitions
between the mobile app and the mobile web. Inconsistency in design (for example, a different
navigation scheme or different color scheme) might cause confusion.

Put The User In Control

Keep Interactive Elements Familiar And Predictable

Predictability is a fundamental principle of UX design. When things work in the way users predict, they
feel a stronger sense of control. Unlike on desktop, where users can use hover effects to understand
whether something is interactive or not, on mobile, users can check interactivity only by tapping on an
element. That’s why, with buttons and other interactive elements, it’s essential to think about how the
design communicates affordance. How do users understand an element as a button? Form should follow
function: The way an object looks tells users how to use it. Visual elements that look like buttons but
aren’t clickable will easily confuse users.

The “Back” Button Should Work Properly

An improperly created “back” button can cause a lot of problems for users. Prevent situations when
tapping the “back” button in a multi-step process would take users all the way back to the home screen.

A good design makes it easier for users to go back and make corrections. When users know that they can
take a second look at data they’ve provided or options they’ve selected, this allows them to proceed with
ease.

Meaningful Error Messages

To err is human. Errors occur when people engage with apps. Sometimes, they happen because the user
makes a mistake. Sometimes, they happen because the app fails. Whatever the cause, these errors and
how they are handled have a huge impact on the UX. Bad error handling paired with useless error mes-
sages can fill users with frustration and could be the reason why users abandon your app.
Take an error-state screen from Spotify as an example. It doesn’t help users understand the context and
doesn’t help them find the answer to the question, “What can I do about it?”

Don’t assume users are tech-savvy enough to figure things out. Always tell people what’s wrong in plain
language. Each error message should tell users:

• what went wrong and possibly why,

• what’s the next step the user should take to fix the error?

Design An Accessible Interface

Accessible design allows users of all abilities to use products successfully. Consider how users with
vision loss, hearing loss and other disabilities can interact with your app.

Be Aware Of Color-Blindness

4.5% of the global population experience color-blindness (that’s 1 in 12 men and 1 in 200 women), 4%
suffer from low vision (1 in 30 people), and 0.6% are blind (1 in 188 people). It’s easy to forget that
we’re designing for this group of users because most designers don’t experience such problems.

Let me give you a simple example. Success and error messages in mobile forms are often colored green
and red, respectively. But red and green are the colors most affected by color-vision deficiency (these
colors can be difficult to distinguish for people with deuteranopia or protanopia). Most probably you’ve
seen the following error message when filling out a form: “The fields marked in red are required”? While
it might not seem like a big thing, this error message combined with the form in the example below can
be an extremely frustrating experience for people who have color-vision deficiency.

The form field’s design relies only on red

and green to indicate fields with and without an error. Color-blind users cannot differentiate the fields
highlighted in red.

As the W3C’s guidelines state, color shouldn’t be used as the only visual means of conveying information,
indicating an action, prompting a response or distinguishing a visual element. It’s important to use other
visual signifiers to ensure that users will be able to interact with an interface.
The use of icons and labels to show which fields are invalid better communicates the information to a
color-blind user.

Make Animations Optional

Users who suffer from motion sickness often turn off the animated effects in their OS settings. When the
option to reduce motion is enabled in accessibility preferences, your app should minimize or eliminate
its own animations.

Make The Navigation Simple

Helping users navigate should be a high priority for every app. All the cool features and compelling
content that your app has won’t matter if people can’t find them; also, if it takes too much time or effort
to discover how to navigate your product, chances are you’re just going to lose users. Users should be
able to explore the app intuitively and to complete all primary tasks without any explanation.

Use Standard Navigation Components

It’s better to use standard navigation patterns, such as the tab bar (for iOS) and the navigation drawer
(for Android). The majority of users are familiar with both navigation patterns and will intuitively know
how to get around your app.

Prioritize Navigation Options

Prioritize navigation based on the way users interact with your app. Assign different priority levels (high,
medium, low) to common user tasks. Give prominence in the UI to paths and destinations with high
priority levels and frequent use. Use those paths to define your navigation. Organize your information
structure in a way that requires a minimum number of taps, swipes and screens.

Don’t Mix Navigation Patterns

When you choose a primary navigation pattern for your app, use it consistently. There shouldn’t be a
situation in which part of your app has a tab bar, while another part has a side drawer.
Make Navigation Visible

As Jakob Nielsen says, recognizing something is easier than remembering it. Minimize the user’s
memory load by making actions and options visible. Navigation should be available at all times, not just
when we anticipate that the user needs it.

Communicate Current Location

Failing to indicate the current location is a very common problem of many mobile app menus. “Where
am I?” is one of the fundamental question’s users need to answer in order to successfully navigate. People
should know where they are in your app at any moment.

Use Functional Animation to Clarify Navigational Transitions

Animation is the best tool to describe state transitions. It helps users comprehend a state change in the
page’s layout, what has triggered the change and how to initiate the change again when needed.

Be Careful With Using Gestures In The UI

Using gestures in interaction design can be tempting. But in most cases, it’s better to avoid this tempta-
tion. When gestures are used as a primary navigation option, they can cause a terrible UX. Why? Because
gestures are hidden controls.

As Thomas Joos points out in his article “Beyond the Button: Embracing the Gesture-Driven Interface,”
the biggest downside of using gestures in a user interface is the learning curve. Every time a visible
control is replaced with a gesture, the app’s learning curve goes up. This happens because gestures have
lower discoverability — they are always hidden, and people need to be able to identify these options in
order to use them. That’s why it’s essential to use only widely accepted gestures (the ones that users
expect in your app).

When it comes to using gestures in a UI, follow a few simple rules:

• Use standard gestures.

By “standard,” I mean gestures that are most natural for the app in your category. People are fa-
miliar with the standard gestures, so no extra effort is required to discover or remember them.
• Offer gestures as a supplement to, not a replacement for, visible navigation options.
Gestures might work as shortcuts for navigation, but not as a complete replacement for visible
menus. Thus, always offer a simple, visible way to navigate, even if it means a few extra ac-
tions.

Visible Area Of The Screen

Load just enough content to fill the screen when a page opens. Content available on scroll should continue
to load in the background. The benefit of this approach is that users will be engaged in reading the initial
content and, in some cases, won’t even notice that content is still loading.
Make It Clear When Loading Is Occuring

A blank or static screen that users see when content is loading can make it seem like your app is frozen,
resulting in confusion and frustration, and potentially causing people to leave your app. At a minimum,
show a loading spinner that makes it clear that something is happening. For a longer wait time (more
than 10 seconds), it’s essential to display a progress bar so that the user can gauge how long they’ll be
waiting.

Offer A Visual Distraction

If an app gives users something interesting to look at while waiting, users will pay less attention to the
wait itself. Thus, to ensure people don’t get bored while waiting for something to happen, offer them a
distraction. A fine animated waiting indicator can retain users’ attention while they wait.

Skeleton Screens

Skeleton screens (i.e. temporary information containers) are essentially a blank version of a page into
which information is gradually loaded. A skeleton screen would appear the moment your app starts load-
ing data, giving users the impression that your app is fast and responsive. Unlike a loading indicator,
which just conveys that something is happening, a skeleton screen focuses on actual progress.

Optimize Content For Mobile

Content plays a significant role in design. In most cases, the primary reason why people use an app is the
content it provides. But it’s not enough just to have clear, well-crafted content. The content has to be
easy to digest.

Make Text Readable and Legible

When we think about content, in most cases we mean typography.

The key to mobile typography is readability and legibility. If users can’t read your content, there’s no
point in offering content in the first place.

First, a few practical recommendations on legibility:

• Font size
Generally, anything smaller than 16 pixels (or 11 points) is challenging to read on any screen.
• Font family
Most users prefer a clear, easy-to-read font. A safe bet is the system’s default typeface (Apple
iOS uses the San Francisco font; Google Android uses Roboto).
• Contrast
Light-colored text (such as light gray) might look aesthetically appealing, but users will have a
hard time reading it, especially against a light background. Make sure there is plenty of contrast
between the font and the background for easy readability.

And now, a few recommendations for readability:

 • Avoid all caps.
All caps text — meaning text with all letters capitalized — is fine in contexts that don’t involve
attentive reading (such as acronyms and logos), but avoid it when your message requires heavy
reading.

Limit the length of text lines.

A good rule of thumb is to use 30 to 40 characters per line for mobile.

Don’t squeeze lines.

Adding space between text aids the user in reading and creates a feeling that there isn’t so much infor-
mation to take in.

D-Quality Images and The Right Aspect Ratio

The rise of devices with high-resolution screens sets a bar for the quality of images. Images shouldn’t
appear pixelated on HD screens.

Images should always appear in the right aspect ratio, so that they don’t look distorted. Images that are
stretched too wide or too long just to fit in a space will look unappealing and out of place.

The latest challenge many mobile designers face is optimizing the UX for the iPhone X. Designing for
the iPhone X requires a different size of artboard that any other iPhone (you’ll need 375 x 812-point
resolution images at 3x).
 (Image credit: Apple)
Design For Touch

Designing for touch has a goal of reducing the number of incorrect inputs and making interaction with
an app more comfortable.

Design For Fingers, Not Cursors

When you’re designing actionable elements in a mobile interface, it’s vital to make targets big enough
so that they’re easy for users to tap. Mistaken taps often happen due to small touch controls.

Source: https://www.smashingmagazine.com/2018/02/comprehensive-guide-to-mobile-app-design/
What is Client Server Application?

The client server application is a form of computing. The client server application is software available
on the clients’ computer that generates requests to a remote server. Client server application divides tasks
and workload between servers and clients, which are either found in the same system or they communi-
cate through a computer network over the internet. The client is dependent on sending a request to other
programs, for accessing a service made by the server.

The clients from their respective devices request a file or an application from the remote server, the server
then further hears the request made by the client and verifies the credentials, if everything is accepted
then the request requested file or application is served to the client. The communication between the
client and the user is two-way communication. The server can connect with the client to ensure that the
client has the necessary update or when the client required anything. Once the server has done its job it
loses the connection with the client to save the bond with the space on the network.

The client-server communications are usually permitted by the TCP/IP protocol. The requests made by
the client are organized and prioritized in a scheduling format, which in turn helps in coping with receiv-
ing requests. Popular client server applications are email, the worldwide web, and network printing. In
client server application data can be accessed efficiently even with the client server not being within
proximity.

What is Web Application?

The web application is also known as a web app. It is an application software that runs on a web server.
The web application is accessed by the client via a web browser with an active internet connection to
perform tasks. The web application allows businesses a cost-effective way of communication to ex-
change information. It makes transactions fast, safe, and secure.

The web application needs a web server to handle the requests made by the client. It often saves the
required information requested by the client to perform the task efficiently. The user requests for a par-
ticular data or information to the web server over the internet, the web server then further forwards the
request to the required web application server.
The web application then performs the requested tasks and generates the result of the requested task and
serves the task results to the web server. The web server then communicates back with the client and
displays the information.

The web application includes a variety of things such as online forms, shopping carts, file scanning, file
conversion, etc. web application can run on several platforms until the browser is suitable. All the clients
have a similar version. The communication in a web application is accessible from anywhere.

Parameter of
Client Server Application Web Application
Comparison

Architecture It is made up of two tire architecture It is made up of multi tire architecture

Interaction takes place via a user

Interaction Interaction takes place via a web browser
interface or application

It requires pre-installation in the

Operation It can run directly on suitable web browse
device

May get overloaded by tasks

Capable of working over multiple platforms in
Efficiency decreasing the performance
the same time with quick performance
efficiency

Cookies Cookies are not required Cookies are needed

High risk comparatively as a greater number of

security Less risk as there are fewer users
users

Mobile application development poses many challenges such as usability, security, integration, connec-
tivity and speed. Rapid development of these complex applications, if not carefully executed, can quickly
lead into major support issues.
Various platform options are available for developing applications targeted for iOS, Android and Win-
dows mobile devices. Mobile applications are classified into different types based on the mobile devel-
opment architecture employed to create them.

Mobile Client Architecture – Native vs. Hybrid vs. Web apps

best option for mobile app development. There a number of factors to consider including:
 • Target audience – who will be using the app?
• Target platforms – what devices will be targeted?
• App features and functionality – what features will be in the app? What hardware features (mic,
camera, compass, gps, etc.) will be used
• Timeline and budget – how fast do you need an app and how much are you willing to pay?
• Developer skills – what languages and platforms do your developers already know how to use?

The client architecture options can be broken down into a couple different areas,

Native Apps

Native apps are binary executable applications that are stored on and run locally on the device. Native
apps usually work just like any other built-in app (mail or web browser, for example) and have full access
to the device APIs and features, as provided by the vendor. Native apps are usually obtained via an app
store (i.e. the iOS App Store or Android Marketplace), though can also be obtained via enterprise or ad-
hoc deployment depending upon the platform. Native apps are also usually updated via an app store (or
similar) and there can be a lead time and approval process involved before updates can be deployed to
end users.

Native apps are usually developed in the default language of their respective mobile platform, for exam-
ple – Objective-C on iOS, Java on Android, and C# on Windows Phone 7. As native apps are usually
written using a programming language, framework, and tools specific to a single mobile platform – they
cannot be used on other mobile platforms. So, perhaps an obvious example – but Android apps can’t run
on iOS and vice-versa.

Mobile Web Apps

Mobile web applications run inside and are (usually) accessed via visiting a URL in the web browser on
a mobile device. Depending on the platform, mobile web apps can also usually be launched via an icon
from the home screen if the user chooses to “install” or bookmark the web app, similar to how a native
app is launched. Mobile web apps are built using HTML, JavaScript, and CSS – and they may or may
not make use of HTML5 (for advanced interactions) or a javascript framework that eases mobile web
development, such as jQuery Mobile or Sencha Touch. Mobile web apps can usually mimic the look and
feel of a native app, though they have less access to device features and APIs than a native app, as the
app is constrained by running within the web browser. As the code for a mobile web app is run on a web
server and not distributed via any app store, the code can be freely updated and redeployed without any
submission process or approval from an app store vendor.

Hybrid Mobile Apps

“Hybrid” mobile apps cover a couple different, similar architecture options – the common thread between
them is that they are largely based on web technology (i.e. HTML/CSS/JavaScript) running within a
native app, mimicking the look and feel of a native app. All native app frameworks include capabilities
for displaying web-based content within an app (i.e. the UIWebView in iOS), and hybrid apps make use
of this functionality to display web content within a native app wrapper. The web content (images,
HTML, JavaScript, etc.) making up the app can either be packaged up and stored locally within the app,
or it can be accessed from a web server. The native part of the application is able to fully access device-
specific APIs and hardware features that a web application doesn’t normally have access to. The most
common way to build a hybrid app is to put web content within a native “wrapper” app – app screens
can then either be completely web-based or a combination of both web and native screens. As hybrid
apps are written within a native app shell – they can also be distributed via the app stores. The Facebook
app on most platforms is a good example of a hybrid app – combining web views with native views in
order to display dynamic content, like the news feed.

Deployment

Native and hybrid apps can be downloaded and installed directly from an “app store” on most modern
platforms, which provides a potential marketing boost and an easy way for potential users to discover
and download apps. The vendor’s app store is then also responsible for alerting users and deploying
updates to apps. However, one issue with app stores is the inevitable lead time involved in waiting for
approval of new apps and app updates, which can take a week or more depending on the time of year. If
delayed updates or approvals would be an issue for your app, you may want to consider a mobile web
app instead.

Native and hybrid apps can also be deployed to internal corporate users via “enterprise deployment”, by
a mobile device management (MDM) solution or an internal “app store”.
Cost and Timeline

Cost and timeline are usually the most important factors in most software projects. Native applications
have to be completely re-written between platforms and thus have the highest cost if you plan on building
an app on multiple platforms. In a perfect world where mobile web app code works perfectly across all
platforms, mobile web apps would theoretically be the lowest cost option for cross-platform develop-
ment. Unfortunately, a significant amount of time is often spent at the end of a mobile web app project
ironing out inconsistencies and performance across different platforms usually increasing the cost beyond
that of building a native app on a single platform. Nonetheless, developing a single codebase will always
be less costly than developing three separate codebases. For hybrid apps, only the native portion of the
app must be re-written between platforms, placing the cost of building cross-platform hybrid apps some-
where in the middle between native apps (highest cost) and mobile web apps (lowest cost).

Architecture Selection

Each architecture option works best for different kinds of applications. Native applications currently
work best for:

• Performance-intensive apps
 • Apps with offline or disconnected requirements
• Games or apps with rich visuals
• Apps that require background processing
• Apps requiring heavy interaction with local data or device hardware

Native apps also work well for marquee applications that can’t compromise on user experience or per-
formance, where cost savings and productivity gains from cross-platform code sharing is not a goal.
Native apps also make sense if only a single platform or device is being targeted, where there is no reason
to re-use code on other platforms.

Hybrid and Mobile Web applications work well for business and content applications, and apps with
more basic user interface and functionality requirements. They both also work well for apps targeting
multiple platforms. Hybrid apps work well for adding native functionality to existing mobile web apps,
or simply creating a native wrapper around a mobile web site. Mobile web apps also work well for cre-
ating a simple mobile-optimized version of an existing web site.

Performance

The JavaScript code used in a mobile web or hybrid app is being interpreted by the web browser on the
device, and thus runs slower than compiled, native code used in a native app in most cases – though
JavaScript performance has seen massive gains in recent years, and will probably continue to improve.
Processing done with native code in a native app will execute faster than the same processing in JavaS-
cript in a mobile web or hybrid app. Though, hybrid apps have an advantage here in that they can make
use of both native and web-based code – processing can be offloaded to native code if required.