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.
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 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
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.
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)
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.