Cross-platform app development is more important than ever. 10 years ago, you just whipped out your Visual Studio when you needed a client application, but not anymore. With “app-ification” going mainstream on Android, iOS, Windows, and Mac, what is a developer to do?
Web apps are a good solution some of the time (except for that little detail called IE!).
But what about when you need the features and performance of native code, across platforms? And you’re a startup with a small team and impossible deadlines?
Well, at MobileSpan we’ve been living in this world for the past 2 years, and we want to share our approach.
We chose to build our application by integrating with the source code of Chromium.
Chromium is the open-source base of Google Chrome. My co-founder and I are Xooglers from the Chrome team, so we were very familiar with it and it was an easy choice for us. But you don't have to spend 4 years at Google to take advantage of Chrome's rich code base.

But... I'm not building a browser!

So, why would Chrome source be useful to me for cross-platform app development? I'm not building a browser...
In reality, Chrome is much more than just a browser. Chrome code is highly tuned for performance, reliability, and cross-platform compatibility across PCs and iOS + Android devices.
Out of necessity, the Chrome team has created cross-platform abstractions for many low-level platform features. We use this source as the core API on which we build our business logic, and it's made the bulk of our app cross-platform with little effort.
Most importantly -- Chrome code has been battle-tested like almost nothing else, with an installed base in the hundreds of millions. That makes all the difference when you want to spend your days working on your company’s business logic instead of debugging platform issues.
Basically, you can structure your code like the diagram below, where you only write your application logic, and let Chromium do the heavy lifting.
Chrome Development Diagram

So what's in Chrome that's so great?

Well, consider the parts of a modern browser. Chrome contains high-performance, cross-platform implementations of:
  • Concurrency handling
  • Compression
  • Encryption
  • Certificate handling
  • Low-level socket interfaces
  • High-level protocol implementations like HTTP, HTTPS, FTP)
  • DNS resolution
  • Proxy handling
  • Complex disk caching
  • Cookie handling
... and more
What it lets you do is build a single, cross-platform application layer, on top of all this goodness.
Chrome code also has other unexpected, higher-level goodies like:
  • Chrome Remote Desktop,
  • a full P2P (TURN, STUN, etc) stack (used by the Chrome Remote Desktop code),
  • an XMPP client (used by Chrome Sync as well as Chrome Remote Desktop)

Where Do I Start?

First Things First: The right tools to generate your project

The first step in starting your project is to create the appropriate project file for your platform (Visual Studio, XCode etc). Chromium uses GYP to declaratively specify files and project settings in a platform independent manner. I strongly recommend starting your project as a GYP file. GYP generates project files for each platform (Visual Studio solution and project files, XCode project files and Android .mk files). In addition, powerful dependency options in GYP allow compiler and linker settings needed by the various Chromium project files to automatically flow into the projects that depend on them. This drastically reduces your own build headaches, as well as problems when you update your checkout of Chrome sources.

A basketful of helpers prevent your project from becoming a basket-case.

Once you get to the meat of your app, you will find yourself needing all sorts of helper libraries for everything ranging from string manipulation, concurrency handling, synchronization, thread pools, message loops, logging, file manipulation, timers, shared memory management, and more.
If you find yourself starting to write a generic helper class or library, search the Chromium sources first. Chances are very high that you will find just the class you want, with very good unit-test coverage to boot.
The base library in the Chromium sources (found in src/base) provides a vast array of cross-platform tools that cover all the areas mentioned above and a lot more. There are also helpers for platform-specific areas such as the Windows registry or the iOS keychain.
It has become quite the game for developers at MobileSpan to search the Chromium sources for helpers they need.

Network stack, anyone?

Unless you are building your app for Windows 3.1, chances are that you want to talk to a server of some kind. This might involve simple HTTP or HTTPS API calls or low-level socket calls or anything in between.
The net library in Chromium (src/net) is your friend here. You’ll find a full cross-platform HTTP and HTTPS stack, code for cookie handling, caching, TCP and UDP sockets and socket pools, SSL certificate handling, DNS resolution, proxy server resolution ..., well, you get the idea, pretty much anything network related.


Need to handle public/private keys, encrypt data store secrets? The crypto library (src/crypto) is another excellent cross-platform library that is almost sure to have the encryption or key management routine you are looking for. By now, you get the picture of how the sources are organized.

XMPP, P2P, Protocol Buffers etc.

These aren’t things you would normally expect to find in a web browser but Chromium includes an extensive XMPP and P2P client library built on top of libjingle (look at src/jingle and src/remoting). If you use protocol buffers in your code, GYP has support for .proto files. Just add the .proto files to your GYP file and it will do the right thing of building the protoc compiler and generate wrapper code for your protobufs. This even works for iOS projects.


Your code is only as good the unit-tests you write for them, right? Though not strictly a part of the Chrome, the GTest and GMock libraries that are part of the Chrome checkout provide an excellent framework for writing unit-tests and mocking your C++ classes. All Chrome tests are written using these frameworks so you have a big sample codebase to get inspired by.
GYP even creates platform-appropriate containers for your tests. For example, on iOS, it will automatically create an iOS app to contain your tests so you can run them in the simulator. You just write your tests in cc files, add them to a gyp file, add the right dependencies and viola, you have cross-platform unit-tests.
At MobileSpan, we implemented the core of our business logic in a cross-platform library that is built using Chrome. We then built our UI per platform that uses this underlying library. Porting our app to a new platform means mainly building the UI layer on the new platform and then tying it together with the cross-platform client library.

Conclusion: Tying It Together

If I am sounding like a Chrome fan-boy, that’s because I am one. Since we embraced Chromium more than 2 years ago, we have found it to work really well for us as a dev platform, saving countless person-hours. It has allowed us to reuse some really well-written and, more importantly, well-tested code across several client platforms, and to concentrate our efforts on making a solid product that works equally well on multiple platforms.

Items for a future post

This just scratches the surface of using Chrome source as a development platform. What should I cover in a next post?
Some options include:
  • Deep dive into specific libraries like Network, Crypto, etc.
  • Keeping up to date with Chromium sources
  • How to fork and keep your sanity (and knowing when to fork certain sources)
  • Process of checking out Chromium sources
  • More details on cross-platform UI development
Have you poked at Chrome's codebase or used it to build a cool product? Tell us about it in the comments section.

Sanjeev Radhakrishnan

Sanjeev Radhakrishnan

Co-Founder and CTO, Sanjeev leads technology development and architecture at MobileSpan. He brings many years of experience from working on Google Chrome's security and sandboxing.