Deciding Which Development Platform You Should Choose For Your Company’s Next Mobile App

January 25, 2017

By:  John Tomblin, Senior Solutions Architect
Scottsdale Bizz is a wholly-owned division of Sofvue, LLC

One of the biggest myths in the small business community is that once you build source code for your smart-phone app, the same source code will work on other platforms.  Bad news – that assumption is wrong.  Currently, there are three dominant mobile app platforms; iOS, Android and Windows Phone.  Within these platforms are numerous sub-platforms.  For Window Phone, there is 7, 7+ and 8. For the Apple platform (iOS), there’s iOS 1.0, 2.0, 3.0 and 3.0+, and for Android, there is 1.0, 2.0 and Android 2.0+.

As to the many different programming languages used to create apps, there are dozens of options including HTML5, C, C++, C#, VB.NET, Pascal, JavaScript, Java, Objective-C, Swift, Ruby on Rails, Python, Visual Basic, XML, to name a few.

With dozens of options to choose from, how do you decide which platform to develop first?  The answer is… “it depends.”  Here’s four questions you should answer before moving forward with your project.

1) What is the availability of programmers for the different languages?

If you are building an iOS application from scratch for the Apple Store, you want to find an Objective-C developer.  Objective-C is native to the iOS, and there are many programming firms available to support development.  If your app is being developed for the Android Store, you’ll need a Java development firm.  For the Windows Phone platform, you’ll be best served finding a C#, C++ or Javascript programmer.  The more popular the language, the more programming options you will find available for writing source code.  Also, in choosing a firm today, consider your programming needs five years from now.  Will the language you choose today still be popular in five or ten years?  How long has your firm been in business, and will they be around in five years?  Will programming resources still be readily available?

2) How large is the support community for the programming language selected?

If you’re looking at using a specific programming language, but discover the support community is non-existent, it means programmers everywhere have already shifted away from the language in favor of another more current choice.  In the programming world, language choices made by programmers fall out of favor.  What was popular ten years ago might be non-existent today, and a completely unknown language three years ago, might be all the rage.  Like most of us, programmers want to take the path of least resistance.  Great programmers are always on the hunt for ways to streamline and automate their source code, while simultaneously improving the speed and performance of the applications they develop.  They are also always on the chase to locate programming tools and resources that have a large support community, one that allows them to share knowledge and locate information and resources that speed up development time to existing or new source code.  If a programmer is coding in language X, but discover there’s a new upcoming language that’s superior, and they can test new code on a “staging” or “development server”, they’ll do it.  You won’t see many programming firms touting the benefits of languages like Pascal.  It was hugely popular in the 80’s and 90’s, but no so much today.  There is still a small market niche for Pascal, but other languages have since surpassed it in popularity.

3) What does your development team already know, or what programming language do they want to know?

It’s always interesting to learn the backstory of an existing application, and listen to stakeholders and developers explain the original reasons (and often very good reasons) why a language was selected for a mobile app five or ten ago, and yet today find the language choice completely obsolete.  What drove the business requirements five years ago might be completely different today.  Managers come and go, programmers come and go, stakeholders come and go, priorities change and markets shift.  If you’re about to develop a new app, ask your programmers what language they prefer and why, and if you are considering changing an existing app to a different language, do your own due diligence to determine whether the cost actually supports the ROI.

4) If it costs three times as much to write an app in a different language today, but you save ten times the original cost over the next five years, does the long-term return justify the short-term costs?

The short answer is yes, but for an app, it always comes down to the financial return and long-term benefits.  When funding is limited, or bank interest rates are too high, or the app project requires taking revenue from the company to fund development, then it can difficult to switch from one language to another, but that can also be short-sighted approach.  It’s easy to say that a “better” language is available, and that an existing app’s source code should be rewritten, but being able to prove it on paper can be a daunting, if not an impossible task.  In his book “Software Estimation: Demystifying the Black Art”, published by Microsoft Press, Steve McConnell discusses the many facets of software cost estimating, but for many small business enterprises, resources and experience usually fall short since most small companies cannot afford to support a full-time R&D or development team.  The bottom line is this;

(1) if you’re updating an existing app, and your programming team suggest changing to another language, then ask them to provide a detailed list of the pros and cons, and the estimated costs – the real costs.  In a few instances when we knew project costs were going to be high, we hired outside third-party consultants to do a cost analysis.  This allowed us to not only obtain viable numbers, but also complete the analysis with no bias.

(2) Best intentions aside, programmers are biased when it comes to estimating development costs.  Most development firms know they are often in a bidding war, and they don’t want to shoot too high in fear that their project bid might keep them from winning the contract, so they’ll assume no delays, no cost overruns and no scope creep.  The problem is that all three of these tend to creep (scope creep) their way into projects, so whatever cost estimates your programming team provides, double it.  Programmers are brilliant at programming, but when it comes to estimating costs, not so much.  Unless your lead programmer has many years of immersive cost estimating experience, doubling the estimate will provide you with a more realistic estimate of actual costs.

(3) If you building an app from scratch, identify the most popular languages, then find development firms who can program in your chosen language.

To learn more, or to schedule an introductory to discuss an upcoming project, contact our office at 623-845-2747.

Share On