Make Cross Platform Apps that Suck Less
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Make Cross Platform Apps that Suck Less

Uploaded on

<p>This presents a framework we built when making the Glastonbury 2011 app for iOS, Android and Qt. We looked at the available options, and found them wanting. </p> ...

<p>This presents a framework we built when making the Glastonbury 2011 app for iOS, Android and Qt. We looked at the available options, and found them wanting. </p>
TL;DR: Javascript app logic, native UI. And we open sourced it.

<p>And it works. The Glastonbury 2011 app was well received, featured in the app stores we released for, and is now winning awards.</p>

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 362 263 27 18 15 15 6 5 3 3 2
http://localhost 2 1 1 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • Even this is a simplification\n
  • \n
  •\n\nBy definition: great utility, great UX \n12 Square Kilometers\n140 thousand people\n65 stages\n1800 acts\n5 days\n
  • \n
  • 3 Native apps ruled out for cost reasons.\n
  • As is the year of the linux desktop\n
  • Reproduced with permission\n\n
  •\n\nThe &amp;#x201C;HTML5&amp;#x201D; marketing message is getting through. &amp;#x201C;The Web is already cross platform&amp;#x201D;\n
  • Nearly right may not be good enough.\nUncanny Valley.\n
  • There is no release cycle, or version numbers. OEMs take a snapshot, then fix the bugs.\n\nWebKit is not the solution to every problem.\nWe focus on web content, not complete solutions to every imaginable technology need.\n\n
  • Joe Hewitt&amp;#x2019;s scrollability\nDavid Kaneda boasting that they spent three weeks getting the scrolling right\ re-implemented it anyway.\n
  • \n
  •\n\nBut also great for prototyping.\nNot commissioned with the users in mind.\n
  • \n
  • \n
  • \nPlatform Services layer is not application specific.\n
  • A Familiar web stack.\n
  • A Familiar web stack.\n
  • \n
  • * provides Javascript wrappers around native widgets\n * minimal differences in APIs between platforms\n * good device APIs.\n
  • ListViews / UITableViewControllers\nMemory Leaks\nDifferent to get right. \n
  • * Interface Builder, or layout editors.\n* No resource selection framework, no 9-patches/slices. No auto selecting retina images\n* Layout is all calculated by the developer using widths and heights.\n\nNot good enough, but great for internal enterprise apps (like Swing)\n
  • The design of the app is compromised, &amp;#x201C;an app you won&amp;#x2019;t be proud of&amp;#x201D;.\n\nYou end up writing lots of native code anyway\n\n(Like any cross platform UI solution) there is always a lead handset. Almost always this is iOS.\n\nSometimes this &amp;#x201C;best effort&amp;#x201D; isn&amp;#x2019;t always appreciated by Android users.\nUnsupported API e.g. quite a lot of the CoreAnimation, because it is difficult to replicate on Android.\n\n\n
  • Quick on this section.\n
  • Impact is a proprietary game engine.\nExperiment was successful, but abandoned, and now uses the appMobi Direct Canvas.\n\n
  • Getting around the uncanny valley problem.\nThe web did a very similar thing when browser meant desktop.\nCurrent winds seem to be shifting in this direction. (i.e. html apps not being native)\n
  • Enormous runtime overhead. Hello World on Titanium 5+ megabytes. Kitchen Sink is 12M\n10% of Android owner will balk at 0.5 meg.\n\nFUNDAMENTAL PROBLEM\n
  • \n
  • \n
  • The presentation layer is written per app, per platform.\nThe application logic is written once per app.\n\nThe native presentation layer talks to JS logic layer only when necessary.\n
  • \n
  • Fewer, fatter calls through the FFI\nThis is a deliberately trivial example. setListData would be a better example.\nRaw events are processed natively\nApp Specific events\n
  • \n
  • \n
  • \n
  • \n
  • Modular javascript good for memory, performance and testing.\nNative Screen Lifecycle events are sent to the screen module.\nThe JS assembly is packaged by a nice build script.\n
  • \n
  •\nKirin was tested on the iOS, and performed well.\nDeveloper weren&amp;#x2019;t comfortable with JS.\n\n
  •\nFor glastonbury, with a few large custom components, \nBuy 1, get next ones half price.\n\nWe only have data for Glastonbury 2011.\n
  • \n
  • Version 0.5\nDocs and demos are not upto scratch\nNot enough services for iOS.\nAlso looking for contrib.\nVery early: little or no documentation other than the source code, and a demo app. \nExpect this to change.\n
  • Qt may come later (depending on demand).\nAndroid much more mature, more services too.\nWindows Phone 7 will almost certainly be targeted.\n\n\n\n
  • \n
  • \n


  • 1. Making Cross PlatformApps Suck LessJames Hugman
  • 2. I am… • an engineer at Future Platforms • We make apps for clients • We’re technology agnostic. i.e. Web, Native, Whatever.@jhugman
  • 3. Story Arc • A public service announcement • A big client, a big job • A painful flashback • Experiments yield a surprising result • The future looks bright.@jhugman
  • 4. Web v Native is a False DilemmaWeb Native
  • 5. Reality
  • 6. Reality? LinkedIn Guardian Angry PhoneGap Titanium Appstore Birds
  • 7. Reality? native Guardian Profanisaurus Facebook UI Gmail LinkedIn Plugins web PhoneGap web Logic native
  • 8. Glastonbury 2011• “…we want users to love us…”• iPhone, Android, Nokia• Hostile terrain
  • 9. Consequences • UI should feel native and platform specific • Assume offline@jhugman
  • 10. Technology Options • HTML app • Something else • Three native apps@jhugman
  • 11. Approach 1HTML5 is coming!
  • 12. The promise@jhugman
  • 13. Executive Summary@jhugman
  • 14. Executive Summary Bu y o ne g et n FREE! ! !@jhugman
  • 15. Fundamental problems • Native is closest to native • Different platform metaphors.@jhugman
  • 16. Webkit Fragmentation • Webkit is everywhere • “No two implementations are alike” — @ppk • Different platform half-lives@jhugman
  • 17. Lots of work • Developer time getting it just right. • CPU is spent doing UI, not your app.@jhugman
  • 18. Developer happiness • Endless browser bugs • Less time building features • #ifdef code@jhugman
  • 19. Addendum • Clients love to pay for web-technologies • but hate the quality@jhugman
  • 20. Approach 2Something else
  • 21. What’s left native ? Too expensive UI Not there yet web web Logic native
  • 22. App Architectures Presentation Layer Application Logic Layer Platform Services Layer
  • 23. App Architectures Presentation Layer (Sencha, JS, SASS, CSS, HTML) Application Logic Layer (Javascript, requirejs, Backbone, SQL, HTTP) Platform Services Layer Webview Native PhoneGap plugins PhoneGap App
  • 24. App Architectures Presentation Layer (written in JS, rendered natively) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) “Something Else” app
  • 25. Titanium“a cross platformoperating system”
  • 26. The Pitch • Write UI in Javascript • Native widgets are generated at runtime • iOS & Android@jhugman
  • 27. JS/Native BridgePerformance is I/O Bound Native Button To Native setText() setTextColor() setBackgroundColor() From Javascript onTouchDown onTouchUp onClick
  • 28. No UI Tooling • No development tooling • No runtime tools@jhugman
  • 29. Other significant problems • Porting by framework’s best effort • Difficult to take advantage of unsupported API@jhugman
  • 30. DOM-less Game LibrariesCanvas APIs implementedwith OpenGL
  • 31. Examples • Game Closure • Impact for iOS • appMobi’s DirectCanvas@jhugman
  • 32. Observations • Game UI is not Platform UI • also see: Web UI is not Platform UI@jhugman
  • 33. UI Performance is I/O Bound • Each bundles its own Javascript engine@jhugman
  • 34. Introducing KirinA new platform
  • 35. Requirements • Maximise code re-use • Native, platform appropriate UIs • Happy developers & designers • Minimal runtime to download@jhugman
  • 36. Idealised Architecture Presentation Layer (written in Native) Application Logic Layer (Javascript, SQL, HTTP) Platform Services Layer (Native) Kirin App
  • 37. Consequences • Platform appropriate UX • Better tooling • Fewer compromises@jhugman
  • 38. Fewer JS/Native functioncalls Activity configureSpecificButtonWithData_(data) To Native configureSpecificButtonWithData_(data) From Javascript onSpecificButtonClick
  • 39. Consequences • Can use existing JS Engine in an invisible WebView@jhugman
  • 40. Priorities • Great performance • Easy to grow • Modular • Easy-to-use Foreign Function Interface@jhugman
  • 41. Super easy FFINative to Javascript:// In MyScreenActivity.javamScreenProxy.onButtonClick();// In MyScreenUIViewController.m[KIRIN fireEventIntoJS: @”native2jsScreenProxy.onButtonClick()”];// In MyScreen.jsexports.onButtonClick = function () { // do some logic.}
  • 42. Super easy FFIJavascript to Native:// In MyScreen.jskirin.js2nativeScreenProxy.setText_andSize_(“Hello world”, 15);// In MyScreenActivity.javapublic void setText_andSize_(String message, int size) { // do the thing}// In MyScreenUIViewController.m-(void) setText:(NSString*) message andSize:(NSInteger)size { // do the thing}
  • 43. Inspired by node.js • CommonJS Modules • Transparent threading@jhugman
  • 44. Hello WorldWould you like to see ademo?
  • 45. Back to Glastonbury• What we shipped: • iOS, native only • Qt in JS/QML, with Kirin • Android with Kirin
  • 46. Outcome• Two apps with Kirin (Android & Qt)• Android app was built in half (50%) the time of either Qt or iOS apps.
  • 47. Outcome• 100,000+ downloads• Featured in all three app stores• Lots of great reviews• Very happy client• Winning awards
  • 48. But that’s not all…
  • 49. Open Sourcing Kirin • Apache Licence • Release early, release often • Looking for feedback • Looking for feature requests@jhugman
  • 50. Current Status • iOS and Android on Github • Coming… • Android Fragments • Windows Phone 7 • Qt (already implemented)@jhugman
  • 51.
  • 52. Follow @KirinJS @jhugman