Launching A SwiftUI App

This week I finally released 1.0 of Kohldampf, my first iOS app, written with SwiftUI.

Why play around with app development?

I’ve been running into small app use-cases that I didn’t see covered by the apps I could find in AppStore. Being a web developer, I used to implement those as small web apps, trying to keep them responsive and light-weight enough to achieve a good UX. There’s a couple of “gotchas” to using web apps like that:

  • As PWA support probably will never become great on iOS, my web apps just never felt native. Additionally my usage of Safari, with 50+ tabs open at all times, searching the open tab with my web app never felt like a focused user flow.
  • Every web app requires to set up authentication and data syncing. This is something that I’d rather not have to deal with for those small use-cases. Without those, data would be local to one device, which also doesn’t suite my usage.
  • Apple presented SwiftUI at WWDC last summer, and I was interested in Apple’s take of modern UI development. At first sight SwiftUI looked like an effortless way to deliver a native, fluid UI. Having seen the limitations of React Native at work, and living in an Apple-exclusive household, cross-platform is less of a concern for me, as long as cross-device(factor) is a given.

Journey

In October when I had a couple of days to get started with the app, there was pretty much 0 tutorials around – all blog posts were from WWDC with outdated information, as SwiftUI changed considerably across the different betas. As I had no previous knowledge of Swift or native app development, I spent those days mostly setting up a working foundation (data structure and syncing).

Due to the lack of time I only got around to pick up on the app a couple of months later, and went through re-learning the same lessons as in October. My style of learning is by running into problems, and trying to solve them along the way. I just can’t bring it over myself to read a proper book on Swift and memorizing things before jumping into coding. Accordingly I would never claim to know anything about Swift(UI) in a professional context. Expect a post sharing my take on SwiftUI.

Overall I’d say that the app represents two full-time weeks of work, plus maybe another two weeks of after-work development (1-2h).

Deciding to launch

It’d be easy to keep development builds running on my device fleet and call it a day – after all I only wrote the app for my own limited use case, right? True, but now that the work has been done, why not share it with others? Maybe someone else has the same benefit as me, who knows? Additionally it feels more “accomplished” to have released something. This also forces me to QA my work, polish it to a certain degree, but also call it “finished” at some point.

Preparing the app launch (writing app descriptions, screenshots, filling out AppStore forms) took a couple of evenings after work and felt nearly as laborious and unnerving as authoring the app.

Thanks a lot to Maraike for hacking together the landing page (WIP).

Monetization

The app costs a one-time fee, even though I wrote the app as hobby without intent of making money from it. Three reasons:

  • I do not want to contribute to the user expectation that all software is free.
  • The price will keep the user base so small that I don’t have to deal with too much feedback and feature requests. Though one could argue that the cost user paid will actually increase expectation that the app is continuously maintained and improved. I argue that the one-time cost signals to the user that it’s a transparent transaction: the user spends a transparent amount of money for the exact app that is described. The expectation of continuous improvement would be appropriate, would I continuously charge via a subscription, a model that nearly all developer rely on who have to cover for their living costs from developing apps.
  • Other than for web apps, there’s actual costs in having an app, thanks to Apple’s 99€/year developer license. Having a small amount of revenue will reduce my losses (to be fair, I freely decided to have those costs).

Onwards

At the moment my own ideas fill more backlog than I’ll realistically get around to implement this year. But it’s a satisfying learning curve, and that will keep my attention for a bit.