Monetizing AIR Applications

One major drawback I’ve thought about for a while with when it concerns AIR is that you can’t make sellable applications. After all anyone can pass around the SWF, or even decompile it making it dead easy to ‘crack’. With this is mind the only way I could see you being able to monetize an AIR application was through advertising.

AIRapps.net is working on a solution to this with their E-Commerce Framework for AIR. They have some presentations on Buying and Application and a Payment Widget worth taking look at.

On a side note how ridiculous is it that Adobe are forcing them to change their name because it has the word ‘AIR’ in the title and they believe it is

infringing upon the registered trademarks they have secured to protect their use of the name AIR.

Adobe should chill out!

17 Responses to “Monetizing AIR Applications”

  1. Adam says:

    Haha, AdobeAir-con, nice find :)

  2. Agree’d take a chill pill Adobe. they are trying to help the comunity.

    I am worried about any local attempt to lock or secure an AIR app as swfs can be de-compiled. Still no real way to secure it without involving a remote server, but I hold hopes that Adobe will address this in future version *wishes for c/c++ plugin architecture in AIR 2.0*

  3. It’s possible to decompile and crack any applications, and people do this in organised teams very soon after most major software releases. Plenty of applications were sold (and still are) that used Visual Basic for example. Applications made using VB were easily reverse engineered back into source code using freely available tools.

    Does the ability to decompile AIR apps makes them any more vunerable if precautions are taken to protect IP through encryption and obfuscation? What’s missing from pretty much all of the applications made so far is license management. This could be built into the AIR runtime, or provided seperately.

    Some protection schemes are very basic and can be immediately applied to AIR apps. Zinc for example, commercial (C++ based) software from MDM for wrapping Flash SWFs up, does an online serial check when you start it up. If the server detects you have used the serial on another computer it locks the current copy. If you were to disable the internet connection it would not perform the check and continue to function with (not condoning this!). So some forms are easily circumvented, but I think it’s simply a matter of the types of app being distributed so far being very open, as opposed to you not being able to make saleable applications without ads.

    So really there’s no magic bullet. It’s all about how hard you can make it to steal your app. That’s how it’s always been for any software, most shareware from small companies and individuals could be patched with a couple of assembly “nops” and bob’s your uncle, something like 3DS MAX would take the best of the best to crack the licensing engine. I’m sure the Flash community will share the best methods as soon as people start making sales.

  4. Tink says:

    @ Rich

    “It’s possible to decompile and crack any applications”

    “It’s all about how hard you can make it to steal your app.”

    Precisely, and as we all know SWF’s are extremely easy to redistribute or decompile.

  5. James Ahlschwede says:

    “With this is mind the only way I could see you being able to monetize an AIR application was through advertising.”

    There are at least 2 other ways.

    First of all, don’t think that because piracy is possible that it kills the direct sales business model. Economics studies show that as a group people are honest and like to do the right thing. Even in markets where piracy is common, like games, you still see successful releases without any copy protection. Do apps for other demographics have the same level of risk? View piracy as a marketing challenge, not a technical problem.

    AIR is very good at making desktop applications that integrate with online elements- so there’s another business model right there, you’re not selling the software, you’re selling the online service. Think World of Warcraft, or think of any website that people pay to access. Think about how Flickr would monetize an AIR app with sales of Pro accounts. You can do the same thing.

  6. Tink says:

    Thanks James

    I still don’t see how Flickr would monetize their app. They currently sell pro accounts anyway, so spending time building an AIR app wouldn’t get them more money (I guess theres the slim possibility they could sell more pro accounts).

    The only way to enforce money would be to only have pro accounts to people running the AIR app, in which they be cuting off their own nose to be utilizing AIR.

  7. Ryan Stewart says:

    What about offering an AIR version of the Flickr uploader to only pro members and enforcing it on the server side? You could do that with a lot of the web 2.0 applications out there today.

    I think there are a bunch of ways to monetize AIR applications. We’re always looking for feedback on this, so feel free to send me an email, but I think people are already looking at cool ways to make money from AIR by tying it back to their current websites.

    =Ryan
    rstewart@adobe.com

  8. Tink says:

    “What about offering an AIR version of the Flickr uploader to only pro members and enforcing it on the server side?”

    I guess that could entice the odd sale. It’ not a mahor selling point though as users need to be online to upload anyway, so who cares if you upload through AIR or through the browser. You pay to be able to upload right.

    You my have a point though, as I hate using my browser for ftping.

    I’d be interested in a list of way to monetize AIR. We’re definately interested in it.

  9. @Ryan – Simple answer – implement the native C plugin architecture and allow us to extend the AIR framework ;)

  10. razor7 says:

    I have used Sothink SWF decompiler in my AIR app, and there is not AS in there, it seems that all the data is on the EXE file.

  11. Tink says:

    EXE? As far as I’m aware the AIR extension is a ZIP file that contains n SWF and an XML file and any assets required.

  12. razor7 says:

    Jajaja…no…when you export the release version of your AIR app in Flex builder 3, there is a generated AIR installer for your app, so if you install it, you will get an EXE in the program files/your app directory.

  13. Tuddi says:

    http://www.airapps.net/ has now been renamd to http://www.o2apps.com/ (“thanks” to abusive adobe) and by going to the new site, results in a mass mailing worm trying to access the visiting computer, and there are NO links working on that site. Nothing at all.

    So… I would recommend people to NOT visit the site, unless they are well protected. It’s not as if we need more mass mailing of spam to take place.

  14. Daniele says:

    I guess a good add-on would be a method to read some unique hardware ID, like the processor serial or something like that. In that way the app could encrypt that with keyA, and the user should send it to the developer. The developer would decrypt it with key A, re-encrypt it with keyB, and send it back as an unlock code.

    This unlock code should be fed to the air app, that will decrypt it using keyB and if the result string matches the hardware ID: Bingo!

    what do you think?

  15. Dean says:

    Access to something system-unique would be great! That would certainly allow a measure of copy protection.

    That said, I still plan to sell my AIR app online, and still expect to see a return.

  16. Guys,

    I just came across the following website: http://www.sharify.it/
    Seems to be a good solution for monetizing our Air App.
    What do you think ?

  17. Tink says:

    Yeah nice find, never used it, but looks promising.

Leave a Reply