What do I need to know before starting my app

Everyday our company gets more requests of this kind, either by phone, email or the web.

I need an app for…

The first thing we do is make sure our client actually needs a mobile app in order to interact with its clients. Is it necessary to be able to use the app offline? What data should be available offline? These might be simple questions, but they let us build a secure base for our budget. In any case, our job is far from being done, and we haven’t made the sale yet!

Next, we assess our client’s technical knowledge. When our counterpart is technical, it’s easier to explain and to agree on certain aspects of the software development. But if they lack that expertise, we must double our efforts in order to bring the best service to our clients.

Every software development follows a life cycle. The product is BORN, it LIVES and it DIES. Just like with life itself, a software will spend more time living than in any other stage. Therefore, we must make sure our clients understand that they’re going to invest more money in maintaining their products than they will to actually make them or to discontinue them.

This is particularly the case in the Mobile world. Companies like Apple and Google are constantly modifying the hardware and software of our products. Every year Apple comes up with a new iPhone or iPad, along with new iOS (Apple’s operating system for these devices) versions. And we’re not even contemplating the many partial updates. The same thing happens with Google, launching a new Android version each year. And how about those devices? When we actually buy one… it’s already become obsolete!

This means that, when our mobile app is ready, we must implement updates at least once or twice a year, within the platforms we use. Otherwise, we must make sure to not make any type of changes. Adjustments, modifications and additions need to be made in order to contemplate new functions and user’s suggestions. If we consider all of this, it’s quite obvious we need to consider a maintenance budget.

Let’s go back to the explanations given to our clients. Having a development budget is crucial. In general, we won’t know it until the moment we actually send the estimate to the client. In today’s competitive world, this is acceptable and even unavoidable. However, we do understand how this aspect could have a negative impact on the product’s future. Once we have a global budget as well as a development budget we can advise on the other stages of the production, which also require funding. For instance: an amazing app, but without any marketing budget, is doomed to fail.

Next, we’ll detail the technical options for the development of mobile apps. There are 3 main types of techniques/technologies to create a mobile app.

Native, hybrid and generated code apps
We won’t deal with whether one technique is better than the other one. Each one has a specific purpose and they all have pros and cons. However, we do want to provide all the data so that our clients have the necessary tools to make an informed decision and so they can benefit from it.

Generated code
With tools like Xamarin we can develop mobile apps which implement a native code, developing on C# through Visual Studio. In theory, just one development allows us to generate an app for both IOS and Android. These apps will probably have the same performance as a native one.

Pros. The biggest benefit is the initial development cost: one development, two apps.

Pros. If we already have experience with C# language, we don’t need to learn XCode or Java.

Pros. We can develop it with just one person.

Cons. Just like with any tool, we must consider the fine print of the contract. There could be licensing costs, like with ReactNative.

Cons. If the client wishes to further maintain (with his own team) the app, they will have to find capable resources with experience in this specific platform. This will increase the maintaining costs. This aspect is the most sensible and least considered by our clients.

Cons. These tools have no official support by makers of mobile devices such as Google or Apple. This means that, at any given moment, they could be bought by another company, they could close or disappear. If this should happen, our client’s product will need to be developed again from scratch.

Hybrid
Hybrid apps are kind of like an application or website within a masked browser, which we call the shell. Just like with other apps, they let us, with just one development, change the shell in order to keep our app working on both platforms.

Pros. One development, two platforms supported. This has a very positive impact on budget.

Pros. One developer should be enough to do all the work.

Cons. This technique creates more layers than the other ones, which means we’ll never be able to achieve the same performance or speed that we can have with a native code app. An app featuring a lot of multimedia, or a game, is unfeasible.

Native
This type of app has a more pure construction. They’re developed by using the mechanisms, languages and tools provided by or officially supported by the maker of the operating system. In the case of Android (Java and now Kotlin or C++) with Android Studio, and in the case of iOS (Objective-C or Swift 1, 2, 3) with XCode. It’s clear we have to make two developments, possibly with two people.

Pros. We have almost complete guarantee that our product will work on most devices. We have the support of the technology’s makers. There’s no need for middlemen or generated code, which has a positive impact on the resources management.

Pros. We can make any kind of app that we get asked for. The only limits come with operative systems.

Cons. The main negative aspect is budgetary, since we need a double effort in order to achieve both platforms (if that should be the case).

Pros. Support within time. Many know the story of Parse (backend platform, bought by Facebook some time ago). It was the base of many apps until Facebook decided to shut it down, forcing many people (with just one year notice) to migrate their apps. This is one of the many things that can happen when using a tool from a third party. With native apps, as long as the operative system is still functioning, we won’t encounter this problem.

Beyond pros and cons, it’s important to make sure we have a clear idea of what the budget for an app will be, since we have to consider the entire life cycle of said app. There’s no use in selling an app that won’t be able to survive.

At inmind we focalize on the development of native apps. We have enough experience to know that, in some scenarios, other mechanisms can be the best option. Still, we focus our effort, knowledge and experience on native apps.