CodePromo Distribution Options
By 
CodePromo, my app that makes it easy to generate & share promo codes, interfaces with iTunes Connect. Consequently it can’t be distributed in the App Store. I’m fine with that and knew it when I started. I’m writing this post to air the alternatives.
My original plan was to distribute the application as a binary:
I’d build the application locally, distribute a zip, and then developers could re-sign the app and install it on their development phones.
The binary based approach seem better than the other reasonable alternative, distributing source, for fairly obvious reasons.
I’m having second thoughts about distributing a binary. Building a binary means using my dev cert, linking to the SDKs, etc. I worry that’ll cause me grief from Apple.
That leaves distributing source. This is not an untried approach. Oliver Drobnik uses this approach for his on-the-phone app sales tracking app My App Sales.
(Interestingly, Oliver’s competitor on the desktop, AppViz, uses the same mechanism to collect the data and was featured by Apple and listed in their software directory.)
I’m not opposed to selling a license to the source, but worry that even this will cause me grief from Apple. Oliver says he hasn’t been hassled by Apple. In an email to me, Oliver reasoned that:
Apple cannot and will not tell you what you can or cannot do with your compiler and your iPhone. And source code is a form of free speech that Apple cannot do anything against…
Does Apple disagree?
I would not spend too much time on this if I was you unless you are doing this for your own peruse. I doubt that many people would pay for such an app and you will need to do all the maintenance of who has paid and who has not so that people will not get upset when you launch a new version of the app. The app store usually take care of all that for you and I am happy to pay 30% to not have to keep track of that.
Timos is missing the point and that is, as you know, you cannot distribute through the app store…so I would say go for it…if Apple are unhappy with tools such as MyAppSales, AppViz and ultimately your app, they will change the way access is handled to iTunes Connect.
Either way I would go the source route. Maybe get purchasers to agree that they will only use the source to generate and issue the app and not to develop a competitive product!
You might consider a hybrid approach where the bulk of the app is pre-built by you as a static library, and then you just distribute an xcode project with the static lib and some sort of wrapper source file (just the main.m for example). This way developers still have to build the final app binary, but you’re distributing a bulk of the app as a compiled library instead of source.
This assumes that one of the reasons against distributing as pure source is that you want to keep the source private. If that’s not the case, then there is little advantage to my suggestion.
Adam: I agree that that’s an option. I’d previously written about that, calling them Build And Go apps. I’m looking for the right mix of ease for the developers and not raising Apple’s ire.
I think I’d agree with Adam. I didn’t find it too hard to get the Three20 demo app to build and run in the Simulator, even though I eventually decided against using the framework, and if I remember right it’s basically a static lib for the whole framework. The demo’s just a bit of source on top. Granted 99% of your app would be in the static lib, but only developers who’ve paid their fee to Apple would be able to put it on a device. Which is exactly your audience, and it shouldn’t be too difficult for anyone to do who has an app in the AppStore. But I guess you have to balance that against the cost to you to support your customers that DO run into problems building. Not an easy call. As a developer, though, the static lib approach seems workable.
It seems hard to imagine that Apple would want to regulate the static lib market. I’m guessing there’s gotta be people wanting to sell libraries to developers for _embedded_ use in an app. At that point it seems difficult to draw a clear line about how much of an app is in the static lib versus in local source. I have no hints about what Apple would do, though.
Check out Sales Report (https://itunes.apple.com/us/app/sales-report/id300011444?mt=8) by Marigo Holdings LLC.
It’s already approved in the app store and clearly uses iTunes connect functionality (it says as much in its description)!
You may be surprised that Apple will approve of yours. The worst that could happen is that they reject it, and then you can explore these other distibution methods.
Michael: very interesting! I’ve written them for details as to how they pulled that off.
I don’t remember seeing anything in the terms and conditions of the SDK that specifically precludes iTunes Connect functionality in a native app. The data is “freely” available (to paid developers) and is published (in a format that can be readily ingested) specifically for your benefit.
As long as you meet the other terms I would expect it to be approved rather quickly.
On the other side of the discussion, I was discussing this with my partners in your tiny app development company and we all wanted source so that we could modify it. In our case we record who we give promo codes to and on what date, and sometimes add a note (primarily to track our marketing efforts, see who actually turns in their codes, etc.). With source obviously we could make it our own. If you go the static library route, hopefully there will be plenty of hooks into it so we could do that, and whatever else other developers wanted to do to customize it for their needs.
so where’s the problem with source distributing it? are you afraid that everyone could see how bad your code is?
Wow, I think I was asleep when I posted. “our tiny app development,” obviously, and other issues. Anyway, just putting in a vote for source or lots of good hooks to a library.
One issue with distributing it through the app store… Apple is sure to occasionally modify the interface for generating promo codes, and when it does, you’ll have an indeterminate turnaround time for getting a fix out on the app store. CodePromo could be “broken” for days or weeks while waiting for the update to get approved.
Having used apps like AppSalesMobile and AppViz, which are distributed directly to the user, I have found that when Apple changes something, fixes are available right away, which is really comforting.
Just something to think about.
Make it a web app – no AppStore to deal with.
@Joe: Check out the original post he made about this:
“You can’t generate promo codes from Mobile Safari.”
https://www.mobileorchard.com/codepromo-generatesend-promo-codes-from-your-iphone-beta-testers-wanted/
@Charles: Joe is not saying access the iTunes Connect service directly, he’s saying that Dan could create a web app that connects to the iTunes Connect service on your behalf.
@Adam: I’ve been thinking about that, I wonder if it would be possible (i.e. Would Apple approve it) to implement the “native app” as an enhanced UIWebView, and pull down JavaScript from a server each time. Then you could have the best of both worlds, “native app” and “web app”.