My appearance on the Release Notes podcast

I was interviewed by the good folks over at Release Notes the past two weeks. In part 1 I talk about the how mobile was in the early days, how we marketed and sold applications, and our complicated relationship with Palm. Click here to listen to the first part (~37 minutes).

In the second part, I talk about the future, about the transition we have undergone as the mobile market has changed and expanded, and what drove us to reinvent powerOne. Click here to listen to the second part.

It was an honor to be on the podcast. A special thanks to Charles and Joe for having me.

The way it was: channel sales before app stores

There aren’t a lot of us around who existed selling mobile software before iOS and Android. I believe there is a misconception over the way things were back then though and how we built out sales channels. My history in mobile dates back to 1997. Compaq was still its own company (and producing its own mobile hardware devices), Dell was the king of device sales, and Apple was barely an after thought¹.

We built a multi-pronged channel approach to generate revenue. Channel is the place of marketing’s 4 P’s (product, place, promotion, price). I even had a dedicated sales woman who was a queen at managing channel. It was a big deal back then! Now… well, not much choice. You can sell through Apple’s App Store, Google’s Play store, Amazon’s Appstore, Mac App Store, Windows App Store and maybe your own site depending on the platform. Most other channels are gone, although enterprise sales probably still have value-added resellers and other channels.

  • When I started out we had a partnership with a retail publisher. Macmillan Digital Publishing bundled us with a few other titles and sold through CompUSA, Best Buy, Office Depot, Staples and the like. We received a $1.00 per title, and the bundle, which included about five titles, sold for about $50. All were shareware titles and we did five of these over 3 years. The last one was a suite of titles we developed. It was a good deal for us. It was a channel we couldn’t attack directly at our early age and lack of funding, basically putting us in front of a group of customers who otherwise wouldn’t have known about us. We bundled a lesser product — a Lite version in the parlance — and then upsold our higher end version for $20 more. It didn’t drive a lot of up-sell traffic as we didn’t “own” the customer relationship and really couldn’t promote the higher-end versions effectively.
  • Once this bundle started selling, we started selling from our own web site as well. We sold two versions: the Lite version for $20 and the Pro version for $40. We drove people to the Pro version with ads in a magazine included in the box with each PalmPilot sold. I remember writing my first check — $20,000 — for an ad. My hand shook. Eventually our prices changed. The Lite version became free, a Personal version was $10, and then we had other versions from anywhere from $30-160. Our average selling price was $37 net.
  • We sold through online resellers, most prominently Handango and PalmGear (and a few others I can’t remember on the Windows Mobile side). These guys started our as good partners and a 20-25% cut of the revenues (they received), but they slowly started to raise their prices and, at the end, were demanding 60-70% of the sales revenue. When Steve Jobs stood on stage and said he was only charging 30% and what a great deal that would be, he was referring to these guys. Very little mobile software was ever sold through retail channels. Handango and PalmGear were the go-to places.
  • We, on the other hand, did sell through retail. Not just the aforementioned bundles but also through some very select channels. The Franklin-Covey retail stores were a perfect match. We also sold through (physical CDs, not electronic downloads in those days), Dell’s and Palm’s stores. Each took about a 30% cut. We had the opportunity to go to other retail, especially Costco which did a lot of sales back then, but we turned them down. It wasn’t the cut of the revenues we worried about, which was 30-50%, but instead was the terms. These stores could return the inventory at any time for a full refund and they ordered in the tens of thousands. This meant we couldn’t spend the money until we were certain it all sold, and we weren’t confident enough in our niche, vertical products to expect it to do well in a horizontal market like these.
  • Of the retail we did pursue, Franklin-Covey was the biggest of these sellers, although Palm, Amazon and Dell sold a lot of software for us as well. We sent and they sold thousands of titles through Franklin Covey retail stores. Palm, Amazon and Dell were a little different. They would place smaller orders and we would deliver them, mostly just in time or even drop-ship direct to customers. This mitigated the inventory risks.
  • While it wasn’t a sales channel, our biggest market opportunity came in 1999 when we started bundling with PalmPilots. We were on a CD that came in the box with other titles. The Palm deal led to other deals and at one point were bundled with about 85% of handheld computers sold. We gave away the Lite version and charged for the higher-end products. We even gave customers a little something for free (some extra calculations) if they came to the site and registered.  We built a 400,000 person mailing list and figure we distributed close to 20 million calculators in that time period. This became our primary marketing effort pretty quickly and, it turned out, drove about 75% of our sales. (I only know that because when the deals dried up our sales plummeted by that much.) I don’t think we ever truly utilized that marketing list. That was probably our biggest opportunity wasted. We did occasional mailers but didn’t really understand the impact that attention could have driven for us. It was extremely expensive back then to email them, honestly, and our minds were elsewhere…
  • … like the education market. When we focused on vertical markets and education in the early 2000s we signed up a number of value-added resellers and others that helped generate some income, but most of the education sales were speculative. We needed standardized test approval to be adopted and, well, that didn’t happen in the end. This is a story I’ve told before. We did do some smaller sales to a school or classroom. It was nice to send a single disk and paper saying how many computers it could go on, and get multi-thousand dollar checks in return. With standardized test adoption we would have seen districts and states adopt. That would have been big money, dwarfing all other revenue we had at that time easily.

Channel was a big part of our marketing strategy and, frankly, besides bundling, channel was our biggest strength and catapulted Infinity Softworks into being one of the best revenue businesses in the handheld era². Unfortunately it didn’t last long — our peak revenues were from 1999 to 2004 — and we never did figure out a way to break out into massive growth. The world was very different back then.

¹ In 1997, when graduating college, I thought I’d either develop Mac software or Palm software. The PalmPilot had just come out a few months before and it seemed like it had more promise. Oh well.

² That’s not saying a lot, although much better revenue then today for an indie developer with a small team.

Upgrading our thinking on App Store revenues

Every four to six months we get on another round of “Apple’s screwing developers without trials and upgrades.” While I agree it would be awesome to have, I’m on the record as believing that it is too late now. The expectation game was set long ago and App Store prices aren’t going up. Furthermore, the glut of App Store apps makes it hard to raise prices. iOS software has been commoditized.

The real question is how can we, as developers, use what’s given to us to build effective software sales. (Effective meaning “achieve our goals.”) I believe that trials and upgrades, two commonly requested features, are within our reach.

Whether we like it or not, Apple controls what we can do for business models. This is what they give us for purchasing:

  • Pay Up-Front: The first model. This shows the paid amount on the button in the App Store, you buy it and download it and it is yours forever.
  • In-App Purchase: Buy things once the app is downloaded and running on your device.
  • Subscriptions: Renewable purchases that can either be renewed manually or renewed automatically.
  • Free: No cost at all to download.

I will also note that we can use advertising in our apps and purchase physical goods within our apps.

There are some App Store review guidelines that are worth considering in this discussion.

  • 2.9: Apps that are “demo”, “trial”, or “test” versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines
  • 11.1: Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
  • 11.2: Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected
  • 11.3: Apps that use IAP to purchase credits or other currencies must consume those credits within the App
  • 11.9: Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
  • 11.13: Apps that link to external mechanisms for purchases or subscriptions to be used in the App, such as a “buy” button that goes to a web site to purchase a digital book, will be rejected

Really, section 11 is the big one and these are the applicable rules, I think. It also appears that section 11.9 allows subscription software services as well. There are lots of examples of mobile apps that extend web apps that do allow trials that expire after a period of time or a subscription where the app stops working once the subscription ends.

This is the framework within we must work. So now we need to mix-and-match this framework to get the desired results. A few suggestions of ways we can make money:

  • Charge up front: many of us have been doing this for years and is causing all the consternation so let’s not beat this horse.
  • Advertising: integrated ads, while anathema to so many of us, actually generates good money for the right apps.
  • Donation: give away the app, ask for “tips” to help keep it going.
  • Freemium: have a free app with some paid features.
  • Paymium: have a paid app with additional paid features.
  • Trial: if coupled with a web version, the mobile version can have a trial period.
  • Upgrades: use in app purchase to charge for new features added to the app.
  • Subscription: charge to use the app for periods of time. (For those that hate Apple’s 30% cut you can charge for this on your web site and activate with a login and password in the app. You can’t advertise that fact within your app, though.)
  • Free: give away the app and charge for something else.
  • Physical Goods: make something and use the app to promote it.

You’ll notice Trial and Upgrade can be done if we think through our business models carefully enough, and are willing to take the plunge into expanding beyond iOS development.

As Rob Rhyne said at the Release Notes conference, it’s not too hard for independent developers to make money on the App Store. It’s just hard for independent developers to make money.

Web! Native! Both?

I once had a professor who insisted that writing software was 70% planning and 30% implementation. I thought he was crazy at the time. 18 years later I completely understand where he was coming from.

Nolan Lawson kicked off another round of discussions about using web technologies exclusively to build native apps (and a follow-up here). The native app people always come down on the side of no way. They rightly point to the fact that web apps don’t feel like native apps. The animations between views aren’t as smooth, the look-and-feel can never be native enough, and the “write-once, run-everywhere” approach just means really mediocre applications everywhere. Learn to write native code!

The web-centric developers point to the complexities of learning web, iOS, Android, Windows and Mac program. Learning any one language well is hard enough. Learning five well enough to write performant apps and maintain those apps is nearly impossible. Besides it is the web that made Mac relevant. We already have write-once, run-everywhere. It’s called a web browser. Why should we go back to coding like its 1995?

These arguments, however, ignore a third way: the hybrid app. The hybrid app is where some of the application uses web technology and some use native code. We use embedded web views wrapped within native code to present the application to the customer.

Apple already does this in some of their apps today. The Mail app uses web views to show email. It is also rumored that iMessage uses web views to show individual message bubbles. iBooks may use web views as well. Third-party apps, especially reader applications, RSS apps and apps like Flipboard and read-it-later applications use web views in this way as well. The entire app isn’t HTML and the entire app isn’t native.

The key to this approach is understanding clearly what makes each of the various technologies superior and then use each of those technologies appropriately to build a superior experience. Just like in the days when developers would use Assembly to write really CPU-intensive aspects of their apps, web technologies can be used to do what they are best at: rendering and formatting text, especially when combined with other medias. Have you ever tried showing an image along with a block of formatted text in iOS or Android? How about a bulleted list with text around it? It’s possible but it isn’t easy. HTML makes that simple, even giving us the ability to edit that text and return the output to the native app.

HTML fails miserably at animation¹, though, and it is nearly impossible to make HTML look like Android or iOS. Don’t use it for that. Learning the basics of navigation, list management and animation techniques in any native platform, though, takes a much smaller amount of time and doesn’t require nearly the skill set.

This is why planning is so important. When we started working on Equals we broke the product down into small pieces, deciding how to accomplish each piece, thinking ahead to both how the app would work on the web and also how it would be presented on native platforms.

We used Equals’ technology to develop our first mobile app: DEWALT Mobile Pro for Android. I had never written an Android app before this. (powerOne for Android was developed by a third-party.) True to my word, DEWALT Mobile Pro is a hybrid app: it uses all native Android code to present the list, calculator and various dialogs, and uses HTML technology to present the template itself, which combines various elements — images, links, text, and some input keypads — in a single page.

It took less than three months to write the entire application, including learning how to develop for Android. In comparison, it took six months to develop powerOne for iPhone back in 2008. The difference, frankly, was the amount of time I needed to invest in native code that shows and allows data input into the templates.

By utilizing a combination of HTML5 and native code I believe I was able to attain a superior presentation of the templates while, at the same time, maintaining a native look-and-feel for the application. We can shout “native!” “web!” but in the end we should use the technologies — or, more appropriately, the combination of technologies — that make the best applications. Sometimes that’s native code, sometimes it’s web code, and sometimes it’s both.

¹ I am specifically referring to animation that acts like native code. Making a spinner spin isn’t a big deal anywhere. But transitioning from one view to another never reacts well in HTML. If you do any animations, I can highly recommend Greensock’s GSAP technology. It is amazing, and the recommended animation engine by Google for their Material Design stuff.

Why Apple’s Force Touch technology was Monday’s most interesting announcement

There was a lot of interesting aspects to Apple’s Monday keynote. The Apple Watch is compelling, although I still have not decided if the first generation is for me. The new Macbook is exciting. The only thing we ever plug into our family laptop is the power cord. The idea of lighter, simpler and smaller really appeals to me. And the ResearchKit SDK is fascinating. I hope it really helps us solve some of life’s most troubling diseases. Given all that, though, the minute or two spent on Force Touch technology was the most interesting.

When Apple introduced the iPhone, one of the biggest innovations was Apple’s touch layer. For really the first time we could use a finger to scroll around a screen, zoom in with a tap, gesture with a pinch motion and more.

All of these gestures, though, were two-dimensional across the surface of the device. With Force Touch, Apple now makes touches three-dimensional. The force applied to the touch will also have meaning.

Think of all the ways this could be used by developers:

  • A game could use Force Touch to indicate how hard to throw a weapon
  • Drawing apps can thicken the line based on the force used to touch the screen
  • Note-taking apps with pen input can use force to distinguish between the pen and the wrist resting on the device, significantly improving palm rejection (and opening up true pen input)
  • Buttons can take on additional meaning, revealing power user functionality based on the force of a tap

There are already rumors that Apple will be integrating the technology into iPhones. This is a no-brainer and hopefully Force Touch will be a standard iPad feature as well. Adding a third-dimension to touch interaction could open a world of fascinating possibilities, one that no other device manufacturer has.