In the past couple of years, I have spoken to several aspiring iOS developers about what kind of hobby app they should make after escaping the tutorial trap. By “hobby app”, I mean an app for which one does not intend to be paid at all by an employer or enough by users to cover one’s living expenses. As someone who used hobby apps to jump-start his iOS-development career and who continues to develop hobby apps, I am interested in this question. I share my thinking in this post with the hope of providing thought-food to anyone considering development of a hobby app.
Reasons for Making a Hobby App
Before answering the question of what kind of hobby app to make, the developer should answer, for a reason that will soon become apparent, the question of why make a hobby app at all. Here are some of my reasons:
-
A hobby app acts as a professional portfolio. Just as a musician can point to recordings of performances as evidence, for a potential client, of competence as a musician, an iOS developer can point to hobby apps as evidence of competence as an iOS developer. Although this benefit is more important, professionally speaking, for someone lacking a history of employment as an iOS developer, my situation in 2015, I maintain that hobby apps continue to provide me professional benefit even now, four years into my career as an iOS developer, for the following reason: Although the two apps I’ve worked on professionally since 2015 are impressive, useful, and worthy of pride, these two apps provide limited evidence of my competence as an iOS developer because I created them in collaboration with one and a multitude of other iOS developers. Much of the success of those two apps is not the result of my own efforts but rather of the efforts of the fine iOS developers I have worked with. But I am the exclusive developer of my three hobby apps, Immigration, RaceRunner, and Conjugar. I therefore maintain that, to the extent that these apps are good, they provide evidence of my professional competence that my two jobby-job apps cannot.1
-
A hobby app can provide value to myself or others that cannot be obtained from other apps. For example, as of 2013, there was no iOS app that featured the four most-important sets of United Statesian immigration laws and procedures. Immigration, an app I released that year, does this, thereby providing value to the population of users who require access to these laws and procedures, a population that has ironically not included me for some time. For another example, although there are many iOS run-tracking apps, there is no iOS run-tracking app that provides features focused on racing and training for races. RaceRunner does. I race. RaceRunner therefore provides me value. There are many Spanish-verb-conjugation apps, but none taught, until the advent of Conjugar, all the tenses and the curious practice of voseo. Conjugar therefore provides value to Spanish-verb-tense completionists.
-
Creating a hobby app can serve as a learning experience, either about app-development in general or about a specific app-development concept. Immigration, my first iOS app, taught me about app development. RaceRunner, my first Swift app, taught me about Swift. (Let’s just say I wrestled with optionals.) Conjugar taught me about programmatic layout and dependency injection. Indeed, I created and recently enhanced Conjugar to teach other iOS developers about those concepts.
-
Creating a hobby app is a fun activity. There are many activities that are potentially even funner than creating a hobby app, so why not engage in those instead? For me, playing the iOS game Vainglory™ is one such activity. The game is so fun that, if I had no obligations and no goals other than improving my gameplay, I could play the game from sunup to sundown and beyond. I have, from time to time, engaged in multi-hour sessions playing the game, but these long sessions leave me feeling queasy, like I had just consumed a large bag of Cool Ranch Doritos,™ particularly when I suffer a series of embarrassing losses in the game. On some level, seeing those hours go poof bothers me. In sharp contrast, sessions of working on my hobby apps leave me with a pleasant feeling of accomplishment, a feeling that is even stronger after I solve a knotty problem like integrating in-app subscriptions or CloudKit.™
-
Hobby apps can earn income. Not enough income, by definition, to provide one’s entire livelihood, but income nonetheless. Definition aside, one reason that hobby apps cannot provide one’s entire livelihood is that a commercially successful app requires marketing and salespersonship. I submit that maintaining, marketing, and selling an app that provides livelihood-level income entails enough work for a full-time job. But the potential for income in a hobby app is more compelling when other motivations are less present. For example, I created Immigration because, in early 2013, I saw the potential for deriving value from such an app in my day-to-day work. As I noted above, I no longer derive any personal value from Immigration, but the fact that the app earns more-than-enough income to pay for my developer account is one reason I maintain that app.2
Reasons Not to Pursue a Hobby-App Idea
If you can answer the question of why create a hobby app, the answer to the question of which hobby app to create becomes apparent: the app that best serves the hobby-app purposes described above. I’ve already described how my three hobby apps serve the hobby-app purposes, so to flesh out this analysis, I’ll describe some apps that wouldn’t serve the purposes and that I therefore wouldn’t develop.
-
Just as the value that an app provides is the reason people use a particular app, fun is the reason that people play a particular game. I therefore consider fun to be the game analogy of app value. I experimented with SpriteKit and enjoyed the challenges of, for example, implementing a virtual joystick and horizontal screen-scrolling. But I do not have an idea for a game that would be so fun that the game would provide a compelling alternative to the plethora of recreational activities that are available to me or to other humans. At present, then, any game I could create would not provide significant value. For this reason, I have no plans to create a game.
-
Some app ideas present difficult logistical challenges. For example, I might have a great idea for a social-networking app and the chops to implement the app and backend, but I do not have the time or budget to convince people to use a new social-networking app. This lack of users would frustrate the purpose of a social-networking app, connecting with other humans. Because of these logistical challenges, I would not create a social-networking app.
-
I sometimes compose and edit long-form text on my iPhone, primarily in Notes. I could create a text-editing app. Relevant APIs spring to mind:
UITextView
, CoreData, and CloudKit. But I have no ideas for features I could include in a text editor that existing apps like Notes, Bear, and Google Docs do not already provide. In marketing terms, I would be unable to articulate a unique value proposition for my hypothetical text-editing app. In the absence of a unique value proposition, I would not be motivated to maintain the app for my own use or advocate use of the app to others. The app would likely languish in the App Store, unupdated, until Apple pulled it after some form-factor, OS, or architecture change. Given the effort involved in creating and releasing an app, this outcome would sadden me. Accordingly, I would not create a text-editing app. -
Some app ideas might run afoul of either present or future App Store Review Guidelines (Guidelines). In early 2018, I created a Java app, Permitter, that visits daily the website of my region’s light-rail system and buys permits for the system’s closest parking lot.3 My wife has been using this app to buy her permits daily since early 2018. This app provides her tremendous value in that, if she did not have it, she would need to visit the website daily before 6:30 AM. I wrote this app in Java, but I have considered porting it to Swift and iOS, which would allow me to productize the work I have done. Although browser automation, the core functionality of Permitter, is not explicitly forbidden by the Guidelines, rule 2.5.6 gives pause: “Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.” Would Apple reject Permitter from the iOS App Store based on rule 2.5.6? I don’t know. Will the Guidelines ever include an explicit rule against browser automation? I don’t know. This uncertainty would prevent me from releasing Permitter as an iOS app.
-
Some apps require domain expertise that the developer does not possess or may have difficulty acquiring. For me, this would rule out, for example, a hobby app focused on freediving, “a form of underwater diving that relies on breath-holding until resurfacing rather than the use of breathing apparatus such as scuba gear.” I have no expertise on freediving. Even if I were interested in gaining sufficient freediving expertise to make a hobby app focused on it, and I am not, my loved ones would understandably frown upon my engaging in this hazardous activity, impeding my development of a freediving app. I note that not having domain expertise, by itself, is no reason to rule out a hobby-app idea. In early 2017, when I began work on Conjugar, I had virtually no knowledge of Spanish-verb conjugations. But I have an aptitude for studying languages, and I learned. (Pro tip: SpanishDict.) My research and study were considerably safer than freediving.
There is one factor that should not cause the developer to rule out a hobby-app idea: a high degree of difficulty. Given sufficient time and motivation, I am confident that I can surmount any software-development challenge. My first app, which I started work on mere weeks after learning Objective-C and iOS development from the online Stanford course, features a scrolling tab bar and hierarchical-list control. Although certain app ideas may be impossible to implement in one’s spare time, I submit that focus on difficulty needlessly constrains a developer’s ambition. As a relevant aside, I have observed the following benefit of working with product managers and designers in the professional setting. Although product managers and designers consider input from developers on difficulty of implementation, this difficulty is not top-of-mind, allowing them to dream bigger. These bigger dreams, I have found, result in better apps.
Call for Factors
This is my thinking on hobby apps. What other factors have you, the reader, considered?
Credit
Although I have been ruminating on app ideas for more than 6.5 years, recent discussions between Sean Allen and guests on his podcast iOS Dev Discussions prompted this post, and I thank him for this prompting.
Endnotes
-
The unfiltered stream-of-consciousness that would emanate from my brain in the absence of any constraints would probably not interest the reader. I’m not James Joyce. I therefore tend to avoid lengthy tangents in my posts. But consideration of the professional-portfolio benefit of hobby apps raises a question that is unrelated to the subject of this post but nonetheless worthy of consideration: Should the source code for a hobby app reside in a public GitHub repo? One argument in favor is that persons who are interested in the developer’s competence can easily inspect the source code and assure themselves of that competence. This is why RaceRunner, which I developed before I secured full-time employment as an iOS developer, is in a public GitHub repo. Aside from professional considerations, the very purpose of an app may be to teach other developers about software-development concepts. This is the case for Conjugar, which demonstrates programmatic layout and dependency injection. A public GitHub repo is the natural home for such a pedagogic app, and Conjugar therefore resides in one. But there are drawbacks to this code visibility. One is that if an app exists, at least in part, to earn income, as Immigration does, code visibility could facilitate copycat apps that could depress income. This is why Immigration does not reside in a public GitHub repo. Another is that code visibility could facilitate low-quality copycat apps. This happened to Conjugar. Someone released to the App Store a low-quality copycat app, creatively named “Conjugar-Learn Spanish”, that appeared identical to Conjugar except for its name and app icon. I say “appeared” rather than “appears” because the latest version hangs on launch after demanding push-notification permission whose purpose is unclear. I say “low-quality” for the same reason. I am annoyed that searching in the App Store for “Conjugar” surfaces this copycat, potentially confusing would-be users of my app. In light of this unpleasant copycat experience, I advise against putting the source code for a hobby app in a public GitHub repo unless there is a compelling reason for doing so, for example a pedagogic one. ↩
-
The main reason is that people find Immigration useful. ↩
-
Why Java? As explained in Permitter’s readme, I was unsuccessful in my exploratory attempts to use an iOS browser automator, WKZombie. I had no desire to roll my own browser-automation framework. Selenium is a well-established browser automator that is sadly unavailable on iOS. Selenium does appear to work on Mac, but for cost reasons, my home server runs Windows. Selenium has bindings for Java, a language I used professionally in the early aughts, so I used Java for Permitter. ↩