DH Bot is my newest app designed for the App Store. If you’re not sure what DH Bot is, then read its summary page and come back. The short version:
Access the DreamHost web panel API with speed and simplicity using your iPhone or iPod touch. Check account status, domain registrations, disk usage, and more.
For the longest I referred to it as DH Manager, or DH Man for short. Over time the masculine, sheer brogrammer-ness of the name irritated me, so I changed it to DH Bot. The design process for the icon seemed to flow much easier if I could focus on something like a robot. However, the legacy of DH Manager still lives on, as all classes are prefixed with DHM.
A week or two of design and several iterations resulted in the mascot for DH Bot, which I call “Treddy”. Previous attempts to incorporate DreamHost into parts of Treddy were downright ridiculous.
An early version of Treddy had trouble incorporating the ‘H’. 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.
Everything in DH Bot is written in Objective-C. It’s still early to jump on the Swift bandwagon, but it looks promising. With either language, the steep learning curve is still the massive Apple frameworks used for development: Foundation, UIKit, and StoreKit. Those three frameworks along with RestKit (to interact with the DreamHost API), create the foundation for DH Bot.
Dependencies can be a huge burden if you’re integrating various open source projects. The DH Bot Xcode project uses CocoaPods to manage dependencies.
There are 7585 lines of code (SLOC) as of v1.0.0, which excludes dependencies. If you’re tracking SLOC then I recommend using the tool CLOC. Counting lines of code doesn’t represent a meaningful metric. It’s nice to know but it doesn’t indicate stable, bug-free software. I tracked SLOC progress because there are fewer inaccuracies than tracking hours. I could also track commits to Subversion but filtering on what gets committed is harder. I’d then have to figure out how to filter out commits related to graphics versus code. It just gets messy. So, here’s a graph of the actual SLOC. It includes only DH Bot header (.h) and implementation (.m) files.
I have a couple indicators to determine whether a platform can enable your work or hinder it:
- How it handles strings, and
- How it manages lists (or tables) in the UI.
UIKit handles both reasonably well. Internationalizing is easy for strings in code but I hit some bumps when those strings are in Storyboards. The process to update the translated .strings file after changing the base Storyboard is awkward and poorly integrated with Xcode. DH Bot has a crude translation started in French but nothing officially supported in iTunes. It’s not clear which translations would yield the most value.
There are some quirks with UITableViewController and how UITableViewCell is customized while using Storyboards. I couldn’t do everything in the Storyboard, so eventually added custom cells via XIB files. No problems that plenty of Google research didn’t finally clarify.
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 onboarding experience can be an interactive tour or a set of slides. It’s great to see this catching on in the software community. Onboarding is another way to bridge the gap between application developers and users.
The onboarding 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. One could argue (rightfully) 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.
Now we come to the point. DH Bot is not a charity organization. The developer (me) 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 will have the following in-app purchases:
- 400 points $0.99
- 800 points $1.99
- 1,400 points $2.99
- 2,200 points $3.99
- 3,000 points $4.99
The store concept of buy once, update forever doesn’t align with the goals of an independent developer concerned with cash flow. Effort is ongoing 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.
Ads are another way to earn income if the app is used frequently, by many users, and who (hopefully!) generate an excellent click-through rate. I’m trying ads with Elevator CEO and the results are not good.
So, the effort to create a sustainable business model centers on in-app purchases. From the app description:
Each API command has an associated point value. Points are consumable, in-app purchases. Most getter commands cost one point, but setters are two points ore more. You can buy additional points to keep executing commands. Features and improvements will be free, which is why DH Bot itself is a free application. You also get free points to start.
Command point values in DH Bot are set by Unsaturated Innovations LLC according to the cost of DH Bot development, testing, and maintenance.
This pay-by-usage is exactly what sustains the developer and what differentiates a hobby from a business. The key is to be upfront and clear about costs.
A Well-Earned Promotion
I’ve been a DreamHost customer since 1999. Last year I contacted them to request a hi-res version of the DreamHost logo to use in-app. It was returned with the utmost speed and friendliest customer service. DreamHost refreshed their logo a couple months ago. I requested the logo again (a year after my first request) and DreamHost’s Creative Director, Jason, sent me an update. If you’re looking for a great hosting company, it’s hard to do better.
It’s about time they had an app to match it.