The Tyranny of Mobile Apps

How We Learned to Stop Worrying and Love the App Stores

We did not want to build a mobile app: we were coerced. Over the last year, in order to turn our new game idea into a reality, we were compelled to spend significant amounts of time learning how to build, deploy and maintain a mobile app. Our team was well versed in building web apps and we could have created the game more much easily, quickly and cheaply as a browser-based game. However, our previous experiences had taught us a hard lesson: it is an uphill battle when you don’t have a mobile app. This article is about the journey towards our first mobile app: the Words Across America game.

Why do so many companies spend significant amounts of money building and maintaining mobiles apps that are simply redundant to their web sites? There are many instances where a mobile app provides a better experience than a browser-based interface, but there is a large body of mobile apps that that offer nothing beyond what the company’s web site does or could provide.

We considered taking a more editorial approach about the underlying economic, political and social issues such as digital colonialism, consumer protections, antitrust laws, etc. However, for the purposes of this article, we’ll leave it at “that’s just the way it is” and move on to discuss some of the mechanical and technical realities that forced us into mobile app development.

Our Previous Web App Game

When developing our first game, we were aware that making it available in the app stores was advantageous. However, we did not have any mobile app development experience, nor the budget to hire or contract out for that expertise. Either we invested the non-trivial amount of time and effort to learn, or we stick with making it a web app and getting it out the door faster. Nothing about the game required it to be a mobile app: HTML, CSS and Javascript were all we needed on the front end.

Given that it was better to first assess the game’s appeal, we decided to start with a web app and later re-evaluate whether to invest in a mobile app version. With some moderate success of the web app, maybe we could even fund contracting out the development?

After building the web app version, the game had some success, a few thousand played, but this was not enough to fund a mobile app. It was over the period when we were marketing and refining that first game where we encountered all the issues that would force us to make a mobile app a hard requirement for our next project.

PWAs

A Progressive Web App (PWA) is nothing more than a web app that conforms to a particular pattern of behavior and protocols. We will not delve into the details of PWAs here, but the essence is that there is a piece of Javascript code you provide called the “service worker” and this, plus a few other pieces, allows a web app to get some extra capabilities which make it hard to distinguish from a mobile app. When you run a PWA in a browser on your mobile device, it can even strip away all of the browser decorations so it looks very much like a native app. The core PWA idea is to use a web browser as a virtual machine (or app container) so that the same app can run on any device where a web browser can run.

Allowing an app running in a browser to look just like a standalone app made PWAs the ideal technology for games like ours. We did not want to limited ourselves to mobile devices, so having a single web app that could work on any platform having a web browser was perfect. It seemed like our problem was solved. In a sense, this was a solution, but in another sense, it was not.

After adding the necessary bits to conform to the PWA protocols, we had a mobile device experience which was nearly indistinguishable from a native app. Besides starting in a browser instead of an app store, a user could click an “install” button and get an app icon on their Home Screen to directly access the game. When launched from the Home Screen, it would behave like a regular mobile app, taking the entire screen for itself even though it was running inside a web browser under the covers.

As we continued marketing the game, we gradually came to a realization that PWAs were not enough: people have been conditioned to look for these types of recreational games in the app stores. Like it or not, we were missing out on a lot of potential players by not being listed in the app stores.

PWAs and App Stores

If a PWA can look and behave just like any other mobile app, it seems like these should be able to be included in the mobile app stores. In fact, they can, sort of. Google’s Play Store and the Microsoft Store allow PWAs to be listed and we happily jumped through the extra hoops to get our game listed on those app stores.

In contrast was Apple, who is somewhat antagonistic toward PWAs. They (effectively) do not allow PWAs in their App Store and provide somewhat weak arguments about technical or aesthetic deficiencies. These existing shortcomings of PWAs could easily be overcome by developing the standard and adding the necessary browser support. Apple has sort-of, kind-of supported PWAs in Safari, but done enough through its actions and in-actions to make it a somewhat crippled experience.

Maybe Apple would make the odd PWA exception for higher profile companies, but for the most part, a PWA submission would be dead in the water for mid to small sized companies. Again, we’ll avoid the diving into why this is the case with Apple, but the answer likely involves the word “billions” and the word “dollars”. We had a little more to say about this topic at the time in this previous Blog Article.

Web Views

Mobile apps have the notion of a “web view”. Mobile apps can run an embedded browser and display any web page’s HTML/CSS and run Javascript. In theory, all our game needed was a “shell” of a native app to render all our game pages as web-views and we could have a mobile app for cheap. In fact, many companies have used that strategy to avoid having to replicate their web site as a native app, for all or some of its views/pages.

The problem with web views is that the app stores (Apple in particular) frown upon them. And when we say “frown”, we really mean they will likely reject your app if all it has are web views. With anything short of a native app, the probability of rejection from the Apple App Store is high. However, even if we went down that road, just having a “shell” mobile app would still involve us learning a good chunk of the mobile app development concepts and technologies.

With the rejection risk being high, we decided not to invest the time trying the web view approach for iOS. Thus, with PWAs and web views both being dead ends, we were locked out of half the mobile market unless we invested in a native iOS app.

Free Games and Privacy

Our company takes great strides to protect our customers’ privacy. We do not use any third-party tracking or data analysis tools and we will not sell any of the players’ game play data. This puts us at a bit of a disadvantage. Not tracking users across the Internet gives us less visibility. Further, not showing ads, not using tracking pixels and not reselling our customers’ data gives us less ways to get paid.

We did not create our games for completely altruistic reasons: we do hope to make money. However, we want to do this in the most up-front way possible: we provide a small amount of entertainment value and the player pays a small amount to compensate us for our time. The problem with this straightforward approach of exchanging value is that many people are not conditioned on this dynamic for recreational games.

There are thousands of free word games available to play. That is what people directly see, so the idea of paying for a word game is at best foreign to many and down right offensive to some. As one of our Facebook commenters so eloquently informed us: “F**k that. I never pay for games.”

Instead of users seeing how value is being exchanged in these free word games, it is hidden. The companies making these games do so in the hopes of showing ads and/or selling the users’ data. Thus, the value the person pays for the game’s entertainment is measured by what they give up in their attention (time) and/or their privacy (data).

Unfortunately, many people are unaware of what happens behind the scenes in the ad networks and with data brokers. Further, it also appears that a good many people simply do not put much value their time or privacy. “So what?” is a common response when trying to educate people about this trade-off.

Conditioning and attitudes like these have been a major friction points for us and our business model. However, we prefer to try and fail honestly than to succeed by participating in bad system. This previous Blog Article has more on this topic from when we were first uncovering these realities.

Trust

Again, we do hope to make money with our games, so when we launched our first game we used Stripe to accept credit card payments. Stripe’s APIs and documentation are first rate, they are highly reputable and widely used. A problem is that the average person has never heard of Stripe.

How would you feel entering in your credit card info into a web site of some small-time game company that few people have heard of and you have only recently discovered? The fact that the web site’s form is powered by a reputable company like Stripe is not going to be noticed by the average person, and even if that tiny Stripe logo we added was noticed, they are not a consumer brand, so are not widely recognized outside the technology industry.

Our initial solution to this problem was to swap out Stripe for PayPal. We did not choose PayPal originally because they charge higher fees and are harder to integrate with. However, we finally gave in so that we could have a more recognizable brand name on our payment page. Here, “perceived trust” was the goal: Stripe is at least as trustworthy as PayPal (probably more so).

Adding PayPal did not move the needle much though. People were still interacting with a relatively unknown web site and company. With the proliferation of nefarious sites and scams, there has been increasing coverage and awareness of security issues by the general population. A better educated public is good, but this puts a startup without the brand recognition at a serious disadvantage if they want to accept payments on the web.

Reflecting on these experiences, we came to realize some important benefits of being listed in the app stores. Or rather, the benefit of being vetted by Apple/Google and taking payments through their app store mechanisms. Not only do people trust Apple and Google more, they are also conditioned to make payments of goods in the app stores. Realization of this two-pronged advantage was the key turning point that swayed us from “probably should” to “definitely must” build a mobile app for our next game.

Game Evolution

Besides the all those external factors, we had also learned about the many strengths and weaknesses of the game itself.

• We invested a lot of time in features that wound up having very little value.
• We learned a lot about which parts of the game people were drawn to.
• We had a number of recurring themes in our feedback about some game play deficiencies.

All these lessons were slowly accumulating in our minds. Over time, they started to take form as a vague collection of loosely connected concepts for a possible new game. Slowly, some semi-coherent bits and pieces started to emerge. Eventually, all the ideas coalesced and the entirety of a new game came into focus. We took some of the best parts of the previous game, extended it in new ways and decided to pivot away from our first game and put all our energy into this new game idea: Words Across America.

Once we had mapped out what the game would be, it was time to begin building it. By this time, we knew we needed to bite the bullet and learn how to build a mobile app.

Flutter to the Rescue

Learning two different technology frameworks/languages was out of the question (iOS/Swift and Android/Kotlin). It is also unnecessary as there are many cross-platform frameworks that allow you to build an app for both iOS and Android from a single code base. However, the fact that there are “many” presented a challenge because now we had to pick one. As with any programming language or framework, each has a rabid base of followers and detractors, so cutting through the noise was a challenge.

To cut to the conclusion, we selected Flutter as the framework, with Dart as the programming language, and we have no regrets with that decision. We have a lot more to say about how we came to choose Flutter and about our good and bad experiences with the framework. However, since that discussion is much more technical, we will write about it separately in a follow-up article.

Summary

To summarize the lessons learned, we were forced to build a mobile app because:

• there is a conditioning to look for recreational games in app stores;
• Apple’s App Store does not like apps that use web or browser technologies;
• there is more trust of apps found in app stores than found on the web;
• there is more trust when submitting payments to Apple/Google; and
• there is more conditioning to pay for apps in the app stores.

We’ve written a couple followup articles about our first-time experiences with mobile app development. The article Journey of a Mobile App Newbie discusses general design and development concerns, while the more technically focused Discovering Flutter and Mobile Apps reviews our choice and initial experiences with the Flutter mobile app development framework.