Tag Archives: Launching iOS apps

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 history of our interaction with the giant of the mobile industryAppStore – was a long and winding road. Our client had created a fantastic and useful mobile application for those who are interested in astrology. It produced and shared various horoscopes, advice, and parting words, and even offered a function to check the compatibility of people using their horoscopes.

 

The App

The client has a tiered subscription of 3 levels – basic, student and master and offered either for a month or a year. Each level promises to offer more benefits than the last.  The application also includes built-in amulets – pendants, as a digital counterpart.

 

The Process

At first, our application was refused to be published in the Apple app store due to the issue of redundancy, the fact that there are already so many similar applications with our apps current functionality. App Store’s stance – it simply is not needed there.

 

Of course, this response did not suit our client, and we set about attempting to provide alternative solutions to solving this issue and helping our client.

 

While looking for different ways to solve the problem, we first tried to change the application itself, its positioning and its functions so that it looked less like astrology, and more like an application within the “healthy habits” category. Then, after additional thought, we proposed to change the topic from astrology to psychology.

 

The Result

The Application was submitted four times for review, but only three times appealed… We worked collaboratively with the team and Apple technical support about why our application was unique.

 

As a result, we changed the theme of the application and its functionality to better suit what the users would enjoy. New options and features were added, and although they extended the functions of the application, they did not change the essence of the application itself. 

 

Additionally, it was proposed to republish the application on behalf of another company from another country, but in the end, all our actions and efforts yielded our desired results, before this step was necessary. In the end, Apple approved the application in its marketplace.

 

After a difficult and long journey spanning 10 months of trying to publish the application, it was approved. 

 

The road will be mastered by the one who walks it.