A few things to consider (I went thru the exact same path):
- Android: toll to get approved on the Android market is significantly less. You can release the apk unsigned, they'll install.
- Use webkit to wrap your app inside some dummy binaries. Apple approves your app then you keep updating your app leaving on AWS or Google App Engine your pick
- Don't go full blown. Release a lite app with minimum features, then add more as you go. Apple tech reviewers are humans. You need to familiarize them with your app, then you can crank up the features.
- Blog about it and get the community to be supportive and all jazzed up on how evil Apple is (IMHO: you did that too late)
- Release some libraries open source. I am not sure why you released the whole thing, because I don't think it will help you much beside maybe the buzz factor (which you would have gotten by writing to techcrunch, hacker news, slashdot and theregister.
- Finally, never give up, never surrender. It's a tough world out there and if it was easy, everyone would be able to do it.
- Blog about it and get the community to be supportive and all jazzed up on how evil Apple is (IMHO: you did that too late)
Before you do this, make sure that:
1) You've got a valid complaint. I've seen too many developers complain about something being rejected when everyone who looks at the rules will instantly see that they're in violation (if you think it's a dumb rule doesn't matter, Apple made it up and Apple decides both if you're in violation and the consequenses of the violation)
2) Be aware that you're most likely burning bridges at Apple and killing any goodwill you might have with them. Calling them an evil empire just isn't the kind of thing that's likely to bring them over to your side.
I think that the OP has carefully avoided calling Apple names and such, and instead focused on the basic facts: he's spent a lot of time and effort to make the app (which has been received well by people at Apple), but there's a limit to what resources a small company can spend while waiting for a response. You'll also note that he's making sure to point out that he'd like to get back to work on it as soon as possible.
I wonder how many indie developers make a choice to not develop significant iOS-based products (such as this one) and instead build "unit converters" and "fart apps" since those make it into the store with no problem.
The abundance of such trivial apps is more than adequately explained by (1) their trivialness to implement, and (2) their established reputation for actually making money.
I'm sure there are exceptions, but I don't believe the kind of people who want to make significant, high-quality apps like the one Rob made are the kind of people who would so easily stoop to making a fart app.
Not only do they make it into the store without problem, the initial investment, and thus risk in dollar terms, is significantly lower too. So I bet it does have a large effect.
I think that the kind of folks who are _capable_ of building significant iOS based apps simply choose not to, instead of simply producing fart apps.
I avoided the platform for as long as I could. During that time: the tools improved, hardware and APIs have improved greatly, provisioning hardware got a lot easier, and the review process shortened significantly.
So now, I'm dipping my toes in and embarking on a fairly significant app. However, because I'm a long-time Mac developer, much of my existing code and experience moves over without much fuss—perhaps the developers of "signifiant" apps just have a different kind of "fart app"?
Rob's situation is fairly unique, and unfortunate. The whole ordeal is a load of BS, and I hope things change for the better for him. Briefs is a great idea, and it was easily the coolest iOS product demo at C4[3].
I just have to wonder if had Rob
released a minimum viable product - without the polish and all the types of interactions and months of hard work
and submitted it to the App Store - would it have been rejected sooner.
With our apps, even though they are fairly standard, we know the biggest risk is rejection by Apple. We hedge that risk somewhat by submitting a MVP (setting the release date in the future so it won't go live accidentally if approved).
Barring the possibility of Apple ever laying down clear, comprehensive, stable and reliable guidelines for avoiding rejection (with many real, anonymized examples), it sounds like the MVP approach is the best way to go.
Rob's case is special, though, because his app was never actually rejected. I suppose if he'd been willing to submit a MVP and wait the same amount of time in limbo before putting any more effort into it, he could have saved himself all that hard work. But the aggravation of not getting an answer would have still sucked.
The quiet issue that most people don't hear about are not initial submissions, but updates that get stuck in the same review limbo for months and months. My app has been on the store for nearly two years, had many incremental updates, and my iPad compatibility update (not even a new app) has now been in review for 3 months. It's really hard to explain to your existing userbase why you cannot get an update released. Many of them aren't even aware that Apple can be the bottleneck for such a long time.
That's true. There really isn't a good way to communicate with your userbase. You're basically limited to updating the app description and hoping your existing users bother to click the "More" link to read it (assuming you didn't put the update at the top, because that's prime real estate for attracting new customers).
It really astounds me hearing about how long new apps and updates can get stuck in limbo, with no feedback from Apple or path to action. So far I've managed to avoid any nightmare scenarios, but every new anecdote I read makes me increasingly anxious that one day, that time will come.
To be fair, it is using interpreted code, which is clearly not allowed. He chose to build something that clearly goes against the terms and then he's hoping for an executive-level exception to the rule because "it's so cool". But if they give him an exception, everyone else will be pointing to how the approval process is inconsistent when they reject someone else's with some form of interpreted code.
So the question of Apple being at fault for not having "clear, comprehensive guidelines" can't really be raised.( In this particular case.)
I thought he made it pretty clear that he made some effort to get his software approved by exception through talking to execs, etc. So obviously that explains the "limbo". Presumably, he recognized it would just get rejected through the ordinary channels.
And with respect to the other thing, your bringing that up kinda proves what I said, doesn't it? :P
Is anyone else concerned Apple will release a touch-screen iMac, and all future "touch" software will need to go through the iTunes store? If touch software ends up being more popular I see all development needing to go through the Apple development screening. I'm beginning to feel that if they could screen websites they'd do that too, oh wait. They do that too by limiting Flash.
As we know, this is a good reason to be on Team HTML 5 (with all it's tradeoffs). I admire Rob's incredible amount of patience though and hope it pays off.
Even with the risk of arbitrary rejection, it seems like the odds of payoff from your hard work are better with an iPhone app than a website written in any HTML dialect.
The biggest problem with deploying an HTML webapp to iPhone users is that they aren't trained to accept them. Users are forced to learn to use the App Store, but virtually none of them know how to make a bookmark on the home screens and even fewer know that this can then enable a website to become an application. (For those not washed in the gory details, full screen is not available until the user relaunches from a home screen icon.)
All together, you will need to have a motivated and technically adept audience for your webapp to succeed.
> No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and builtin interpreter(s)...An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise.
> Briefs are eventually compiled into binary .plist files for delivery to the iPhone. But authoring uses a simple language called bs. BS is a simple language written specifically for creating briefs. Its syntax is very similar to CSS (helpful for those experienced web designers).
This makes me wonder if the real reason there is not Balsamiq for iPad is because of the threat of rejection for "running" and "editing" Balsamiq markup models. I understand that Balsamiq is an Adobe AIR/Flash product, and it would have required a major port to CoreGraphics/Cocoa (since the CS5 compiler was banned because it leveled the mobile platform playing field by allowing near write-once, run any device).
From an entrepreneur's perspective, devoting one's business solely into the app store isn't a wise move. Since Apple has the veto power over the app distribution channel the risk of wasting hundreds of hours but not getting to the market is too high.
What one should do is to develop software that runs multiple platforms, and if it becomes popular I doubt Apple would want to lose out in the fanfare.
Imaging Apple disapproving Dropbox? not quite possible, because people love it on other platforms, and if Apple doesn't support it on iPhone people will go get a blackberry.
The video for the app isn't very informative. It explains the problem, but does little to show how this app is useful and how it solves the problem presented for over 2/3's of the video.
Maybe consider Jailbreak - there's a paid jailbreak-apps store called Rock, which I heard is legally legal (don't quote me on this). Although I suspect people who jailbreak their phones may not be the target market for something like Briefs
My full respect for releasing it as open source, even after the big disappointment of being not approved. I can sense the hard work, that has been put into this. Thanks.
Looks like a really cool app. I guess open sourcing it will allow iPhone developers to run it?
I guess Apple really wanted to reject the App, but didn't want the backlash so is just letting it rot. Sorta like those companies that you interview with that never send a 'no' back and make you go mad with being in limbo. There are reports about some apps being pending review for 200 days.
I guess he's hoping for approval or he might have released it on Cydia.
- Android: toll to get approved on the Android market is significantly less. You can release the apk unsigned, they'll install.
- Use webkit to wrap your app inside some dummy binaries. Apple approves your app then you keep updating your app leaving on AWS or Google App Engine your pick
- Don't go full blown. Release a lite app with minimum features, then add more as you go. Apple tech reviewers are humans. You need to familiarize them with your app, then you can crank up the features.
- Blog about it and get the community to be supportive and all jazzed up on how evil Apple is (IMHO: you did that too late)
- Release some libraries open source. I am not sure why you released the whole thing, because I don't think it will help you much beside maybe the buzz factor (which you would have gotten by writing to techcrunch, hacker news, slashdot and theregister.
- Finally, never give up, never surrender. It's a tough world out there and if it was easy, everyone would be able to do it.
Good luck!