Creating an app - a quick walk-through and some insights

I WANT AN ELEPHANT’s main mission is to provide and deliver tools and services for app publishers and developers. Anyhow, we develop apps in our spare time. Just because we like to do so and to stay up-to-date. However, we often don’t invest the time and energy to market those apps. In conclusion, we don’t try to push them to the limit regarding users, downloads, and revenues. We use them to keep in touch with the tools, frameworks, processes, and store policies.

The following article will illustrate the main steps it takes to create, upload, and bring an app to the stores. Our example is an app for the members of agile projects. The scrum master will get some tools and the developers some planning poker cards. The final result (Google here, Apple here) is available in the stores.

Conception

Our concept includes some basic things. We will not write a full document with hundreds of pages. And as our team for this project consists only of two people, we will not establish an agile project structure. We keep it simple. But some planning, discussion, and definitions are required.

App title

The title should include some basic scrum or agile keywords and give an idea of what to expect. We start with a short search within the stores and see what results we get. We list some basic title ideas and check if they are taken. Naturally, we could use tools like App Annie or others for our research. But we keep it simple.
We decide to have SCRUM (in uppercase) within the title and search for another word which explains the app’s purpose or its functions. “Tools”, “Planning” or similar are already taken. The functions we have in mind are some utilities for the team members. Therefore we choose “Utils” as short of utilities. Results in “SCRUM Utils”. Important to have some basic search terms already covered.

Subtitle

The second topic we think about is the subtitle. It should describe our app more into detail and include a common search term as well. Of course, we could retrieve search terms with Google Trends or similar tools. This brings us to our subtitle “Support your agile project with project poker cards and scrum master utilities”. The subtitle or short description (Android) contains 80 characters. We try to supplement as many search terms as we can.
Is it a good idea to start with the title of your app? Probably not the first step. But we will not bore you with a full concept here. Just give some ideas.

App features

Now we talk about the features and functions of our app, a possible layout, and structure. Above all, we separate our scrum app into two main parts. One for the scrum master and one for the development team. Each user chooses his or her role and saves the selection. The apps only offer the required functions, even after a restart. This brings us to the first requirement (A) – role selection. The team member will get some cards for their planning poker. They choose the card which corresponds to their estimation and experience and shows them to the team. These are the requirements (B) and (C). Offer a choice of cards and display them full size. For the first version, no storage, sharing, or other functionality is needed.

The scrum master will get some smaller tools to simplify his/ her life. The fourth requirement (D) is a screen, with the main scrum rules. Therefore we have to display some text. There should an option to enter some free text into a multiline text field, too. In this field, the visions should be entered (E). As a result, we require again some storage and am editable text area.
To make quick notes, the scrum master should be able to record some audio remarks or comments (F) and take some quick pictures (G). In addition, options to replay the recordings, or respectively display the results within the app (H)(I).
This should cover the main functions. We will add some content sharing for recorded audio (J) and the images (K) and of course an about screen about the authors (L).

Screen design

The last part of our concept will consist of some mock-ups. It is always a good idea to visualize the main screens and functions. We use Draw.io to design our scrum app.

The mock-ups are quickly created and it is always fun to visualize ideas. They will help to discover layout issues and will allow a quicker implementation. And another good part, they are some good marketing material or some nice basis of a discussion on Producthunt, Reddit, or other marketing channels.

Development

To develop the scrum app, we select Google Flutter as a basis. Flutter was released in May 2017. Therefore it is relatively new. Of course, we could have chosen React (check this comparison between React Native and Flutter) among others, but sometimes it is more fun to try a new approach. Flutter allows us to develop quickly, to use hot reload features, and to test and see our developed results quickly. In addition, there are many plugins we could use. A very important point in selecting your tools is market penetration but also further development and community support. We developed apps with Apache Cordova in the past, and here are some tools that have almost reached or are already at the end of their life. E.g. Cocoon and Phonegap. Results in apps, which can’t be maintained or updated anymore.

Development Environment

As IDE we choose Android Studio, as it supports us with Flutter Plugins, mobile Emulators, and many other convenience features. As an alternative, Visual Studio Code would work as well but would require the Android Virtual Device (AVD) which is shipped only with Android Studio.

Development

In terms of coding, it is a little hard to get some insight. Flutter elements are called widgets. We basically combine them to get the views, pages, buttons, and functionality. To get our SCRUM Utils app going, we use various plugins to enhance the standard. A huge library can be found here. The plugins are rated and organized. We choose only the ones, which support Android and iOS and have a high rating. We use (among others):

A camera plugin
To handle device-specific directories, a path plugin
A plugin to handle permissions
A voice recorder plugin for the spoken notes

Coding

Some sample code looks like this:

@override
Widget build(BuildContext context) {
  print(context.locale.toString());
  return MaterialApp(
    title: tr('<main.title>'),
    localizationsDelegates: context.localizationDelegates,
    supportedLocales: context.supportedLocales,
    locale: context.locale,
    theme: ThemeData(
      primarySwatch: Colors.lightBlue,
    ),
    initialRoute: getRoute(role),
    routes: {
      '/': (context) => ScrumRolePage(),
      "master": (context) => ScrumMasterPage(),
      "rules": (context) => ScrumRulesPage(),
      "roles": (context) => ScrumRolePage(),
      "member": (context) => ScrumMemberPage(),
      "camera": (context) => ScrumCamera(),
      "record": (context) => ScrumAudioPage(),
      "vision": (context) => ScrumVisionPage(),
      "about": (context) => ScrumAboutPage(),
    },
  );
}

This is basically our internal app navigation. The user clicks on a button, the routing chooses where to go.
For testing, we create pre-builds and deploy them on the mobile phones we possess. It is always a good practice, to test on as many devices as you can. Including tablets, and the mobiles of your friends and relatives.
After a while of coding and testing, our app is finished and we are ready for the next steps.

iOS and Android

We plan to release our app on Google Play and on the Apple App Store. Therefore we have to take the differences between both systems into consideration.
It is important to choose only extensions for Flutter, which support both. Furthermore, it is essential to have some switches within your code which treat some functionality differently. For instance, finding the correct storage path differs on both devices. Getting storage permission or permission to access the camera as well.

Store assets

Something you might not be aware of, but to publish and distribute, you have to provide a little more than the app itself. Legal and marketing requirements have to be fulfilled. Apple and Google define their store policies and are very strict to enforce them. If you don’t comply, you can’t release your app.

App icon

We start with something fancy. Our app icon. For our scrum app, we do a little research. Just used an image search and check our keywords to get some idea. We brainstorm a little more and get things going. You could choose from many design tools. And start designing. Just a hint, use vector graphics, so your icons scale smoothly. We normally create our visuals with our beloved Inkscape.

The result should be exported as a PNG graphic. The stores require them in a square format. The Play console asks for 512*512 pixels, App Store Connect (former iTunes Connect) 1024*1024 pixels.
For Android, it is now recommended to craft adaptive icons. They adapt better to new cell phones. We will skip this for later. We can verify our icon designs with A+B testing. This allows us to select various markets or user groups and to present dem other styles. With the collected data and reporting we are able to find the look that attracts the most users.

Descriptions and keywords

Description, short description, promo text, keywords, and so on are next. The title and subtitle are ready (see above). Therefore we start to describe our app. We explain the following:

Our features in short and in detail
Who should use our app
The benefits of our app

And we try to add as many keywords, business, project, and agile speech as we can. Always having in mind, the outcome still should be readable. The stores take some basic formatting as well. We are allowed to use whatever is supported. For the moment, we abandon any smileys to stay serious.

To increase our potential audience, we use the App Store Localizer to translate and transfer our final result. We use the import feature to import the translation which we have done on ourselves and use the automatic translation feature to supplement the missing ones. Doing so, we will have searchable and retrievable descriptions for our SCRUM Utils app in about 70 languages and dialects.

App Store localization, translation and transfer

App screenshots

Creating screenshots for our app is fun on the one hand, but a lot of work on the other. To get the best result, we have to create screenshots for all available devices and in all available languages. The first task is designing the screenshots with in-app views, followed by translating them and supplemented by a lot of copy&paste work. The stores allow us to start with one language only. Therefore, not everything has to be ready for our first release.

We get the screenshot specifications from the stores (Apple here, Google here) and create everything in our graphics software of our choice. First the design, then adding the in-app screenshots and the texts.
Then we copy the in-app designs and repeat the whole thing for the next resolutions. Important, as a frame for our screenshots we use store-specific mobile phone skeletons. When we have finished all screenshots (Apple+Google) for one language, we can move on to the next language. This means copy&paste of all images and adding the translated texts. If we would create all possible screenshots, we would result in approximately 3000 different pictures.

Bottom line, it is a manual process. You have the complete freedom of design, but will require some time to finish up everything. The result of our design and our efforts look like this:

Screenshot automation

If you like to optimize your screenshot (approximately 3000 pieces) creation, LaunchMatic is a perfect fit. There are other tools out there, but this is the smartest and newest one.
The intuitive online UI allows us to set up our basic designs quickly. We select our favorite template of a huge selection. Take some in-app screenshots of the Xcode simulator, Android Studio emulator, and our real devices. We import them to LaunchMatic and apply them to each screen. If we change a screenshot or adjust an object, LaunchMatic will automatically distribute the changes to the other resolutions. Finally, we apply our text descriptions in English. LaunchMatic allows us to translate them to all available languages. It doesn’t take a huge amount of imagination: this is a huge time saver.

We used LaunchMatic for our app to create the iOS device screenshots and all tablet versions and all localizations.

LaunchMatic: create and translate your screenshots

Uploading assets

The manual upload of all assets requires us to repeat countless steps again and again. The screenshots have to be uploaded by language and device. Switching the language is done by changing a select-box. We have to copy each text description as well on a manual basis.
The upload of texts with the App Store Localizer (see above) is already automated. But what about the screenshots?

Currently, the App Store Localizer doesn’t have a feature for that, yet. But it will be available in the near future. We then will provide screenshots, credentials, and everything will be uploaded directly to the stores.
In the meantime, we can use the App Store Export & Importer. Copy all screenshots into a ZIP-file, add it to Google Drive and we are ready to go with an automated screenshot transfer.

Publishing

Once our assets (screenshots, texts, icons) are successfully transferred to the stores, it is time for uploading our app builds. To create our Android build, we configure a signing key with the Java keytool and link the resulting keyfile within Android Studio. That’s basically all we have to do for a release within the Play Console.
For our Apple release, we require a little more. Firstly a real Apple Hardware. A MacBook Pro or Air, a Mac Mini is fine as well. If you only process some Windows or Linux Hardware, check out if you could find something cheap on eBay. But be careful, the system should support a current Xcode version. Otherwise, it won’t help.
For iOS, we create signing certificates and provisioning profiles, including the last one(s) in our build, and submit everything to the App Store Connect using Xcode. Check out this tutorial for Android signing and this one for iOS.

Uploading our ready app to App Store Connect

Wrap-up

Of course, this is not the end – we are not done yet. If we work ourselves through the stores, we quickly notice, there is still some information missing. You have to provide some more information about the audience, the available countries, encryption, privacy policies, and more. While some options can be set within the stores themselves, some other material has to be prepared by us.

Website

To host our marketing material and the data policy we create a simple website with a provider of our choice. To have something quick up and running, we choose Jimdo this time. We select a ready to use a template and set up some pictures and a basic description. We provide a contact form as well and of course, add some download buttons and links to the Apple App Store and Google Play Store.

Data Policy/ Terms and conditions

A very important part of our previously created website is the terms and conditions and our app’s data policy. We have to provide a data policy URL with-in the Google Play Console. Otherwise not publication possible. To get a data policy and terms and conditions information, the best option is to contact a lawyer and get things done for you. To get you going, there are some free to use generators to use in addition. They will not replace legal consultant nor replace professionally created agreements.

Approval and review

Now we are almost done 🙂 All assets are uploaded. All builds are online. Of course, we have tested the builds with the store’s testing capabilities. And of course, we have created all content according to the official rules and regulations. It is time to release both apps builds to the public. Google and Apple check your app in detail. There are even real people involved in the process. In the past, we managed to get our apps rejected several times. The reasons are quite different. Of course we never knowingly did anything wrong, but every now and then we just missed something.

Some reasons some of our apps got rejected:

The screenshots do not show enough of the actual app
The sense and purpose of the app is not clear
Terms or names of other apps used within our descriptions
Wrong ad settings during configuration
…

Happy us, if we don’t do anything completely wrong, a new build and a correction of the mistakes normally help to get everything approved.
In any case, we have to consider the time for the release process in our planning. Apple currently needs about one day to release our app. Google currently needs three days to release the app.

Summary

Our app is ready and available to the public (Google here, Apple here). After we received some valuable feedback, there are already some ideas about new features on the list. Time to think about our next release. And the grid is not responsive enough… Or should we invest some time in marketing this time? Or is it better to go for our next app?

Of course, at a certain point, the question of a make or buy decision also comes up. Should we develop everything on our own or find someone for our app’s maintenance? Further thoughts on this, including how much an app actually costs, can be found here.

Creating an app? There are many topics and tasks to consider. Conception, layout, implementation, descriptions, screenshots, regulations, and much more. As an app entrepreneur, you have to be at least familiar with the processes. Hopefully, you got some inside with our article, and maybe our experience, our tools, and our links will help you to get started.
In any case, it is fun to create something. To publish a cool, crazy, or interesting and possibly useful app. For us, having app ideas is an almost daily companion – implementing an app is fun and passion. Give it a try yourself and let us know what you have achieved.

Creating an app – a quick walk-through