Is your company ready to meet the mobility challenge? Anyone who’s faced the urgency of creating a mobile solution is all too aware of the limitations. They have most likely tried a few different approaches, ranging from developing on native SDKs to using frameworks to developing in-house using HTML5. And they have most likely come to the conclusion that true enterprise-grade technology is necessary. Mobile application development platforms (MADP) are the solution, but figuring out which MADP to use can be time-consuming at best and confusing at worst. To help you make that decision, we’ve created a MADP vendor selection guide checklist, which outlines the top 10 things you need to consider when evaluating a mobile platform. These include: - Support for multi-channel app development - Developer productivity and designer creativity - Middleware capabilities and B2E capabilities - Platform maturity and developer ecosystem

1. 10Key Criteria for
Mobile Platform Selection
A MUST-HAVE CHECKLIST FOR MOBILE
APPLICATION DEVELOPMENT

2. 2
3
4
6
7
9
10
11
13
15
16
17
18
Introduction
1. Support for Multi-Channel
2. Service Level Agreements
3. Developer Productivity
4. Developer Creativity
5. Open Standards-Based Platform
6. Middleware Capabilities
7. B2E Capabilities
8. Total Cost of Ownership
9. Mobility Track Record
10. Platform Maturity and Developer Ecosystem
Conclusion
Table of Contents

3. 4
1. Support for Multi-Channel
IS MULTI-CHANNEL DEVELOPMENT SUPPORTED?
Why supporting all channels is important:
Multi-channel coverage is pivotal for organizations approaching mobility with the diversity of devices their users
have in mind. With true multi-channel support, a developer can write once and deploy across mobile devices,
tablets, wearables and desktop. Consequently, this centralized approach and connectedness results in efficiencies
for the organization’s mobile development team and consistency of experience across all channels for their users.
Why supporting all output modes is important:
Users have different devices and different preferences for accessing their apps. Whether or not
to create native or HTML5 or hybrid apps depends on the purpose of that app, e.g. for enterprise
apps Native is a more suitable mode due to large off-line storage and higher security capabilities,
while for some consumer-facing e-commerce apps, hybrid apps may make more sense.
P Is multi-channel truly supported from the single code-base, requiring single skill-set?
P How is Native supported?
P How is desktop supported – from a single code base
or through other products, e.g. Lotus?
P Native, Hybrid and Web using a unified SDK?
P How much of the code is generated (human readable!) and
how much do the developers need to hand-code?
P Are non-HTML5 browsers and CSS 1.0/2.0 supported?
P What are the platform OS versions, devices and form factors supported? (see Table 2)
QUESTIONS TO ASK:

4. 5
Table 1: Kony vs Other Platforms Comparison Table: Supporting Multiple Modes
OUTPUT -> HTML4 HTML5 HYBRID NATIVE
KONY Out-of-the-box Out-of-the-box Out-of-the-box Out-of-the-box
Older XHTML-MP, CSS 1.0/2.0 HTML5 - SPA (Single
Page App).
Cross-platform native
apps can be built with a
single code base using
Kony’s Multi-channel
APIs and widgets
COMPETITORS None Partial and Manual Manual None
Not Supported SPA support unavailable.
Only HTML5
Dynamic is supported
which again is 90%
Hand-coded
Require external
3rd party libraries
Apps for each stream
built by leveraging native
mobile SDKs only
Table 2: Kony vs Other Platforms Comparison Table: Supporting Multiple Channels
OUTPUT -> PLATFORM MOBILE PHONES TABLETS WEARABLES DESKTOP
KONY Native - iOS,
Android, Windows,
BlackBerry.
Hybrid & Web
Native - iPhone,
Android, Windows
Phone, BlackBerry.
Native - iPad,
Android & Windows
Tablet. Web.
Apple Watch
& Android
Wear(Notifications)
Windows desktop
apps & Desktop
Web support.
COMPETITORS iOS, Android,
Windows Phone
Hybrid & Web Only iPad and some
Android tablets
None 32/64 bit rich client,
no Desktop Web

5. 6
2. Service Level Agreements
DOES THE VENDOR PROVIDE SLAS TO COVER NEW RELEASES OF DEVICES AND OSS?
Why SLAs is important:
In a rapidly evolving mobile landscape, a service level agreement (SLA) guarantees that your customers will be covered within
a certain amount of time as new devices and operating systems are released to the market. Without SLAs, the future of your
application is uncertain. As certain toolkits rely on 3rd party frameworks (such as the open-source Phone Gap framework),
the upgrade path of your applications is unclear. Without these SLAs, it is possible that your users will be alienated and left in
the dark upon upgrading their OS or device. Don’t penalize early-mover users. Stick with a platform option with a clear SLA.
When reading an SLA from any platform, framework, or toolkit provider, it is necessary to look out for specific language
so that you ensure continuity of an application. For instance, be careful to note the amount of time after each OS and
each device are released to market. Users have come to expect applications to be promptly updated and function
not only as they did with previous OS releases, but to include relevant integration of new OS or device features.
SLA
P What exactly is covered by the SLA? Look for the specific
language to identify any ambiguities.
P Are new operating system releases covered? What
is the committed SLA in terms of days?
P Are new device releases covered? What is the committed SLA?
P What is the provider’s track record for complying with SLAs?
P How much of the code is generated (human readable!) and
how much do the developers need to hand-code?
QUESTIONS TO ASK:

6. 7
3. Developer Productivity
WHAT IS THE PLATFORM’S TOOLING SUPPORT AND HOW
IS DEVELOPER EFFICIENCY ACHIEVED?
Why robust platform tooling support is important:
The key advantage of the Designer component of a platform for a developer is the ability to use multiple tools
to minimize the lines of code and repetitive effort. While a product bake-off or a POC (Proof of Concept) will
help you understand these capabilities better, it is important to analyze the step-by-step effort.
P How is the UI created? Is there support for visual, low-code development?
P How is a service connection defined, created and tested? Is there a
visual editor available to create a service connection?
P How is the app logic defined? Is there tooling such as mapping editor,
action sequence editor, logic editor, etc., available?
P Is it possible to directly import 3rd party libraries?
QUESTIONS TO ASK:

7. 8
Table 3: Summary of steps involved in development
TASK ITEMS COMPETITOR TASK EFFORT
COMPETITOR SKILLS,
ARTEFACTS
KONY TASK EFFORT KONY SKILLS ARTEFACTS
DEFINE,
CONNECT AND
TEST A SERVICE
CONNECTION
Define, connect and test a
service connection
Start by defining an
adaptor connectivity
XML based adapter
definition file is created
using the Adapter Editor
Define service by
configuring one on Kony
MobileFabric; connect
mobile app to service
using Service Data Mapper
providedby Kony Visualizer
Visual data mapper provided
to Connect to services
Define service invocation
logic separately that
captures the method,
type and parameters for
each Service adapter
Service invocation logic
is developed in JavaScript
as a separate artifact
Not required with
Kony Platform
N/A
Define service
transformation logic
Developer defines XSL
files for each service
transformation logic
where XPATH and XSLT
both need to be defined
Define service
transformation
logic (optional)
Develop XPATH in the
Service Definition Editor
to develop and test
service transformation
DESIGN AND
DEVELOP
APP USER
INTERFACE (UI)
Start by defining
the app screen User
Interface (UI) layout
Develop HTML Code
to build UI layout
(div, tablet, etc.)
Create UI resources
(including variations of
different screen sizes
and resolutions)
Configure app menus
using Competitor
APIs in JavaScript
Create app screen User
Interface (UI) layout using
visual drag-n-drop editor
provided by Kony Visualizer
Developer uses Visual
Canvas to rapidly
create app UI.
Optionally, developers
select platform specific
properties to leverage
platform specific
UI differences
Define UI form factor
variations and screen
sizes/resolutions from
one platform to another
Develop separate HTML
code for each UI form factor
Not Required with
Kony platform
N/A
Design and develop look
and feel (branding & style)
for each screen size and
resolution
Develop CSS styles for
each mobile screen
size and resolution
Design and develop look
and feel (branding &
style) for each app UI
Developer can leverage
Skins & Themes
Editor to define look & feel
Ability to prototype
along with animations
and interactions. Later
quickly preview app UX
during development.
Leverage basic HTML
preview capabilities
provided by Eclipse
Use JavaScript to build
animations and interactions
Ability to quickly prototype
apps using action libraries in
Kony and to quickly preview
app UI on real devices
during development
Developer uses configurable
actions from Kony library
to build a prototype and,
quickly preview it using
Visualizer preview app to
view the generated native
applications on real devices
DEVELOP APP
BUSINESS LOGIC
Define app logic for
each screen & associated
service invocations to
map the response data to
the app UI or variables
Developer needs to define
JavaScript function code.
Optionally, you may
develop XSL code as well
Developer uses Mapping
Editor in Visualizer to
map data from external
services to UI elements
Developers can use the
graphical interface for
mapping data elements
Define app navigation
logic to capture each event
and screen transition
Developer needs to define
JavaScript function code
Developer uses Action
Sequence Editor
Developers can make
use of the action libraries
to define navigation and
animation sequences
Define core app logic
(decisions, rules,
technical and business
validations, etc.)
Developer needs to define
JavaScript function code
Developer uses Action
Sequence Editor and Logic
Editor with content assist
Developers can make
use of the action libraries
to define navigation and
animation sequences

8. 9
4. Developer Creativity
WHAT ARE THE PLATFORM’S CAPABILITIES TO CREATE
PIXEL-PERFECT ADVANCED-UI APPS WITH NO LIMITATIONS?
Why platforms should not compromise UI:
Besides giving the developer necessary tools to create apps efficiently, a key criteria to consider is whether
the platform allows developers to build pixel-perfect apps with advanced UI features and workflows. Because
a MADP’s key premise is to enable the creation of apps across many platforms and form factors, developers
are often left with an impression that there are tradeoffs to creating a great user experience because they
are limited by the platform’s “common denominator” approach. While it is true that many development
platforms in the market have this limitation, there are ways to identify the platforms that do not.
Creating a great UI is achieved by leveraging cross-platform and platform-specific APIs. Also,
allowing the import of any type of 3rd party libraries is key. Simply review and compare the
number and types of APIs as well as openness to integrate any 3rd party libraries.
P What are the APIs and libraries provided by the platform?
P How is leveraging platform-specific properties achieved?
P What kind of 3rd party libraries can be integrated? Can Native libraries be imported as well?
P Is there 100% native API capability provided within the platform?
QUESTIONS TO ASK:

9. 10
SOA
JS
JAVA
JSONCSS
XML
5. Open Standards-Based Platform
HOW OPEN IS THE PLATFORM AND WHAT ARE THE STANDARDS SUPPORTED?
Why an Open and Standards-based platform is important:
Simply put, open and standards-based products give companies flexibility to integrate
any products and peace of mind that they are not heavily dependent on, and limited by,
the platform vendor’s proprietary technologies. It is important to thoroughly review
the standards supported for each component of the platform like studio/designer,
middleware server, etc., to ensure the minimum dependency on proprietary elements.
Open Defined: A product is NOT open when a customer is limited to
choosing a particular path for its product that the vendor provides, or
if a customer cannot buy 3rd party components and add them in.
Proprietary Defined: A product is proprietary when a customer is buying some
IP from the vendor and is dependent on that vendor for the service.
Table 4: Open/Standards Comparison Table KONY COMPETITORS
EXTERNAL LIBRARIES
Library Usage to build on native mobile capabilities Any native libraries can be integrated
Only Java Script Libraries
can be integrated
SERVICES
REST/JSON Service
REST/XML Service
SOAP Service
Web Services
Java Service
Java Database Connectivity (JDBC)
WEB STANDARDS
HTML5 and CSS 3.0
HTML4 and CSS 1.0/2.0
Service Oriented Architecture
P What development language is supported?
P What standard is the server based on?
P What application servers are supported?
P How is importing 3rd party products supported?
P Are standard connectors supported?
P How are HTML5, HTML4 and older standards supported?
QUESTIONS TO ASK:

10. 11
6. Middleware Capabilities
WHAT ARE THE PLATFORM’S MIDDLEWARE CAPABILITIES?
Why having a robust middleware application is important:
In a platform, the middleware server plays a key role in providing enterprise-grade functionalities
such as integration, security, service and API management, mobile device and app management.
Therefore, ensuring that the server of the platform is robust enough to provide reliable performance
and scalability is crucial. See Figure 8 for a Server Components Comparison table.
P What are the DevOps considerations and capabilities offered?
P What are the connectivity/integration capabilities of the server? What kind
of custom, proprietary and standard connectors are supported?
P How is usage reporting handled? Are there built-in reporting capabilities available?
P What are the options available for enterprise security?
P Is there an option to manage mobile applications and mobile devices?
What is the level of analytics I can build for my mobile applications?
QUESTIONS TO ASK:

11. 12
Table 5: Middleware Server Components Comparison KONY COMPETITORS
Middleware Server Components
Sync Server
Version Management
Synchronization
Over the air Sync
Offline Sync
Conflict Resolution
Messaging
Push Notifications (iOS, Android, Windows)
SMS, email, passbook
Android C2DM Push
Android GCM Push
Integration
Codeless Standard Connectors (Web services, SOAP, REST, XML, JSON)
Proprietary Connectors (e.g., SAP, Salesforce, Database, ESB, etc.)
Custom Connectors
Object Services with Autogen of Data Objects
Orchestration
Looping Services
Concurrent Async Services
Sequential Services
Security
Centralized console visibility
PCI/PII Compliance
App Obfuscation
SSO Support
On Device Encryption
Certificates and client side authentication
Identity Management (Active Directory, Salesforce, SAML, Facebook, Auth 2.0) Partial
Reporting Engine
Mobile data collection
Built in reporting
Adobe Omniture
Google Analytics
Web Trends Analytics
Crash Analytics

12. 13
7. B2E Capabilities
WHAT ARE THE PLATFORM’S BUSINESS TO ENTERPRISE (B2E) CAPABILITIES?
Why having strong B2E support is important:
A true MADP should offer end-to-end B2E capabilities consisting of mobile application management (MAM), mobile
device management (MDM), enterprise connectors and sync server. Without these, deploying mobile apps in an enterprise
environment will pose numerous challenges, especially when Bring Your Own Device (BYOD) is being embraced by the
organization. Simply having an enterprise app store, and incomplete MDM capabilities, will not serve as a true enterprise-
grade platform to create and manage apps. For all the other components, you would need to employ other vendors.
Table 6: B2E Checklist KONY COMPETITORS
Standard Connectors
Custom Connectors
Proprietary Connectors
Sync Server
MAM with secure app container
Enterprise App Store
MDM
MCM
Enterprise Security
P What are the key components of the B2E offering?
P Are both standard and custom connectors supported?
P How is the server handling sync?
P How well integrated are the client dev, middleware, security and management services?
P Does the provider offer any pre-built B2E solutions?
QUESTIONS TO ASK:

13. 14
Table 8: Enterprise Application Connectors KONY COMPETITORS
CONNECTORS
SAP Connector
Salesforce Connector
XML Service Connector
JSON Service Connector
SOAP Service Connector
Java Service Connector
API Proxy Connector
Database (MYSQL, MSSQL, Oracle)
ESB (Mulesoft) Connector
Table 9: Enterprise Security KONY COMPETITORS
DEVICE DETECTION AND SECURITY
Intelligent Device Detection
Encrypted Data Translation
SSL
Multi-Factor Authentication
One-time password
OFX
PKI
Symmetric Cipher
Anti-Tamper protection
White box cryptography of keys
SQLite DB encryption
Cryptography APIs
Table 7: Sync Server Capabilities KONY COMPETITORS
ENTERPRISE APPLICATION FEATURES
Over The Air Synchronization
Offline Synchronization Partial
Conflict Resolution
Bi Directional Synchronization
Incremental Upload
Incremental Download
DEVICE AND SERVER SIDE COMPONENTS
KonySync Libs
(embedded in Application)
Persistence Logic
Change Tracking
Sync Protocol (oData)
Delta Determination
Merge Data with Backend
Expandable on-device SQlite DB unique to an application

14. 15
8. Total Cost of Ownership
WHAT WILL THE TOTAL COST OF OWNERSHIP (TCO) FOR MY APP PROJECT BE?
Why is it important to ask for a TCO study?
Mobile app development has a lot of hidden costs. Even with a platform, app maintenance,
upgrades and development efforts can vary significantly from vendor to vendor. Besides, TCO
analysis will give you a good idea on the overall scope and timeline of the project.
P How detailed is the TCO model?
P Does it include various complexities of screens and integration capabilities?
P Does it take into consideration my team’s size and learning curve and/
or optional services (i.e. vendor, partner, off-shore, etc.)?
P Does it include estimates for maintenance and upgrades?
P Does it include detailed descriptions of each and every task?
QUESTIONS TO ASK:

15. 16
9. Mobility Track Record
WHAT IS THE PLATFORM VENDOR’S MOBILITY TRACK RECORD?
Why customer footprint and number of deployments is important:
Mobile is a relatively new and dynamic space and you cannot rely on a vendor only
because it is a large software/technology enterprise that, in line with many other core
products, offers mobility solutions. When evaluating a vendor, you have to make sure
you are looking to a platform/product that is best-of-breed in mobility. And there is no
better proof than the number of customers and live apps segmented by deployment size,
geography and industries. The more diverse the vendor’s customer portfolio is, the better.
KONY
Number of Enterprise Apps published 1000+
Number of App Users 25 Million
Number of Annual Sessions 1 Billion
Number of professionals specialized in Mobility 1400
P Is the vendor a leader in widely recognized industry reports?
P How many industries do the vendor’s products
serve? The more diverse, the better.
P Has the vendor done multi-country, large-scale deployments?
P How many months does it usually take the vendor to take
the app live after the execution of the contract?
QUESTIONS TO ASK:

16. 17
10. Platform Maturity and
Developer Ecosystem
WHAT IS THE MATURITY OF THE PLATFORM AND STRENGTH OF DEVELOPER ECOSYSTEM?
Why platform maturity is important:
Platform maturity can be gauged by the number of man-hours invested in the development
of the platform (core platform engineering work). Simply put, the more man-months
invested in the platform, the more advanced/superior you can expect it to be.
Why a strong developer ecosystem is important:
A developer ecosystem includes the vendor’s own engineering and delivery team plus system integrator (SI) partners
and other developers trained on the platform. The larger the ecosystem, the more streamlined implementation and
delivery of your project. Also, the sheer size of the ecosystem speaks to the degree of innovation the core engineering
team is able to deliver due to the feedback and interaction received from the larger developer community.
P How many man-months have been invested in the platform?
P How many in-house developers does the company have?
P How many partner SIs have been trained on the platform?
P How extensive is the developer support and documentation?
QUESTIONS TO ASK:

17. 18
Conclusion
BRINGING IT ALL TOGETHER
Why 10/10 is critical to selecting your mobile application development platform (MADP).
By taking a holistic approach to app development – as well as platform vendor selection – organizations of
any size can achieve more control, predictability and speed. We hope this checklist gets shared, printed and
referenced by anyone who is faced with the complexity of enterprise mobility - from designers and developers
to line-of-business leads and CXOs. As a next step in your research, our recommendation is our popular
e-book, 10 New Rules for Mobile Strategy and Success, which you can download for free here.

18. 19
Phone: 1.888.323.9630 | info@kony.com | www.kony.com
To learn more contact us at:
Mobilize the Enterprise
© 2016 Kony, Inc. All rights reserved.
Kony is the fastest-growing, cloud-based enterprise mobility solutions
company and an industry leader among mobile application development
platform (MADP) providers. Kony empowers today’s leading organizations
to compete in mobile time by rapidly delivering multi-edge mobile
apps across the broadest array of devices and systems, today and in the
future. Kony offers pre-built business mobile apps to help organizations
better engage with customers and partners, as well as increase employee
productivity through mobile device access to company systems and
information. Powered by Kony’s industry-leading Mobility Platform,
enterprises can design, build, configure, and manage mobile apps across
the entire software development lifecycle, and get to market faster with a
lower total cost of ownership.