DH Bot
A native iOS app written in Objective-C and designed in Storyboard UI. Built for the Dreamhost API.
12 minute readGitHub Repository
Introduction
DH Bot was an iOS app first released on November 11, 2014. It was built to control the DreamHost API, which had very few app options on the App Store. The final release of the app was March 16, 2015. The DreamHost APIs have since been deprecated and removed from the DreamHost web control panel. Without an API to use the app itself became useless.
The following sections highlight the design, development, and attempts to monetize the app. The goal with DH Bot was not to develop "lean" and hope updates win over customers. Rather, the minimum viable product was very close to the final product. This was my second lesson in app economics—and likely my last.
Icon
I probably fussed over the details and lived in Illustrator more than I should have. There's no traceable return on icon investment but App Store buyers are visual deciders. If the icon is no good then how can the app be good? My reasoning is that people do judge a book by its cover.
The mascot for DH Bot is called "Treddy". An early version of Treddy had trouble incorporating the 'H' in DreamHost. The idea was there but the execution was way off. The final version achieves the same intent. Some highlights and lowlights were added, gradients adjusted, and it was ready to ship.
Code
Everything in DH Bot is written in Objective-C using Foundation, UIKit, iAd, and StoreKit. Those frameworks along with RestKit to interact with the DreamHost API create the foundation for DH Bot.
The DH Bot Xcode project uses CocoaPods to manage dependencies. As of the final version, v1.1.0, there are 8474 lines of code excluding dependencies.
Per my usual practice I document extensively even for my own applications. It's the professional thing to do. The developer you write doc for could be yourself. My rule of thumb is 1:2 ratio of doc to code.
| Language | Files | Blank | Comment | Code |
|---|---|---|---|---|
| Objective C | 136 | 2455 | 2245 | 7430 |
| C/C++ Header | 138 | 785 | 2501 | 1044 |
| Sum | 274 | 3240 | 4746 | 8474 |
The final version of the app supported most of the DreamHost API.
- Overall Status (
account-status) - Domain Usage (
account-domain_usage) - User Usage (
account-user_usage) - SSH keys (
account-list_keys) - Lists (
announcement_list-list_lists) - DNS Records (
dns-list_records) - Domains Hosted (
domain-list_domains) - Domain Registered (
domain-list_registrations) -
Domain Availability check (
domain-registration_available) - Jabber Users (
jabber-list_users) - Mail Filter list (
mail-list_filters) - MySQL Databases (
mysql-list_dbs) - MySQL Hostnames (
mysql-list_hostnames) - MySQL Users (
mysql-list_users) - VPS Servers (
dreamhost_ps-list_ps) - VPS Reboot (
dreamhost_ps-reboot) - Users (
user-list_users_no_pw)
User Interface
Native UI development is crude and severely lagging web development stacks. It's frustrating. Internationalizing is easy for strings in code but I hit some bumps when those strings were in Storyboards. I couldn't do everything in the Storyboard so eventually added custom cells via XIB files.
An elaborate storyboard connects the view-controllers together. You can see how most view-controllers branch from the same area. The flow is generally: [api key] ➞ [list of commands] ➞ [command results] ➞ [result details].
The process to update the translated .strings file after
changing the base Storyboard is awkward and poorly integrated with
Xcode. DH Bot had a rough translation started in French but nothing
officially supported in iTunes.
Onboarding
The onboarding experience can be an interactive tour or a set of slides. Onboarding is another way to bridge the gap between developers and users. I feel it should plainly state:
- The purpose of the app (its primary function),
- What's needed (an account, e-mail, etc), and
- Any costs or expenses associated with use.
In other words: no surprises. The app description should include all those points. However, this ignores the expectations of the platform. Users expect to download, install, and run in less than a minute. At best, app descriptions are scanned by the customer. My expectation is that the first paragraph is read and nothing more.
Here's a sample of the onboarding screens from DH Bot. They're displayed when the app is first started and on subsequent updates.
Monetizing
The store concept of buy once, update forever doesn't align with the goals of an independent developer concerned with cash flow. It's an ongoing effort to support OS updates, new phones, changing APIs, and other forces outside their control. The number of DreamHost customers can only grow at a moderate pace over time, thus, recurring revenue from existing customers is the key.
Attempt 1: In-App Purchases
Now we come to the point. The developer seeks to make a profit from his hours, days, weeks, and months of labor. Points are the DH Bot currency of commands. To execute an API command you need to spend one or more points. DH Bot setup the following in-app purchases:
400points $0.99800points $1.991,400points $2.992,200points $3.993,000points $4.99
Each API command has an associated point value. Most getter commands cost one point but setters are two points or more. Additional points are available via the App Store. Command point values are prominently displayed. Every user starts with free points to try the app.
Despite these efforts it was clear the business model was flawed so after a few months it was abondoned.
Attempt 2: Ads
Points and in-app purchases were removed. The market pushed DH Bot in a direction I didn't anticipate but one that I now accept as the default: ad-supported or free. Unfortunately, click-through rates are low and the app itself is built to do one or two things quickly.
Ad-supported business models are based upon the attention economy which yields a completely different product. DH Bot couldn't build a large enough user base. The generated ad revenue had zero financial materiality. The economics of app development are still evolving but it's clear an app like DH Bot was one of many in the long tail.
Banner ads and—even worse—interstitial ads already look dated and unsightly. Users expect integrated ads that flow through the app, much like social media apps inject ads between updates on your timeline. Whether uses like them is another question.
Retirement
DH Bot is no longer on the App Store but I occasionally reference its codebase. If I need a reminder how I implemented something say, with StoreKit, then I take a peek at the code and comments.
As a longtime DreamHost customer I was writing the app for myself first but hoped others would discover its value. I also discovered the risk in developing a product based upon a service I didn't control. There's no guarantee the terms of that service will remain compatible with your business, or that the service itself won't be shut down.
Plan your apps accordingly.