Looking Back on Six Years of Titanium Development

This guest post was authored by Jason Priebe. Jason has over 20 years of experience building and managing large-scale Internet-based solutions. He is a hands-on technologist who spends his days crafting cloud infrastructures, building web applications, developing scalable video streaming platforms, and creating mobile apps. He especially enjoys leading software teams, from the design collaboration with senior developers to the mentoring of novice programmers.

In April of this year, my company launched its 5th mobile app, the WRAL Weather app. This was an app that really pushed our abilities as well as the capabilities of Titanium. It got me thinking about how far our app development has come over the past 5 years.

I lead a team of 6 developers working for Capitol Broadcasting Company, a local media company in Raleigh, North Carolina, USA. Our team’s bread-and-butter is web development (LAMP stack on the backend, jquery/RequireJS on the frontend) and devops (we manage our AWS stack with packer and terraform). Our biggest site, WRAL.com, has about 5 million unique visitors monthly.

Before we first started using Titanium, we were relying on outside partners to build and maintain whitelisted mobile apps for us. As we saw more and more traffic migrating from our web sites to our mobile apps, the apps became more central to our digital strategy.

Years ago, I had urged one of our larger mobile partners to consider cross-platform development options. They were taking too long to get features out the door, and often the Android version of an app would trail the iOS version by months. They rejected the concept and instead continued to rely on platform specialists.

Ultimately, our needs outgrew the partners’ ability to innovate. I don’t think that’s directly related to their insistence on native development, but it may have contributed to it. The partners’ limited resources were stretched with operational responsibilities and code maintenance. Adding new features, especially features that were specific to just one client, became increasingly difficult for them.

We decided to take control of our own destiny and bring development in-house.

Web devs building apps

In my mind, the “build it twice” approach seemed like a highly inefficient way of doing things. Efficiency was even more important when we were considering bringing the development in-house.

My team would be responsible for the mobile app development, and we would still be responsible for improving and maintaining our web sites, continued development of our internal publishing system, keeping up with operational demands from news, sales, and marketing, and maintaining our cloud and on-prem compute environments. We would add the mobile app responsibility with no change in the size of our team.

With a small team (only 6 developers), we don’t have room for a dedicated Objective-C/Swift/iOS developer and a dedicated Java/Android developer. I need every one of my team members to be able to diagnose and correct a problem with the mobile app. We share an on-call rotation, so it is important that all the team members can diagnose and correct problems in mobile apps, web apps, backend systems, or even the compute platform itself. Javascript is something we already use extensively, so using it for app development is a perfect fit for my team.

So, when the time came for us to build our own apps, I wanted to test the validity of my cross-platform ideas; I evaluated a number of toolkits, and Titanium made the most sense to us for a number of reasons:

  • it uses Javascript
  • it builds apps that have real native UIs, not hybrid web apps
  • the UI code is cross-platform; for the most part, you can write your UI code once
  • it already had a large, well-developed API

In 2012, we started with some of our less popular apps and worked our way up to our biggest apps. In 2014, we built the WRAL News app in Titanium (android / ios). This app has about 240,000 installs.

We built the WRAL Weather app
(android / ios) in 2018. This app has about 180,000 installs.


Looking back on this initiative to bring the apps in-house and use Titanium, I consider the effort a success.
By building in-house, we’ve been able to support our editorial, sales, marketing, and product development teams by building the features that they want. Our apps are much more tightly integrated with our publishing system than they were when we used an outside parter; this lets us bring to our apps the kind of rich content our editors create for the web every day.

In addition, our development team has realized considerable efficiency gains by using Titanium. Not only have we been able to make great reuse of our code across platforms (I would estimate that more than 90% of our Javascript is shared between iOS and Android), but we’ve been able to build a nice code base that we share across all of our apps. As much as 75% of the code is shared across our apps.

Here are some interesting stats on the codebase for the WRAL Weather app:

  • 203 JS files (139 shared across app family)
  • 76K JS LOC (56K shared across app family)
  • 9 Android-specific modules (3 built in-house)
  • 6 iOS-specific modules (1 built in-house)
  • 8 Android+iOS modules (2 built in-house)

I can’t easily quantify how much of the Javascript is platform-specific. If I had to guess, I would say that it is under 10%. Most of our platform-specific code is in the native modules.

Titanium has allowed our team to play to its strengths and encourage cross-training rather than specialization. We have been able to build feature-rich apps, and we’ve been able to hit our target schedules. Based on recent observations, the SDK is healthier than ever, as I have seen a lot of effort put into bug fixes and platform parity improvements. Axway’s commitment to the SDK has been extremely encouraging. I look forward to seeing where the platform goes over the coming years.