Can someone develop and publish apps

10 tips that clients should consider when developing an app

3) Multiple platforms = more effort

Multiple platforms mean more effort at first sounds absolutely logical, since with native development the app has to be developed individually for each platform (iOS, Android, Windows Phone, ...). Hybrid development could provide a remedy here. But unfortunately this does not always work out.

For a more detailed understanding, let's look at the individual phases of a project:

  • Brainstorming:
    The basic idea of ​​our app is independent of platform and technology, but should not completely ignore the possibilities and limitations of these
  • concept:
    When designing the app, we have to take care of workflows, user interactions and the structure of the app. Here it is important to orientate yourself on the paradigms and possibilities of the individual platforms. In this respect, separate adjustments and extensions to the basic concept may be required for each individual platform.
  • design:
    The basics of the design are identical across platforms, but different designs must also be created for the different user interfaces of the individual platforms and the associated peculiarities or different UI elements.
  • development:
    If the app is developed natively, the full effort per platform must be expected. In the case of hybrid approaches, the effort only has to be calculated once, but optimizations and special adjustments are necessary for each platform. (See also: Web apps vs. native apps)
  • Testing:
    When testing, we always have to calculate the full effort for each platform - regardless of the technology used to develop it. Because the app has to be tested with several devices and display resolutions on every platform. (See also: Effort in testing apps)
  • Maintenance / support:
    All operating systems are constantly being further developed. If a new version with several changes is published, the app must at least be tested on this and possibly also adapted. The structure of the App Store entries and the store guidelines can also change. This means that, regardless of the chosen implementation technology, there are always costs per platform.

4) Choose the right technology

The decision on the technology should, if possible, always be made at the end of the conception phase, since a sensible choice depends heavily on the planned functions and the framework conditions of the project. Every technological decision should be assessed in terms of initial effort, future support and, above all, future security.

As soon as the storage of user data, the connection of external data sources or complex data processing are involved, the app will need support from a server component. The aim should then be to move the business logic of the app into the backend. The app can be created and maintained centrally and does not have to be implemented individually for each platform. This not only saves effort, but above all avoids unintentional differences between the individual platforms and thus minimizes the potential for errors.

5) External services can cost money

Many services that are already common today - map services, routing, analytics, etc. - are available free of charge in their basic versions. However, free does not always mean free, because many of these services are often only free up to a defined limit of users, inquiries, campaigns, etc. From then on, license costs may apply.

The developer usually has to take care of acquiring the appropriate licenses himself. Therefore, when using external services, a usage forecast should always be created, which is included in the selection of the required services as a criterion for costs that arise immediately or later.

6) The content trap

Apps are often labeled as software products. The effort involved is seen primarily in the actual programming. This impression is misleading, because in fact, conception and content creation usually make up a very large, if not the largest part of the effort.

As a client, you should therefore expect that someone will have to “bring the app to life” and, if content is not generated by users or automatically, will have to provide content.

In addition, help texts or FAQs often have to be tailored to the individual platforms, as these either describe specific processes or use individual terminology. So it can happen that one or the other text has to be available in several versions.

7) Testing is time-consuming - also for the client

Testing an app is time-consuming and requires the right equipment. While with iOS, due to Apple's monopoly, the variation in different devices and operating system versions is still reasonably manageable, with Android & Co. this changes drastically. There are hundreds of devices with different operating system versions, resolutions, display sizes and performance and equipment features. In any case, the app should be tested on a representative set of devices. If there is a smartphone version as well as a tablet or even a smartwatch version, these device classes are also added.

While testing the app on the different devices is still easy, it is a bit more complex when connecting third-party systems and your own backends. Test routines and corresponding test systems help to simulate situations in a targeted manner and to simulate error cases.

Last but not least, you should also note that a smartphone can sometimes be offline or has a very unstable or slow internet connection. If the app depends on an online connection, such situations must also be simulated.

8) Apps have to go through the review

Apps cannot simply be published in the App Store. On the one hand, they have to adhere to the store guidelines and, on the other hand, at least at Apple, they have to do a manual review in which employees of the company check the app according to these guidelines. Apple specifies a duration of approx. 2 weeks for this review (in practice more than 3-4 days), but also does not guarantee any lead times. It is particularly important to note that every new version of the app (after a rejection or an update) starts this process from the beginning.

With Android, apps are immediately visible in the store. But be careful, here, too, automated processes run in the background that thoroughly check the app. For example, if third-party brand names or logos are used (without prior written notice of your own rights to do so), the app will be rejected due to trademark infringements. Then there is only the way to complain about this case via a support form. Waiting times of 2-3 weeks are not uncommon. (See also: Trademark law in apps)

9) Plan an app relaunch in a targeted manner

As a client of an app, you should have an idea of ​​the further development right from the start. Because the higher the user base, the more difficult it will be to carry out a complete relaunch of the app at a later point in time. On the one hand, users get used to operating concepts and appearance, and on the other hand, mainly to the functions offered. Simply removing existing functions during a relaunch or throwing proven ones overboard often results in a rapid decline in store ratings.

Therefore, when developing an app, “rule no. 1” should be observed: Never remove individual functions from an existing app without a valid reason (such as poor usage figures for the feature) or without offering a replacement. Most importantly, take care of the data migration. There is nothing worse for the user than when laboriously entered data disappears after an app update or cannot be exported or migrated before a function is removed.

10) Keeping apps alive means effort

Like pretty much everything in IT, apps and mobile operating systems are a constantly evolving ecosystem. Developing an app and then stamping it as done is not a good idea:

  • First, there will be errors that will only be noticed during ongoing operations and will have to be rectified as quickly as possible.
  • Second, there will be user feedback that should be considered.
  • And third, the app has to adapt to the changing requirements of operating systems and app stores.

Regular maintenance and updates of the app are therefore essential. Currently, at least for iOS and Android, the manufacturers publish a major major release for the operating system once a year (around September). This means that at least this date should be planned as a fixed point for testing and updating the app to the new operating system version.

Further reading tip:

• The development process of a mobile app: From the idea via the app store to the smartphone - Part 1

• The development process of a mobile app: From the idea via the app store to the smartphone - Part 2