Tag Archives: Android

How does the use of new technologies and third-party developers cause problems even though they look great “on paper”? The answer is that it creates poor communication between the customer and the launch teams.

 

Itera Research’s rule of thumb: If analysis can be done, do it. 

In this case study, we explore exactly why we adhere to such a policy, and what information it can give us.

 

May the stars show you the way!

Our study starts with a mobile application for astrologers. This app provides various horoscopes, tips, parting words, and checking the compatibility of the horoscopes between people.

The client has a subscription which includes 3 levels – Basic, Student and Master. Each level gives more and more benefits. The subscription can be either monthly or yearly and includes built-in awards, amulets and pendants (but only their digital counterpart).

The user buys all sorts of virtual amulets in the game and puts them on himself in this application. It also monetizes through advertisements.

 

Which platform to use as a framework

In the process of discussing platforms, we came to the conclusion that we will make a UWP application that will be released for two platforms at once – iOS and Android. The reason – after analysis such a decision was dictated by the cost – the development of one UWP application was equal to only 120% of the cost of one application for one platform.

To do this, we decided to use the Flutter framework, which already has everything you need to create applications for all popular platforms.

For first-time listeners, Flutter is an open-source development kit and framework for building mobile apps for Android and iOS, web apps, and native apps for Windows, macOS, and Linux using the Dart programming language, developed and maintained by Google Corporation…

 

Our main problem…

Developers from different companies worked on the project. Toward the end of development, when the application itself was finished, we began to add various libraries to it: analytics, payments, advertising, etc., and that is when difficulties began to arise.

The main cause of the problems was the third-party team – we did not have access to the programs themselves, or the code, making it impossible to fix anything or help them in any way. We spent a lot of time setting up and sorting through various libraries to make everything work at least at an acceptable level.

But the real difficulty was communication and timely resolution of problems that arose since we were back-end developers, while the other two developers were third-party. They were engaged in writing applications on Flutter directly on platforms (Android and iOS)

The project manager and tester were also from Itera Research, but it was still a long and painful process for both the development team and testers, as well as for the customer. The process of setting up the libraries lasted three weeks, which was agreeable to the client.

 

Why was it important for us to set this up?

Since this is a mobile application, operating systems prohibit the connection of payment using third-party services – MasterCard, Visa, etc.

All mobile apps work using internal payments with which Google and Apple work. This makes it, so they have their dashboard, settings, and subscriptions, and all payments go through their services only.

This library allowed the application to send requests to Google and Apple pay points and make payments within their services, that is, a kind of payment connector.  Such technology is called “In-App purchases”.

 

Timing is everything…

We were severely limited by the deadlines due to constant delays in the work process adding a level of challenge. Another problem was in the technical part – the server was not ready. We could not properly test the application or interact with it, even at a basic level. There were not enough resources from third-party developers, creating a significant amount of time we sat idle. Additionally, the third-party developers were also frequently idle due to the inability to check the performance of their applications. As a result, this downtime greatly interfered with the development process.

In such a situation, it is always important to devote time to work and communication with the client. Try not to panic him, but competently discuss the current state of affairs, show the results already made, and let the client test his application with his own hands. It was this approach that helped us maintain relations with the customer and complete the project, albeit with difficulties and missed deadlines.

The project itself was designed in two months, and we provided the finished product after 4 months, but only the Android version. With the publication of the application in iOS, we had to do a lot of magic. You can read about it here.

 

What else did we include in the development process?

We experimented a lot with payment, advertising, and analytics libraries. We constantly tried new options and changed existing ones until the result satisfied us. There were technical difficulties in making the functionality that the customer wanted. And, we had to make a lot of effort to make it all consistently work correctly.

Therefore, you might say that at first glance there appeared to be simple solutions given ready-made libraries, but this brought complexity that had to be adapted to a new project.

 

Native app or Cross-Platform?

If we talk not only about money but about the manufacturability of the application itself, in terms of convenience and other things, we might ask which is better. 

With native applications, it would be easier to integrate third-party services, as there is more documentation and ways to work with code and programming languages.

If the customer had chosen native applications, then it would be easier for the development team, and it would take less time to test. But in the end, we found that a cross-platform application was cheaper for the client. It takes a little longer and is more expensive to make native applications, while the cross-platform application causes less stress, nerves and risks. Since it was stressful for both the development team and the client, because many things did not work, we had to allocate a budget to fix and adapt all this.

 

Astrologers sum up…

Our team faced a lot of difficulties both technically and with communication. The biggest challenges were caused by the fact that there were outsourced developers to include. They worked remotely, which made the process of communication and interaction more difficult.

In the project itself, we had to take on the role of leaders in development. We gave recommendations and advice, issued technical specifications to all teams, and constantly communicated with the customer. 

Taking on a leadership role, while at the same time taking full responsibility for the project, it paid off – the product was completed, and the customer was satisfied.

The global smartphone market share is continuously growing. Nowadays, a responsive website or native mobile app is a MUST-HAVE in order to support your presence online.

So, how to start a mobile app from scratch?

Step 1. Specify The Application Concept

Depending upon the type of application, different amounts of time and effort may be required to achieve it. For example, an ecommerce mobile app, a healthcare app, game or augmented reality – each of these requires a different approach and each varies in terms of the technology that must be used for completion. Once the concept is defined, it’s time to hire professionals (preferably a contractor who has expertise in a similar area). In terms of technology and general expertise, for example, you may need an IT professional from a development background who is focused on business mobile apps, e-learning iOS apps or CRM; the mobile market differs from the game studio.

Step 2. Competitors

Review successful competitors. Time is money, so forget the idea that a large-scale successful project can be replicated quickly and for a low price. Remember instead that each product/service has its fair market price. For all large-scale and feature-rich projects I would suggest starting from proof-of-concept, which is just Phase 1. During this phase you will see how the development is going and how fast feedback arrives, and based on that proof-of-concept you will have a clear project plan for the next stages.

Step 3. SOW (Statement of Work Document)

Generate a brief describing the workflow for the entire app. The major focus here is that if you are planning a large app, it is best to have the Statement of Work document ready BEFORE development starts. This will save you money and time in the future. Prepare mockups to make the user flow and use cases crystal clear and design graphic concepts for any major page(s). Share your GO-AHEAD to a development team only once the SOW / specs/ sketches / wire are completed (at least briefly).

Step 4. Data Flow

There are 2 types of mobile apps: stand-alone; and client-server (with the server-side integrated via web services). A stand-alone is a static app where there is no server-side so that each time you need to add anything, you need to use a developer and resubmit the app into the marketplace.

A client-server mobile app allows you to add and edit data under your mobile application via a web-based user interface; when planning a client-server app, please consider that you will have to discuss that interface with a web developer as well.
3rd party API integrations should be discussed with a development team before starting the project (starting from Facebook and Twitter API and up to some specific 3rd party services for retrieving products, services, shipping etc.).

All new data, such as product listings, new posts, new videos, and all new info appearing under your mobile app should be retrieved from some server side; it can be either your current website or external services. Remember that both platforms (iOS and Android) do have serious limitations in terms of the formats supported. So, for example, if you’re planning to retrieve a video under a mobile app from some cameras online, always take some time to discuss the available formats for streaming so that your development team can come up with suggestions regarding formats.

Summary

In order to succeed with a mobile business app or on the gaming market it is essential to follow these four simple steps. As a result, you will have a clear understanding of the scale and scope of the app, so you can track where you are with the development progress. You will easily be able to plan the budget and costs as well as effectively planning the launch date and marketing activities.

The right beginning makes for a good ending.

 

Sincerely,

Itera Research Team