Archive for March 2016

Five Months on the Apple TV App Store

Apple launched the fourth generation Apple TV on October 29th, 2015. That was also the first day of the Apple TV App Store and the first day that my tvOS app, Chess TV!, was available. Chess TV! is an app that I created as a side-project in about 30 hours of my time after receiving a free Apple TV dev kit from Apple prior to the official launch of the device. I have been pleasantly surprised by its sales. This is the story of its first five months.

Building Chess TV!

I have quite a bit of experience with chess programming. I studied chess AI as my culminating experience in graduate school and I have developed prior chess apps as well as the main (only?) chess programming library for the Dart programming language. Yet, I felt there was no reason to reinvent the wheel. My goal was to create a great big screen chess playing experience, not to create a cutting edge AI.

To that end I searched through the repositories of the many open source chess engines. All of them (even the weak ones) are strong enough to be competitive for all but the most elite players. My criteria instead was:

  • Will this engine be easy to integrate with my code?
  • Is this engine well documented (or its source easy to understand enough), so that I will have no problem utilizing its public interface to implement features I want like undo/redo, algebraic move output, etc.?
Surprisingly, many of the popular engines are so concerned with performance that things like ease of integration and documentation take a backseat. I ultimately settled on integrating Mister Queen by Michael Fogleman. Mister Queen is not a well known engine by any means, but in my testing using The Bratko-Kopec Test it scored a 13/24 when provided 8 seconds per position (12 at 4 seconds and still 13 at 16 seconds) which indicates it’s about expert strength (ELO ~2000, stronger than 99+% of users).

Mister Queen is written in clear, concise, C. For a one-man project, as with most of Michael Fogleman’s projects, it’s surprising for its completeness and depth. I think I made a great choice, as it’s been a joy to integrate and has provided several features off-the-shelf (like built-in testing positions (more about that later)) that I would have otherwise needed to write myself. I do not regret at all choosing Mister Queen over the more popular alternatives. Sometimes in programming software, just as in using it, ease-of-use trumps all else.

Because Mister Queen is written in C, I chose to use Objective-C, instead of Swift, in writing Chess TV!. Although Swift has good support for C, it can’t beat Objective-C on that front! Working with UIKit on tvOS is almost identical to working with it on iOS. The main difference is thinking about focus (what UI element is currently selected by the Apple TV’s trackpad like remote). Once I had implemented a chess board using custom UIViews for each square with intelligent focusing behavior, I chose to use off-the-shelf widgets for the rest of the interface. The result is a UI that looks plain and no-nonsense, but also fits well with the rest of tvOS.

I’ve noticed a lot of bugs in other apps with regards to how the remote’s menu button operates. Misbehavior in this regard can even lead to rejections by app review. By using a standard tab bar controller, I’ve managed to avoid this.

I wanted Chess TV! to be more than just a chess playing app. Conveniently, Mister Queen is bundled with ~400 famous chess puzzles (positions where you choose the best move) from famous chess books (you cannot copyright a chess position - that was settled in the legal system). So, I built Chess TV! so that in addition to its playing mode it also has a puzzle mode, something none of its competitors have…

Competition

When the app store launched, Chess TV! was the only chess app on the store. By the second day of the store a competitor, also priced at $0.99, appeared. We dueled it out for chess app supremacy. Because there were so few apps on the store at the time, throughout November it was not unusual to find both apps in the top paid apps list.

In the last couple of months two free competitors have also appeared on the store as well as two apps related to chess (a chess clock and a chess watching app). For whatever reason, the two free apps do not seem to have diminished my sales. I have done zero marketing of Chess TV!. I think it may be that users are trying out the other apps and then deciding they want something more substantial. It’s possible that my higher price point (see next section) has actually signalled to the market place that Chess TV! is a premium product. If that theory is true, then the marketing efforts of the free competitors may actually be boosting Chess TV! sales.

I will say that I think Chess TV! is the most featureful (especially considering the puzzles) tvOS chess app. There are a couple features (3D, saving and resuming games) that other apps have that Chess TV! does not. Since launch, I have added features like support for background music, board flipping, and alternative board patterns based on feedback from users and the inclusion of these in competitors’ apps. I have also added Spanish localization, but it’s unclear how much this has boosted sales.

Pricing & Sales

Chess TV! launched at $0.99 cents and sat there for several months. I have experimented with prices ranging from $2.99 to $4.99. I tried each price out for about a week and compared sales to the prior week. Eventually I settled at $3.99, not based on much science other than these weekly examinations. I’m not sure it’s the ideal price, but I do think the signalling of Chess TV! as a premium product has helped it. Units are of course down from the $0.99 price point, but sales (in dollars) are actually stable or up.

Sales average $150-$200/month (before Apple’s cut). It’s not going to make me rich, but if these sales continue for the rest of the year (a big if), then for something I did as a hobby in about 30–40 hours of time (including updates, excluding me thinking about it, talking about it, and checking up on it) I would consider the sales more than satisfactory. They’re certainly higher than I expected, especially considering I’ve done zero marketing.

The tvOS App Store Needs Work

One reason I’ve done zero marketing is that as of now, there’s no way to link to a tvOS only app’s store page (or purchase an app for that matter) from any other device. That’s right, unlike iOS apps which you can link to the store page of in a web browser and purchase through iTunes, there’s no equivalent for tvOS only apps. This is a huge problem. What do you link to (for people to purchase from) on a marketing page? I have a simple page for Chess TV! that I don’t send to anyone since it doesn’t have real links.

I’ve brought up this issue with Apple developer relations and also at the Apple TV Tech Talk in NYC. Apple seemed sympathetic to the issue, but it’s been five months and there’s been no resolution. It’s a major sore point for anyone who wants to develop and market a tvOS only app.

When the tvOS app store launched in October it definitely was not ready for prime time. It didn’t even have categories! Now it has some rudimentary categories, but still not subcategories. This is despite the fact that we are able to select a subcategory for our tvOS apps when we submit them. Perhaps Apple is embarassed by the lack of apps that would appear in some of these subcategories. It definitely hurts Chess TV! which would likely dominate the board game subcategory if the subcategory was browsable by users.

Apple has never featured Chess TV!, which I understand since it’s not graphically impressive nor does it utilize any of the unique features of the Apple TV. The least they could do for us lowly chess developers would be to give us store page links and subcategories.

Summary

In building Chess TV! I was able to leverage a great open source chess engine, Apple’s free dev kit (to get a jump on the competition), and my UIKit skills from iOS, to build an app in a relatively short amount of time that resonates with more users than I expected. Thanks must go to Apple, Michael Fogleman, and all of the early adopters who took a chance on Chess TV!. Yet, the tvOS app store needs some tweaks before it will be truly developer friendly.

Posted in , , , , , , , , , , , | 1 Comment

Three Options for App Owners Facing the End of Parse

I originally wrote this post for Crew’s Backstage blog and it originally appeared there on March 1, 2016. Special thanks to Jory Mackay for his many superb edits and improvements. Note that the original audience is non-technical app owners. I have made a few minor edits from the original post here.
If you’re one of the 500,000+ app owners that use Parse—the most popular mobile backend-as-a-service (BaaS)—to power your app, January 28th was a particularly bad day. After half a decade providing app developers with flexible data storage, and everything from user authentication to push notifications, the team behind Parse announced they’d be shutting down their services.

Which should’ve come as a surprise. Since Facebook acquired Parse in 2013, they have only provided positive indications about their commitment to Parse. If you have an app developed using a Parse backend, it’s time you started looking for an alternative.

First off, it needs to be stated plainly that this most likely won’t be a quick and easy fix. The backend is a major component of your app. In many cases, the backend and the code that connects to the backend can make up as much as 50% of your app, especially if your app is a social network, messaging app, or other app centered on storing large amounts of user created data.

Changing backends is obviously a big endeavor. Luckily, you have both time and options. Parse has provided a one year window (until January 28th, 2017) in which its services will continue to operate. If you feel that your app has not yet gained enough traction to warrant a partial rewrite, consider taking a wait-and-see approach. You could wait until the late Spring/Summer with the existing backend and then begin the rewrite if your app has taken off. But keep in mind that the longer you wait, the more dangerous your situation becomes (software development is a fickle business).

So, if it’s time to move, what are your best options?

Option 1: Open Source Parse Server (or the Path of Least Resistance)

Despite shutting Parse down, Facebook has graciously open sourced a large amount of its technology. This will allow you to run your own ‘mini-Parse’ on your own hardware or your own virtualized server (through AWS, Heroku, Azure, Linode, Digital Ocean, etc…).

Unfortunately, it’s not as feature rich as Parse was/is, and of course it comes with no formal support contract. You’ll also have to maintain your own server or virtualized server, which is more than some developers/clients want to do.

But, ultimately, this option will entail the least development work/code changes.

Pros:
  • Free
  • Complete control of your own destiny
  • Fewest code changes

Cons:
  • No formal support
  • Have to maintain your own server or virtualized environment
  • Still missing some features other BaaS providers have

Option 2: Switch to Another Established BaaS Provider (CloudKit & Firebase)

Apple provides a comprehensive BaaS known as CloudKit. It offers many of the same services that Parse offered and its resource limits are very similar to Parse.

CloudKit backs Apple’s own services like iCloud Drive and iCloud Photo Library, so you know the infrastructure is industrial strength and unlikely to go away in the near future. There are ample tutorials and book chapters to help developers get up to speed on it.

But, there is a catch. CloudKit has no native SDK for Android (or Windows, Linux, etc…). While the recently introduced webhooks may allow you to cobble together a cross-platform solution, CloudKit is clearly designed only for iOS, Mac, and Web apps (an official JavaScript SDK does exist). If your app is only on these platforms then it may make a lot of sense.

Firebase, acquired by Google in 2014, is perhaps the BaaS most similar to Parse. Like Parse it’s backed by a big company with a great reputation in the field of big data, is feature rich, and works cross-platform.

Firebase offers realtime capabilities that make it ideal for messaging apps and also offers clearly tiered pricing that makes sense for most startups. Firebase is relatively popular and there are many more tutorials available surrounding it than some of the lesser known BaaS providers, so it is likely one of the easier options for a developer to get up to speed on. However, some developers dislike Firebase’s API.

Pros:
  • Free for apps with a small userbase
  • Backed by Apple or Google
  • Feature rich
  • Well documented
  • Realtime messaging support (Firebase)

Cons:
  • iOS/Mac/Web only (CloudKit)
  • No built-in support for push notifications (Firebase)
  • At the mercy of another tech giant (like Parse was to Facebook)

Option 3: Roll Your Own Backend

Writing a custom backend can be as daunting a task as writing a mobile app, depending on the complexity of that backend. There are a myriad of frameworks, languages, servers, and development environments to choose from. If your developer does not have previous experience writing a backend, it’s likely to be a laborious, error-prone task.

However, it’s also the only path that puts you completely in control of your own destiny (even beyond the open source Parse Server).

Your custom backend is built specifically for your app. It can include whatever features you need and you can scale it however suits your growth. However, it also means maintaining your own servers. You can somewhat get a jumpstart by utilizing cloud data stores provided by services like Azure, AWS, and Google Cloud Platform.

Pros:
  • Complete control of your app’s destiny
  • Customized for the features your app needs
  • Cheaper to scale
  • Can use cloud data stores from AWS, Azure, and Google

Cons:
  • Unsupported by a big company (no Apple or Google backing your server code)
  • Have to maintain your own servers or virtualized environments
  • Highest development cost
  • Longest development time

So what’s the best option?

Choosing what direction to take your Parse-powered app is ultimately both a technical and a business decision. Utilizing Parse’s open source solution will be the least costly in terms of both programmatic effort and maintenance costs. Porting your app to CloudKit, Firebase, or a lesser-known BaaS Provider will be costly and time consuming but will provide you with comprehensive support and eliminate the need to maintain your own server. Finally, building your own custom backend provides the ultimate in control but also will be the most costly and time consuming to develop.

If none of these sound right for you, there are a myriad of lesser known BaaS providers like Kii, Kinvey, FatFractal, and many more out there. The risk, however, is that you build against one of them and then they cease to exist. Using one of these options may make sense for an MVP but is unlikely to make sense for something you expect to scale.

You must consider the development work involved, platform needs, pricing, and your timeline. As well as the future of the platform that you’re building upon.

No option is perfect, but continuing with Parse Server on your own server probably makes sense as the path of least resistance for most apps. If you’re interested in porting your app from Parse, get in touch with me.

Posted in , , , , , , , , , | Leave a comment
Copyright 2012-2016 David Kopec. Powered by Blogger.

Search

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by LiteThemes.com.