The 5 Mobile App Distribution Methods and Channels in the Mobile App Lifecycle

We are always talking about the advantages of mobility; however, there is one downside that we are so used to that we tend to overlook. In terms of app delivery and updates, mobile platforms forced us to go back using the obsolete method of binary distribution. Especially on iOS, there are a number of restrictions that makes deployment complicated.

For this reason, there are a number of different ways of distributing apps for different purposes. Let’s examine each mobile application distribution use case in detail:

 

1. Distribution During Development

  • Used by the developers that are actively working on the app.
  • It may be necessary to update the app frequently.
  • The main issue here is to keep the deployment times as short as possible not to impede the development process.
  • For this purpose, Apple requires the use of an iOS Development certificate.

 

With the Smartface Development Module

  • You don’t need to recompile your app every time you make an update.
  • You can deploy your application remotely and when you make an update in the code, only the delta code will be downloaded just in a few seconds.
  • You don’t need a Mac or a development certificate to test your app during development.

 

2. Distribution for Prereleases

  • Used for distribution to a small group of specific devices and users, primarily for testing or evaluation of the app.
  • The main issue here is the keeping track of versions and the testers both for iOS and Android. The prerelease distribution of an app must be tightly controlled.
  • For this purpose, Apple requires the use of “Ad Hoc” certificates, which allows distribution to a predefined set of devices. For enterprises, the use of an iOS Enterprise certificate is also applicable, which removes this device restriction.
  • One additional, usually overlooked but important concern is that after testing, the app needs to be resigned with production certificates. This requires going back to the development phase for configuration changes and recompilation. Since this is a manual process, it creates a risk with missing or unspecified changes after testing.

 

With the Smartface Testing Module

  • You get a cross-platform testing distribution environment. No need for separate tools for iOS and Android.
  • You can share the app with individual testers and testing teams and keep track of each tester.
  • You can keep a full archive of binaries of all versions previously shared.
  • You can resign the application for production without going back to development so that you can make sure that the tested application is released to production without any additional changes.

For more information, you can visit https://developer.smartface.io/docs/testing-distribution

 

mobile-app-middle-image

3. Distribution for In-House Enterprise Use

  • Used for distribution to internal stakeholders such as employees or contractors.
  • For this purpose, Apple requires the use of Enterprise certificates for app distribution without going through the App Store.
  • Apple requires that any external party other than the employees must have a binding, protective agreement for internal use of the application. Even if it is a B2B app, the customers still cannot use the app. The only exception is the on-premise or supervised use of the app by the customers in a company-owned device (e.g. in a branch).
  • The main issue here is to manage and monitor the access of to the application in an ongoing manner so that only permitted users have access (e.g. if an employee leaves the company, the access should be cut off immediately).
  • The reason for these restrictions is that iOS Enterprise certificates allow distribution of iOS apps not reviewed by Apple. If these rules are broken (e.g. the app is publicly released, or the certificate is stolen), Apple reserves the right to revoke the certificate or even pursue further action. This makes it crucial to distribute the app with proper methods.
  • Another concern is the prevention of the leaking of the enterprise certificate. Such leaked or stolen certificates are usually used to publish and distribute apps with malicious intent and Apple has no tolerance in such cases.
  • In the same manner, if an Android keystore is obtained somehow, it is possible to create impostor malicious applications. For this reason, keeping the signing identities secure is as important as keeping the application secure.

 

With the Smartface Enterprise App Store and Cloud Build Modules

  • You get a cross-platform Enterprise App Store that can be integrated with any identity management system through LDAP, ADFS or oAuth so that you can ensure restricted access compliant with Apple’s policies.
  • No MDM enrollment needed, so any employee or stakeholder can use it with their own devices instantly.
  • You have reports of which users are downloading which apps so that you can have full control over app distribution.
  • With the Cloud Build module, you can restrict access to the signing identities, protecting them from unauthorized downloads while allowing developers to use them for publishing applications.

For more information, you can visit https://smartface.io/byod-mdm-mam-enterprise-app-store/

 

4. Distribution for Public App Stores

  • Used for distribution to end users through the App Store or Google Play.
  • For this purpose, Apple requires the use of public distribution certificates.
  • For the App Store, the apps must be uploaded from a Mac in a specified way and then they are submitted for review before going live and it may take a couple of days, if not more.
  • For Google Play, there is a reactive review process, but still it may take a couple of hours for the app to be published.

 

With the Smartface Store Submission and Cloud Build Modules

  • You can upload your binaries directly from Smartface Cloud to the public app stores, there is no need for a Mac and it allows segregation of duties as the application developer and uploader roles can be separated.
  • With the Cloud Build module, you can restrict access to the signing identities, protecting them from unauthorized downloads while allowing developers to use them for publishing applications.

For more information, you can visit https://developer.smartface.io/docs/submit-to-stores

 

5. Distribution for Application Updates

Standard way of updating apps without Smartface

  • Since the application updates are carried out through application binaries, this is essentially the same with enterprise or public distribution processes.
  • Regardless of the scope of the update, the full binary must be resubmitted to the App Store and Google Play, going through the same review process every time.
  • After the update is published, the users will be prompted that an update is available. In most cases, the app must be downloaded in full and reinstalled over the current installation.
  • It is not possible to force users to download and update the app and multiple versions of an app will be present in the field, causing backend compatibility complexities.
  • Some web-based solutions such as hybrid apps try to overcome this issue, but in return, they sacrifice the native user experience, features and performance no matter how close they are trying to be “like native”.

 

With the Smartface Remote App Update Module

  • Actual native apps can be updated remotely with hot deployment.
  • As long as you comply with Apple’s policies, almost any kind of change can be made in the app remotely.
  • Especially for small updates, there is no need to go through the review processes.
  • Updates can be forced and deployed instantly so that critical fixes can be applied without any complexities and backend compatibility issues can be eliminated.

For more information, you can visit https://smartface.io/rau

 

With Smartface Cloud, you get a fully integrated mobile application and lifecycle management platform, eliminating the complexities of distribution in the full lifecycle of a mobile app from development to production.

What is NoOps and How to Achieve NoOps in Mobile App Development?

As enterprises are embracing DevOps and realizing its benefits, especially in their well-established software stacks, they are challenged with another question with the increasing prominence of DevOps in the cloud applications supported with automation.

The question can be expressed as “why don’t we fully streamline the DevOps processes even further since it is more or less consist of tasks in a highly structured flow?”

The primary hurdle is the presence of physical hardware that requires maintenance in any case, but moving to the cloud and taking advantage of SaaS (Software as a Service) or PaaS (Platform as a Service) products eliminates this layer of complexity and automated DevOps starts to make more sense.

And this concept actually has a recently coined name of “NoOps”, which is gaining foothold in parallel with the cloud adoption.

 

What is NoOps?

In the simplest way, NoOps can be considered as integrating and automating (wherever possible) DevOps processes. In this sense, it is perceived as an alternative to DevOps or sometimes even as “DevOps” killer, but, it is more like an extension and further streamlining of the DevOps concept.

The term is first identified by Forrester and they emphasize that

“NoOps means that application developers will never have to speak with an operations professional again.”

Indeed, when NoOps is implemented and used in the right way and in the right conditions, it is as beneficial and productive as the name suggests.

However, it requires the right tools and preferably a full cloud presence and it should not be considered as a silver bullet for DevOps needs.

cloud-image

With the advantage of the cloud, NoOps eliminates the hassle of integration and upload/download operations.

 

DevOps vs. NoOps

There are certain fields where you have an established DevOps culture and an “Ops” team, such as maintaining critical backend applications, which may include dealing with locally installed hardware and software.

However, in emerging technologies such as mobility, it is not as easy as to find and maintain internal resources for DevOps or you might not have the operations experience that you have already gained in backend applications for decades.

DevopsvsNoops

 

 

DevOps in Enterprise Mobility

Due to its nature, mobility has its own DevOps challenges:

  • Requiring a binary to be installed on mobile devices
  • Device and operating system fragmentation making coding, testing and distribution processes demanding
  • Binary distribution regulations to mobile devices
  • Strict app signing requirements
  • Issues with keeping signing identities safe, secure and accessible
  • Complex app signing and submission processes that force the use of specific hardware and software.
  • Lengthy and complex store submission and review processes causing issues in maintenance of the apps after production

For this reason, we highlight the fact that mobile app development is only the tip of the iceberg and the lifecycle management of mobile apps (the “Ops” part) is as important as the development itself, if not more.

Mobile App DevOps Lifecycle

The Typical Mobile App Lifecycle

 

Switching From DevOps to NoOps in Mobile App Development

Achieving NoOps in mobile app development is more difficult but also more important than many other fields due to the problems outlined in the previous section.

For a true NoOps approach in mobility, it is important to be able to prevent the DevOps chain breaking from development to production, which can be achieved with a fully integrated mobility platform in the cloud.

We developed Smartface Cloud for enterprises to embrace the NoOps approach in enterprise mobility.

You can consider Smartface like an automated production line, where everything is transferred automatically between stations.

Smartface Cloud is a next generation NoOps platform with an end-to-end integrated cloud structure with development, testing, deployment, distribution and management.

How to Solve The Dilemma of MDM (Mobile Device Management) in BYOD (Bring Your Own Device) Cases Using MAM (Mobile App Management)

As mobile devices get more capable and affordable, enterprises are realizing the benefits of enterprise mobility such as agility and productivity intensively.

However, mobility introduces a serious burden on enterprises from security, management as well as the cost perspective.

Previously, only some employees were using company-issued notebooks, which are well-protected with things like data encryption, domain enrollment and VPN. Their only purpose was work, and the mobility of the devices were limited, making is less prone to accidents or theft.

However, with enterprise mobility, there is an ongoing mind shift not just regarding the use of devices but also the management of the devices.

Unlike company-issued notebooks, providing mobile devices to employees do not work in all cases for certain reasons.

Such devices may not be embraced as much as personal devices due to reasons like preference over iOS over Android or being not comfortable with the form factor. For this reason, they might be more prone to accidents and losses. Usually, these devices are provided along with a company phone line, employees might be forced to carry a second device for the personal phone line. This is something burdensome for most employees and it may make devices to be disregarded with as little use as possible.

For this reason, Bring Your Own Device (BYOD) or Choose Your Own Device (CYOD) policies are emerging so that the benefits of the enterprise mobility initiatives can reach its maximum potential.

 

In its latest Predicts 2018: Mobile, Endpoint and Wearable Computing Strategies report, Gartner indicates that

By 2022, more than 75% of smartphones used in the enterprise will be bring your own device (BYOD), forcing a migration from device-centric management to app- and data-centric management. (Source: Gartner)

 

However, another concern arises in such cases, which is keeping the company data secure as many things can go negatively with personal devices on different levels, such as malware, theft, intentionally malicious acts or accidents, etc.

This is where Mobile Device Management (MDM) solutions first come to one’s mind. In theory, it is a highly viable solution for security issues with things like

  • Remote data access for all types of stored data including but not limited to apps, photos and messages
  • Remote data wipe
  • Real-time location tracking
  • Application and network restrictions
  • Screenshot capture, etc.

These policies seemingly solve the downsides of the BYOD policies.

In practice though, things do not work as expected, not from a technical perspective but from a behavioral perspective.

Only a handful users get to enroll their personal devices to MDM due to the very nature of the solution. The enterprise may provide all guarantees that they will not use MDM invasively in personal devices, but once a user gets their device enrolled, there is to turning back. The enterprise can apply new policies anytime, which actually means that the enterprise is taking ownership of the personal device.

Moreover, in some cases, the enterprise mobile applications do not contain sensitive data and the only reason MDM is used is for in-house distribution, which is an over-costly solution for a simple need.

In B2B cases, where the enterprise cannot force policies, MDM is not even an option for application distribution.

The question then becomes, how can an enterprise ensure proper distribution and security of enterprise apps without crippling enterprise mobility efforts or alienating users.

This is where MDM enrollment-free Mobile Application Management (MAM) solutions come in play. Just like how cross-platform native mobile development approaches provide best of both worlds in terms of productivity and quality, MAM solutions provide the highest level of security without the invasion of personal privacy.

MAM solutions provide similar security features that MDM solutions provide only at an application level with features like

  • Application data encryption and leak protection
  • Remote application data wipe
  • Root/jailbreak detection
  • Per-app VPN
  • Enrollment-free enterprise app store and more

 

Smartface Enterprise App Store

With its “no-ops” approach, Smartface Cloud provides an end-to-end solution for mobile app development and mobile app management. Smartface Cloud lifecycle management modules also support apps that are not developed with Smartface.

You can use Smartface Cloud to develop native iOS and Android apps just with JavaScript and then manage these applications in the same environment.

As for the lifecycle, Smartface Enterprise App Store eliminates the need for expensive, invasive and arduous process of MDM enrollment for internal app distribution for B2B or B2E for any type of mobile app.

Just in a few minutes, you can have an enterprise app store up and running with features like

  • Customizable storefront branding
  • Custom URL
  • Ability to distribute any type of enterprise IPA/APK
  • Ability to redirect users to a custom URL
  • LDAP (Active Directory) and OAuth support for user authentication
  • Detailed user and device reports

Enjoy the comfort of enterprise mobility in the cloud with Smartface.

How to Create a Synergy Between Conversational Interfaces (Chatbots) with Touch Interfaces (Mobile Apps) for the Best User Experience

Although chatbots and virtual personal assistants are getting more and more prominent each day by providing a new channel for certain types of processes; it should be noted that just like any other interaction channel, they are just means to an end, which is usually about interacting with the user in the most productive and mutually beneficial way.

For this reason, chatbots should not be considered as inferior or superior to the other channels. Each interaction point, whether it is a web site, a mobile app, a call center agent or a chatbot, has advantages and disadvantages and works best in specific use cases.

In that sense, chatbots are more suited to things like:

  • Conversation-oriented processes, replacing human agents in the first line of contact
  • Responding to frequent, small and automatable tasks
  • Structured and well-defined processes usually followed in a specific order and/or specific inputs
  • Running decision trees with finite and definable options

These processes are more prevalent in B2C use cases and this makes chatbots more suitable for B2C applications in terms productivity and positive business impact. They are usually a part of a corporate website or provided through public chatbot channels such as Facebook Messenger.

 

Although there are even more use cases in B2E/B2B space for mobility, chatbots may not be suitable for most due to the following limitations:

  • Offline operations, as chatbots require an always-on connection.
  • Execution of complex processes that require different types of inputs, not just text entry; since the means of interacting with chatbots are limited compared to touch interfaces.
  • Difficult-to-predict use cases, which have a wide array of branching steps, which require high efforts in chatbot development.
  • Quick data entry such as order collection, in which interaction with chatbots may slow down the process.
  • Processes which require one-handed use of the mobile device, where typing full words and sentences is difficult.
  • Public locations where speech to text is not viable.
  • The requirement of a private and in-house distributed client since using channels like Facebook would not be viable for internal enterprise operations. However, if a mobile app only contains the chatbot itself, then it would be a missed opportunity in terms of enterprise mobility as more services can be provided in a mobile app.

 

Therefore, especially for B2B/B2E, where using public channels is not an option, the decision is not about choosing between a mobile app or a chatbot, it is about finding the right combination of conversational and touch interfaces in a mobile app.

As an example, in an employee HR self-service mobile app, the leave request process can be handled with a chatbot, reducing it to a single step instead of selecting options from pickers to define the scope of the leave request. In the same app, the expense request process can be handled with mobile interactions like image upload or location detection.

In more complex apps, chatbots can be used for navigation, even though everything else is done with touch interactions. Similar to the IVR (interactive voice response) mechanism used in call centers, the user can just type in or tell the function to be accessed and then the related screen can be displayed with further steps to be completed through the touch interface.

For developing fully native mobile apps with chatbot capabilities for iOS and Android, Smartface SmartApps offer a convenient solution. These are open-source full-featured enterprise mobile apps which you can use freely and extend as you wish. A chatbot client is also available in the SmartApps portfolio. You can use the native Smartface Chatbot Client in any mobile app.

In a cherry-pick manner, you can combine different functionalities from different SmartApps in a single app, including the chatbot client to provide your users the best combination of touch and conversational interfaces.

For more information on Smartface SmartApps and the Smartface Chatbot Client, you can visit https://smartface.io/smartapps

Developer’s Guide to Mobile App Security in 8 Steps

As per popular demand, we are back with yet another article about security. Regardless of which framework, mobile operating system or methodology you use for mobile application development, security is a critical issue.

Like iOS and Android, different mobile platforms may have different tools and solutions for security, but the main questions are the same. Enterpise mobile application development platforms like Smartface also offer additional security functionalities to ease the process of mobile application security.

 

What is app security?

App security is taking enough amount of protection against attacks. There are many vulnerabilities that allow hackers or malicious people to gain access, it is important to identify those vulnerabilities and fix them.

 

How do you identify the vulnerabilities in mobile applications?

There are many ways and many approaches to identify them. The best way to identify them is put the application to a proven Application Security Test (AST). This is a long process and based on the business model and the need, it may cost more time and resources than anticipated. Depending on the mobile security needs need developers may follow some security app development approaches and use third party tools.

 

What is the decision criteria for preventive security measures for mobile apps?

It mostly depends on the available resources. For most of the enterprises, time to market is much more important, so they choose best tools to get the highest security that money can buy.

SMBs prefer to have known protection techniques applied to their product, they avoid higher costs with customized options.

Sometimes security means decreased usability in a mobile application or vice versa. Such as the fingerprint authentication provided nowadays with the flagship devices (such as iPhone 5S, iPhone 6 and Samsung Galaxy S5 and Galaxy S6). Fingerprint authentication is not as secure as it seems and can be easily cracked/spoofed. Some companies may accept related vulnerabilities and may opt in to authenticate their customers through fingerprint.

 

What things are at risk?

Mobile application development is different from server-side programming; on server-side programming, codes are hidden from the user in most cases, and user cannot alter them; however, in mobile applications, there are both client application and server side services. It means that both of these have to be secured. Below are the items to be secured in order to have a complete protection on the client side:

  • Authentication – the way the users log-in
  • Data at rest – stored data on device
  • Data transfer – received and transmitted data
  • Code security – the app code in the client
  • App distribution – having the app distributed from a trusted source
  • Memory integrity & security – debugging the application
  • Application tampering – codes of the app should not be altered
  • Version check – some older versions may cause vulnerabilities

 

How to authenticate mobile applications?

Use two-factor authentication for an optimal level of security. This requires two things in order to authenticate: “what you know” – is the password (needs to be secret) and “what you have” – will be the device after activation, which the activation data should be protected from cloning.

 

How to secure data storage in mobile applications?

The sensitive data on device, regardless of the storage location, has to be encrypted. The encryption key also has to be secured within the code or has to be retrieved from server when app starts. Symmetric or asymmetric encryptions are acceptable; if attacker can guess the data stored then it is prone to known text attacks. In order to harden the security, schema of data also has to be obfuscated.

The temporary data has to be deleted as soon as they are not needed.

If a device is compromised, it is important to wipe the all data based on some local triggers and/or server calls.

 

How to secure data transfer?

Basically it is the communication between server and the client app. Most of the communication flows over web services, which rely on HTTP protocol. Use SSL (https) within the communication.

The certificate store is important, it defines which certificate is to be trusted. It is possible to having the device SSL certificate store to be compromised. In that case, the app is prone to man in the middle attacks or eavesdropping. Embed the public key of the server within the app and do not change it. When the certificate on the server is to be replaced; this means that the mobile app requires an update.

 

How to ensure code is secure?

First of all, it depends on programming language. If the language is a run-time based interpreted language, then the apps written in these languages should be encrypted and stored in this way (such as JavaScript). They are decrypted on the run-time by the app.

Some other languages are to be obfuscated (such as Java).

C/C++ code does not require obfuscation or encryption; it is directly compiled to assembly, reverse engineering/decompiling mobile applications written in Objective-C or C++ does not provide proper information to extract.

 

How to distribute apps?

In the current app distribution methods, the apps does not always keep the information where it has been downloaded.

Rather than coding, it is about teaching the customers to install their apps only from designated app stores. It is especially important for Android users to avoid pirated/cracked apk files as they may contain malicious code.

If a user downloads and installs the fake or modified app and uses it (such as trying to login), this means attackers gain may gain access to sensitive information (the user name and password).

 

How to ensure data in memory is secure?

It is possible to attach a debugger to app and listen & modify the values in memory. It can make the app login without password (modify data or alter the program flow) or collect sensitive information.

Do not keep sensitive data in memory more than needed, delete or change it after it was used.

The best protection would be using anti-debugger tools for mobile apps to prevent any debugger to connect the app.

 

How to ensure app is not tampered?

Tampering can be done on two things: app code or app data. It is similar to memory integrity & security issue; main difference is that this type of attack is not done during run-time. Attacker may change the installation package, insert its own code/data or alter the code/data.

An integrity check has to be made for the app package, the best way would be an online check made by some privileged user.

 

How to make a version check?

Version check on app startup should be made in order to ensure user is using a valid version of the client app. Updates should be classified as “optional” or “mandatory”. If there is a newer version of the app, client app displays a dialog for updating.

Optional updates can be dismissed and user can continue, however in mandatory updates, the app must be updated before use. If an issue (such as flows or logic in business model) in older version may lead to security vulnerability, it has to be a mandatory update.

 

What are the best practices?

First determine how much of security is enough for the app. Use known brand tools to provide the necessary amount of security within the app. If not, there is always the possibility to miss things during development. Using the tools, with their requirement of coding they put the flow to secure way.

Most of the security flaws are introduced with business flows rather than coding. if proper methods are used. It’s better to make security reviews when the code is being reviewed for functionality.

For the sensitivity of the data, you may refer to the following chart to determine how to secure it:

mobile app security

Smartface has built-in enterprise-grade security features and takes care of most security concerns for you. With Smartface, you don’t need to worry about mobile application security.

Download Smartface now and secure your applications easily.