Software

How not to become an indie developer

The write-an-app-and-get-rich-quick meme has been circulating ever since the iPhone SDK was first announced.

As a long-term Mac developer, I took it all with a pinch of salt. Success certainly hadn’t come that easily for me: I started developing “shareware” for the Mac in 1994 and only went full-time indie in 2006; so after 12 years of part-time indie-doom.

Yet, the get-rich-quick meme was endemic for many years and it sure looked as if every high-school kid who wrote an app became a zillionaire overnight. Nobody (and I mean nobody), ever said “I’ve got a great app, but it’s not making that much money”.

The economics of the iOS app store were always a mystery to me: How can you make a steady income from 70% of $0.99, even forgetting about sales tax in much of the world? Can you really sell thousands of apps every day.. forever? In a marketplace that full? With such a huge bias for novelty and the “next big thing”? all the while competing with all the VC-backed “free” offerings?

It did not seem likely to me that there were a lot of people out there making the kind of money that allows you to pay back your mortgage and bring up your kids.

Intrigued nonetheless, I decided to make a small experiment  in the early days of the App Store: I used some of the existing stretching routines from my MacBreakZ product to create a small iPhone app, just to see what would happen. StretchZ sold a few copies here and there, but it was much as I had thought: you need a really good app to make “decent” money.. and even then the effort-to-revenue ratio is prohibitive.

About half a year ago, Brent Simmons finally dared to ask the question: “Where are all the successful Indie iOS App Store developers”?

This unleashed a flurry of opinion pieces resulting in some of the developers with more or less respectable success to post their sales figures online. Respect! I won’t publish my figures any time soon 🙂

The recent revelation that even indie rock star Marco Arment of, amongst other things, ATP podcasting fame, does not make much more than an average developer in industry, was sobering for many.

The discussion seems to have bifurcated into roughly two camps since:

  1. the Doom-and-Gloom camp
  2. the Forced-Optimism camp

The difference between both camps is largely down to what their expectations were.

The Doom-and-Gloom-ers are coming to realize that it is very though to make a living on the App Store even if you make top-notch apps.

The Forced-Optimism crowd tend to be excited hobbyists, who are delighted when they see that some day, they might actually be able to make a living from doing what they love!

On the one hand, I find some of Forced-Optimism crowd quite irritating because they bend over backwards to keep any blame for what is going on from Apple. On the other, the Doom-and-Gloom crowd often seems to blame only Apple and seem unwilling to take much responsibility for their perceived lack of success themselves.

These are of course sweeping generalizations and there’s not a single individual who fits in only one of those camps and many developers have a more much subtle and nuanced view. I’m overstating their positions to make a point: reality is more subtle.

I think that it is naive to believe that you can just go out there, develop an app that you would like to use yourself, put it on the app store and wait for the millions to come rolling in. Yet, that seems to be a fair description of the general approach taken by many developers and “idea people”.

Engaging in ridiculous oversimplifications such as “apps need to be beautiful”, “apps need to do one thing really well”, etc. is not enough to be successful in a competitive market.

Similarly, keeping any blame for the current situation from Apple is just as ridiculous.

Apple did not blunder into this situation by chance. Apple took a very deliberate choice to create a walled-garden App Store for iOS. You cannot install an app on your Apple devices without Apple’s consent and Apple has enforced its the role as gatekeeper. It is thus more than fair to hold Apple accountable for what happens in its store.

The aforementioned naive belief of many developers that just writing an app will make you rich does not come from nowhere. Apple has been at pains to present the App Store as an Eldorado for app developers. They never cease to announce the billions that they “share with app developers”, so perhaps app developers can be excused for having high expectations.. and Apple can be blamed for creating them.

Apple also creates the shape of the App Store through its own policies. Early on Apple seemed to simply have repurposed the iTunes music store implementation to now sell apps. In fact this is still the case.

Top 10 lists, featured sections, $0.99 price tags, no communication between content providers and content consumers, no trials, difficult returns, etc.. all this is the stuff of the Music industry and not that of the software industry.

Free trials, discounted upgrades, direct contact with customers, FAQs, Wikis. That is the stuff of software development.

You can call this “old fashioned”, but Apple has hardly “reinvented” the software industry. What it has done is turn software into a consumable piece of entertainment.

Is it it any wonder that professional grade software isn’t doing great on the App Store?

Why then is Apple so unwilling to change anything?

The answer is quite simply that it seems to be working very well for them. Change is always dangerous, especially if you don’t understand why you are successful in the first place. It is easy to talk yourself (and others) into believing that you are successful because you are doing things the way that you are. The more successful you are, the easier it is to convince yourself that you are doing everything right.

I’m fairly certain that Tim Cook isn’t losing any sleep worrying about how much money Indie developers are making.

What does all this mean for aspiring Indie developers?

Go in expecting nothing. Don’t give up your day job.

Don’t be naive and expect that you’ll be an overnight success. That, as they say takes 10 years.

Don’t rely on money you may never see. Write your first killer app for fun and a bit of pocket money.

Once you’ve got your app in the App Store, try to learn from what happens. What did you do right? What did you do wrong? How far are you from being able to go part-time? What is  your back-up plan?

Also avoid spending your own money on your killer app in anticipation of a large pay-off that may never come. Paying a designer tens of thousands of dollars makes the designer happy, but it is more likely to make you poorer than richer. Once you’ve established that there’s a market for your app, you can still invest in more professional help.

Indie software development can be an enormously satisfying experience. You can create something yourself and share it with the world.

It is also a very hard thing. It takes a lot of effort and energy. It is full of ups and downs. Having people use your stuff can be very rewarding, but you’ll also have plenty of negative feedback. If you have thin skin, now is the time to grow a thicker skin (still working on it personally).

Keep your expectations in check.. Don’t take crazy risks, and above everything else: Enjoy the experience.

 

 

Image Capture Workflow Updated for A Better Finder Rename 9

Back in 2009, we published a couple of blog posts describing how to
use OS X’s Image Capture.app with A Better Finder Rename 8:

The second post linked to an Automator workflow to use with this process, but the release of A Better Finder Rename 9 “broke” this workflow; it works only with A Better Finder Rename 8.

We have updated this workflow for A Better Finder Rename 9, so you no longer have to settle for the default import location. Instead, you may choose your import destination at run-time. Grab a copy of the workflow here:

Vitamin-R 2.0 Upgrades & Mac App Store

It’s been almost 3 years since Vitamin-R was first released into the public eye.

Those who experienced version 0.01 beta 1 (!) can testify to how much the product changed between then and the 1.0 release and of course Vitamin-R has never since stood still for more than a few weeks. In total, we have up to this point released no fewer than 109 updates and I think you would agree that it’s now nearly time for the big 2.0 release.

If you own any of our software, you will have noticed that we release features as soon as they’re ready. This helps us create better product as we get feedback earlier and it also gets new features into your hands quicker.

The price we pay for this practice is that we don’t get to do the “big reveal” when the time comes to ask you for an upgrade fee.. but rest assured that we are making an extra special effort to make 2.0 more than just another point update!

Many people hate upgrade fees and we accommodate these people by providing “forever upgrades” both with your initial purchase and at any point after.

While upgrade fees may be a little painful, they are instrumental in ensuring that a product meets the requirements of experienced users. Without them there is little economic incentive to develop a product beyond what is necessary for its immediate appeal. It is no coincidence that most iPhone apps get used only a couple of times before they are forgotten forever.

Without upgrade fees there’s no economic incentive for developers to look past the moment of the sale, leading to software that is optimized for immediate appeal but fails to live up to its promise shortly thereafter. We want none of that. With Vitamin-R we want to introduce you to a more productive and enjoyable way of working and support you at every stage of your journey. In order to do so we want to furnish you with the tools to evolve your own style. This means making Vitamin-R highly customizable and leveraging your usage information to provide you with insights into your own work patterns; neither of which does much to increase the immediate appeal of the product to prospective new clients.

Please note that none of this means that we are intend on making Vitamin-R more complicated. On the contrary, streamlined operation is even more important for experienced than for novice users.

In the past, we have always given customers very generous “grace periods”, meaning that if you bought the product shortly before a major upgrade, we would grant you a free upgrade.

Unfortunately in the changing world of Mac software development this is no longer so easily done.

As you may know the Mac App Store, through which many of copies of Vitamin-R are bought, does not offer any support for paid upgrades. Instead Apple is charging full price for major new versions of its software such as “Pages”, “Numbers”, “Keynote”, “Final Cut Pro”, “Aperture”, etc.

This makes a lot of sense for Apple who operate on the “big reveal” model more than perhaps any other company in history and who of course make money on the software sale, their 30% App Store processing fee and on hardware sales.

This puts software developers like us into an awkward position.

We are masters of our own web stores and can continue to offer discounted upgrade pricing, forever upgrades and “grace periods” and we will.

On the Mac App Store, however, it’s Apple’s rules all the way. There are no discounted upgrades, no grace periods and we do not even know the identities of the people who buy our software.

All third party software developers are facing the same problems. Some decide to go Mac App Store only. Some decide to stay off the Mac App Store altogether. Most, like us are trying to mitigate the problem as much as we can.

We realize that not everybody will be happy with our solution, but what we have decided to do is the following.

To Get A Discounted Upgrade to Vitamin-R From Our Web Site / To Take Advantage of the “Grace Period”

1. Direct and Mac App Store customers alike will be able to buy a discounted upgrade from our web store via http://www.publicspace.net/Vitamin-R/upgrade.html

2. Direct customers who have purchased Vitamin-R after the 1st of January 2013 will be able to obtain a free upgrade code to version 2 from http://www.publicspace.net/unlockCodeDB/index.html

3. Mac App Store customers who have bought Vitamin-R after the 1st of January 2013 will be able to obtain a free upgrade by mailing their iTunes Store receipt to support@publicspace.net

This is much the same retrofitted solution that OmniGroup are going to apply to OmniFocus 2 upgrades.

Vitamin-R on the Mac App Store

As many of you know, Apple has decreed that all new Mac App Store submissions must comply with their new requirement for using the Mac OS X Lion “Sandbox”.

This is a security mechanism that restricts what applications can do. By default applications can do almost nothing other than bring up a window and respond to mouse clicks; there’s no access to your files, the internet, etc. This limits the damage that a crashing or virus-infected application can do. If the application, for instance, cannot access the internet or the file system, it can’t steal your data and it can’t transfer it anywhere.

It is then up to the developer to define which “entitlements” their application requires (e.g. I need access to user files, I need to be able to open a web browser on the product homepage, etc.) and up to Apple to grant or reject such entitlements. Obviously the fewer entitlements Apple grants the higher the security.

This is how iPhone and iPad apps have always worked: can’t do much, Apple decides what they can do.

It’s also the exact opposite of how Mac or PC or any other applications have traditionally worked. Mac applications by default have access to everything on your machine and the internet. The only restrictions are based on the file system permissions, so you can’t look at or change the files of another user unless you are a system administrator.

In principle, sandboxing does increase security and that is a good thing.

Unfortunately in practice, Apple have made a dog’s breakfast of both the technical implementation and the policies around the sandboxing.

While it is possible to define “entitlements” to cover almost every aspect of what an application could possibly want to do, Apple have not allowed third party developers access to these entitlements. For many things there are no “third party accessible” entitlements and for many other things, Apple is unlikely to grant those entitlements anyway. The mechanisms that are available do not allow for all existing features of existing applications to be preserved when that application is sandboxed.

I have spent considerable time adopting the Lion sandbox for the Mac App Store versions of my products, as I want to continue to update them in order to bring you the latest (and hopefully greatest) features.

Vitamin-R is the first of these sandboxed versions that I have submitted and now after two rejections it seems that it will finally be accepted.

In order to comply with the Sandboxing rules and Apple’s rejection of my request for several entitlements, the following features had to be removed:

  • Support for the Neurosky Mindwave headset was removed
  • The ability to quit applications in the “eliminate distractions” screen was removed.
  • The ability to automatically close Finder windows in the “eliminate distractions” screen was removed
  • Growl support was removed

Other changes include:

  • If you use the Dropbox integration on Mac OS X 10.7.0, 10.7.1 and 10.7.2, you will be prompted to locate your dropbox folder every time you launch the application. (Upgrading to the latest Mac OS X Lion version will fix this).
  • The download now includes the Noise Machine soundscapes files and is therefore much larger
  • Many other minor and hopefully invisible changes

I understand that many of you will be upset to lose these features and all I can say is that “it wasn’t my idea”.

When I mentioned that these features had to be removed because of the sandbox requirement in the “What’s new” section of the Vitamin-R Mac App Store page, my “meta-data” was promptly rejected and I was asked to remove any mention of Apple policies.

In other words, I’m not allowed to use Apple’s Mac App Store to inform Mac App Store customers of what is going on, because that would make Apple look bad. Apple prefers its customers to be mad at me for complying with their rules rather than to put up their hand and say “it was us and we’re not sorry because we think we are right”.

Well, I’m gutted about the whole thing.

If accepted in its current form, Vitamin-R will have survived its migration to the sandbox relatively intact. Many of the features that had to be cut were minor and won’t be missed too much by most users.

In any event, if you have bought Vitamin-R on the Mac App Store and you are missing a feature you need, please just contact us at support@publicspace.net and we’ll issue you with an unlock code for the “full” version.

Please don’t vent on the Mac App Store because this penalizes developers for something that they have absolutely no choice about. It also does not allow developers to respond to criticism as they cannot post replies and do not have any idea of who you are and how to contact you to resolve the problem.

Unfortunately, the new Mac App Store sandbox requirement means that henceforward there will be two versions of most Mac applications: a sandboxed one that misses features and a full one that is only available directly from the developer. You can basically choose between greater convenience and greater freedom. Usually it is convenience that wins out.

Vitamin-R & the Mac App Store Sandbox

It is finally happening. Apple have made good on their promise/ threat of requiring all applications on the Mac App Store to adopt the Lion Sandbox technology by June 1st.

You may already have heard many Mac developers moan about this, while others are trying to see the bright side or are at least putting on a brave face. It’s all true and it’s all a lie.

First off, sandboxing does improve security. The idea is that every application that is launched by the operating system works in its own “sandbox”. It can do anything it wants within its sandbox, but when it tries to interact with the rest of your system by accessing files, connecting to the internet, talk to other applications, etc.. it is restricted by its “entitlements”. All this so that even if your application is infected by a virus or is deliberately “naughty” (aka malware), it can only do so much damage.

The kinds of entitlements that exist are defined by Apple and while it is the developers who decide which entitlements they believe their application needs, it is Apple that grants or rejects each entitlement.

The basic equation is this: the less your application is allowed to do, the less damage it can do. So if Apple is serious about the security aspect of the sandbox, it will grant what it deems to be the minimal entitlements required by the application.

Even though it means more work for developers, the sandbox in itself is not a bad idea. Security is good, right?

The rub lies in the fact that unlike iPad and iPhone applications which effectively take over your whole device, most Mac applications live in an eco-system together with other applications. They share files, they interact with other applications and the system to deliver an integrated user experience.

The sandbox gets into the way of all this. Sandboxed applications can only access files on your disk after you have opened them in the “Open…” or “Save…” dialog. They can only interact with other application via AppleScript if they have a specific entitlement for that specific application and that means that Apple has to grant that specific entitlement during the review process. Worse yet, there are no entitlements for a whole range of things that a powerful app could potentially want to do.

For many applications, this will mean that existing application features that have existed for a long time will need to be removed in order to comply with Sandboxing rules.

I have finished sandboxing Vitamin-R and I have managed to keep most of its features alive and well.

Some features, however, did not make the cut. So I have removed the following features from the Mac App Store version of Vitamin-R:

  • the ability to quit other applications from the “Eliminate Distractions” screen
  • the integration with NeuroSky’s MindWave brain computer interface

(There are entitlements for either of these things).

Other features require “temporary entitlements” that Apple may or may not grant.

The features “at risk” are:

  • Things integration
  • Things beta integration (new if accepted)
  • OmniFocus integration
  • Growl integration
  • The Hit List Integration

There is no rational reason for doubting that Apple will grant these entitlements, but the MAS review process is notoriously capricious. The term “temporary” also does not fill one with great confidence, so these features may well disappear somewhere down the line even if accepted now.

I will be submitting Vitamin-R 1.81 to the Mac App Store as soon as version 1.80 is released next week and if everything goes smoothly and Apple isn’t backlogged, it should be available within a fortnight.

On a personal note: I do not want to remove a single feature from any of my applications. Apple is forcing my hand and I’m doing what I can to preserve functionality. The versions of my software distributed via my own website will remain outside of the sandbox and thus unaffected.

I’m also looking into ways of allowing users who have purchased via the Mac App Store to download and use the “full” version of Vitamin-R from my website for free. This is made more difficult by the fact that Apple does not share customer data with third party developers and I thus have no idea of who buys my software on the Mac App Store.

I hope to have a simple solution ready sometime in June, but this again depends on whether the Mac App Store review team accept the solution.

If you are upset about losing features, the best idea is to let Apple know about it. We developers have already done all we can. There’s a “Support” link in the “Quick Links” section of the Mac App Store front page and of course there are Apple Stores all over the world.

Vitamin-R receives 4.5 out of 5 mice review from MacWorld

It’s always nice for an indie developer to get a good review, but doubly so if it’s MacWorld:

http://www.macworld.com/reviews/product/573630/review/vitaminr_118.html?expand=true

I like the conclusion:

“Overall I found Vitamin-R to be one of the few get-thing-done applications that actually works for me—in my book, that’s a huge task accomplished.”

so much that I had to plaster it over all the product pages 🙂

twitter..

I’ll admit it, I’m not a great Twitter fan. Perhaps at 30 something, I’m already well past it.

I find myself agreeing at least partially with notorious software pundit, Joel Spolsky who announces his retirement from blogging with this little tidbit:

l appreciate that many people find Twitter to be valuable, I find it a truly awful way to exchange thoughts and ideas. It creates a mentally stunted world in which the most complicated thought you can think is one sentence long. It’s a cacophony of people shouting their thoughts into the abyss without listening to what anyone else is saying. Logging on gives you a page full of little hand grenades: impossible-to-understand, context-free sentences that take five minutes of research to unravel and which then turn out to be stupid, irrelevant, or pertaining to the television series Battlestar Galactica. I would write an essay describing why Twitter gives me a headache and makes me fear for the future of humanity, but it doesn’t deserve more than 140 characters of explanation, and I’ve already spent 820. [Joel on Software Blog]

Nonetheless, despite the fact that I have never advertised the existence of a twitter feed in my name (you’ve got to see what all the fuss is about after all), I do seem to have acquired a very small following anyway, so I feel honour bound to make an effort.

So henceforward, at least until I completely forget about it again, here’s a link to my official twitter feed.

Tutorial: Using A Better Finder Rename to import image files from your camera with Snow Leopard

Photographers, both professionals and ambitious amateurs make up a large fraction of A Better Finder Rename users.

All-in-one photo management and manipulation software like iPhoto assumes that file names are of little consequence and you’ll want to organize your images according to a project structure or meta data. This is fine as long as you never leave the photo management software, but of course you do so for all kinds of reasons: export the files to send to a third party, manipulate your files in a third party application, publish them to a non .Mac gallery, etc., etc.

In all these situations, you’d rather give your image files more meaningful names than IMG_66387.jpg. But how can you do this when all the files are managed by iPhoto software?

There are essentially two solutions: You can give your files meaningful names before importing them into your photo management software or after exporting them out of your photo management software.

Don’t ever try to rename files within the photo management software’s folder hierarchy! Applications, such as iPhoto, keep a lot of information outside of the actual image files and if you rename these files without the program knowing anything about it, you will lose valuable meta-data such as your albums, galleries, etc..

Using A Better Finder Rename to rename your image files after exporting them is trivial: simply drag & drop the files into A Better Finder Rename and let it do its magic.

Renaming the files before you import them is a little trickier.

Many Mac users do not know that you don’t need to import your pictures directly into iPhoto. For the true professionals, Mac OS X offers a specialized application that does nothing but import images from your camera (and other image devices): Image Capture.

Image Capture lives in your “Applications” folder. Simply double click to launch it:

Now it’s time to connect your camera and switch it on. iPhoto will probably launch and ask you whether you want to import your pictures. Politely tell it that you don’t need it and quit it for now.

The Image Capture window will now show your camera.

(You may have to click the Devices triangle to see your camera):

You can do pretty much everything in Image Capture that you could do in iPhoto as far as importing your images is concerned. “Import All” will simply get all the pictures off your camera, while “Import” will let you choose from the thumbnails which ones you want to import. Note that you can also choose which folder you want to import your pictures to, but be sure to sure to stretch your Image Capture window so you can see the “Import To:” drop down list.:

Once the photos are imported to the folder of your choice, you can use A Better Finder Rename to rename them and then import them using iPhoto’s import feature:

Voila.

But that’s still 3 steps and a little too complicated for you?

The next step requires A Better Finder Rename version 8.31 or better, released October 1, 2009. Remember the “Import To:” drop down list? Not only does it allow you to select the folder Image Capture should import images to, but it also allow you to select a program that should be run just after files have finished importing:

For now let’s simply choose the “A Better Finder Rename” application as the automatic task by:

  • selecting the “Other…” item in the “Import To:” drop down list
  • navigating to the “A Better Finder Rename” application in the “Applications” folder.

Pressing the “Import All” button will now first download all the images from your camera into your Pictures folder and then start up A Better Finder Rename:

You can now use the full power of the tool to give your pictures more meaningful file names.

You can, however, still go one step further.

It is for instance often convenient to encode the shooting time and date in the file name; that way you always know at a glance when the original picture was taken. If you use this type of naming convention you can take advantage of A Better Finder Rename’s droplet feature.

Droplets are small, independent, applications that automate common tasks. You save a rename action and the correct parameters into such a droplet application and every time you drag some files on the droplet the files are automatically renamed according to these settings.

Instead of defining A Better Finder Rename as the “automatic task”, we can use a droplet that we have prepared earlier. In this case, I have encoded our naming convention into a droplet called “Image Capture Automation” and defined it as the automatic task in Image Capture:

Now as soon as I push the “Import All” button, the pictures are imported to the hard disk and once this is finished they are automatically renamed with our naming convention.

One final note. You may have noticed that Image Capture in Snow Leopard does not allow you to specify what folder you would like your images downloaded to when you select a program to run afterwards. Instead, images are always downloaded to your Pictures folder before a program, such as A Better Finder Rename is run. If you’d like to be able to specify what folder your images are sent to before running A Better Finder Rename, take a look at this post. We’ve prepared an Automator action for Image Capture that does this.