This article is tailored towards those wishing to get a Smartphone app developed and will go over the available app architectures, whether you want to build it natively or via a platform-agnostic solution, how apps are priced, and lastly, how you can contact us for a free initial consultation regarding your app idea. The intended audience will typically include entrepreneurs wishing to implement their ideas onto Smartphones or businesses looking to interact with their clients in new ways and establish their presence on the app markets.
App Architectures
The three types of app architectures available to chose from are Stand-Alone, Client-Server, and Peer-To-Peer. Each of these has their own advantages and limitations.
Stand-Alone Apps
Stand-Alone apps are the simplest paradigm and only involve the end-user’s Smartphone. The functionality of these apps does not include communicating with other users or remote servers. A good reason to develop this type of app would be if you wanted to display information to your users as well as establish a presence on the app stores. Another term for this type of app is “vanity app”. The pros of this app include an increase in marketing and legitimacy by having a place on the official app markets whereas the cons are that the user cannot communicate to others or your central server. Because of the lack of back-end logic and developer time required to complete these apps, the cost of obtaining a vanity app is the least among the other architectures.
Client-Server Apps
Most commonly, apps utilize the Client-Server model, as demonstrated in Figure 1. In this scenario, the technologies utilized are the Smartphone end-points, a central server, and a database. The database is most often at the core of any app and holds many tables that store the app’s data. These tables are devoted towards log-in information and any other information relevant to the app.
From the Figure above, we see:
- The Smartphone makes a request (very often an HTTP request, but any network application-protocol may be utilized) to the server, indicating it would like to perform a CRUD (Create, Read, Update, Delete) operation.
- The server processes and handles the request from the Smartphone client and queries the database on behalf of the user.
- The database responds to the server’s request and sends back the desired data set to the server.
- The server then processes and handles the response from the database and then sends this information back to the client
As apparent from the description above, the Smartphone app essentially acts as a User Interface, the server as an intermediary between the app and the database, and the database as the information store. The primary portion of the logic resides in the server and database, rendering the app itself a ‘dumb terminal’ processing little to no logic and simply relaying users requests, however, for some special purposes, the app on the Smartphone end-point can be designed to take care of a majority of this logic.
In apps processing big data or utilizing a significant network bandwidth, multiple servers and databases can be deployed to handle the workload. Because of this, the Client-Server model is scalable, although not more so than that of the Peer-To-Peer model.
Peer-To-Peer Apps
Peer-To-Peer apps are those that communicate directly with other Smartphones in their vicinity, leaving the centralized server-database out of the picture and instead implementing a distributed approach. Refer to Figure 2 for a pictorial example. Because of their decentralized nature, these apps are quite scalable since it’s the Smartphone end-points themselves that store all of the data and process all of the workload.
For app ideas involving user interaction within the immediate vicinity, the Bluetooth and Near Field Communication protocols may be utilized. For those involving Peer-To-Peer interactions at a distance, the WiFi P2P protocol (or similar) is likewise used.
These are the least common of all apps, however, they are an excellent selection for scalability, as the cost of additional resources is not incurred by purchasing extra RAM, disk space, or network bandwidth, but rather by the systems running the app.
Hybrid Apps
For the sake of completeness, it must be mentioned that a hybrid approach between the Client-Server and Peer-To-Peer paradigms is possible as well. With this approach, the central server-database can keep tabs of whatever it wants going on in the app realm, leaving the rest of the work to be done among the peers’ Smartphones themselves.
Native Versus Platform-Agnostic Development
Another consideration for those wishing to develop an app is whether they want the app to be native or platform-agnostic.
Native Apps
Native app development includes the creation of separate source code for the platforms on which the app is desired to be published. For Android, this would include source code in Java (or any other language that is compiled to Java bytecode and run upon the Java Virtual Machine), Swift for iOS, and C# (or any other language that is compiled to the intermediate assembly language recognized by the Common Language Runtime).
These apps are more pricey than the platform-agnostic counterpart, as development time increases with each additional element in the set of source codes to be created and maintained, but they are necessary if performance is crucial for the app or if intricate features are to be implemented.
Further, native Android apps can “kernel hack” the underlying Linux Operating System, allowing them to interact directly and uninhibited with any part of your Smartphone. This exposes powerful potential for Android development but is not possible on iOS and Windows Smartphones because of their proprietary and closed-source nature.
Platform-Agnostic Apps
Platform-agnostic apps are created with one code source that can be ported to Android, iOS, and Windows Smartphones. This brings the price of the app lower to that of the natively developed app. Yet, because platform-agnostic apps work within the context of a WebView, basically a browser within the app, the features that are able to implemented are less than those of the native application.
How We Determine Pricing
At INTP LLC, we like to provide the best solution at the best cost to our clients and we always utilize technologies that will best fit your needs while incurring minimal future maintenance, also called ‘technical debt’. Because of this, we do not provide a generic “per-hour” pricing or a one-size-fits-all project fee. Rather, we conduct an initial meeting upon which a full Software Requirement Specifications is created. From this, we are able to provide a figure based upon forecast development time, hardware resources to be utilized, and the amount of maintenance to be involved.
The equation below outlines how we determine the pricing of your app:
Price = Developer Time + Designer Time + Resources Utilized + Recurring Maintenance Cost
Free Initial Consultation
For a free initial consultation regarding your app idea, please feel free to contact us online via www.intp.io/contact, email us at info@intp.io, or call us at 303-902-6422.
