Mobile Applications Development

If you are not 5 years late with your intel, mobile apps are the thing today. We are all using

If you are not 5 years late with your intel, mobile apps are the thing today. We are all using smartphones, using all kind of apps, some of us have our own mobile application startups, some of us just develop them for others, but there is practically no way to avoid mobile today.

I am actually an android developer myself (but iPhone and iPad user), and Profico is a mobile development company (among other things) that i Co-founded. Here at Profico we have one main goal: to deliver high-end apps with custom interfaces, working smoothly and to have each of them as a reference point for new endeavors. This is not only about mobile apps development, but about other lines of business. That these are not only goals, but also facts you can witness in our references section. In this, a bit longer article, I am going to write about how mobile apps are developed @Profico, and some of those references will be mentioned too.

We get clients from different sources. Most of them are simply referred to us from our existing clients, some come from from Google, some from our G+ or Facebook page, some apps are developed with one of our many company partners. Once we get contacted by a client in order for us to develop an app for him, there are some key parameters to decide, of which you can read about underneath.

1. Define the scope! What exactly are we to develop? Is it only the mobile app? Does the client posses design? Are we to develop web services support (we will talk about these later on)? Is there a web interface? …

2. Define the needs! How complex is the app? Is it to be made using some framework or is native platform development the way to go? Maybe all the client needs is a simple responsive web page or web application.

3. Pick the platforms! Since Profico is all about high-end interfaces and ‘cool’ apps, we cheer for the native application development choice. Sometimes client wants to support only one platform, and sometimes we do parallel development on all of the currently popular platforms: iOS, Android and WP.

Once the three are defined, we can start talking about the more detailed app features and give out some kind of cost estimates. At this point, lets assume that both client and us are satisfied with the cost-to-qualiy ratio, and we decide to do some development!! 🙂

How does the mobile application project development flow look like?

The word you are looking for is Agile development! We tend to keep our clients as product owners close to the development team. If the client isn’t fine with that, then we do some more documentation at the beginning and only have weekly deliveries and QA. We use a wide toolset to achieve the agile component, but the three main tools would be Trello, Skype and E-mail. Also one very important tool is TestFlight, with which our clients get regular updates on the mobile application development status, and can use it on different devices.

When the project terms are agreed upon, we usually write down the features list, have a talk with the designer and put up a wireframe. Mobile applications development is all about a good wireframe. If we miss out on the layout configuration at the very beginning, our development, thus the project costs could exceed the planned amounts. Nevertheless, any changes in the specification are possible at any time, some will change the mobile application price, some will just reuse already allocated resources.

Like I mentioned earlier, depending on the client, we provide full outsourcing of all project needs, meaning that we handle iOS development, Android development, Windows Phone development, web services (web application) development, database optimizations and the web administrators interface development. Some clients take up the whole deal and outsource entire project to Profico, some need support only on one platform. All the modules are treated as independent and are developed separately, with intent to reuse as much logic as possible between the platforms. What does that mean? It means that, from the architectural point, we will reuse the logic behind data objects, error handling, behavior handling etc., in between iOS, Android, WP, and maybe even WEB component, supporting the platform specific requests.

From now on, this article could get a little more “techy”, so if you need more info about Profico, and are not into the technical stuff, click here to go to the bottom of this article.

What is the usual mobile application system architecture?

From our experience, the usual mobile apps that we are asked to develop are based on a simple 3 tier architecture:

1. Mobile application (iOS platform, Android platform or Windows Phone platform)
2. Services server (based on PHP, Node.js, Ruby or some other web framework, produces mostly JSON but sometimes XML results too)
3. Database server (MySQL, MongoDB, SQL server, Oracle, depending on the needs and expected load)

Addon: Web Administration – most of the clients like to have the option of managing the mobile application and services server connection using a web administrative interface. This way the admin can easily edit and delete users, modify content, set permission or whatever crosses your mind 🙂

Native mobile application programming

Here at profico we tend to develop native mobile applications. Developing native mobile application, instead of using different mobile development frameworks allows you to produce more custom and unique apps, that can fully use the devices capabilities. Native programming for iOS, Android and WP is done using Objective C, Java and C# programming languages, inside the SDK-a provided by Apple, Google and Microsoft. Almost all of the best apps are programmed as a native mobile application, resulting in tons of quality plugins and libs to be found all around the internet and for each mobile application platform.

We at profico tend to write blog posts about how we solved some problems that had no solution so far, in order to add some value back to the general mobile developers network, see some of them here. Though doing native mobile application programming has mostly only functional advantages over using some framework to develop apps, there is always the price and development time disadvantage. Nevertheless, when your client wants only the best product, platform specific apps development is a MUST.

iOS Development

iOS applications development is done using Objective C programming language, and the X Code Integrated Development Environment. This must be done on a OSX powered computer, so when starting up with iOS development, the initial costs are somewhat higher than of those when starting up with Android or WP development. Objective C programming language has its syntax specifics, but once you get used to it, you won’t feel dizzy looking at all the brackets anymore 🙂 In the terms of iOS development, you can do iPhone development, or the tablet iPad development, both having quite a number of devices from the original iPhone, to iPhone 5, or iPad mini. iPhone and iPad programming can be done all at once, combining the code for both in one app and reusing what can be reused.

Although not as troublesome as in Android programming, in iOS programming there is quite some work to be done in order to actually support all the iOS devices. There are multiple screen sizes and multiple screen resolutions, so iOS developers are starting to think relatively and not absolutely like they used to before. Apple has quite some restrictions when publishing the iOS application to the app store. The app has to be consistent with all the apples guidelines and also use only the allowed API calls, so the entire publishing process takes a few days. You need to have a payed developers account on the app store too, with a yearly subscription fee. Everything about iOS development is pretty strictly defined by Apple, making the Quality of apps available on the App store quite high.

Android development

Android development is done using Java programming language and the Android SDK provided by Google. It can be done using multiple IDEs, but the most popular ones would be Eclipse (or the modified, Googles Eclipse), Android Studio (by Google) or my personal favorite IntelliJ. All the IDEs are quite handy and provide all the advanced functionalities that would be expected from a professional IDE. They are all Java based too, thus available on all platforms (Win, Max, Linux), not limiting the Android programmer to one OS only, like in the iOS case. I am personally a mixed user, having both iOS and Android phones, and doing Android development on a retina Macbook pro computer running IntelliJ IDE.

Android application development
In terms of supporting multiple devices, everything is relative about Android. You have tons of devices, from super small mobile phones, to huge SmartTVs or tablets. If you decide to limit yourself to normal sized phones and tablets, there are still thousands of Android devices to support. We sort them out into 4-5 categories by the screen size (in inches) and into 4-5 categories by the screens density (dots per inch – DPI). All the graphics have to be prepared for every of the categories, and also all the layouts have to be carefully considered with the amounts of data to represent on different screen sizes. This is actually a quite troublesome job for the developer, and @Profico we are always trying to toss it to the other guy 🙂 Nevertheless, all our apps are programmed in terms of relative sizing, and will work fine on all of the devices.

When publishing the app on Google Play (Android market, as it was used to be known as), there are practically no restrictions, and the app is visible in Google Play in matter of hours. Although there are quite a few guidelines Google provides for his developers, they are just suggestions. The developer certificate is free, and you only have to register with your GoogleID.

In contrary to Apple, everything about Android development is pretty much up to the developer. Although I am an Android developer and frequent user, personally i hate that fact. It would be much better if google would be more strict about his apps, too much junk and malware is to be found on Google Play, making users way too suspicious for each install.

 

Windows Phone development

Codeanywhere surface app
Windows Phone applications development is done using C# or Visual Basic (even C++ for DirectX) programming language inside .NET environment, and Visual Studio IDE. When outsourcing Windows Phone applications at Profico, we use the C# language, because its object oriented paradigm is way ahead of Visual Basic. Personally I don’t do the Windows Phone development, but have done quite some DirectX C++ programming back in days, and one thing is for sure: Visual Studio is the best IDE there is. Microsoft has invested much in this product which grows better and better throughout the version, yet staying very simple and extra fast. To develop Windows Phone applications you need to install the Windows Phone 8.0 SDK. The platform you are limited to is Windows 8, 64bit version. Microsoft provides a wide variety of tutorials and samples for one to begin programming for Windows Phone.

Once your Windows Phone application programming is done, you are to check our if it meets all the App certification requirements for Windows Phone, and submit it to Microsoft. You app will pass through few steps Microsoft defines for app submissions, and will or will not be visible in the store. Although this seems closer to Apples regime, actually it is not that time consuming or complicated. I actually had the opportunity to lead a team that was developing one Symbian app for the OVI store, and that one was the real deal to publish, Apple is an angel comparing to Nokia 🙂

Mobile app project development phases

1. Functional specifications
Like we mentioned earlier on in this article, if both sides are happy, we start with the mobile application development. First step is to gather all the intel from the client and derive a features list. This is to be done as detailed as possible, and both the business and technical leads from Profico are part of this first step, of course alongside the client. Features are kept as simple sentences that encompass one of the apps functionalities, not too big and not too small in matter of development time. One feature shouldn’t depend on many of the others.

2. Wireframing
Based on the features, we develop a wireframe. Usually the designer is a part of this phase too. Wireframing of all the screens is a great help to all three sides: Profico, as the development team know about the layout early enough, the designer has a defined structure and doesn’t have to worry about the logic and application flow too much, and the client has a feel about how the app will look like once it is delivered.

3. UI/UX design
Since the mobile development is all about the layout (if you check out the thin client architecture model) we do need the design ready in order to start programming. Little can be done from the side of mobile application until we know all of the unique parts of the interface, and how custom controls and widgets have to be made. This is the part where the designers ask the questions, and based on clients input, our input and the wireframes, develop the interface. The final product of this phase are the screens, style guides and slices.

4. Web services development + Mobile application development
Once all the screens are known, we can start with what we are best in: mobile application development 🙂 The system is consisted (as mentioned) from the application server (with the DB), and thin mobile client. We go through each screen, define services, and start the development on both web and mobile side. This is of course not a strict separation of phases, but this is the basic order, some overlaps do happen, of course. We will discuss more about these two phases in the text below.

5. Quality Assurance Management
To assure that the final product is successfully finished, we perform testing on three levels. First one is the developers testing, or team testing (this part is mentioned as one of the phases in the text to follow), second one is lab testing and the third one is user testing.

Mobile applications development process

Codeanywhere - iPad coding

1. Picking out supported software version
Wether it is iOS programming, Android programming, WP programming or any other cool programming, you are always limited by the SDK and OS versions provided by the manufacturer. Depending on how crazy the designer was with custom controls and animations, depending on how data is to be handled from the server, and depending on how much usage each OS version currently has in the global market, we decide on which iOS version, Android version or WP version to choose. This decision is made by Profico and the client. Usually it comes down to supporting the current OS version and one lower version, because it mostly covers 98% of available devices, and higher costs of supporting 2 lower versions usually doesn’t payout for the client.

2. Interface coding
Since the mobile application is actually only a thin client, most of the programming is handling custom layouts, making some cool animations, preparing the layout for all the screen resolutions and densities. Believe it or not, from my experience, I would say that more than 70% of mobile application programming goes out to only interface development. But it is more than worth it. If you work with good designers (and Profico, of course, works with the best ones 🙂 ), the interface can be so cool and breath taking, you wouldn’t mind spending double the time to code, ahh… 🙂

3. Services coding
When near the end with interface coding, we start developing the modules to connect the mobile application to our web services, and come up with data models that are easy to connect to the interface. Apps architecture is usually divided to the functional and visual part, this modules being part of the functional of course. Another part of the functional is the routing, app lifecycle handlers etc.

4. Connecting interface to data models
This is where we combine all the previous phases and come up with the projects alpha version. We hook up the interface to the data models, we include all the background services, lifecycle handling, use real time data, remove all the dummy labels, include debugging info etc. The final product of this phase is an app that developers would call “done”. Of course it isn’t, thats only what developers say to make everyone happy, but we have 2 other phases to fix this.

5. Features testing and debugging
We go back to the beginning and get our selfs the list of all the features this app has to support. Each of them is evaluated and tested on the device. Behavior is monitored and all the possible mistakes are noted. It is a good practice to have this phase performed by someone outside the team, or at least not directly involved in the development. All the notes are debugged by the development team, meaning all the requirements have been met.

6. Devices testing and debugging
In this phase, we tend to try out the app on as many different devices, or at least on as many different device profiles as possible. For iOS this isn’t that much of a problem, we have all the devices inside Profico, and only have to test out the build on each. But for Android or WP, this part can be tricky, and thats why we have one device of each quality category, each screen size and each screen density at hand. Also client can be involved in this phase, simply using TestFlight.

Web services development process

1. Picking out the appropriate technology – depending on the project requirements, some technologies are preferred. For example if speed is not an issue, ORM-s are a good choice (easy updates, good structured), but if you need speed raw, optimized queries, or some query builders are a better choice. If you expect heavy load, accelerators are to be considered, or even using C-based rest clients with load spreading. This has to be done at the beginning, and considered the entire time.

2. Definition of all services – we go throughout the wireframes, and the designed screens and come up with the services documentation – what the mobile client sends, and what the web application services have to respond with.

3. Definition of security – usually the data exchanged through the services API is confidential, so security has to be taken into consideration. The usual scenario is forced SSL, all data is encrypted, and tokens are exchanged between the server and each mobile application.

4. Services testing and debugging – having debugged services is really important for the development team, so special care is taken by the web developers to test out the services and simulate app usage. Once the development of the mobile application hits the “connect to services” phase, no interruptions should occur.

5. Stress testing – we fill the database with a few million dummy data entries (or more, depending on the client) and test out each services memory consumption and execution time. After all those are inside normal limits, we use curl from different server to simulate users load testing.

 

Prices and payment options

Although these are almost completely subject of mutual agreement between Profico and the client, I felt the need to just mention the usual practices. From the price perspective, Profico does the development of the entire system, or a certain part of it. Design is always notified as a separate entry, and is agreed upon with the design studio by Profico or by the client itself. We have a partner design company where our clients get lower prices. They produce top quality design, and are usually chosen as the best ones by our clients.

As mentioned earlier, price depends on the projects deadlines, features list, interface customizations etc. If you would like your product to be evaluated, use the contact form to give us a few details about the features.

The usual practice is to have the total amount divided into multiple parts, depending on the project timeline. Each part is then payed each week, every 2 weeks or each month of the projects timeline. Certain amount is payed in advance to assure that the client is obligated to finish up the project if Profico is meeting its agreed terms. Before any payment is made, or any of the apps features delivered, contract is signed between Profico and the client (over the Internet of course).

appcurious

Fin

Well, this is the end of my short post about how mobile applications development is handled at Profico. I tried to bring the entire process as close to the reader as possible. As you probably saw we try to simplify things inside our internal process for Profico, but also for the designer and most importantly the client. With regular builds delivery and clients involvement in the development process we produce good and productive feel. The option for the client to change the specification or simply decide to bring another “touch” to the process with his/hers ideas is always there.

If you liked this post, and have an app to be developed, give us a buzz on e-mail with some basic insights about the application, and lets see where it leads us 🙂

Leave a Reply