Fixes and Performance Enhancements for VectorBoolean

I’m happy to announce another round of bug fixes and performance enhancements for VectorBoolean, my library for implementing boolean operations on vector graphics.

These fixes were possible due to the gracious funding of Bohemian Coding, makers of Sketch, which uses a version of VectorBoolean.

As before, if you’d like some bug fixes or enhancements to VectorBoolean, I am available for hire. Click the Contact button at the top for how to reach me.

A Postmortem of Failed Products

At the end of a software release it’s common to do a postmortem to determine what went right and what went wrong. It’s a serious time of reflection, important for learning how to be better at your job. Since most of my products have just been end-of-lifed, I thought I would do the same. But instead of serious reflection I’ll just make fun of myself for being a Grade A moron.

These sorts of things need to be done in detailed, orderly fashion, so I’ll take each product one at a time in roughly chronological order, and show how it exemplifies my moronitude.

Illuminate

I actually built Illuminate myself, back when I was at Order N. However it was technically an acquisition because my new company purchased it from my old company. For those who never used Illuminate (read: everybody) it was a window/app switcher, like Exposé or ManyTrick’s Witch.

The one thing I got right about Illuminate is it was actually a novel approach of solving the problem. I thought it was a good one, and exemplified how I wanted it to work, which, as it turns out, is how a moron would want it to work. I never got any press or attention at all, and no one ever seem interested. Potential customers either seemed to think that there wasn’t a problem to be solved (i.e. Exposé was sufficient) or there was and Witch solved it correctly.

I was fairly proactive in asking for reviews, and a few people promised to give one although none of them did. One potential reviewer just didn’t get it (i.e. what’s wrong with Exposé? I only ever have, like, 10 windows open at once). What was worse is they, of course, tested Illuminate with applications that didn’t support the accessibility APIs which is how all the functionality is implemented. So they felt Illuminate was completely, horribly broken and refused to review it at all.

The reviewer did have a point though: the 1.0 version did turn out to be buggy. I ended up investing a lot more time into the app: I fixed many bugs, improved the usability, added some minor features, and got it into the App Store. I also dropped the price down to $10. After all this, I was pretty proud of the app; it was starting to live up to the initial promise.

Not that everything was ponies and BBEdit release notes. The accessibility API’s had all sorts of technical limitations as did the screen capturing APIs, and users were running into them all the time. Of course Apple’s products didn’t have the same limitations, and it was hard to explain to users why this was, since it involved explaining things like private APIs.

And then came the sandbox, which for this article needs it’s own Jaws-like theme music. The version of Illuminate that was in the App Store was technically sandboxed, but had a lot of temporary entitlements. However Apple’s docs made it clear that apps like Illuminate were not welcome in the App Store, and most of the temporary entitlements never gained permanent versions. I believe even ManyTricks pulled Witch from the App Store eventually.

Unfortunately the big problem was that Illuminate wasn’t solving a problem for users, at least in the way they wanted. Illuminate sold maybe two dozen copies during the two years it was on sale. Financially it was a big loss; I spent way more on acquiring it than it could ever hope to generate in revenue. Overall, Illuminate was my biggest failure, both in marketing and financially.

Log Leech

Log Leech was my first product acquisition that I didn’t actually write myself. It was a Mac system utility for viewing logs, and had already gotten a few positive reviews by the time I was approached about acquiring it. After I bought it, I cleaned up the code, made some UI refinements, and ported it to iOS.

I thought porting it to iOS would be a great idea. After all, there was no 1st party competition and a lot of the 3rd party competitors were crap. However, I ran into trouble on the outset. After submitting it to the App Store I got a call from Developer Relations saying they didn’t allow “that kind of app” in the store. I pointed out there were already half a dozen of “that kind of app” in the App Store, which they seemed genuinely surprised about. How were they supposed to know what got let into the App Store?

After all that, I think the iOS version sold maybe 10 copies. Something in iOS 7 broke it, and it wasn’t worth even looking into how to fix it, so I pulled it from sale.

The Mac version did much better. It seemed to be well liked among it’s audience and was even a Macworld Mac Gem once. Which, incidentally, was the only review or press that Fortunate Bear has gotten, ever, outside of my own press releases. There was almost no support email, and almost all of the ones I got were feature requests.

But then the sandbox happened (*dun dun*). In both versions of the app, Log Leech uses the Apple System Logger (ASL) API to access and parse the logs (i.e. it doesn’t read or parse the log files itself). On iOS, the ASL is no problem. On the Mac, the sandbox prevented ASL from reading the files it needed to work. I added a temporary entitlement on ASL’s behalf to read those files so I could get into the store, and then filed a Radar for a permanent entitlement, which is what Apple said to do. However, that Radar was marked as “don’t fix,” which means, as far as I know, there’s no way for a Mac app to use ASL in the sandbox.

By now the future of Log Leech was coming into question. Not only was Mac version going to have to be pulled from the App Store for the next update, I wasn’t even sure what the next update would be. The only way to go forward was to build a deeper tool that didn’t rely on ASL, which would involve a complete rewrite, and the sandbox would still make it difficult. In order to take Log Leech to a financially sustainable level, I would need to add far more features so I could charge more for it since it was a niche market. But I saw no evidence that such a market existed.

And in the end, I just don’t care about log files. God help me, I don’t. I couldn’t muster the energy or excitement to work on it.

Overall, Log Leech was probably my biggest success, assuming you define success as not having to take a second mortgage on your house. It solved an actual problem that people cared about, and had the biggest return on investment financially. Despite those successes, it still didn’t generate enough for even a part-time developer to survive on. It would work as a hobbyist project, but nothing more.

Pagesmith

I picked up Pagesmith (formerly Pagehand) about the same time as Skyscraper. It was my first “major” product, and the first that wasn’t a system utility. I loved the product. It had a unique vision (a word processor focused on typography) and an innovative UI. It was a product that I really felt I could sink my teeth into. And before I took it up, it had garnered attention from some notable people, including John Gruber of Daring Fireball.

So immediately I set off adding the most requested feature of footnotes, and planning the next most requested feature of image support. I got footnotes about 99% there, and even had a user testing it privately. It was about this time I had a much better handle on where the product was technically, and realized I needed to redo the text engine in order to do footnotes and image support properly. There was a large amount of technical debt throughout the entire app, meaning there would need to be a significant time investment just to get the basic, necessary features. The footnotes support never saw the light of day.

The support load for Pagesmith wasn’t that bad. Mainly people were confused because Pagesmith used PDF files as it’s native file format, but they weren’t plain PDF files; Pagesmith stored all the data it needed to edit the file in a custom chunk. So some potential customers thought Pagesmith was a PDF editor which it wasn’t, or didn’t understand why saving a Pagesmith PDF in Preview (which stripped out the custom chunk) made it uneditable in Pagesmith. But other than the file type confusion, most emails were for feature requests, usually footnotes and/or image support.

But then came the sandbox (cue shrieking violins). Actually, the sandbox wasn’t that bad for Pagesmith. The hard part was file association. Previously, Pagesmith had a helper app that would claim ownership of all PDF’s, then at run time determine if they were Pagesmith PDFs or regular old PDFs and launch the appropriate app. Of course all of this was a big no-no in the sandbox.

Ultimately, it was market reasons that killed Pagesmith. Apple’s Pages was the main competitor and for most of Pagesmith’s life, was half the cost and did more things. It didn’t help that Apple recently made Pages free. It’s hard to compete as a solo developer against a team that can give it’s work away for free, and automatically gets top billing in the App Store. There is a small market that wants what Pagesmith has and Pages doesn’t, but it’s not a big enough market to support anything but a hobbyist. Most users are satisfied with Pages.

Financially, Pagesmith was a positive investment in that it made back more than I put into it, although not by a whole lot. Certainly not enough to support continued development. And that’s a shame, because of all the acquisitions it was the most interesting to me, and the one I was hoping to use the most personally. But the market for it just isn’t big enough.

P.S. One of my best support emails came from the App Store launch of Pagesmith. A person, who didn’t even download the app, was so enraged at the concept of Pagesmith he wrote me not one, but two tirades about it. He claimed everything I said in the press release and product page was a lie (even technical specs) and that I was trying to scam him personally.

Skyscraper

I had high hopes for Skyscraper (formerly called Pandora) when I acquired it. Skyscraper was a web crawler/scraper focused on finding and downloading images. It had the biggest and most proven financial history of all the apps I had acquired. I had every reason to believe that if I got a good release out, it could make enough to support itself as a part time project. It clearly had a market, and I thought if I made an iOS port of it, that would be even bigger.

I dealt with the sandbox first this time. It was a major headache and reduced the usability of the app, but I got it approved. This increased the sales from when I was just selling it in my store. So the sandbox wasn’t the death knell this time.

But oh, the support. The support was an unending nightmare. The fundamental problem was Skyscraper was a web scraper and by default used Google Image Search. Google did not like this; Google did not like this at all, because it didn’t use the official API. Google was constantly inventing ways to throttle or stop Skyscraper (well, web scrapers in general) from working. There were so many support requests wondering why it didn’t work at all, or why it would work for a little while then suddenly stop. I think everybody who ever used the app fell victim to Google’s throttling (i.e. you’d get about 3 searches, then it would stop working with no error as to why).

The code was in bad shape too. The app was old, and needed a serious re-write especially if I were going to get it to work on iOS. But this didn’t seem to be insurmountable, it would just be a time investment. However, I never got around to putting any real improvements into Skyscraper because of time spent on other products.

Unfortunately the real downfall of Skyscraper was the name, or the sudden lack of being called “Pandora.” Skyscraper (Pandora) was first created before the music service came out. However, afterwards, a lot of customers apparently bought or found it because they were looking for the music service. I found this out when I sent out my acquisition email to existing customers (which included the rename to Skyscraper) and got a lot of emails back asking how to use it to listen to their music. Sales of Skyscraper never came close to matching the sales numbers of when it was called Pandora.

So suddenly I found myself with an app that didn’t have a market anywhere as big as I thought it did, and it’s main functionality was probably violating Google’s terms of service. I thought about cutting out the Google Image search plugin, and switching to Flickr’s official API and releasing that. But it was clear that’s not what most users wanted and would further shrink the potential market. This, coupled with the large support burden caused me to pull the plug before really doing anything meaningful with the app.

Financially, Skyscraper was a big loss. It only made back a fraction of what I paid for it. In order to make the app work financially, it would require a large and constant development investment, essentially resulting in a one-upmanship with Google, and the time and patience to deal with all the support emails. That felt like a sure fire way of digging the hole even deeper.

Bonus Failure: Vectorspring

Vectorspring was a home grown product that I spent several months on a year or so ago but never released; I even had a brief sneak peek of it on this blog. It morphed a bit during it’s development, but was going to be a vector graphics animation tool, initially targeting the HTML5 canvas tag but then targeting SVG.

Vectorspring was. so. much. fun. Have you ever had a project where you have trouble going to sleep at night because you’re thinking about the challenges the project has, then get up early so you can try out your solutions? That’s how Vectorspring was for me. It was a product that really excited me. I had big plans for it too, like sharing a text engine between Pagesmith and Vectorspring, and re-using some of the same UI ideas.

Of course reality set in later. First was the effort required to get a minimal product together. Like most projects there were a couple of changes in directions that had set me back time-wise. But I had already invested 6 months in it, and it was maybe 40% done, if that. So this was going to cause me to neglect my other products for at least a year all told, and I needed to decide if that was worth it.

The other problem was marketing. I loved working on Vectorspring, but there was no market differentiator. It didn’t have any unique features or innovative approaches to solving the problems. Plus it was already a crowded market. By this time I had learned from my other products how futile it is for a small, young company to try to get any attention at all.

Ultimately I stopped work on it to spend time on other things I thought might have more potential of making some money. I ended up improving Illuminate more (which turned out to be a waste of time), and created Newsline Pro (which has made a whopping $0 since being released). So I could still be working on it and have made the same amount of money. Oh well.

Engineering-wise and personally, this is still my dream app. If I were to pick it up again, I would probably architect it differently, but that’s true of any of my apps. That said, Vectorspring won’t be raised from the dead unless I can come up with a good market differentiator and somehow find the time necessary to invest into it.

Conclusion

So there you have it; my failures, they are legion.

I suppose I should say something insightful here, but I have no idea what that would be, since as this article clearly shows I certainly haven’t done anything insightful. OK, how about this: most of my failures seem to be marketing failures. This includes misjudging if there is a market for a product or how big that market even is. Also I still have no idea how a small indie shop can get press or other attention except through sheer, dumb luck. The only sure fire way I know of involves spending a lot of money, which small indie shops don’t have. Sometimes the press fairy will visit you and give you a shiny product review, but it seems completely unrelated to what you do as a developer. I have no idea why Log Leech got a review and the other products didn’t.

Most of my failures weren’t technical. With the exception of some of the arbitrary sandbox restrictions imposed by Apple, most of the technical problems are solvable given enough time. Which brings me to another conclusion: although Apple can make some things far more difficult than necessary, they’re not really the reason for my failures either. My products were failures before Apple said they couldn’t be in their store.

Which brings me to a question I’ve already been asked: why not sell my products to another developer? For me, that would be dishonest. These products are — market wise — fundamentally flawed. No matter how good they’re made, the market will never big enough to support an indie developer even part time. They might be big enough for a hobbyist, but a hobbyist is better off just writing their own from scratch. They’d certainly enjoy it more. So to me, selling these products would be like selling a car I know to be a lemon.

Everything said, I’d like to acknowledge that I’m incredibly blessed and fortunate. My wife allowed me two years to work on trying to build up a products company, during which time not only was I not bringing in any money but was actively spending large amounts of it. Who has that sort of opportunity? Pretty much nobody, that’s who. So while I’m disappointed that I was handed this amazing opportunity and couldn’t do anything with it, I’m still immensely grateful.