What I Learned During my Mac App Store Review

Two things happened on Thursday that made it obvious to me what I should write about this week. Mountain Lion was announced, and my first Mac App was approved for the Mac App Store.

Even though iDevBlogADay is about iOS programming, more and more of us are moving from iOS to the Mac. With the announcement that GameCenter will be coming to OS X, I'm guessing that more iOS developers might be thinking about coding for the Mac now than might have been last week.

So today I'm going to talk about my experience in getting my first App on the Mac App Store and specifically the differences in the approval process between the Mac App Store and the iOS App Store.

I wasn't nearly as prepared as I thought

I first submitted my Mac App on October 17th, so it took me a day short of 4 months to get my App approved. That's at least 3 times longer than I ever took to get any of my iOS apps approved. Partly because the MAS requirements are different, and part because I wasn't paying enough attention. I learned a lot in the process, and I thought I would try to help other people avoid (at least some of) the mistakes I made. Hopefully this will help you avoid wasting both your time and the review team's time.

Note: I'm only going to focus on the general interest stuff in this post. Since I wrote a developer tool whose primary purpose is to make things happen on a remote iOS device, it doesn't fit into the expected behavior of a "normal" OS X App. So I'm going to ignore the issues I had that are specific to the type of App I wrote.

You can't require 3rd-party Apps to be installed

My App uses Dropbox and Boxcar to "push" an iOS App build to all my test devices wirelessly. And my first rejection was because my app required third party products to be installed. That was a surprise to me, because I have used several iOS apps that require 3rd party services (how many iOS Apps have you seen that do nothing until you log in with Facebook Connect? - I've seen several).

So this required me to sit back and do a redesign (or sorts). Since I had built the entire App intending to rely on those services, I didn't know what to do. So I added a new preference so that, instead of Dropbox and push notifications, you could use local Web Sharing and send an email to your device with the link to click to install your test App. It's not nearly as useful as the Dropbox/Boxcar method, and I feel there should be a different solution, but I haven't thought of a better way that could work inside the sandbox restrictions.

But the main thing is, my App is functional (even if in limited way) if you don't have Dropbox and Boxcar, so it got me past that hurdle. (Personal aside: I use both Dropbox and Boxcar on an almost daily basis and if you don't, and you have both a Mac and either an iPhone or iPad, I think you're missing out on two of the most useful tools available to you).

The first rule of Sandbox is you don't talk about Sandbox

Another rejection was because I had a description that said something like "To comply with Sandbox restrictions, if you use Dropbox, it must be installed in $HOME/Dropbox". It seemed a reasonable thing to me at the time. In order to write to the Dropbox folder (with sandboxing enabled), I have to put the Dropbox folder path in the temporary exceptions part of my entitlements file. I understand why Apple doesn't want us doing that - it means that, if they change their policy, then our descriptions would become inaccurate. Also, most users don't understand such things, but hopefully all of mine do, since all this App's users are iOS developers.

I had read the review guidelines, but I would not have thought this wouldn't be okay. The rule that this violates is: "3.3 Apps with descriptions not relevant to the application content and functionality will be rejected". So keep in mind that talking about internal Apple procedures might be considered "not relevant" and earn you a rejection.

Test on Macs with different configurations

I was also rejected because my App crashed if run on a Mac that didn't have Xcode installed. The reason for that is beyond the scope of this post (and wouldn't be relevant for most Apps), but it had never occurred to me to try to test my code on a machine without Xcode installed (all my Macs have Xcode - why wouldn't they - it's what I do all day). I uninstalled Xcode from one of my machines, and sure enough, I got the crash.

It was easy enough to fix the crash, but the important thing I learned was: I needed to have tested on configurations that were more generic than what I normally use.

They are serious about keeping the user informed

I was rejected for not including a progress bar.

Well, not explicitly - but there was a point while using my App when there was a pause, and no feedback was being provided to the user. Stuff was happening in the background, and I wasn't blocking the UI thread or anything, but I wasn't telling the user what the App was doing. It didn't seem (to me at least) that it lasted that long, but they rejected it.

So I put a progress bar on it and, you know what, it greatly improved the user experience. I'm really glad I got rejected for that, because I like it much better now.

They are serious about User Experience

I also got rejected because I didn't specify a minimum window size. Or at least, adding a minimum window size fixed the problem.

The rejection said that the user could resize the window so small that the app could no longer be used. They were correct - that window exists to be a drag-and-drop target, and if you make the window small enough, then you can't drop your .app bundle onto it anymore. My initial reaction was "well, the user shouldn't do that and still expect it to work". But I was wrong.

The bottom line is that I hadn't even considered what I wanted the App to do if the user resized the window - windows don't get resized on mobile devices, so it hadn't entered my thought process. After that rejection, I thought about what I wanted the App to do when a resize happened. And it's a much better App for having thought that through.

So, in conclusion: It's as much about design as code

I would say that, more than anything else, I learned that the difference between the User Experience on OS X and iOS is at least as great, if not greater, than the difference between writing code for OS X and iOS. When I was reading books and teaching myself about programming for the Mac, I tended to focus on the framework changes (e.g. NSView vs. UIView) and the new elements (NSMenu, NSDraggingDestination, NSTask, etc) and I mostly skimmed the design parts. That was a mistake.

Over the months, I got very frustrated with the review process. There were times I thought that I was never going to get the App approved. But even though people kept telling me that I should just withdraw it and sell it outside the App Store, I'm glad I didn't give up. It's a much better App than it would have been if I hadn't done what it took to get it approved for the store.

WARNING: Blatant Self Promotion Ahead

Don't say I didn't warn you.

If you've read this far, and are an iOS developer, you might be interested in my new App, AppDropOTA. Which you can get for about the cost of the proverbial cup of Starbucks coffee here (App Store link).

After installing it, you configure it with your Boxcar email address and copy and paste a Dropbox Public folder URL into the Preferences panel. (Also, if you don't have it, you should go install the Boxcar App and log in to it with your email address).

Now use Xcode to build an iOS App for the device, grab the .app bundle and drop it onto the AppDropOTA window. Your .app bundle will be turned into an .ipa file and placed into your Dropbox Public folder so it's accessible via HTTP. Then you'll get a push notification on the Boxcar app on your device(s). Launch Boxcar (via Notification Center is the quickest way), open the notification, and tap the "View Original" link on the item detail screen. You'll get an alert pop-up prompting you to install your App. Click "Install" and you're done.

When I'm testing, I do this several times a day. I have 9 iOS devices I test with: an iPad 2, an iPhone 4S and an iPhone 4 running 5.0, an iPod Touch running 5.1 beta, an iPad 1, an iPhone 4 and an iPod touch running 4.3 and an iPhone 3G and a iPod Touch running 4.2. (Soon, I hope to convince my customers to drop 4.x support, but haven't, yet). I learned the hard way that I needed to test on different hardware when I shipped an App update for a customer that immediately crashed on all armv6 devices because of this Xcode bug. I wrote AppDropOTA to speed up the process of getting Apps on all my test devices.

Some people use TestFlight for this. For me, TestFlight is too public to use for every test build. I use TestFlight for builds I'm sharing with my customers, but I never push something to TestFlight until I've run it on my own device first. AppDropOTA is what I use for that (and it's faster that TestFlight, too).

Hey, iOS Devs, Nice AppStore. Would be a shame if something were to happen to it…

So, breaking iOS AppStore news this afternoon: Path uploads your entire iPhone address book to its servers.

This sucks, and I'm pissed off, but not because my data is so precious, but because I'm scared of where this could end up.

Many of us in the iOS development community make our living off writing mobile apps.  Even more developers dream of one day being able to write apps as a profession.  One (probably overstated) estimate out this week says half a million jobs have been created. For those of us that can write code (or are wanting to learn).  Even if that number is inflated, this is still a great thing.

I just got back from the 360MacDev conference in Denver (a spin-off of the 360iDev conference I've attended and loved the last two years).  It was fantastic, and I had a great time.  There's a great community of developers out there who are not just willing but genuinely happy to share what they know with anyone who will listen (although there is the occasional exception).

There's exactly one reason why this is possible - because the ecosystem is still growing, and there are plenty of people who want to pay to get an App written, which is, of course, because Apps are generating a lot of money.

But all is not well.  As the app stores grow more crowded, people are cheating to try to stand out, and worse, users are discovering that their iPhones are tracking them everywhere they go, their Android Phones are logging all their keystrokes, malware has invaded the Android market and even the iPhone isn't safe from malware.

And when the size of the market starts shrinking, then everyone starts to panic, and before long people don't want to hire you and then the knives come out.

There is one thing that we, as a development community, cannot afford - and that is for the people that download and use our software to be scared of that software.  Because then the need for apps starts to dry up, and the need for mobile programmers will start to drop.

Some of us are old enough that we remember trying to sell shareware on the PC back when viruses were rampant.  It was a tough sell.  And some of us remember how hard it was to sell mobile software (for PalmOS or Windows Mobile) in the pre-AppStore world.  Back then, it was a real undertaking just convincing a user that downloading any third-party program was worth their time.  We don't want to go back to that.

This is the golden age of the indie developer (or at least the most golden age so far).  When else in history could  a single person make half a million dollars in a month, or  make a world-wide hit while commuting or  could 3 people beat a company with almost 1000x more employees?  It's certainly not something I expected a "geek" to be able to do while I was growing up.

And for that to continue, we need our users to trust us, and the easiest and best way to do that is to be worthy of their trust.  There will alway be rogue actors and  assholes that try to scam users.  But those apps are short-lived (although not short enough), poorly reviewed, and there's very little we can do about individual fraudsters, or users who don't pay attention to which developer an app came from.

But when a respectable, well-written App like Path can't be trusted, then we all have a problem.  The app is beautiful, obviously professionally designed and written, and well reviewed.  It didn't need to be slimy to be successful.

And what we, as professional mobile app developers, of whatever flavor, need to take to heart, in my opinion, is this: Don' t Be Scary.

If the professional, successful App Designers and Programmers agree to put what's best for the ecosystem first, then companies will stop risking all of our long-term success, for a short-term advantage.

Yes, it's less work to store your users' pictures unencrypted and unprotected on a server or store plain-text passwords in your app, and if you want your app to be more popular, it's tempting to harvest your users' contact info, or jack up your App ranking,  but, even if you have a legitimate non-spammy reason for uploading your customers' info, just don't.  Please, please, please always err on the side of earning your users' trust.  Yes, it might be more work for your current app, but remember, your current users are the potential users for all our apps, and whatever app you're working on next.

And yes, some of us will piss off some people who want us to make apps for them by refusing to scare our users, but there will be other people who want us to build apps.

We will hopefully all be writing apps for years… Unless our users stop being our users.

Don't forget that very few mobile apps are "necessary."  They're a luxury - and many (if not most) app purchases are quick impulse buys.  It probably won't take much fear on the part of an individual user before he or she decides that, even if the App is worth 99 cents, it isn't worth the risk that it might steal their data.

Then we all lose.

(Path Story link Via @mattgemmell.)

Mobile Apps - Boom or Bust? Sherman, please set the Wayback Machine for 1994, and then 1853

In the last few days, I've seen reports that Mobile Apps are repeating the 1996 expansion, and reports that Mobile Apps don't provide a viable business model. I think that  there are elements of truth in both articles, but I don't think either is an adequate depiction of what I'm seeing. Let me see if I can explain.

Like others, I feel like I've been here before, but for me the year wasn't 1996, but 1994. That year, I was a consultant in Dallas Texas, mostly hooking up Internet connectivity and web servers for companies that nothing to do with technology. At one point I literally couldn't introduce myself to people without having them say, "Did you say that you do websites? I've got to get a website for my business. Can you help me?"

Back in the present, I've recently gotten my third phone call in as many months from a person I've never heard of, saying "I heard from (a mutual friend) that you write iPhone apps. I've got to get an iPhone app for my business. Do you think you could help me?"

Now it's definitely true that most Apps don't generate enough revenue to make back their development costs. But that's okay. In 1994 (or 1996 or 2011 for that matter) most websites don't generate enough revenue to make back their costs. And I haven't seen any evidence that people are no longer building websites. Most companies these days see having a web presence as a necessary cost of doing business. And many are starting to look upon Mobile Apps with the same thoughts.

To me, the example for making a viable business out of Mobile App development is to think not of 1996 or even 1994, but California, 1853. Gold had been discovered and the Gold Rush was on. Prospecting for gold, like the App Store, was "not a viable business." Very few of the people that went prospecting ever made a lot of money, and many of them ended up in debt. You've likely never heard of any prospectors, but you've heard of at least one viable businesses from the period: Levi Strauss & Co.

Then, as now, the people looking to strike it rich will largely fail to do so, but now, as then, a viable business can be made from providing services to the prospectors.

People Seem to Prefer Videos and other things I learned from trying to advertise my iPhone app.

I have a couple of apps of my own in the AppStore. Most of the sales of the apps I have worked on have been the apps I did for other people, because, well, they are better than I am at marketing.

So, I've been trying to figure out how to do marketing with one of my apps, KidChart. It's been out several months and sales have trailed way off. I like it (my wife and I use it every day), but I haven't figured out how to market it. It has been getting about 3-4 sales a week the last couple of months. I talked to a marketing firm who does iPhone marketing, but they want $1000 per month for a 6 month campaign. And I just don't know if I can ever make that back. (I don't know how much of the problem is due to people not seeing it and how much is due to them not liking what they see).

So to try to figure out I signed up with a trial account from Performable, and I ran some facebook ads to see how the A/B testing worked. The experiment is going to continue through the weekend, but, in case anyone cares, here are my preliminary results:

Date	Spend	Ad Clicks	Additional Sales	CPA
Aug 23, 2010	$22.80	30	1	$22.80
Aug 24, 2010	$51.34	81	9	$5.70
Aug 25, 2010	$30.06	48	6	$5.01
Aug 26, 2010	$20	35	4	$5

Now the good news is, with a combination of tweaking multiple simultaneous ads on facebook and multiple landing pages on performable, I managed to reduce my Cost Per Acquisition by 78%. The bad news is that this is for a $1.99 app.

What has gone well so far:

1. I've learned a lot more than I used to know about ads and marketing (I'm new to all this stuff, and, although I've read about it, applying it has been new to me).

2. I've gotten some good feedback about the app. It's obviously designed for (and by) and pitched at a very analytical parent (which I am, but a lot of people aren't). I need to figure out what to do about that.

3. I've learned that the page with the video on it performs 114% better as a landing page than the page with more text and static images (12.5% conversion versus 5.8%). This is a bit of a surprise to me, because I expected a 2-minute video would be too long for people to sit through.

4. The folks at performable have been very responsive to my questions.

5. Running ads seems to be a good way to drive enough traffic at your website that you should be able to use it to improve your site and improve the app description you have in the App Store. This should result in better conversions when someone runs across your app.

6. I still have a lot to learn.

What hasn't gone well so far:

1. I also tried to run some ads on reddit.com, and that didn't go well at all. I got some very insulting comments right off the bat that may have turned off anyone who might have wanted to look at the app (I guess I should have turned comments off, but I was hoping I'd get useful feedback), and then reddit.com got into a controversy about a pro-marijuana ad that got censored by Conde Nast, the whole front page turned into a series of drug-legalization tirades, and no one seems to be looking at any of the ads any more (much less clicking on them). If this had happened on facebook, I would have just paused or stopped running the ad, but reddit doesn't allow you to do that (or doesn't make it easy to figure out how - I've sent them email, but haven't gotten a reply).

2. Performable is easy to set up, and, like I said above, their staff has been really responsive, but I don't know if I'll be staying with them. At least at the moment, I can't get the level of detail I want, so I'll might just end up setting up my own A/B test library on my own server. If you want quick and easy, though, and you don't care about trying to correlate time-of-day logs or anything nerdy like that, I think performable would be a great choice.

3. I'm pretty convinced at this point that it's never going to be possible to make your money back on advertising. I didn't really expect to be able to, but I'm pretty sure now.

4. I still have a lot to learn.