Hacker News Reader

Comment by ianamartin | Hacker News Reader

I'm not sure how this holds up to the promise of "Sell outside the app store and pocket that extra 30%."

If you're selling iOS apps, you have no choice but the app store. You could try giving the app away for free on the iOS App Store and shunting people to a website to purchase the license after a certain amount of time, but I'm certain that breaks Apple's rules. Same goes for the Mac App Store.

You'd get shut down pretty quickly if you ever managed to squeak through the approval process.

Based on the code examples provided on the website, I don't see any of the most popular languages use for apps that go in an "app store" of any kind (Obj-C, Swift, Java)

I'm sure intent is not to be misleading, but I don't see how this can recoup a 30% app store take. Could you explain that in more detail, since you are replying in this thread?

View on HN

The FAQs address this, but just to be clear: Keygen unfortunately (as you said) doesn't work for mobile apps stores, due to Apple's (and Google's) developer terms. When referring to the App Store, I mean the macOS App Store i.e. for desktop apps. I'm advocating selling desktop apps independently outside of the App Store, which you can most assuredly do. :)

Regarding the missing languages e.g. Obj-C, Swift and Java--that's simply due to me not having put in the effort to write examples in those languages (I'm not fluent in any of those).

Thank you for the response.

I would politely suggest that you rethink the wording on this? I see now that it's addressed in the FAQ, but you're hitting it up front as a top marketing item. Perhaps specify macOS App Store, so that people don't get confused.

I can't understand how you can talk about this product as being any app store alternative if you can't provide examples in the languages that people use to write apps that go in stores.

No one is writing macOS apps in Python or C#. Well, a few people are, but not people who are charging.

I'm not trying to be a pedant, and I think this is interesting. I just can't wrap my head around what you're trying to do or who you're doing it for.

It hasn't been an issue thus far, but I'll see if I can make that clearer. I'm not implying that developers are writing macOS apps in Python or C#, but they are writing Windows apps in C#, and they're writing cross-platform desktop apps in JS, as well as licensing servers and on-premise software (and that includes a lot--WordPress plugins, software like Sidekiq, etc.) in all of those languages. Keygen can either be integrated directly into a product e.g. macOS/Windows app, or it can be integrated into a server to transparently handle licensing (nobody can infer that you're using Keygen in this case using something like Little Snitch). Like I said before, there's a simple reason Swift and Obj-C aren't up there: I don't know them very well; I'm in the process of learning Swift, so that will change soon though.

To be fair, this is exactly how I use Netflix. I have a free app that I pay to use completely outside the app store. Not sure of the actual rules, but it's definitely possible.

It's fine to have out of band payments for subscription services on the App Store, so long as it's possible to subscribe to the service through an in app purchase and you don't advertise paying outside the app within the app.

Apple takes these matters pretty seriously, it is their bottom line after all. I once had an app get rejected by App Review because it was possible to buy a subscription from the WebView that opened the Forgot Password page.

It's not Apple's bottom line. Not in any way.

But they will shut down any out-of-band payment options. There is nothing even remotely fine about this.

Correct. In my experience in talking with Apple/Google, that is most definitely not a good idea and could get your developer license revoked. Maybe someday they'll open up the walled garden (lmao ok), but for now devs should stick to only selling desktop apps independently.

Reply on news.ycombinator.com