Matt Netkow
About Blog Projects Contact
Adobe App Design Course Presentation

A few nights ago, I had the pleasure of presenting to an Adobe Education Exchange class on "App Design", specifically using Adobe tools like Brackets and PhoneGap Build.  It’s a neat concept - a 2 week course, taught 100% remotely over Adobe Connect at night (7pm CST in this case).  I was happy to spread the word about PhoneGap Build!  

I presented for 10 minutes on how I used tools like PhoneGap Build to create Fitwatchr and gave some advice for beginners.  Afterwards there was a 5 minute Q&A session.  This was a lot of fun! There were tons of questions regarding how Fitwatchr works and even a bunch on the mobile industry, the state of wearable technology, and more.

You can see my slides on GitHub here.  If you attended the class and have any follow-up questions, please don’t hesitate to send me an email!

Why I Charge for my Mobile App, Fitwatchr

The prevailing strategies to monetize mobile applications in 2014 involve the inclusion of ads, in-app payments, or charging a flat fee - typically $0.99.  When I was deciding how to charge for Fitwatchr, I read many articles on various approaches.  I didn’t expect to reach the volume of users needed to make decent money with ads, which is typically thousands with high engagement, so that option was out.  In-app payments seemed inappropriate as well, since I didn’t like the idea of presenting the most useful features behind paywalls.  Therefore, I decided on charging a flat $2.99 for the app, as I loathe the bottom barrel $0.99 price, which I will discuss later.  I’ve been charging for Fitwatchr for about 9 months now to some success - we’ll hit 10,000 users by mid summer 2014.  Without the obvious reason of a monetary incentive, I’ve also encountered some real benefits to charging for an app:

1) It gives people “skin in the game”

They’ve made a financial investment, albeit small, so they tend to care more about the long term experience of the app. They are likely to use it multiple times and give feedback.  To be honest, in the very beginning, most of the feedback I received was negative.  However, connecting with users is a rewarding and humbling experience and I have learned quite a lot through that process.  In addition to enhancing customer service skills, you can leverage the positive and negative feedback to improve the app’s quality and overall experience.

2) To fight against the devaluation of consumer software

Software app costs vary widely between the business and consumer worlds.  B2B engagements are quite healthy, with developers being billed for hundreds of dollars an hour and unless you are independent, you see a fraction of that.  This generates many multitudes of value for the receiving business, making it well worth it.  On the other hand, however, App Store prices have been a race to the bottom ever since they launched years ago.  I fear that this devalues software in the eyes of the average consumer; charging more than $0.99 is now viewed as too expensive, nevermind the Starbucks latte that costs easily twice as much!  Even my fellow software developers were shocked to hear that I am charging $2.99.  My app revolves around exercise and weight loss and has the potential to be relevant for years to come.  If software provides long-term, consistent value, the cost should reflect it - regardless of industry or business type.

3) Market Validation

Charging for the app also provides a critical aspect of market validation - if people are willing to pay, your idea is on the right path.  Validation is lessened with a free app, due to how casual the installation process is: users download it, open it, and can remove it quickly if desired. However, a monetary cost acts as more of an upfront blocker; consumers may review the app in depth before committing.  With a paid app, the market directs the product.  

Overall, there isn’t one definitive path to take when deciding to create free vs. paid mobile apps.  Every app should be reviewed on an individual basis by the developer.  What are your arguments for free vs. paid? Let me know in the comments below.

Development Tips when using PhoneGap Build Plugins

Plugins are an incredibly useful way to bring native functionality to PhoneGap apps. Once you start including them though, complexity can skyrocket, mainly because you are now dependent on actual devices to test. This can lead to frustration as feedback loops are increased. To help shorten these, follow these tips:

Practice safe programming practices: add a check that the plugin exists before attempting to use it: 

if (window.plugins !== undefined && window.plugins.myPlugin !== undefined) {

// safe to use plugin now

}

Without those, app may unexpectedly crash/become unresponsive.

Read the plugin documentation carefully. It’s easy to miss a required parameter (especially with JavaScript’s lack of static typing), setup steps, or even object casing (“gaPlugin” vs. “GAPlugin”). Also beware that the docs may be out of date - if you are following instructions perfectly but still have trouble try checking the plugin’s open issues section if available. Oftentimes out of date documentation has been noticed by someone else, but the project leader hasn’t accepted the pull request that fixes it yet. I’ve had this happen two separate times!

Use various tools to troubleshoot issues.

a. Local debugging: Open the app in a browser locally - are there script errors or other issues that may make the plugin issue a red herring?

b. Remote debugging: Add extra console logging messages and exception handling to narrow down the issue directly.

Are there any other tips that I should add? Let me know below.