Building iOS and Android apps with React, ES6 and PhoneGap

Front End Software Engineering in the Service of America’s Pastime

These are exciting, if not volatile, times for front end software web engineering. New libraries and frameworks appear every day. Most have a pretty short shelf life. Tens of thousands of abandoned Github projects exist only to impress potential employers. But a few really stand out as both novel and practical. One of our top front end engineers Rich Goldman describes a project he built that uses React, an open source front end framework by our friends at Facebook, which stands out as the best of its kind, at least for the foreseeable future.

In this first of two articles, I’ll give an overview of how a friend and I took an idea for a simple, monetizable smartphone app from inception to publication. I’ll explain why we chose the combination of technologies we did from the vast array of open source options that were available to us, and I’ll be sure to point out anything we found interesting along the way.

The idea itself is called “Pitch or Perch.” It’s a fantasy baseball app that assigns numeric scores to starting pitchers, which quickly lets users determine whether they should start a given pitcher or bench him. This is normally the most difficult aspect of managing a team, because there are literally hundreds of starting pitchers in Major League Baseball. Beyond their natural talent, pitchers can display a wide variance in quality from start to start. They’re prone to hot and cold streaks; they may be facing a gargantuan offense, such as the historic 2016 Red Sox; they may be up against an ace on the opposing team, which would greatly decrease their chances of getting a win; they may be pitching in a ballpark that has thin air, like at mile-high Coors Field in Colorado, where the average ERA is a full point higher than in any other stadium. These are just some of the factors that play heavily into whether a pitcher is going to hurt or help your fantasy team on a given day. It’s almost impossible to keep track of all this, so an app that uses a good data feed and a set of relatively simple algorithms can quickly help users set their pitching rotation with confidence and move on with their day.

Before you can decide on front end technologies, you need to have a good handle on what you’re trying to accomplish. In our case, we knew we wanted to build a fairly simple app that we could sell through the iTunes and Android Stores. A common misconception is that you need to have a separate iOS developer and Android developer who build out the apps using different languages and codebases. While this may be true for real-time multiplayer games, it’s often possible to write the code once using HTML5 and JavaScript and then port that to iOS and Android (and other platforms) using Adobe PhoneGap. There may be a trade-off in how smooth the overall experience is, but you can also save a huge amount of time and money with just a minimal loss of experience, assuming the interaction between the HTML5 and the platform APIs isn’t overly extensive or twitchy.

In our case, the user was primarily reading data (just vital pitcher stats and the numeric score), and so the app seemed like an excellent candidate for PhoneGap. We decided the app should just update itself overnight with the next day’s projections. In fact, we didn’t even need the user to log in, because we weren’t collecting any information from them. At some point in the future, we may allow the user to store their pitchers in our database, but with only about 30 or 35 pitchers starting on a given day, it’s not a big concern for launch date: Opening Day 2017.

One feature we believed critical was being able to see at least three days out. A common issue in leagues with daily lineups is that the user might “go dark” for a period of time — usually it’s kayaking with the family or something equally prosaic. They need to be able to set their lineups at least a few days in advance.

And this is where it helped to work with a good data feed provider. After some research, we realized there really weren’t many options for reliable MLB data. I was surprised to learn that MLB doesn’t even offer a developer API for player statistics. They collect statistics comprehensively — and you can view them as HTML on their website — but there’s no free or paid service that allows you to access that data via REST calls. We looked at a few javascript libraries for scraping HTML, but it seemed like a terribly tedious and brittle approach. Next, we looked at some sports feeds by Yahoo and fantasy startups such as Rotowire, but they didn’t have the breadth of the data we needed — which was a considerable amount. We needed every pitcher’s stats for the season up to that point. Our algorithms required every pitcher’s complete projection data from multiple sources such as Yahoo, DraftKings, and Fanduel; stadium data; and team hitting statistics. Luckily, there was one company that could provide us with an API that robust — a startup called, you guessed it, FantasyData ( After expressing our need to see projection numbers multiple days out, they added that data immediately. Try that with a company like Yahoo!

The simplicity of the interface suggested that React could work well for us. Obviously, React isn’t the best solution for all situations. Complex enterprise products might benefit more from full-featured frameworks such as Angular or Ember. In fact, React is just the “View” in the traditional Model-View-Controller pattern. It’s meant to be lightweight and agnostic about the data behind it. React behaves very well with the latest specification for javascript, ECMAScript 6 (also called “vanilla js,” meaning you don’t need to use libraries like jquery anymore — vanilla javascript is good enough). The two go hand in hand, which makes it a good long-term choice for dev teams that want to stay ahead of the curve. As opposed to a complex framework like Angular, which has an extremely steep initial learning curve and often locks you into using older libraries, any javascript engineer can learn basic React within a week or two and be able to build practical applications quickly using the latest in ES6 techniques and best practices.

One thing that confuses a lot of people is that packages of javascript code must all work in concert to function as a complete application within a given environment. The packages you use for a project have their own versioned dependencies, and these are all managed by the Node Package Manager (NPM). Often the functionality of these tools overlap to some degree, and so you need to experiment and research quite a bit to find the best combination of tools for a given situation. A lot of this wisdom is anecdotal, picked up along the way through blog posts and confessional StackOverflow comments.
A couple of important tools we used are Webpack and Babel. Without getting into too much dry detail, these libraries allow you to transform and transpile your assets, similar to compiling a desktop app in Java or C#. React views need to be transformed into HTML and javascript. Additionally, Internet Explorer doesn’t fully support ES6 (of course), and so you need to transpile it down to ES5 if you want your app to work in IE. These processing steps are accomplished with Webpack and Babel.

Luckily, we can automate these steps using another very popular tool called Gulp. Gulp is a javascript build tool, not unlike Ant for Java or Make for the Unix platform. But since Gulp is javascript, not XML, it’s quite flexible, powerful, and easy to debug. There are literally thousands of Gulp plugins that you can import into your build chain to do a wide variety of tasks ranging from deployment to CDN to customizing your development environment. And since Gulp works with data streams in memory, you can run intensive build processes quickly — assuming you have the RAM.

In our case, we just wanted some basic post-processing functionality for our app. We wanted to minimize and obfuscate our javascript libraries; minimize our CSS; and we wanted to watch certain directories and files for changes so that we could automatically run Webpack and Babel to post-process and re-deploy. Gulp did all this for us and easily. In the future, we may use it to automagically generate image sprites and relevant CSS; optimize pitcher photos for different devices; or even create sourcemaps for our compressed assets, which would allow us to easily debug obfuscated code and CSS. Gulp is our friend.

With our basic tools configured and in place, we were finally ready to work on the app.

First, we figured out the algorithms we would use to calculate our pitcher scores. This is part of our secret sauce, but we can let on that it involves an amalgamation of projection data from different sources. We tweaked the algorithm to print out a score between 60 and 140 for each pitcher. In line with sabermetric statistics, a 100 represents an average start for a pitcher. A 140 represents a start is 40% better than an average start. Obviously, this part is very difficult to quantify, especially considering leagues have different scoring formats. What might be a great start in one fantasy league might be only mediocre in another. But these approximations are close enough for launch, and we’ll eventually allow users to input their league’s scoring format in order to provide them with more accurate predictions. We’ll be keeping a close eye on our calculations and will likely have to tweak things as time goes on to improve our predictive model.

Now on to the React app itself. React relies heavily on the idea of “components.’ A React component consists of the markup associated with a piece of the layout, plus all the javascript required to render that piece of the layout dynamically. For example, the list of the starting pitchers is a React component, so we created a Javascript Extension file called PitcherList.jsx. A Javascript Extension file is just a React view before it’s been converted into pure javascript and markup via Webpack. Think of JSX as being similar to a server-side scripting language such as PHP or ASP, except the language itself is ES6 and the script is executed on the client, not the server. Combining markup and javascript in the same file flies in the face of conventional wisdom, which for years has called for a clear separation between content, presentation, and logic. But React allows us to mingle markup with script so fluidly that it makes sense — as long as the view isn’t overly complex.

Now that we had the list of pitchers, the other major view we needed to build was the pitcher’s vital stats that would appear when you clicked on his name in the list. We called this file PitcherDetails.jsx and added the appropriate HTML5 and ES6 to build out that view. Since Gulp was configured to watch our jsx directory, it automatically picked up on the new file and did the proper post-processing and re-deployment via Webpack and Babel.

We needed one more component, called PitchOrPerch.jsx, which was simply the container for both PitcherList.jsx and PitcherDetails.jsx. In React, a container for other components is a component itself. With three fairly simple React components, our content was complete for launch. Next came the styling. We used the new CSS flexbox model — finally supported across modern browsers — to allow for responsiveness across devices, which was critical for our app. Smartphones have a huge range in resolution and pixel density, and flexbox allowed us to support all these sizes with a minimal amount of effort — and without having to include heavyweight dependencies such as Twitter’s bloated Bootstrap library.

Finally, a few too many hours were spent scanning through gigantic font foundries searching for baseball-inspired fonts, and writing arcane CSS to get the fonts to display on every browser and device.

At this point, I hope you have a better understanding of what it takes to build a simple React application from beginning to end. As I noted before, a real-world app requires not only React but a host of other tools and dependencies, as managed by Node Package Manager.

In my next post, I’ll detail the thrilling travails of converting and optimizing our app for our target platforms, iOS and Android, using Adobe PhoneGap. We’ll look at the process of testing and debugging with tools such as BrowserStack, and at getting our apps approved and published in their respective online stores. And finally, we’ll talk a little about our marketing approach and we’ll see how we actually do in the first month of launch, April 2017.

Batter up!


Sorry, comments are closed for this post.

Boomcycle is a San Ramon, California technology consulting and custom software solutions provider. We enjoy stable, long-term relationships with dozens of highly-skilled and experienced technology business experts, software engineers, project managers, web designers and software architects throughout the United States.

Would you like to save money and increase the value of your business?

Let’s Talk


The contact form prepares us to help you as quickly as possible

Let’s Talk