More App Rejections

From Cromulent Labs, whose app launching widget was initially approved by Apple and then removed from the App Store:

But this time I decided to make a more concerted effort, start a company, and see if I could make some app (or apps) that could simply keep me employed and pay the bills….As with any iOS app, there was a chance (perhaps this this case, more than most) that the app would be rejected by Apple, but I figured it was worth the risk once I determined that it was technically feasible and I found nothing in the App Extension Programming Guide that disallowed it.

And that’s the problem. More and more people are creating businesses and sometimes quitting their jobs hoping they can make it on the App Store. Some do. Many fail. And yet others create a wonderful app, featured by Apple, loved by users, only to later have Apple squash their hard work. The developer assumes all the risk and often pays for it.

I pleaded with this person to make public whatever guidelines they make available for app reviewers to decide what is acceptable and what is not regarding widgets. The Apple representative responded by saying that they prefer that the rules remain vague because that allows developers to come up with innovative ideas and also allows Apple to be flexible in case they change their minds later. When pressed on the issue of their policies leading to wasted developer time, I was told, “If you are afraid something you are working on will be rejected, then don’t work on it.”

Kafkaesque?

During this same conversion, I also asked specifically why Launcher was removed from the App Store after 9 days when other similar apps are still available weeks later….They basically said that Launcher was a trailblazer in uncharted territories and that they felt that they needed to make an example of it in order to get the word out to developers that its functionality is not acceptable without them having to publish new specific guidelines. And they said that the fact that they aren’t seeing hundreds of similar apps submitted every day is proof to them that taking down Launcher was successful in this regard.

I’m so thankful that the apps I depend on to earn a living aren’t in the App Store. Stories like this one and Panic’s recent rejection make me want to give the developer a hug and introduce him to Mac development.

It’s becoming harder and harder to justify the risk of building an app and launching it on the App Store. Developers bear all of the risk. And even after approval by Apple, there’s the looming threat that Apple could reverse their decision at any time.

It all goes back to what I wrote in response to Brent Simmons‘s question, where are the indie iOS developers? Other than game developers, I don’t think there are or can be any. It’s just too dangerous. If you want to earn a living, move to the Mac, get out from under Apple’s foot, and charge a sustainable price for your work.

Being an Indie is Hard

Zach Waugh of Giant Comet and Flint fame writes:

But even after I released Flint for iOS in late 2013, I was only making about half of what I would need to go full-time comfortably. Building apps by yourself is a grind, and I was starting to wear thin, so I decided to leave Giant Comet as a side-project.

A wonderful product, aimed at a passionate, niche market and it’s still a struggle and grind to make it full-time.

On a different note, Jared Sinclair with advice for the creators of the superb Crossy Road, who he’s afraid might go out of business…

So much about staying alive as an ISV now depends on intangibles far beyond your design and programming abilities.

Knowing When to Quit

I hate using the word “quit”. Because it’s not quitting. It’s not even “giving up”.

Today, the prolific Manton Reece wrote a blog post announcing that he is sunsetting his Twitter apps. This, after a recent announcement that Twitter’s (amazing!) new fully searchable tweet archives won’t be made available to third-party developers.

Twitter’s fully-searchable index is an announcement I’ve been waiting on for years. Back when I worked at Yahoo!, I co-created Sideline, a cross-platform desktop client for searching Twitter. A year later, after Sideline was sunsetted, I rebuilt it as a native Mac desktop app called Incoming!. Both Sideline and Incoming! were fantastic ways for discovering what’s currently happening on Twitter and for following the latest trends – whether that be an Egyptian uprising or whatever the hell latest trouble Justin Bieber is into.

But those apps were always crippled by the lack of history in Twitter’s search API.

If Twitter hadn’t already turned into such a giant dick towards third-party devs, their full-search announcement would have filled me with technical amazement and hope at the amazing apps that could be built on top of such a corpus. Sadly, I knew it was too good to be true, and sure enough, a link from Marco sealed the deal.

It’s only a matter of time until all third-party apps are either pushed out of business or users leave for features we simply can’t compete with.

As I said at the top of this post, Manton isn’t quitting. He’s one of the most thoughtful developers I’ve ever had the pleasure of speaking with. He, like many of us, is simply recognizing when a window of opportunity has closed shut. I applaud him for the care with which he’s shutting down Tweet Library and Watermark.

Not to jump on his bandwagon, but I’ve also decided to remove Incoming! from the Mac App Store. It’s ability to dive into breaking news and social trends by aggregating tweets never caught on the way I had hoped. I kept it alive for the last few years hoping that, eventually, we’d get access to Twitter’s entire history. But now that we know that isn’t going to happen, I see no reason in keeping it alive.

Incoming! will of course continue working for users who already have a copy. I plan on making a free version available later this year on my archives page for anyone who still has a use for it.

An Indie Mac Business – Breaking Down the Year

Back in July, for reasons outlined in these two posts, I wrote about the financials of my indie Mac software business. With the year coming to a close, and with the prodding of a few friends, I thought I’d share where the money from my total yearly sales actually goes.

First, the big numbers.

If you read my original post on the topic, you’ll know that in 2013 my software grossed $58,093 in total sales. Since that’s the last complete year of sales data I have, we’ll start with that number. Where does the money go?

Immediately off the top is the commission I pay FastSpring for handling all of my e-commerce. FastSpring charges 8.9% per transaction. That’s quite high compared to a payment processor like Stripe (who I used to use exclusively), but FastSpring offers benefits beyond simply credit card processing that make them worth the extra cost.

So, $58,093 minus 8.9% leaves $53,600.

What are the costs of running my business? I do my best to run a lean ship, but here’s what I’m paying out each month…

  • Grasshopper for a virtual 800 number – $288/year
  • Hockey for beta testing and crash symbolication – $120/year
  • Adobe Photoshop – $120/year
  • Rackspace – One legacy server that I need to move to Linode – $216/year
  • Linode – My primary web server plus two proxy servers that run Lift Off – $600/year
  • DigitalOcean – One server where I host my GitLab installation – $240/year
  • Pingdom – Server monitoring – $108/year
  • Amazon Web Services – Static files stored in S3 – $48/year
  • MaxCDN – CDN for my web server – $70/year
  • Mailchimp – Mailing lists – $100/year (I pay-as-I-go rather than a monthly plan since I’m an infrequent sender.)
  • Domain names – $250/year
  • SSL certificates – $100/year
  • Apple Mac and iOS developer programs – $200/year

That’s everything that’s in my spreadsheet and off the top of my head. Like any business, there are other incidentals throughout the year, but that’s most of them. Grand total?

$2,460

That brings our total down to $51,140.

Finally, taxes. I put aside 30% of every paycheck. Which leaves us with with $35,798 or 62% of what we started with.

My main goal for the new year is to finally grow up and get an actual accountant rather than handling everything myself with TurboTax. I know there are tax and payroll strategies I’m not taking advantage of that could save me real money.

My Checklist For Releasing a New Mac App

In my previous post about how I use OmniFocus, I made reference to an on-hold project template called “New App Release”. Anytime I release an update to one of my Mac apps, I follow this checklist. In case it’s useful to other developers, here’s what it contains…

  1. Verify build with Deploymate – this scans my Xcode project and compares all of my API calls against my build target warning me about any deprecated, missing, or private API calls.
  2. Increment version number in Info.plist.
  3. Tag the release in git.
  4. Publish the git tag.
  5. Archive the project in Xcode and export a [Developer ID].(https://developer.apple.com/developer-id/) signed build to the Desktop.
  6. Verify Gatekeeper and code signing is correct by running spctl -a -v App.app.
  7. Zip the exported app binary.
  8. Write release notes and upload the new build’s zip file to your hosting provider of choice.
  9. Do whatever you need to do to make a new release happen in Sparkle.
  10. Do a test update in the old version of the app.
  11. Do a test download of the new version from your website.
  12. Upload the dSYM file generated by Xcode’s Archive step to Hockey or whatever crash symbolication service you use.

Thanks to Tony Arnold for prompting me to post this checklist.

Delegating Tasks and Outsourcing Your Indie Business

A few weeks ago there was some discussion online about hiring virtual personal assistants to help offload non-essential business tasks. Around that same time a Twitter user messaged me (and quite a few other indie devs) asking what sort of business tasks we would consider outsourcing. I’m pretty sure this industrious @replier was just looking for job leads, but it did cause me to stop and consider what parts of my business would I be comfortable delegating to an assistant.

The short answer is, not much.

For developers of a consumer-oriented product I think there might be a strong possibility of being able to hand off documentation writing and lightweight customer support. It would be great if I had someone answering emails that only required a link to an FAQ article, leaving the truly in-depth questions for me to answer.

But for a technically niche product like VirtualHostX, I worry my non-specialized assistant wouldn’t have the technical chops to answer anything but the most basic support questions. Writing documentation would likely also be a problem. However, if they’ve used the software proficiently in the past, the thought of them editing together some instructional screencasts is very appealing – as that’s something I never find the time to do myself. I’d love to build a list of topics and then have them go off and come back with screencasts ready-to-go. I’d easily pay a few hundred dollars a-piece for that service.

So while I’m not comfortable outsourcing my core business tasks, I have begun delegating personal tasks to free up more time for the business. A few months ago I signed up for Fancy Hands. For a few bucks a month I have access to a network of virtual assistants that I can send odd jobs to. Basically, anything non-confidential that can be completed electronically and/or remotely is fair game. I’ve used my assistant to schedule appointments, cancel hotel reservations, price shop, and do online research. I’ve been very pleased so far.

At first I found it difficult to come up with tasks to delegate to the service. A week or two would pass and I’d suddenly think “Oh, crap. I haven’t tasked them with anything lately” and worry about not getting my money’s worth.

So, I created an “on hold” context in OmniFocus called “Fancy Hands” just like I would create for any other person I assign tasks to. Then, during my weekly review or when I’m flagging tasks for the day, I’ll consciously keep an eye out for anything I can assign to them. This helps with remembering to delegate tasks as the possibility of doing so is forefront in my mind.

I don’t have any big conclusion or take-away. These are just my thoughts after actively trying to learn how to delegate tasks while running a one-person company.

Paul Kim on His Indie Journey

I want to give a big thumbs up and a hug to everything in this fabulous post by Paul Kim. I missed it back in August when this discussion was initially happening but came across it on Gus’s blog this morning. Paul writes about his expectations starting out with Hazel and what he’s discovered looking back on his success. This portion specifically speaks to my (moderate) success and what I’ve learned:

But it wasn’t easy and it wasn’t overnight. A common sentiment I see among a lot of new devs is that if they aren’t living full-time off their app in the first year, it’s a failure. I know when starting out there is the hope that your app will be an immediate success. It’s fine to hope that; after all, its our dreams that drive us to succeed. But you shouldn’t expect it. I would say it took about three years before I could be comfortable living off of it full-time.

That’s exactly one of the points I was trying to make when I wrote about my own journey. My initial expectations for VirtualHostX were very tempered – I just wanted to earn enough money over the lifetime of the app to install hardwood floors in our tiny house. But, as the app and my audience grew, I would occasionally readjust my expectations – eventually to the point where I could financially sustain myself by my app revenue alone.

Jalkut says the same thing in a tweet from July:

If you release your 1.0 with awareness that you may not succeed until 5.0, you’re in good shape.

Paul’s other point about luck is also worth keeping in mind:

One thing that I did learn is to have a healthy respect for randomness. Luck plays a huge role and you can’t always attribute one’s success or failure solely on their decisions and actions….That doesn’t mean you sit back and just let fate decide; you still need to work to improve your chances. Just realize that there’s a big chunk you can’t control and that on some level, you need to be ok with that.

While I’ve poured a lot of time, energy, and work into my apps, I’m very much aware that a lot of their success is just dumb luck. Case in point: I was extremely fortunate that of all the apps I could have built, I happened to pick a niche market without any serious competitors. Not only did that make me the only game in town, but it also allowed me time to breathe and let my app grow organically to meet my ever growing list feature requests from my customers. Sure, picking a niche in an underserved market is business school 101, but for the dumb twenty-four year-old that I was, that was a supremely lucky break.

In any case, if you have any interest in a successful indie journey, give Paul’s post a read.

Marching Through the Wilderness

(How could I not title this post after one of my favorite David Byrne songs?)

Gus has a terrific post on his blog about what he calls “the wilderness” – a period of time between major software releases “where I’m pretty lost, and I don’t know what to do.” His working theory on the matter is that it’s basically a forced period of rest put upon you by an overworked brain. How do you get past it? The same way you walk out of any wilderness – “One foot in front of the other…You can walk for miles and maybe months in the wilderness. Just keep on going.”

I take comfort in knowing that I’m not the only one who experiences periods of low energy slogging through work like this. Unlike Gus, however, I don’t blame it on a stressed or over tired mind. For me, as someone who suffers from depression, I know that these periods aren’t just a symptom of working too hard, but that they’re actually just one part of a cycle between times of depression and times of whatever the opposite of depression happens to be.

I’ve been tracking my mental health through copious notes and journaling for three years as a way to better understand what triggers my depression, how long it lasts, and what I can do to work my way out of it. The biggest lesson I’ve learned is that these periods always have an end. They’ll pass. If you have faith that that’s true, then it becomes easier to listen to your mind and not try and force things when the timing and mood isn’t right. In the same way that I take advantage of my mentally high states and code like a crazy person, I know to divert my focus to other more doable tasks when I’m at a low point. Rather than coding, I’ll update my FAQ articles, record screencasts, or do a deep dive into my marketing analytics safe with the knowledge that I’ll come through to the other side and return to coding in a better state of mind.

Gus equates escaping these periods with putting one foot in front of the other and continuing to walk until you find your way out. For me, I see it more as riding waves on a boat. There’s going to be low points just as there are high ones. The key is to keep sailing.

All The Services and Tools I Use to Run My Software Business

When I started selling my first Mac app in 2007, there was no App Store. I don’t even think “app” was a word. And there certainly wasn’t any ready-made infrastructure for selling software online that you could simply plug into. That meant, like every other independent developer, I had to piece together my own solution for accepting payments, hosting downloads, activating license codes, and delivering app updates.

As I wrote about back then, I rolled my own web app called Shine to coordinate all the disparate services I use to run my business.

August 2014 was the seventh anniversary of my first product release, so I thought I’d take some time and describe what my current setup looks like and all the tools and services I’m using to keep my business humming along.

Shine – My Indie Control Panel

Shine still powers the core of my business. It’s the controller that connects all of my other web services together. You can read a more detailed description of the software here. But, in general, here’s a list of all the functions it handles…

  • Order processing
  • Validating upgrade eligibility
  • Manual order creation
  • Order history and lookup
  • Generating invoices and receipts
  • Generating coupons
  • Basic sales and business stats and charts
  • Generating serial numbers
  • Software activations
  • Collecting and storing user submitted feedback and support requests
  • Searching for, displaying, and archiving mentions of my company and products on social media
  • Coordinating new app version releases, which means accepting a zip file of the app, storing it in Amazon S3, and pushing the new update to users via Sparkle
  • Generating publicly viewable changelogs
  • Sending transactional emails
  • and many other little, but essential, tasks

I literally couldn’t run my business without Shine. Well, I couldn’t in 2007. Services like GumRoad, FastSpring, and Stripe could handle for me much of what Shine does. But I’m so invested in the software it’s hard to move on at this point. Also, I love the ability to control the code which means I can dictate features and business logic exactly as I see fit.

Payment Processing

I originally used PayPal to accept accept orders. Their IPN API would ping Shine whenever a new order came through, and Shine would generate a license code and email the customer. In 2009 I switched to FastSpring. You can read about my experience making the change from PayPal to FastSpring. tl;dr FastSpring is way better. They take over as the seller of record and handle all aspects of order processing. When an order comes through, FastSpring sends the order information to Shine for safe-keeping, and Shine returns a license code. FastSpring also handles emailing the customer a receipt and their license information. They’re also where I go whenever I need to process a refund. Twice monthly they deposit my sales into my bank account minus their commission.

For six months in 2013 I switched away from FastSpring and handled the entire order flow in-house on my website using Stripe. I really liked owning the entire solution – and especially liked Stripe’s much, much lower transaction fees. It also enabled me to use Stripe’s Objective-C API to build a store directly into my apps, so customers could enter their payment information without ever have to open a web page. Unfortunately, I saw a decrease in conversions. I also wasn’t able to calculate VAT and sales tax on my own, so I switched back to FastSpring.

Also worth noting, it’s super easy to integrate FastSpring’s checkout process with your Google Analytics account. The result is all of your sales data, products, and goal conversions nicely tracked and charted in your Analytics account.

Managing Mailing Lists

I’ve been a happy MailChimp customer for five years now. You can read more about how I use and manage my mailing list.

For the last month I switched over to using Drip for sending out my VirtualHostX welcome emails, and they were great. But better analytics, better email template designs, and higher conversion rates led me back to MailChimp.

Sending Transactional Emails

MailChimp is great for sending email blasts, but for transactional emails I use Postmark. Their pricing is affordable and their API is super simple to work with. Whenever an order comes through to Shine, I use Postmark to send out the customer’s order receipt and license information. They do a very good job of managing their outbound email servers’ reputations, so I’ve never had any problems with the emails I send getting flagged as spam.

While I’m 100% satisfied so far with Postmark, I am looking into switching to RackSpace’s Mailgun service so I can send delayed emails. I’d like to automatically send a followup email to customers asking if they have any questions a week after purchase, but I’d prefer not to handle the queueing logic myself. Mailgun’s API has a simple, optional parameter when sending email that allows you to specify a future date when the email will be sent. That’s very appealing to me. I’ll post my results if and when I make the switch.

Web Hosting

All of my servers are hosted at Linode. That includes my primary web server, which hosts all of my domains and the Shine web app, plus the proxy servers which handle VirtualHostX‘s Lift Off service.

I originally started out on SliceHost, and then migrated to RackSpace when they acquired Slice. RackSpace was great, although very expensive compared to AWS. Still, they treated me wonderfully (including a dedicated account manager), so I stuck around. Eventually though, I had to move away after years of them never getting around to supporting two-factor authentication. I just had so much of my livelihood hosted on RackSpace, I couldn’t afford the danger of getting compromised, even using a strong password. (So, if you’re reading this RackSpace, 2FA is the primary reason I left – and, yes, I’m aware of your 2FA beta program, but that came too late.) I’m now on Linode and very happy. Their all SSD machines build my Jekyll site in two seconds, compared to the 14 it took RackSpace’s spinning disks.

Source Code Hosting

I was a very happy paying GitHub customer since 2008, but switched to GitLab in 2013. The short reason for the switch is my GitHub monthly cost ballooned to $50. So, I spun up a $20/month DigitalOcean box, installed GitLab, and now host all of the private repositories I want. You can read a detailed account of why and how I switched from GitHub to GitLab.

My Website

As I noted above, my website is hosted on a Linode instance. It used to run on WordPress, but I found it much simpler to maintain by switching to Jekyll. Another huge consideration was the speed of serving static HTML files with Jekyll versus database backed WordPress pages. Here’s a Pingdom chart showing my site’s average response time before and after switching to Jekyll.

PingdomResponseTime

Content Delivery Network

All of my static website files and app downloads are stored in Amazon S3. My website serves those files over MaxCDN‘s content delivery network using my S3 bucket as a pull zone. Their bandwidth runs me about $100 a year and it’s lightning fast. I could use Amazon’s CloudFront as my CDN, but I find MaxCDN’s control panel for occasionally purging the cache much simpler to use.

Phone Support

I use Grasshopper for my phone support. It costs about $20/month for my own, dedicated 1-800 number. In practice, I rarely do phone support and let most of the incoming calls go to voicemail, but I’ve heard nothing but positive comments from customers who appreciate that there really is a dedicated toll-free number they can call if needed. It makes them feel like there’s a reputable company behind my software. (There is!) Even if you never answer the phone, I highly recommend getting at least a voicemail box where customers can get in touch.

Crash Reporting

All of my Mac and iPhone apps use the HockeyApp SDK for crash reporting. I’ve found their crash symbolication service to be top-notch. Because I already have my own infrastructure setup with Shine, I don’t need a lot of their other services, but the $10/month I pay for crash reporting is completely worth it.

Email Hosting

I use Gmail for all of my company email. You can’t beat their price, search capabilities, and keyboard shortcuts. But, as a backup precaution, I’ve had all of my personal and company email forwarding into two FastMail accounts for the past few years so I can immediately switch providers if it should come to that.

Domain Names

I moved all of my domain names from GoDaddy to I Want My Name four years ago. I knew I wanted off GoDaddy, and at the time, IWMN was the only reputable registrar I could find offering .io domain names.

All of their features and support are great. My only complaint is their dashboard is sloooooow – on the order of 5-7 seconds between page reloads.

SMS Messages

My Mac app Minion has a need to send text messages to users. Twilio was my first choice and they’ve served me well. Their API was a little confusing at first, but now that I’ve got it up and running it’s been rock solid. Their pricing is on par with every other provider I’ve looked into.

Personal Assistants

I recently started using the FancyHands virtual assistant service to offload some of the more mundane tasks of running my business. I’ll have them do research, book and cancel hotels, and whatever other small tasks I don’t want to deal with myself. I’m still testing the waters, but I hope they can become an integrated part of my workflow.

So, that’s it. Off the top of my head, those are all the major services and tools I use to run my indie software business. As I’ve grown up as a business person these last seven years, I’ve learned to delegate and pay money for services that can do a job well instead of trying to handle everything in-house myself.

First Impressions of Using Drip for Email Marketing Automation

About six months ago I began collecting the email addresses of folks who downloaded my app, VirtualHostX. This was entirely opt-in. I simply placed a MailChimp signup form on my download page. I promised users who join a three email course introducing them to a few of the major VirtualHostX features and a 10% off coupon for when they purchased. My goal wasn’t to collect their email addresses and, later, market to them. I simply wanted a way to automatically communicate with users new to the software and make sure they got off on the right foot.

Setting this up in MailChimp was surprisingly simple. They’ve got a whole section on email automation. Kudos to them.

A couple weeks ago, however, I ran across a new marketing product called Drip. It’s founded by the author of a book I really enjoyed about solo entrepreneurship. Drip promises to handle email automation similar to MailChimp but with better goal tracking and higher conversion rates.

I was intrigued.

After going back and forth for a week, I ripped out my old MailChimp form and installed Drip’s pop-up box last night. MailChimp has served me great, but I’m ready to go beyond simply sending emails and towards measuring the actual effectiveness of them. I’m hoping Drip’s goals and conversion tracking will give me those insights.

All of this is influenced by a realization I had earlier this year. VirtualHostX has reached a mature, stable state. There are plenty of more features I can add – my todo list is overflowing – but I’m wondering if I’m starting to see diminishing returns with regards to how many more sales I make compared to how many new features I build. I’m wondering if I could see a bigger difference in sales simply by upping my marketing game. I hope to find out that answer, to a small degree, with Drip.

Anyway, I plan on writing a full review of Drip and what success it does or doesn’t bring me in a few months once I’ve had time to see its effects on my mailing list. But for now, I just wanted to offer my sincere amazement at what a well-executed service it is. As far as I know, Drip is one of the small players in the industry. And I honestly wasn’t expecting much fit and finish. But I’m seriously impressed so far. Their entire onboarding process was stellar. And the workflow that led me through setting up a campaign, building my email course, and getting their JavaScript and tracking installed on my website was phenomenal. They’ve done a really, really great job.