Here, I am including the experience I had while exploring solutions for developing a mobile cross-platform library, i.e. a single codebase that could be part of mobile apps running under different platforms. It covers my journey from mobile cross-platform developments tools (PhoneGap, Titanium, and the likes), code porting tools, and WebViews that weren't up to the task, to C++ and JavaScript engines that did work. There aren't many resources out there explaining how to approach this problem, so we thought it could be helpful if we shared this experience.

1. Developing a mobile
cross-platform library
Kostis Dadamis
11/03/2014

2. What?

3. Description
• Piece of code including common functionality across all
mobile platforms
• E.g. querying a Web API, fetching results, sorting
results, fancy algorithms, etc.
• No UI
• One main codebase
• Some glue code for each platform (focusing on Android
and iOS)
• Package it as a library

4. Description

5. Why?

6. Motivation
• Less code
• Less bugs
• Less testing
• Consistency
• Reuse existing code
• Develop and distribute cross-platform SDKs

7. Attempts

8. Attempts
• Mobile Cross-Platform Development Tools
• C++
• Code porting
• JavaScript in a WebView
• JavaScript in a JavaScript Engine

9. Mobile cross-platform
development tools

10. Mobile Cross-Platform Development Tools
• Mobile Cross-Platform Development Tools
• 18 different tools investigated (e.g.
PhoneGap, Xamarin, Titanium, Corona, MoSync, Kon
y)

11. Mobile Cross-Platform Development Tools
• Mobile Cross-Platform Development Tools
• 18 different tools investigated (e.g. PhoneGap,
Xamarin, Titanium, Corona, MoSync, Kony)
• Output end products (not libraries)

12. Mobile Cross-Platform Development Tools
• Mobile Cross-Platform Development Tools
• 18 different tools investigated (e.g. PhoneGap,
Xamarin, Titanium, Corona, MoSync, Kony)
• Embed a runtime environment

13. Mobile Cross-Platform Development Tools
• Mobile Cross-Platform Development Tools
• 18 different tools investigated (e.g. PhoneGap,
Xamarin, Titanium, Corona, MoSync, Kony)
• Corona and MoSync support this for Android, but it’s a
“coming feature” for iOS

14. C++

15. C++

16. C++
• Build for all possible platforms and CPU architectures
• Glue code
• Android
• Android Native Development Kit (NDK) and Java
Native Interface
• Complicated 
• iOS
• Objective-C++
• Easy 

17. C++
• C++
• Pros
• Official solutions
• Fast
• Ability to import a vast number of open-source
C/C++ libraries
• Applicable to Windows Phone
• Free of charge

18. C++
• C++
• Cons
• Manual GC in Java (workaround by copying)
• Building libraries for all platforms/CPU architectures
is time-consuming
• Documentation

19. Code porting

20. Code porting
• Maintaining code for 1 platform, and translate it for the
other platform(s)
• 7 different tools investigated
• Most solutions immature

21. Code porting
• Worth revisiting in the future
• J2ObjC
• Translates Java (Android) to Objective-C (iOS)
• Hyperloop
• Translates JavaScript to source code for each platform

22. JavaScript

23. JavaScript
• Part of web browsers
• Part of server-side code
• Rapidly gaining popularity
• Reusing JavaScript code?

24. JavaScript in a
WebView

25. JavaScript in a WebView
• JavaScript in a WebView
• Use existing native web-browser Views
(WebViews) to execute JavaScript
• WebViews provide limited functionality to
programmers
• WebView APIs are inconsistent across
platforms
• Could work only with hacks

26. JavaScript in a
JavaScript Engine

27. JavaScript in a JavaScript Engine
• Use standalone JavaScript engine without a View
• iOS
• JavaScriptCore
• Android
• Rhino
• V8
• SpiderMonkey
• JavaScriptCore
• Nashorn

28. JavaScript in a JavaScript Engine
• Problem
• Pure JavaScript engines don’t support networking
• Solution
• Delegate missing functionality to the platforms

29. JavaScript in a JavaScript Engine

30. JavaScript in a JavaScript Engine
• iOS
• JavaScriptCore framework (since iOS 7)
• Pros
• Simple object conversions
• No embedding needed
• Cons
• Lack of documentation

31. JavaScript in a JavaScript Engine
• Android, we have to embed one
• Rhino
• App size 3.6MB (+2.6MB)
• Pros
• Developed in Java
• Cons
• Inactive development
• Outdated documentation

32. JavaScript in a JavaScript Engine
• Android, we have to embed one
• V8
• Pros
• Actively developed
• Cons
• App size 8.1MB (+7.1MB)
• Developed in C++ -> Android NDK/JNI
• Additional translation layer

33. JavaScript in a JavaScript Engine

34. JavaScript in a JavaScript Engine
• JavaScript in a JavaScript Engine
• Pros
• Reusing JavaScript code
• Applicable to Windows Phone
• Cons
• Delegated functionality increases glue code and
overcomplicates architecture
• In Android, either Rhino which is not actively
developed, or V8 which is large and written in C++

35. Proof-of-concept app

36. Conclusions

37. Conclusions
• Some immature solutions are worth revisiting
(Corona, MoSync, J2ObjC, Hyperloop, Nashorn)
• C++
• Pros: Official solutions, fast, access to C/C++
libraries, free
• Cons: Low-level, garbage collection?
• JavaScript in a JavaScript Engine
• Pros: Reusing JavaScript code
• Cons: Delegating missing functionality, Rhino not
actively developed, V8 large and written in C++

38. More info

39. More info
• www.skyscanner.net/blogs (3 parts)

40. Edinburgh • Glasgow • Singapore • Beijing • Miami • Barcelona
thank you

41. Opportunities

42. Opportunities
• Mobile Solution Architect
• www.skyscanner.net/jobs