SDPs: Native or Browser-based Mobile Apps?

Mobile services is one of the hottest places in the single-dealer platform arena right now as tier 1 investment banks chase the retail banks and online brokerages by providing corporate and institutional mobile offerings.

JP Morgan kicked off the race early last year, launching an iPhone version of MorganDirect – an institutional foreign exchange and rate trading platform – and other banks have since released a wealth of research, analytics and portfolio management apps for both internal staff and external clients.
While sell-side traders might not be swapping Bloomberg terminals for a handheld devices any time soon, it seems inevitable that banks will invest in mobile technology to cater for buy-side ‘anytime & anywhere’ demand, to increase flow and offer value-add.

And as business pursues mobile pre-trade, execution and post-trade services, e-commerce managers face some rather tough questions:

• What devices can be supported?
• What specialist resource & expertise is needed?
• How do you manage security & compliance?
• What services can be targeted at such devices?

To help answer these, you’ll need to choose whether your application will be ‘native’ (written in same language as the operating system) or whether it will be a ‘web app’ (written in web languages).

Native Apps

The traditional way to progress is to build up specialist development resource in the relevant mobile technologies, implementing your application using native platform languages. Suppliers like Apple, Microsoft, Google and RIM are keen promote their platforms, so they provide well-productised SDKs to make it quick and easy to build native apps. All the above provide device emulators which are integrated into the development environment with debugging capabilities.

Most recent institutional apps have been written using the iOS SDK, likely due to device uptake, the locked down security model and the relatively small range of physical devices & operating system versions. Exceptions include RBS’ MarketIndex targeting Android before the iPhone, although it’s more retail focussed than institutional.

It should be noted that iOS SDK requires a Mac-based development environment, and relatively specialist resource (Objective-C/XCode). Consultancies like ScottLogic and Rule Financial operate within the corporate/institutional space to deliver such offerings.

Native languages give low level access to all the capabilities of your device – you can access to the accelerometer, compass, 3D hardware accelerated graphics, multi-tasking, camera, file storage (given necessary permission). This bodes well as a lot of second generation single dealer portals are looking for novel features, striking graphics and innovative use of device hardware.

For each device targeted, you’ll need to have to have a deep understanding of each language, how low-level features work and how to support version differences in OSs.

In the past it hasn’t really been practical to re-use much code across iPhone, Microsoft, Android or Blackberry applications. However specialist cross-compiling technology such as IdeaWorks Labs’ AirPlay SDK is now available to address this problem. AirPlay cross-compiles on a machine-code level, meaning there’s no impact on performance while retaining low-level functionality such as OpenGL graphics. A less performant option is use the Adobe AIR runtime, which interprets Flex on most major tablets & smartphones.

To proxy your services over the web, a web integration layer is needed to marshal data to & from the device. Traditional standards are REST or SOAP, although there are many new emerging specifications such as JAX-WS, WS-I and SAAJ. A distribution engine is needed for web streaming and low latency trade messaging, such as Caplin Liberator paired with StreamLink for iOS or StreamLink for Java.

One big question is how to distribute your native app; if you are working with iPhones or iPads you’re be dealing with the Apple AppStore. This is a huge problem for institutional players who don’t wish to be affiliated with Apple’s compliance regulations; Apple asks for a lot: you’re not allowed to distribute trials, demos or beta versions of your app and you can’t charge for upgrades. You have no guarantees for app acceptance, and aren’t informed how long acceptance will take.

Browser apps

An alternative to using a native language is building web apps using HTML/CSS/JS. Web apps can look & behave just like native apps, and have the inherent benefit of working on any mobile device with a web browser.
Interestingly the mobile web apps market is growing much faster than the native app market, and this trend is most pronounced in the services sector.

Source: http://www.taptu.com/metrics/TaptuMobileTouchWebReportJan2010.pdf

There is no installation process associated with web apps; the first run persists it inside the device’s AppCache. The app can then be run offline without touching a web server. Upgrades happen automatically too; web apps check the web server for new versions, updating the AppCache when necessary.

As web apps can be served from any web server, there are no Apple compliance distribution issues. Pre-trade and execution services can be streamed using a Comet distribution engine such as Caplin Liberator and StreamLink for Browsers. Note that the performance of browser communications is rapidly improving with the advent of WebKit browsers and Web Socket support (iOS 4.2).

Web apps still need to be targeted at specific devices; differences in devices e.g. touch gestures and form factors need to be incorporated in the implementation. There are some useful frameworks to help build and style web apps appropriately for the target device; for example the iPhone SDK includes the Dashcode tool for iPhone styling. Other frameworks target a wider number of platforms, such as jQuery Mobile, Titanium, RhoMobile, PhoneGap.

In terms of expertise you’ll need web developer skills rather than iPhone/Android/Blackberry SDK expertise, which might already be available in-house. JavaScript IDEs have recently advanced rapidly offering syntax validation, debugging and code assist. Examples include WTP, Apatana Studio, Eclipse Helios, IntelliJ and VS2010.

Web languages handle internationalisation/localisation very well, supporting different alphabets, regional settings and number formats. They do not however provide access to the low-level features of a device such as the camera which may restrict their remit.

The responsiveness and performance of a web app largely depends on the JavaScript engine within the mobile browser. JavaScript code does not execute as quickly as compiled machine-code, so very CPU intensive applications are better off written in the native language. However the latest browsers run JavaScript orders of magnitude faster than the Internet Explorer 6 days. In addition new HTML5 features such as ‘web workers’ will allow scripts to run concurrently, improving application performance.

Summary

While native apps give the fastest performance and low-level access to device functionality, browser-based web apps are swiftly being adopted to target broader ranges of devices.