Selecting Tech Stack: Business Oriented Messaging Application
As a project manager for a few years, I have been working with various projects especially for startups and I wanted to publish a technical and business analysis of mine for a mobile application project. It is a little long and detailed but I believe that would be quite helpful for those who is interested in how to choose tech or strategy before starting to development process.
Of course, I cannot say I am a professional about this area but I am coming from a background in software and social sciences so I continued my career as a project manager for a few years. I do my best to learn and improve myself, please feel free to utilize and critize.
1- Mobile Development
Mobile development is another area of software development aiming to create applications which can work on mobile devices such as phones and tablets.
Since the use of mobile technology has dramatically increased with the demand for smartphones, tablets and wearable such as smart watches, people started to utilize these devices to fulfill most of their daily job routines. The most basic ones an be listed as: communication, socializing, shopping, money transactions etc.
Therefore, modern day mobile apps require internet connection of either WIFI or mobile data in order to enable their users to transfer data between their servers and among themselves. This has also created a unique opportunity for mobile apps to control the new web which is widely controlled by web browsers today.
However, this has caused mobile apps to be more complex unlike their nature because they become in constant communication with servers just like the modern webpages; so, modern mobile development expectations of the companies has shifted to different approaches in order to meet those expectations with lower costs and development time. Besides, they has had to look for wider target ranges because many different mobile device producers created their own standards and operating systems which caused a huge problem called “compatibility”.
Also, with this growing demand, more companies wanted to be in mobile industry which created another problem called “programming language.” The native mobile applications were able to be developed only with certain programming languages; for example: Java or Kotlin (new) for Android, Swift or Objective C for iOS. And, most of those companies were either developing websites or desktop applications which almost none of those languages are actively used or they were used with completely different libraries, which makes developers to learn a new environment from scratch.
2- Mobile Development Approaches
Native
There are basically two types of mobile development approaches in total. The first one is called Native. As its name is suggesting, it is the most compatible way of developing mobile applications with the platform at which your company is targeting.
Examples
Android: Java, Kotlin
iOS: Objective C, Swift
Hybrid
The latter one is called Hybrid. This one actually started with Apache Cordova project which used a non-native approach to target multiple platforms without using the platform’s own UI (User Interface). They used HTML, which is the language of browsers to draw UI and put a very lightweight browser inside mobile applications. The applications have been built on top of the browser and they have managed to make their applications work on multiple platforms because the browsers has already been working on multiple platforms without any code change. They have created native modules to make use of native functionality such as Bluetooth, GPS and SMS.
Later, this approach has proven to be not performant in terms of application UI performance. So, there has been a choice between software companies. They either choose performance by creating native applications separately for each and every single platform they are targeting or compatibility with low performance by using Apache Cordova and targeting multiple platforms with a single application and code base.
Examples
Apache Cordova
Ionic
Pseudo-Native
However, after some developments in the web development, the mobile development has been affected and React Native approach has been announced as a sub-category to Hybrid app development.
The difference of Cordova and React Native is how the UI is drawn on the screen. React Native uses a common language to create UIs for different platforms and generates the new UI for the target platforms but also manages the UI itself with its own paradigm. This has created a third way to create mobile applications which can work on multiple devices with a single code base and also performance-oriented UIs.
After the React Native project, a few companies created different types of approaches to enable developers to create mobile applications with less effort and to target more platforms.
Examples
React Native
Native Script
3- Pros / Cons of Mobile Development Approaches
Native
Native development is a more performance oriented way of developing applications but each approach has its advantages and drawbacks. The commonly known ones are listed below:
Pros:
- Performance
- Small application size
- Full access to devices like Bluetooth
Cons:
- Different project for each OS (iOS, Android etc)
- Even differences for each OS version (Android 4, iOS 10 etc)
- Differences for devices (Samsung, Mi etc )
- Requires more developers, at least one developer for each project
- More time consuming to sync all projects with server side
- Naturally, more costful because of time, people and energy
Hybrid
Hybrid way of developing mobile apps is more compatibility oriented but it has also certain drawbacks and advantages which are listed below:
Pros:
- Single project for all platforms, works on any platforms without almost no change in the code base
- Device issues are not platform dependent developer’s just write the code once
- Wide range of plugins supporting multiple platforms
- Small team, easy to develop and maintain / sustain
- Low time consumption
Cons:
- Big application size
- Hard to design UIs with HTML / CSS for mobile apps
- Low UI performance
- Limited access to devices with plugins
Pseudo-Native
It is actually in the Hybrid category but it should be handled differently since its characteristics are unique. See pros and cons listed below:
Pros:
- Medium application size
- Single application for common platforms
- Easy UI oriented design
- Performance oriented UI
- Small teams, easy to develop, maintain / sustain
- Low time consumption
- Wide range of plugins supporting multiple platforms
- No OS version differences and problems with minimum requirements
Cons:
- Medium application size
- Limited access to devices
4- Mobile App Development Platforms
5- Showcases
The well known companies and their project utilizing the development platforms.
Xamarin
- UPS: Shipping company
- Azure App: Cloud management
- oLo: Ordering app
- Microsoft’s apps
- More:
- https://dotnet.microsoft.com/apps/xamarin/customers
React Native
- Facebook’s apps: Social media, marketing etc
- Instagram: Photo sharing, social media
- Skype: Chat, video audio talk
- Discord (iOS): Chat, video audio talk
- Walmart: Shopping, e-commerce
- Oculus: Virtual reality (VR)
- Tesla: Management
- Pinterest: Photo sharing, social media
- More:
- https://reactnative.dev/showcase
Apache Cordova / Ionic
- Wikipedia’s app: Online encyclopedia
- Facebook (old): Social media
- Microsoft Xbox: Game related management
- Zynga: Gambling apps
- Electronic Arts (EA): Game related management
- NASA: Info applications
- BMW: Info applications
- CNBC: News app
- More:
- https://phonegap.com/app/
- https://ionicframework.com/customers
Nativescript
- Sennheiser: Smart Control
- Puma: Footwear brand
- California Court Access App: Government
- More:
- https://www.nativescript.org/showcases
Flutter
- Tencent: A huge game company
- Square: Credit card payment hardware methods
- Google Assistant: Siri like assistant app
- Google Ads: Advertisement & statistics management
- STADIA: Cloud gaming platform
- Alibaba group: World’s biggest e-commerce platform
- Philips: Hue smart home tech
- Ebay: Motors marketplace app to sell vehicles
- Nubank: Bank app
- More:
- https://flutter.dev/showcase
- https://itsallwidgets.com/
6- The Project Analysis Criteria
Criteria
There are some variables which should be considered while choosing technologies for a project. These can be listed as:
- Team size: The number of the people the company can assign to the project
- Budget: The amount of money the company can invest on the project
- Duration: The time the company can allocate for the project
- Technical complexity: The complexity of the project the company needs to deal with
- Sustainability: The difficulty level of adding new features or updating the old ones in the project
- MVP (Minimum Viable Product) size: The number of the features which must be ready in the first release of the product
Sustainability
Sustainability is the utmost required variable to be kept as high as possible. Otherwise, the project may not be continued properly or even may be produced at all on the MVP period. While considering sustainability, there are a few factors directly affecting it:
The quality of the code produced in the development period
The quality of the code can easily be achieved with a controlled and well-organized development. Also, choosing proper programming languages and environments suitable for the server and customer side of the project.
Standardized approaches/methods utilized by the company
Another important point is, for sure, following the worldwide standards. It is highly significant because if the project is parallel with the standards set by the authorities and communities engaged in those issues at first hand, the future of the project is secured by knowing those standards solve certain problems and guarantee not to have the future problems with the advancement of the technologies the project utilizes. Therefore, it is highly important to choose standardized ways of doing thing rather than custom implementations and self-produced materials since it would be too difficult for small companies to maintain them.
A scalable stable and unified infrastructure chosen by the company
Choosing correct infrastructure for both sides of the project is an important decision making process; especially if the project is focused on multiple clients and constant communication between them.
The stability and maintainability of the infrastructure of the project is much more important than the project itself in most of the cases because all the project code will be built on top of them and it would be almost impossible to change the infrastructures. Lastly, preferring unified systems is crucial (extremely important) because having two different infrastructures not understanding each other and making them communicate is a huge problem in the software world.
7- Analysis of Team and Project
Analysis of Project
It is a chat application aiming to make people communicate with one another by using the instruments of text, media, voice and video. It should be a standalone project together with its server-side application because it can also be installed to dedicated servers to be used by government establishments or private corporations, which makes it a possible B2B candidate. It aims to be in the platforms of Android, iOS, Web and Desktop, which is relatively a wide range of target size.
In order to choose which technologies are more suitable for the app, it is possible to analyze it within the context of the company by considering the variables defined above.
Team size
The company is a startup company and just like most of the startups, the number of the people which can be assigned to the app project is not as much as a corporation standard. In the current context, it can be estimated that there are two part time iOS mobile developers which can be dedicated to the app project. Also, a part time developer who can both help developing, do QA(Quality Assurance) and also partially manage the mobile part of the project to keep everything in order. That is, it is possible to dedicate one and a half people to develop mobile application side of the project. This can be considered “a highly small team”.
Budget
As an investee and not actively producing incomes, the team is considered to have a tight budget. Parallel to team size, which is closely related with the budget, the costs of the project is expected to be kept as low as possible; therefore, it can be inferred that the app should be developed by consuming “a considerably low budget”.
Technical complexity
App is a chat application which will need a modern animated UI and target UX (User Experience) to be on the front. Also, it should have a fast graphics not to bother its users because it will be frequently used as a chat application. In terms of technical concerns, it has relatively mid-level technical complexity. It needs the following features:
- a proper and standardized way of communicating with the server-side since it will need a fast and stable connection to create a smooth real-time experience for its users
- adapting multiple environments with minimum change since it targets multiple platforms
- scalable server-side architecture because it will be used by a great amount of people
Duration
Duration is actually a dependent variable which is tightly bound with team size and budget. Since the budget is not much and team size is considerably small, duration should be either longer than usually expected or the size of the MVP project should be shrunk so that a qualified project can be produced in an expected time in the favor of creating incomes in a short time and expected features left out of MVP can be added with a planned time period after a stable MVP is achieved. Therefore, the can be considered for this project “a mid level project duration” between 4–5 months.
Sustainability
In terms of sustainability, as explained in the document before, a project must choose standardized, scalable, unified methods and infrastructures to progress without hesitation. It is especially far more important for startup companies like us since it is a great effort to create a project and maintain it with a small team and limited resources.
MVP (Minimum Viable Product) size
Most startup companies may not manage to arrange a proper MVP size which makes them not to finish their products or even worse go bankrupt and be closed. In the app context, as mentioned on duration and considering team size and budget, between a relatively “small” or “mid-level MVP size” should be created to be able to complete it with the estimated time frame and budget allocation. Otherwise, apart from having an incomplete project and losing money, the company may even lose the performance of its team members which leads to a breakdown situation in the company.
8- Project Requirements according to the Analysis
In the light of the background information of approaches and platforms used to develop mobile application; and the project analysis applied on the project, it can been inferred that the project should be and will be produced:
with a small team
- 3 part-time dedicated members for mobile team
- 1 full-time dedicated member for server-side
- 1 member to maintain QA and management
with a limited budget
- Enough to support a team for mobile and a team for server-side for the given period of time
with a mid-level technical complexity
- Standardized communication methods
- Adapting to multiple environments with as little change as possible
- Scalable server-side architecture
in a limited time frame, mid-level production time
- Estimated 4–5 months for MVP production
as sustainable as possible
- easy to maintain code bases
- adding or updating features without problems
- keeping documentations not to lose know-how
- stable and known project behavior by utilizing tests
with a small or mid-level MVP size
- some basic features
- planned updates for future
- adapted to estimated time frame
- as complicated as the team size and knowledge can manage not more
9- Selecting Technologies for the App
Considering all analyzed factors, it can be concluded that there will be two sub-projects; therefore, two infrastructures in total. They will be named as: Application and Backend from now on.
Application
The company targets at multiple platforms (Android, iOS, Web and Desktop) with a small team and a limited budget more importantly in a mid-level production time for an MVP. Thus, it would be wise to choose a way to produce multiple applications for multiple platforms with a single code base in order to:
- complete the product for all the platforms at once in a single code base
- complete the MVP in the limited time with a small team
- manage, maintain and sustain the code base and features with a small team
While accomplishing those above, there are also some other requirements for the project:
- Fast and elegant UI for best user experience
- Having the same experience in all the targeted platforms
- To be able to manage a mid-level project complexity for the mobile side
By looking for a good infrastructure candidate, Pseudo-Native application development approach seems a promising one for the project. Comparing and contrasting the development platforms under that approach, there are two possible development platform candidates we can make use of. The first is React Native by Facebook and the second one is Flutter by Google because:
- both support multiple platforms with native UI which helps us solve the fast and elegant UI problem
- both are actively used in serious projects so they show their power of developing applications
- both are developed and supported by big companies not just communities because communities might be unpredictable in the future about support
- both can manage mid-level complexity for mobile application
So, in order to choose one over other for the project, we should compare and contrast certain points.
Targeting multiple platforms is a little different part between the two project because Flutter brings its own UI system to solve the independent but fast UI problem whereas React Native uses the systems own UI system by making developers use a unified language.
If the project were just targeting Android and iOS, it might be easy to go on with either of them but if we include Web and Desktop environments which are completely different from mobile environment, it becomes a serious discussion to choose which one.
After analyzing in detail, React Native’s Web support is actually developed by a third party community which becomes a problem because some parts can be different and it may force us to do changes in our code base. Also, React Native’s desktop support is not even alpha yet which is unknown whether it will go on or not. So, it can actually support only mobile platforms for now unlike Flutter.
Flutter can support fully mobile platforms, web in beta (which will be already a release by the time we finish the project) and desktop in alpha. They are all developed by Google and all platform applications can be created from just a single code base without changing a single line of code. Because it brings its own UI drawing system, it does not want us to make any changes to adapt any specific platform.
Flutter’s plugin support might be a little less than React Native because React Native is on the market for a long time but it does not affect our situation because we do not have a strong dependence and software complexity on plugins. However, we have developers with Android, iOS, Desktop and Web background to develop a plugin in case there would be a problem and we had to develop a new plugin.
The difference of UI approaches of Flutter and React Native can be explained a few examples. If we think Flutter, React Native and the system as humans, Flutter speaks the language and explains whatever it wants to be drawn on the screen when it will make it draw. However, React Native uses a translator explains what it wants and makes it translated into a paper and gives it to the system but if something goes wrong, React Native does not understand what system says because it does not speak the same language with the system.
In short, while React Native tries to modernize the mobile application development in harmony with the old style of developing mobile apps, Flutter is a technology to determine new application development standards. Therefore, Flutter will be a much more convenient candidate to develop the mobile side of the app project.
10- Flutter vs React Native Analysis
Flutter
Pros:
- Developed and maintained by Google, a corporation supported project
- A relatively wide community support
- Flutter allows overwriting your code: Fully reusable code
- A lot of third party libraries
- Sample tutorials and guidelines are available since Flutter is new to industry
- Supports Android, iOS, Web(beta), Desktop(alpha) without any change in the project
- Faster native UI
- Verified third parties
- UI as code makes developer only use a single language to develop UI and code
Cons:
- New in the industry and not known by less people than React Native
- Less popular
- Plugins are not as much rich as React Native for native development support
React Native
Pros:
- A lot of third party libraries
- Many community supported tutorials and guidelines are available
- Old in the industry and known by many people
- Supports Android, iOS directly.
- More popular
- More plugins for native development support
Cons:
- Reusable code restricted to a few basic components
- Desktop is uncertain and developed only by community members, not the original project
- Web is uncertain and developed only by community members, not the original project
- Slower native UI
- Community supported third parties not really verified ones
- UI needs to be developed with XML-like languge syntax. UI and code are im two different languages