Developing an app in one month

October 31, 2019

Reading time ~5 minutes

Moodassist app icon

A month is usually quite a short time for the development of a whole app. The vision I had was quite small, so I figured, that this a challenge to pursue. The initial idea started with an app that I am using myself. A mood tracker that reminds me to enter my mood every day. After a couple of days or weeks, I can see trends in the recordings. Our mind may trick us into believing that everything is wrong or right in our life just because we had a bad respective good day. Saving the data helps to bring some more objective insights. The problem with the app I was using is, that the app is missing one critical feature. I want to be able to export the data to correlate it with other metrics, for example, my body weight. The idea behind measuring stuff about yourself is called „quantified self“. Thinking long term, this is another data source for a personal ai assistant. In an ideal world, we would be only using open source software, so that I would be able to add this export option to the software by myself. Unfortunately, in order to solve this problem, I have to write this app myself. I just had learned the Swift programming language, wrote my first microservice and developed for the Apple Watch. This was a chance to utilize my knowledge. While I could have used this project to explore even more technology, I stuck to the areas which I was familiar with. A project like this has enough learning opportunities to encounter. Coming from the indie game development scene, a mantra was often repeated: Releasing is the most important feature. People who followed my work may know that I never released my game Caveland in the final form. This time I took this mantra to heart and focused on delivering.

One app? No, two apps!

Initially, I started with just the iPhone app. With the launch watchOS 6 a new app store for watch app launched. I saw an emerging market opportunity with the introduction of said store. Therefore, I decided to complete the standalone watch app first. I used a Watch series 3 for testing. I previously worked with a model of series 4. You could often feel that computing power is a limiting factor. Unfortunately I have no benchmark data. With less computing power, programming becomes more unforgiving as non-performant code easily becomes noticeable. The first version I handed to Apple had some huge performance problems, which I only discovered the moment I showcased the app to someone. This performance issue made me realize that a lot of wearable and other small devices suffer from limited energy availability. There is so much stuff you can not do with wearables because as a consumer you want all-day battery life. This is an interesting fact when looking at the rumors for Apple’s augmented reality glasses. It is not possible to see the App Store through the simulator, which is included in the development platform Xcode. Only once I got hands on the hardware I could see the new store. During development, I found a lot of outdated code on the web. It seems that developer interest in the Apple Watch has plunged.

So now I made the Watch app. I planned to also implement a server or, how it is marketed nowadays, as a „cloud“ feature. What is the use case of the cloud feature? The way the cloud support is implemented is mostly a proof of concept of the philosophy I envision before. A privacy and secure way to connect personal data with other services.

When you already have a data export feature, importing is not a too far fetched idea. To make this feature more meaningful I also needed support for another platform. Therefore, I finished both apps together so that you can get both in a bundle. The iOS app was halfway done anyway.

In my mind, I envisioned a whole platform with a web client and a Mac app. I understand that your mood data is sensitive information. Therefore I designed a system after the principle of privacy by design, where it can be guaranteed that no one can use the data against you. The solution is easy. The access to your data is not connected with an e-mail address, phone number or username. You get a randomly generated code. You can share it and if somehow someone gets to know your code and should not, you can just move to a new randomly generated code. The disadvantage from a business point of view is that there is no way to send you e-mails for advertising.

When you develop a product, the hardest part is actually finishing it. Dozens of projects fail because the creators lose interest or one feature after another is added. Presenting your work can be scary. Upon completing the project, you will find something which needs to be changed, you have always ignored, or is unexpectedly not done. I am glad it is done.

You can get the app in the App Store.

Technical wisdom for developers

Some notes for people, who are interested in building stuff themselves. Properly deploying took the same amount of time as developing the first version of the server software. I am a bit disappointed by the state of python server development. I used uwsgi in combination with Flask. Uswsgi is by default using outdated python 2. As reconfiguring did not work, it was easier to stick to python 2. I observed some response time spike (2s) after some idle time during the night. My hosting provider says it is not them and puts the blame on my software, which I have to put on uwsgi or python. Next time, I like looking into some other language. I like Swift a lot. Swift for servers currently only runs on ubuntu.

Digital. Physical. Minimal.

When I was young I was very excited about the new personal computer technology. This is why I pursued a career in the field of technology. H…… Continue reading

About this blog

Published on September 02, 2018