Selection and setup of platform and tools

The brief

This week we’ve been tasked with the setup and configuration of the tools we need to start making applications. As stated in the introduction video we need to identify a small selection of tools which will aid us in our field of interest, and then we need to set up and configure the tools we need to create an app.

We should consider relevant languages, integrated environments, version control systems, software development kits (SDKs) for key platforms, and other computer aided software engineering systems.

We’ve been steered toward picking the right tool based on the nature of the app/s we want to create, and to concentrate on the tools that are relevant to the apps we want to make.

It is identified in the video that:

The challenge is knowing you cannot master everything.

Understanding the brief

The brief this week is incredibly assistive in guiding us through this task. The advice to pick the right tool based on the nature of the application/s you want to create is paramount and this should be the first thing to consider.

As it states, and as I am more than aware already, there are numerous platforms and tools to choose from. We’ve been given the hint not to try and master everything. This is a key statement that should resonate when approaching this task, being mindful of this throughout will prevent me getting caught in the trap of tinkering too much with different systems.

Another thing to consider is falling foul of focusing on the newest and coolest tech. I’ve seen it so many times in my career where developers can flit between technologies (and jobs) because they are driven by shiny new ways of doing things which are exciting. I understand it’s exciting to work with a new technology but it’s important to understand when a technology becomes viable for selection - By all means we should try out anything and everything as soon as it gets announced but we should be mindful of the fact that the technology we embrace will have bugs, will lack support documentation, and if that technology does stand the test of time (which it might not), will likely be re-versioned dramatically and improved so much that later versions are not backwards compatible and your application could quickly become outdated and need to be re-factored.

Take Angular JS for example, version two was such a departure from version one that it required almost a complete re-write of your application in order to update to it. In comparison take React JS, React has improved greatly since it’s release in 2012, and though it has had many major updates and the approach of writing a React application has advanced immensely, updating to a later version has never been a struggle.

My approach

In order to select the most relevant platforms and tools I’ve outlined the following structure:

Identifying what applications I want to create

I will look at my background, my likes and dislikes and influences with regard to applications that I use regularly and those that don’t interest me. I will use my past experience in creating various applications of differing types to highlight specific areas that are most exciting to me and use statistics to evaluate the viability of my chosen application types within today’s market place.

Identifying the right type of platforms and tools

I will look the the typical platforms and tools used to power the types of application I identify in the section above and seek to find a variant for each application type that I can consider for adoption.

Picking the right platforms and tools

I will look at the advantages and disadvantages of each of the platforms and tools short listed in the previous section with a view to select my preferred suite.

Analysis

Identifying what applications I want to create

This should be the easy part right? We all know what we want to create? Fortunately this is true in most peoples cases, we’ve all had a lot of experience to get to where we are and we know what we are interested in. The what we’re interested in is very important, experience has taught me not to try and build something for myself unless I am both close to the subject matter and I am passionate about the solution. Simply put:

Don’t build something unless you would use it yourself.

If I look at myself and where I’ve come from I can identify easily with who I am and what I should be creating: I’m an artist at heart, I was always meant to do something with art. I’ve always liked urban stylistic art in the form of comics, graffiti, skate and surf art. I’ve always liked character design and take influence from urban artists such as Pete Fowler or Shepard Fairey.

I am not a big gamer, I used to be when I was younger but this has not transferred to my adult life, I do like the challenge of a short game and I like the graphics in some games but this is about as far as it goes. What I am interested in is new technology and it’s application, on the one hand to wow the user, and on the other to provide users with exciting tools to enrich their lifestyle or that could help them to live a better or fuller life.

So I can take all these things along with my experience of creating other applications and throw them all into a melding pot, and from a personal point of view start to form the type of application/s I want to create. I see these as being:

Utility applications that are exciting and possibly could improve users lives.
Interactive experiential applications that wow users.

Bearing this in mind I can look at existing applications of this type and see that:

Utility applications that are exciting and possibly could improve users lives: This type of application requires constant regular use, especially if the application is looking to improve or enrich peoples lives. An example of an enriching application might be Map My Fitness that allows it’s users to better experience their exercise and in turn improve their fitness. This type of application would be useless without being mobile.
Interactive experiential applications that wow users: This type of application is based on new emerging technology. By virtue of this it can have a limited lifespan and is often not something that gets everyday use, but rather it could be a high end technical piece to wow consumers as an installation at a trade show or could be used as a technical piece on a feature film. An example of this type of application might be The Audi Walking Virtual Reality (VR) experience created by Zerolight that allows users to walk around and explore an Audi car, utilising the large play area of the HTC Vive.

Aside from what I want there also needs to be some market evaluation in order to solidify my decision to embrace the paths on which I am heading. The idea of shaping a career around what you like creating only works if consumers will buy the things you create. For this reason I am going to expand the above two examples as case studies:

An enriching lifestyle application

Map My Fitness was first launched in 2007, the project was funded over six rounds of investment totalling $23.7 million, it was acquired for $150 million in November 2013 by Under Armour. At time of purchase the application had a reported 20 million registered users worldwide. Map My Fitness comprises of multiple cross platform mobile applications and supporting web applications.

Statistics taken from Mobile Health News and Crunchbase.

An interactive experiential application

The Audi Walking VR experience was created for Audi by Zerolight in 2016 and was noted at the time as being one of the best VR experiences from a brand seen so far. It’s obviously quite hard to identify exactly how much this application cost to create as companies are sensitive to giving away this type of information, but we can look at VR costs globally.

Based on research VR applications can take between 500-2000 hours to create with an average global day rate of $80-120 which yields a rough estimate of $40,000-200,000 per application.

I can back this up with personal experience and take an average of similar experience applications that we have created at Antiblanks that have taken roughly 400 hours and carry a cost of roughly $40,000.

Considering these rates coupled with the growing adoption of VR worldwide and the fact that companies like Zerolight exist and are being scaled around this specialism does paint a very successful future for VR experiences.

Statistics taken from Think Mobiles and from personal experience.

Identifying the right type of platforms and tools

Now that I’ve identified the type of application/s that I am interested in creating I can select the right platform and tools for the job. Again I will look at both application types but this time list the common platform and tools required to build these applications:

An enriching lifestyle application

This type of application is intended for high use across a range of devices. The project duration depends on the success of the application and it’s traction and continual use in order to drive further investment. For these reasons the application will need to be available on multiple platforms including (at minimum) iOS, Android and web. Also the application will require constant updates for maintenance and to deliver new and engaging features, and this will result in a large amount of development.

In order to lower costs, maintain consistency and drive more features I should focus on cross platform scripting languages and tools for this type of application. Some of the languages/frameworks I will be considering are Angular JS or React JS with PhoneGap (Apache Cordova), React Native, Python with Kivy and C# with Xamarin. I will also be looking at the IDEs Android Studio, XCode and Visual Studio.

An interactive experiential application

This type of application is often intended for specialised use within a controlled environment. Having control over the environment means that the distributor does not need to offer the application across a range of devices. The wow factor is key to the success of the application and this is achieved by using cutting edge technology and pushing the boundaries of it’s capability. There is often a hardware integration involved, and in my past experience working with Leo Associates what I’ve been told clients are looking for is:

The next big thing in technology to make their installation stand out and create a talking point.

Quote taken from Neil Smith, co-owner of Leo Associates.

In order to deliver applications of this nature I will be looking at current technologies including VR and Augmented Reality (AR). To create VR experiences I will need goggles such as those made by Oculus or the more cost effective Samsung Gear VR. I will need to consider the language and 3D engine used to power the experience and for this I will be looking at C# and Unity and C++ and Unreal Engine. I will also need to consider a tool for creating 3D models for use in the experience, for this I will be looking at Blender and Google SketchUp.

Picking the right platforms and tools for cross platform development

Now that I’ve short listed an array of viable platforms and tools for cross platform development I am going to look at the advantages and disadvantages of each in order to select my final candidates for adoption.

Angular JS or React JS with PhoneGap

PhoneGap’s main benefit is it’s ease of use. If you are a web developer like myself, it’s very easy to make a working application using tools that are very familiar (HTML, JavaScript & CSS). PhoneGap is also very quick to develop with, being that you are essentially developing a website to run in the devices in-application web browser then a lot of the Native complexities need not be considered.

The PhoneGap framework is also quite mature; it’s first release was in 2011 and this means it will be stable, will likely not have any major rewrites, will be well documented and will be full featured.

However, one of PhoneGap’s main strengths is also one of it’s main weaknesses; running in the devices in-application browser results in a noticeable performance hit within the UI layer. If you’re application is complex this affects the responsiveness of the UI, this is because all of the processing is taking place within the single UI thread.

In summary, PhoneGap is great for web developers who want to dip their feet into mobile application development. It’s also a good option for experienced development teams to create prototypes or proof of concepts (POCs) to test a potential application or to add value in a pitch situation. But in my opinion, for the applications I want to build, there are better options available to me in this space.

Release year taken from the PhoneGap (Apache Cordova) page on Wikipedia.

React Native

React Native is very similar to PhoneGap in that, for web developers, it’s very easy to make a working application using tools that are very familiar (HTML, or rather JSX, JavaScript & styling similar to CSS). However under the hood they are quite different; React Native is more advanced in the sense that the application it compiles down to is more native. Using iOS terminology to form an example, React Native translates to Native UI components rather than WebView UI. In layman’s terms this means that the application is not a website running in the devices in-application browser, but instead it is compiled to an actual native application.

This has many benefits, the main difference can be seen in the user experience; native applications are more responsive and are not hindered by the constraints of the in-application browser. Also, React Native, though written in JavaScript, supports multi-threading which enables you to run expensive background processes without impacting the rendering of your UI.

React Native does have some drawbacks: It is not all that mature, it was first announced by Facebook in 2015 so it is only three years old, the documentation is good however and there is support for most core components but based on experience upgrading to newer versions can be time consuming and we are still seeing regular feature deprecations. Saying that, the framework is stable and we at Antiblanks and other software houses have been using it to build production applications for some time.

In summary, React Native is a better option to PhoneGap I feel. From a personal point of view I know the framework well, I’ve always liked working with React and I can develop quickly with this technology. Also, despite being in it’s infancy, given the success of React and how the Facebook team behind this has managed releases and maintained backwards compatibility in the main part, I am confident that React Native will be around for a long time and will not suffer any major breaking version alterations.

React Native, or rather JavaScript, does have limitations, and though React Native is capable of delivering the application in the most part, I may need to adopt a small amount of native script (Swift or Objective C for iOS and Java for Android) in order to perform certain parts of the application and then communicate with these over the React Native bridge.

Release year taken from the React page on Wikipedia.

C# with Xamarin

Xamarin is built on top of the .NET framework. Xamarin was founded in 2011 but the framework was not adapted to compile to native iOS and Android until the release of Xamarin 2.0 in 2013. It was acquired in 2016 and is now owned and maintained by Microsoft. The fact that Xamarin is one of the more mature frameworks and is now owned and maintained by Microsoft speaks volumes about it’s longevity.

Saying this, a counter to this argument would be to reference the short lived and now deprecated Microsoft Silverlight. I think in this case though, that had more to do with web trends and the rise of mobile devices - Unless all device manufacturers are planning on getting together and adopting the same codebase for their native applications I don’t think cross platform frameworks will be redundant any time soon!

Xamarin appeals to me for a number of reasons; for one, Xamarin compiles to a native application so performance is not hindered as with other frameworks already mentioned. Xamarin is written in C# which is a very robust and very mature language. At Antiblanks we have adopted a Linux, Apache, MySQL & PHP (LAMP) stack for our low budget web projects and we reserve .NET as our preferred framework for enterprise builds. With this in mind, I see C# as an enterprise language, it’s very robust and it doesn’t have many limitations. I am also well versed in C#, having written the language on and off for about seven years. There is also the inherent bonus of being able to use Microsoft’s Visual Studio IDE which is a premium full featured IDE, and one of the best available on the market.

A quick Google search for ‘What is the best IDE’ will return a number of results, most, if not all of which, feature Microsoft’s Visual Studio at the very top of their recommendations.

All this aside, the only drawback for me is wading into unknown waters and learning a new framework when I have a fair number under my belt already. It’s not that I am adverse to learning new frameworks and usually I jump at something new, but rather I am adverse to trading time spent creating a better application against the time it may take to get to grips with the setup. I need to consider this carefully and weigh this against my objectives and what I want from the course.

Release history and other information taken from the Xamarin page on Wikipedia.

Python with Kivy

Kivy is built on top of Python and was initially released in 2011 by The Kivy Organisation. From research I can deduce that when you create applications with Kivy, you write your control flow (business or application logic) in Python and then the UI is driven by widgets that are represented in Kivy language (Kv), a language dedicated to describing user interface and interactions.

Kivy is relatively mature which is promising for all the reasons I’ve detailed above. Another major plus point for me is that applications created in Kivy are powered by Python. At Antiblanks we’ve seen a rise in customers looking for us to work on Python applications over the last six months and it’s not a skill we hold in-house past having dabbled a small amount with micro-services written in Flask and web services written in Django. Hence there could be a potential trend in the industry that is moving toward using Python; according to Stack Overflow, Python is currently the fastest-growing programming language. Trends like this should not be ignored and if Python has a strong future then there is argument that one should learn the language.

On the flip side of the coin, research shows Kivy to have a few obvious drawbacks: The first being that Kivy has a non-native looking UI. I’ve also found several mentions of the application start time being impacted when using Kivy and I’ve found mention of the resulting APK for Android being noticeably large. On top of this, it must be noted that creating an application in Kivy will require adopting a new language which could be time consuming and hinder progress in the early stages of development.

Release history and other information taken from the Kivy page on Wikipedia, statistics taken from a post about Python’s growth on Net Guru and drawbacks taken from Pros and cons of Kivy on Reddit.

Picking the right platforms and tools for experiential applications

In this section I will look at the advantages and disadvantages of each of the platforms and tools identified to support experiential development in order to select my final candidates for adoption.

C# with Unity

Unity is a cross platform game engine created by Unity Technologies and first released in 2005. Though Unity itself is written in C++, you can script in JavaScript or C#, but from experience the JavaScript resources and documentation for Unity are limited and the preferred development language is C# as the title C# with Unity suggests.

Unity has many advantages, the engine supports a vast number of platforms including all of those I am interested in; iOS, Android, Oculus VR and Samsung Gear VR. As I mentioned before I am well versed in C# and I do have some experience with Unity from a scripting point of view, so there wouldn’t be much of a learning curve for me to get proficient in working with the engine. Unity ships with MonoDevelop as the default IDE, but with only a small amount of configuration you can change this to use Microsoft’s Visual Studio IDE which is a great advantage from my point of view.

Unity has a huge development community and with that a lot of contributors; there are a vast number of plugins you can use to enrich the IDE’s capabilities which can prove a beneficial time saver above rolling your own custom functionality.

Research shows Unity to have some disadvantages. Most notably that games developed with the engine can consume more memory which in turn can create OOM errors and debugging issues. Also the PhysX physics engine has been noted to have some performance issues and to be lacking some important functionality. Finally I’ve read that the tools to create graphics are not as good as those with comparable engines.

Release history and other information taken from the Unity page on Wikipedia, disadvantages taken from a Potenza Global Solutions post on Unity advantages and disadvantages.

C++ with Unreal Engine

Unreal Engine is a source available game engine created by Epic Games that was first released in 1998. Unreal Engine is written in C++ and in order to work with the engine you too need to script in the same language. Unreal Engine is a trusted game engine that is used to power numerous well known games for Playstation and XBox.

Aside closed engines owned and used by top players in the games industry, Unreal Engine is seen as the professional’s choice when it comes to games development. It’s advantages are countless; the engine is highly evolved and it’s been heavily optimised. The decision to expose the engine via the native C++ language means that developers have full control over the engine and the source code, this means that there is no need for interpretation between two scripting languages, and as a result a game written in Unreal Engine will have a smaller resulting file size and will be less processor intensive.

Unreal Engine does have some major disadvantages though. Research shows that the GUI can be slow and can take longer to perform numerous common processes including building the application. Some users report frequent crashes and some even report the application being unusable at times. Importantly for me, coming from mostly web development languages, there is a steep learning curve required to grasp C++ and then coding in the language is also said to be slow.

Release history and other information taken from the Unreal Engine page on Wikipedia, detailed pros and cons taken from Slant Versus Series, Unity vs Unreal Engine 4.

Google SketchUp

Google SketchUp is an easy to use free 3D modelling computer program. SketchUp was originally released in 2000 by Last Software and was acquired by Google in 2016.

Google SketchUp has a number of clear advantages: The first being that it is free to use. The second being that it is very easy to use in comparison to other 3D modelling software packages. Being that I have little to no experience with creating 3D models, and the advice I’ve been given about the sheer gradient of the learning curve with such tools suggests I will need to devote a lot of time to the process, I feel that this may be a good place to start initially with a view to scale up afterwards. Research also shows there to be a vast library of 3D models to work with; Using a pre-created model and adapting it to suit one’s needs can save a lot of production time.

Google SketchUp’s ease of use brings with it some pretty large disadvantages though; much of the ease comes from the fact that the program is far less feature rich than the industry standard options such as Cinema 4D or Maya. The quality and detail of the models is also questionable. Having ran my eyes over numerous models in the 3D warehouse there is a very obvious SketchUp style to a model and I question how viable the use of these models would be in a commercial environment.

Release information taken from the SketchUp page on Wikepedia

Blender

Blender is a professional, free, open source 3D computer graphics program. Blender was initially released in 1998 by the Dutch animation studio NeoGeo but after NeoGeo dissolved the software was continued as an open source project.

Blender is not the most advanced 3D modelling program available. The likes of Cinema 4D or Maya already mentioned above do carry more weight in the commercial space, however, Blender is easier to learn in comparison and it’s a good stepping stone for a novice modeller like myself. The quality of the models you can create in Blender will match that required at industry level and Blender is also geared toward animation which makes it a good option for game or experience development.

Blender is not without it’s disadvantages of course, being focused on the design of animation and games means that the software lacks tools focused on the intricate design of objects with defined measures and parameters.

Release information taken from the Blender page on Wikipedia

Acknowledging the requirement for a back end scripting solution

None of the above solutions are a one stop shop unfortunately. Unless one is building a self contained application in which the data is stored only on the users device, which is quite unusual in the space that I am interested, then there will likely need to be a back end of some kind where data can be stored. This is usually a decoupled web service exposed via an API that the application can consume data from and (if required) write data to.

There are a multitude of options that should be considered here also but, because this is not paramount in breaking ground on development of the application, I am going to save that exploration for another dedicated post when the time comes.

Picking the right version control system

The final item to consider is what version control system to use. In 2018 this is not a difficult decision. In fact, in my opinion there is little to consider at all; Pre-2005 everyone was using Subversion or SVN, this was powerful at the time but it had major drawbacks in that there was no staging area, a commit was a direct push into the repository for example.

These drawbacks were later solved by Mercurial and Git, both of which came about around the same time. Having worked with both, from a workflow point of view there wasn’t much difference between the two. Under the hood there are differences and there are strengths and weaknesses with both if you want to read that deeply into it. My opinion is that this is of low priority and as a user of Git for the last decade or more I know that it can do everything I need it to and I’ve been given no strong reason to switch.

There is the small matter of selecting a preferred Git client though, and this is where I do have a decision to make; Historically I’ve not used a Git client at all. My interaction with Git is terminal based and what I don’t do in the terminal I do in Github. I know all the commands that support my workflow and I’ve never felt the need to switch to using a client. Saying this though, I think the reluctance to switch may just be that I am afraid of change; facing facts, performing a diff in the terminal is not pretty. But this is where I use Github.

In summary I feel it’s a trivial decision when weighed against settling on a good framework and language for my application but I will give it some thought. I’m a Macintosh user so my client needs to run on the Macintosh operating system (OSX). Based on industry knowledge there are three that I would like to consider: SourceTree, Tower and Github Desktop.

Conclusion

Writing this post has been hugely helpful to me in isolating the types of application that interest me and then identifying the relevant platforms and tools available in order for me to create these.

My research coupled with pre-existing knowledge has enabled me to make some sound decisions on the platforms and tools I will be adopting initially. I say initially because I feel that the requirements of the application itself play a large part in driving the technology used to create it, though I am going to make a selection to get started with, I should be mindful that the stack I select may have drawbacks which may make it harder to overcome technical challenges and in this case may need to be revised.

For cross platform development I’ve settled on a solution that can support a single application for iOS, Android and web. I would like to try and create a progressive web application that utilises not only the same code base for each mobile device but also the web version as well. PhoneGap is the obvious solution but I feel it falls too short with it’s many drawbacks so I’ve decided I would like to explore a React and React Native solution where only the lowest level dumb primitive components are switched out so that the entire architecture, control flow and layout container components can be shared and only a thin slice of the UI is duplicated to support the mobile and web versions.

My complete cross platform development setup to support iOS, Android and web will include:

React JS: To create the application architecture using the Redux pattern along with Redux Saga to manage control flow, and to create the dumb low level web UI components.
React Native: To create the dumb low level mobile UI components.
Swift: To deliver any native iOS requirements that React Native cannot achieve.
Java: To deliver any native Android requirements that React Native cannot achieve.
XCode: To write any Swift code and run the application in the iOS device simulator.
Android Studio: To write any Java code and run the application in the Android device simulator.
Atom: To write any ES6 JavaScript code for the React and React Native parts of the application.

Below is my reasoning for discounting the other possible frameworks:

Python with Kivy: Though I was very keen on using Python (with Kivy) based on Python being an in-demand language and wanting to learn this, I felt that Kivy had a few too many drawbacks and wanting to learn Python wasn’t enough of a reason to adopt it. I do still want to work with Python but feel that the back end is a better playground for this.
C# with Xamarin: I was very nearly swayed to adopting Xamarin, but after much thought and analysis of what I want to achieve over the duration of the course; which is to exit with two near complete applications that have commercial viability, I decided that time spent becoming efficient with a new framework would be better invested into the build of these.

For experiential development I’ve settled on using Blender to create my 3D models and Unity 3D above Unreal Engine to create my applications. The main reason for using Unity being that I know the engine and C# already so I can hit the ground running when development begins. Aside from this, all the non-trivial disadvantages with Unity seemed to be less relevant when creating an experience application and were more related to game development. The graphic tools being less powerful is less of a concern to me as my workflow dictates I would create my graphics in Blender and then import these into Unity.

My complete experiential application development setup will include:

Blender: To create my 3D models.
C# with Unity: To develop my experience applications.
Visual Studio: To write any C# code for the Unity application.

Below is my reasoning for discounting the other possible frameworks:

Google SketchUp: I was far too put off by the quality of the models; after some digging, I did find some more detailed examples that were created using third party renderers, but in the most part the models were sub-standard. The ease of learning was appealing, but if the end result is not at the required standard then any benefit of time saved is irrelevant.
C++ with Unreal Engine: I was not feeling convinced that learning C++ was necessary, though I am well placed from a technical stand point to learn the language, so far in my career I haven’t found the need to write C++ and I don’t feel that my applications are lacking as a consequence. Also investing time to learn something so different now doesn’t support my objectives for the course. Finally it seemed like the major benefits to using Unreal Engine were focused on performance and though this is paramount for AAA games it’s perhaps not as important for experience applications.

My version control setup will include:

Git: As the underlying version control system.
GitFlow: To manage my workflow.
Github: To manage my repositories, pull requests and collaborative workflow.
Github Desktop: To manage my local branches and local development workflow.

My reasoning for this solution is as follows:

After trying all three options; SourceTree, Tower and Github Desktop I felt that there wasn’t a great deal between them. Like I mentioned earlier in this post, in my opinion, picking a Git client is far more a trivial decision when weighed against settling on a good framework and language, and for this reason I was almost tempted to stick with my current workflow using Git locally by issuing commands in the terminal and then performing diffs, pull request (PRs) and merges on Github.com.

However trialling the Github Desktop client made me realise that the workflow is exactly the same and performing a diff to see your local changes against those in your origin branch before committing and pushing is far easier than performing the same action in command line. Also from a setup point of view I was able to drag my existing local repository straight into the GUI and I was ready to work with that project, which was an easier and more intuitive journey than with the other candidates.

What’s next?…

Providing a back end solution was left without detailed exploration. As part of my reasoning for discounting Python and Kivy suggests, I would like to invest time to learn Python and I thought that the back end might be the better place to do this.

Aside from this there are other frameworks on offer that I’ve been interested in investigating that can power my application’s back end such as Firebase, Apigee and ReactiveX. I feel that at some point I will need to dedicate an entire post to these tools plus anything else available and critique these all in as much depth as I have the options in this post.

References

In alphabetical order: