Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/2cxBuBB. Spencer Chan overviews Quora's architecture that allows them to share the majority of their application code across their Android, iOS and web apps, discussing challenges and benefits. Filmed at qconnewyork.com. Spencer Chan works on the platform team at Quora, where he maintains the web framework and builds abstractions to help product developers work as quickly as possible. Since he joined Quora four years ago, he has worked on native iOS and Android development, mobile web, and building the knowledge prizes feature.

1. Spencer Chan – Quora
Architecting Cross-Platform
Mobile Frameworks

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
https://www.infoq.com/presentations/
quora-cross-platform

3. Presented at QCon New York
www.qconnewyork.com
Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide

4. Motivation
● Two extremes
○ Fully native
○ Fully HTML+JS
● How can we get the best of both worlds?

5. Motivation
● Two extremes:
○ Fully native
○ Fully HTML+JS
● How can we get the best of both worlds?
● For the last 3 years, Quora has used a custom hybrid
framework
○ We're very happy with it

6. Agenda
1. How Quora's app works
2. Design Decisions
3. Learnings from the past 3 years

7. Takeaways
● What can you expect if you follow the same path we did?
● Is this approach worth exploring for your apps?
● What should you look for in a publicly available
framework?
○ Are you better off building your own?

8. How it Works

9. This is a question page

10. This is a question page
Webviews
outlined
in red

11. ● The webview loads a url
● The page is rendered by a tree of
component objects
● This component is used across all platforms
Meanwhile on the Server

12. After page load

13. After scrolling to the end of the answer

14. Pressing the button
HTML +
CSS

15. Pressing the button
HTML +
CSS +
JS

16. Pressing the button
No native code involved at all!
HTML +
CSS +
JS

17. Now for a different example...

18. Here's a user profile page

19. Tapping here is going to show a menu ...

20. Native menu

21. Native menu

22. Message Passing

23. Message Passing

24. ● Implemented differently for each platform
● Asynchronous message passing is more future proof
● Minimal, but can build on top of this
Message Passing

25. Abstraction is your friend
iOS
Obj-C/Swift
Android
Java
Application
JavaScript

26. Abstraction is your friend
iOS
Obj-C/Swift
Android
Java
Web
Framework
JavaScript
Application
JavaScript

27. ● Abstracting away platform specific code simplifies the remaining
application code
● Also useful for cross-browser compatibility
○ This is one of the main benefits of things like jQuery
Abstraction is your friend

28. Design Decisions

29. Design Decisions
1. HTML Content
2. Native Navigation
3. No Page Types

30. HTML Content
Webviews
outlined
in red

31. HTML Content
No native code involved at all!
HTML +
CSS +
JS

32. HTML Content
● Alternative: native views powered by shared application code
● HTML views increase potential code sharing with websites, if you
have one
○ Client side vs. Server side rendering
● HTML is great for text-heavy products like Quora

33. Design Decisions
1. HTML Content
2. Native Navigation
3. No Page Types

34. Native Navigation
● Each navigation creates a new webview and adds it to the
native navigation stack.
● Pros
○ Native gestures
○ Native animations
● Cons
○ Makes prefetching harder
○ More native code, less code sharing

35. Native Navigation

36. Native Navigation

37. Native Navigation

38. Design Decisions
1. HTML Content
2. Native Navigation
3. No Page Types

39. Native UI Examples: How do we implement this?

40. Solution 1: Page Types
● "This is the notifications page"
○ Native code knows it should have certain buttons and styling

41. Solution 2: No Page Types
● "Native UI should have these buttons and this styling"
○ Native code doesn't need to know about notifications
● This makes it easier to maintain a strong abstraction barrier
● Useful if you expect to add or modify page types often

42. Avoid Message Thrash
● Backwards compatibility is painful
● Easier to do without page types, but still a concern
● Avoid UI thrash!

43. Design Decisions
1. HTML Content
2. Native Navigation
3. No Page Types

44. Learnings

45. 1. Be prepared to deal with webview quirks
2. Demystify loading slowness
3. Code sharing goes deeper than views
4. JavaScript lets everyone contribute
Learnings

46. ● Problem:
○ Spike in crash reports saying app ran out of memory
● Solution:
○ It was a new image loader we were trying out
○ Don't load images in JS on that webview implementation
Webview Issues

47. Webview Issues
Our webviews have an animated
loading screen (the 3 dots in the
middle are animated)

48. ● Problem:
○ We want to fade out the loading screen as soon as any content is
visible in the webview
○ But we can't tell from native code when webview has started
displaying content
● Solution:
○ Poll the webview pixel to see when they start changing
Webview Issues

49. 1. Be prepared to deal with webview quirks
2. Demystify loading slowness
3. Code sharing goes deeper than views
4. JavaScript lets everyone contribute
Learnings

50. ● Bandwidth
○ HTML is bigger than JSON
● Multiple roundtrips
○ Blocking on CSS/JS
○ Web performance could be the subject of a whole separate talk
Real issues caused by webviews

51. ● Latency
○ Loading images from a server on the other side of the
world will be slower than loading them from a CDN
● Slow application code
○ Example: not paginating data
○ Again, this could be a whole separate talk
Issues unrelated to webviews

52. Find the real root causes of your performance problems
Be scientific and rigorous

53. ● Our app will have performance in the same ballpark as our
mobile website
● We have a mobile website and care about its performance
● All of our speed efforts are going towards the same thing
At least there's only one thing to optimize

54. 1. Be prepared to deal with webview quirks
2. Demystify loading slowness
3. Code sharing goes deeper than views
4. JavaScript lets everyone contribute
Learnings

55. ● At Quora, the same boxes handle all platforms
○ No API tier
Shared infrastructure

56. Shared deployment tools
We share the same continuous deployment system we use on web

57. ● If there are 100 buttons and 3 platforms, do you need 300 tests?
● Or just 102
Shared UI integration tests

58. 1. Be prepared to deal with webview quirks
2. Demystify loading slowness
3. Code sharing goes deeper than views
4. JavaScript lets everyone contribute
Learnings

59. Javascript lets everyone contribute

60. ● Easy ramp-up
● Designers code
● Few projects get blocked on native development
Javascript lets everyone contribute

61. 1. Be prepared to deal with webview quirks
2. Demystify loading slowness
3. Code sharing goes deeper than views
4. JavaScript lets everyone contribute
Learnings

62. Conclusion
● There are pros and cons to any architecture
● This one has worked very well for us over the last 3 years
● If you haven't tried hybrid app development, maybe it's worth
considering or exploring
○ either by building your own framework, or using a publically
available one

63. Questions?

64. Watch the video with slide
synchronization on InfoQ.com!
https://www.infoq.com/presentations/
quora-cross-platform