During the planning and development of SmartDraw we were faced with a pair of dilemmas
that many developers have faced lately.
Should we build a native Mac app, and if we do, should we put it in the Mac App Store?
Over the last 12 months both these questions have been hotly debated.
While Apple products are as popular as ever, JavaScript has taken over the world and the browser wars
have produced an incredible platform to develop on.
After much analysis the answer was obvious, building an amazing desktop-class app
was the best way to serve the Mac community, and our users as a whole.
Offering a Trial and App Store Policies
In the crowded world of software, differentiation is difficult, and often comes down
to one or two unique experiences. This has been true for SmartDraw. Our two most
popular features (content and automation) really needed to be experienced in a trial.
Words and screenshots don't do it justice. This meant the lack of a trial in
App Stores was a major hurdle.
We could have hosted the trial on our website, then when the user decided to
buy send them to the app store to purchase there and reinstall. This experiences leads
to a lot of user confusion and technical overhead that didn't make sense.
Software purchases via the App Stores provided very little customer information,
and returns happened in somewhat of a black box. Observing others experiencing
the results of these policies didn't leave a great impression. More often than not,
issues were pushed public, where users were desperate for answers, and developers
and support personal were left scrambling for better ways to communicate with their users.
While the App Stores certainly has its positives, some of these
policies are downright hostile toward businesses trying to sell software.
App Store Pricing Dynamics
Widely discussed in Apple developer circles, the App Stores also had
(and continue to have) pricing issues. Customers expected App Store apps to be
cheap, low-risk, and perpetual. None of those expectations make it easy to
build a sustainable business from, and all were directly related to the policies that made the app store troublesome.
Because users couldn't give apps a test-drive, they were less likely
to impulse buy pricier apps with sane prices. This, coupled with the flood
of apps available created a race to the bottom for prices. There were very
few examples of professional, infrequent user apps that had seen success.
Even charging $19.99 places you in the expensive category. An examination
of the App Stores top charts indicated a very obvious pattern of free-to-play
apps which derived revenue from consumables available via in-app purchase.
Public outrage over excessive in-app purchases, and the complete lack
of upgrade pricing policies in the App Stores further reduced options.
We concluded the App Stores pricing dynamic was a poor fit for the kind of software we produced.
Reliability and the Customer Experience
Apple provides many frameworks to help build great apps. In many cases they
truly help developer productivity. CloudKit, is a great platform for a startup. But,
its pricing is unclear and Apple has not had the best track record with its cloud services.
We never wanted to be in a position of not being able to answer our users' questions
because of unknown issues in CloudKit or other frameworks.
We also had many customers not using Mac and iOS, with a legacy Window
business and growing Android market. Many of the technologies available in
Apple's ecosystem are iOS & Mac only, rendering them nearly useless for us.
As attractive as they were, they were again a poor fit for our product.
The Tech was Ready
At this point using any of Apple's tools (iCloud, CloudKit, App Store distribution, etc.)
was not an option. The only question left was whether we should build a native app,
but that question almost answered itself. On the one hand it was clear Apple's
development platform showed little benefit for us. On the other hand our experiments
with web technologies like Angular, React, and jQuery showed a robust, desktop-class
app was possible in the browser now.
Facebook & LinkedIn had both struggled with wrapped apps on iOS early.
But, their learnings and an active and open JavaScript community had pushed
browsers forward. HTML5, CSS3, JavaScript, and SVG gave us everything we needed,
and allowed us to serve all our customers with one solution.
In the End We Went Online
Choosing to go online first was a difficult choice. But, in the end it
was the path that allowed us to best serve all our current and prospective users.
The benefits of the App Store look so good on paper, and would have been great for
us as a business. But, there were too many asterisks, too many black boxes. As we
iterate on SmartDraw we will continue to ask ourselves if the market has changed.
We will be watching what Apple does at WWDC closely this year.
SmartDraw makes diagramming easy
