As software developers, the options at our fingertips when building applications are legion. You can choose to build your front-ends using mobile tools, HTML tools, desktop tools, or a combination thereof. Once you've chosen your front-end(s), you then need to decide on a data strategy. Do you build using “classic” databases like SQL Server or Oracle? Or do you take the plunge and build on a NoSQL data store like Mongo, Document DB, or Dynamo? Then there's the choice of infrastructure. Do you host on your own hardware, or do you use a cloud provider like Amazon Web Services, Google Cloud, or Microsoft Azure? Then there's the ever-fun choice of development language. Do you build using Python, Scala, C#, Ruby, F#, Java, JavaScript, Node, etc., etc., etc.
As a software consultant, my clients expect me to look out for their long-term interests in making these choices. As many of you already know, this is a primary focus of many of my editorials and I'm choosing to revisit it again, because in the last 30 days, I've had to advise several clients and colleagues about this very subject.
In the last month, I've been working with a client who's about to begin building a new mobile application for their customers. Currently, they contract to another organization who provides a “generic” mobile application bolted onto their existing infrastructure. The client has chosen to build their own custom application and bring development “in-house,” by which they mean using contractors who'll build the first versions of the application before it's moved to an internal development team. During the project discussions, the choice of development tools came up. The myriad tool choices seem to be the “800-pound gorilla” of mobile development.
The first toolset considered was Xamarin. Xamarin is a cross-platform development tool owned and supported by Microsoft. One thing in Xamarin's favor was its choice of XAML for markup and C# as the underlying language. This was favorable because the client uses the Microsoft Stack for development. The negative was that the mobile application development company we chose because of their depth of mobile development experience doesn't build using Xamarin, so the time to market was uncertain and we were unsure whether we could provide an experience that felt native to the two mobile platforms we would support (iOS and Android).
The next platform discussed was React Native. React Native is an open source, cross-platform tool by the teams at Facebook. React Native uses JavaScript as its development language and provides a set of tools and libraries used access the native features of the various platforms. We liked the concept of using JavaScript as a development language. We also liked the idea of using one tool for all of our development efforts; a single code base has lots of merit. Although these were both positive features, we were a bit reluctant on two fronts. The first was the newness of the stack - the client I work with is conservative when it comes to development choices. The second negative was the available pool of developers. Because of the newness, we were unsure if we could recruit developers to come work on this application in the future. Sometimes, good products don't last long.
In the end, we decided to use the native tools for each platform. The iOS build of the application will use Objective-C/XCode and the Android build will use the native Android SDK. We chose these platforms for a number of reasons. The most important reason was user experience. By building applications in the native SDKs, we were 100% confident that we'd be able to deliver the experiences that users have come to expect. We also chose these platforms because of the rich depth of knowledge available. There are literally dozens of training classes, Stack Overflow posts, and books available to help solve any issue that might arise. Finally, we recognized that we'd have a simpler time recruiting developers with knowledge in each respective stack than if we went with something new.
We didn't make this choice without careful consideration. We factored in the idea of supporting multiple code bases, which, in the end seemed to be a minor downside compared to some of the risks associated with the other available choices. I'm excited about the many positive aspects of a product like React Native - and you'll read more about that elsewhere in this issue - but it just wasn't right for this particular client.
It's difficult to choose a development stack in today's development environment because the field is so rich with options. It takes time and proper consideration to make these choices.
