Why Nintendo doesn’t release Mario on the App Store

Recently, I read an interview with Nintendo’s CEO Satoru Iwata on the Japanese gaming website 4gamer (Japanese only), which was very entertaining and interesting.

There are lots of interesting facts that I wasn’t aware of previously in the article, including that Satoru Iwata himself has a hard-core programing background and he actually was writing codes until he was 40 years old.

However, myself as an indie iOS developer making a living on the App Store, the most interesting part was that he clearly explained why Nintendo doesn’t want to release Mario on the AppStore.

Maybe he mentioned that reason in some interviews before, but all articles I had seen so far were just opinions from writers about why Nintendo wouldn’t do that, or why Nintendo should.

He mentions in the interview that Apple doesn’t have any incentives to protect the values of their content, since the content for Apple products are simply used to attract people who want to buy smartphones.

Apple creates a platform (the App Store) to sell their smartphones, but Nintendo creates a platform (gaming hardware) to sell their games. There is a big difference between them he explains.

Nintendo’s worst nightmare is a future where the value of contents are getting lower and lower. He says they can sell a lot of games to more people if they release their titles at lower prices, but they’d rather protect the value of games instead.

It seems that protecting the value of games is the challenge that they’ve been trying to solve, and clearly something that they are struggling with.

I can totally understand this logic as an indie iOS developer even though I am selling tools, not games. I know how difficult it is to create your own business on the App Store because your basic option is to charge money at lower price once and keep updating for free.

The main revenue of Apple comes from selling devices, not from the App Store. Therefore, they have incentives to lower the price of apps on the App Store so that more people will pay a higher price for their smartphones.

This should be another reason why we, iOS developers shouldn’t be able to use auto-renewable subscriptions “easily” for SaaS apps and don’t have options like paid upgrade on the App Store.

In this interview, Satoru Iwata talks with Nobuo Kawakami who started the company Dowango which is the popular movie streaming service called “Niconico douga” in Japan. Nobuo Kawakami’s insight is always very unique and he is the reason why I got into this interview.

Nobuo Kawakami explains that if the company creating the platform, it doesn’t build and sell content for that platform, then that platform is generally not going to be good place for content providers because the company creating the platform doesn’t have the incentive to sell contents.

Nintendo’s platform is a better place for content providers because Nintendo also sells their own games, and they have incentives not to lower the price of their content. This can also be true in some ways for Apple as they sell Final Cut Pro and other software for the Mac, but they pretty much release all of their iOS apps for free now.

Nintendo makes their platform to sell games, but Apple and Google make their platform for different reasons.

In my opinion, if the company creating the platform doesn’t care about content providers, the value of the platform will decline eventually. At this moment, many app developers still want to make apps on the App Store, since so many people keep coming to this platform.

Apple can ignore the whining from developers since the App Store is the best place to do business for now, but I believe they could attract more developers who can create great things by improving their rules.

For example, the idea of changing 30% revenue charge rate based on developer sales is very interesting to me. Check out the blog article below.
An Open Letter to Tim Cook Regarding the App Store 70 / 30 Revenue Split

If they make improvements to the App Store in the interest of the content providers, maybe in the future they can attract Mario too? I have no idea, but I think it would be great if that happens.

-Thanks to Derek Lee for rewriting my English.

*I make an Text to Speech app, one-tap timer and more. About Me.

I released the simplest app I’ve ever made on the App Store

I made a redicuralsy simple timer app.

I made it since I had wanted the app like this for a long. It’s free, search for “ListTimer” on the App Store.

Download ListTimer Here.

※The language of the video is Japanese, but the app supports English too.

This is the simplest app I have ever made, but I created it because I personally want to use it.

Why did I make an another timer app?

I use the default iOS timer app very often, almost everyday. For example, I use it for setting my work time.

In this case, it’s ok to set 3 or 4 hours one time a day. However, if I want to set 3 or 5 minute timer quickly when I cook or do something, it’s a pain.

First, the tapping area on iOS timer app is very small, and you need to select your desired time carefully using that hard-to-use drum roll UI.

I have many situations in which I want to set a timer, but to keep using the iOS default timer app makes me tired everyday, and I wanted to fix it.

How about other timer apps available on the Store?

OK, I tried lots of timer apps available on the App Store myself first. I thought I could find the one suits me easily.

I was wrong, I could find nice apps which have lots of features, or looks cool, and are customizable in different ways. But, All I wanted was a simple app where I can set times very easily and keep using in the long run.

I needed a timer app focused on the part of setting times and starting it quick.

So, I researched on timer apps available, and how I can improve it to make the one I love to use very often.

In the end, I found the easiest way to set times is setting the time list from 1 min to 90 min from the first, and scroll it to start one of them with one-tap.

Every list height should be big enough to tap it comfortable, cool, this suits me best! This is great, simple is best, less is more! I don’t need the other features!

I showed it to my friend, and he said “You can’t set 1:30?”, but I answered calmly just like a king, “This app doesn’t need that, that is because I don’t need it”.

Honestly, I thought I might need to make it possible to customize times, but I can think about it later if this app becomes popular enough.

Background behavior

One problem, third-party apps cannot play audio like iOS default timer app does. This is the same for all third-party timer apps.

I enable Silent mode almost always so this is the most important part for me. If you disable Silent mode, it plays audio with notifications in the background though.

Therefore, this app sends several local notifications in a row to let you know the timer is done.

Local notifications vibrate your device even in the silent mode and background status.

By the way, it doesn’t consume battery power since it schedules a timer locally. It also works offline.

About App Store Descriptions

I like to try new things as much as possible for learning. This time, I have done a different approach on the App Store. Instead of writing the app description normal way, I wrote why I made this app over there.

It could be less boring rather than listing features one by one, oh, wait, this app doesn’t have enough features to list anyway.

I was worried about being rejected from the Apple reviewing process as claiming it as a too simple app, but maybe the reviewer read the descriptions and understood the concept.

Please try it out if you are interested in using the fast one-tap timer app.

Download ListTimer on the App Store here.

*I make an Text to Speech app, one-tap timer and more. About Me.

My competitor made my app promo video for free

Sometimes on the internet, I happen to meet cool guys. However, this time was exceptional.

Last month, I got a short message like this.

My brother and I had a company that built an iOS app similar (in functionality at least) to your app.

We haven’t had much traction and are planning on pulling it from the App store.

I’ve used your app, and it’s quite good.

That being said, I have put together some assets (media kit and video) that might be of use to you (just picture your app in the video instead of ours).

Let me know if this is something you’d be interested in and I could look at re-purposing the video and ‘story treatment’ for you.

I also plan to update our site (reedeo.com) to re-direct people to your app.

Best of luck.


My app Lisgo is a listen later app for Pocket users, and their app’s concept is same.

Honestly speaking, since there are many text to speech apps now, I didn’t know reedeo until he sent me the message, but I could easily tell they made a really nice promo video to explain the benefits of the app.

This is the original video for reedeo.

When I made Lisgo, it was really tough to explain the concept of the app, since most people said “I’d rather read articles, since it’s faster”.

I knew it would be nice to make a promo video for that, but I didn’t do that since it would take a lot of time and efforts.

I replied with thank you very much message, and I sent the free promo code for Lisgo.

Even though their app has a very similar concept, I know it still takes a lot of time to edit the movie for Lisgo, I couldn’t believe his kindness at the time.

Several days later, I got a message from him again.

I finished making the updates to the video, I hope you like it and can use it; here is the link to it on Vimeo.

Best of luck with Lisgo.

And, this is the video he made for Lisgo.

You can tell he didn’t just change some parts of the original video, but added extra scenes to explain the some best parts of Lisgo here. It’s awesome.

I was so impressed with his geniality, so I thought I should update Lisgo’s landing page at least to use this nice promo video efficiently.

It didn’t take so much time since I could use some codes of voicepaper page.

This is the previous Lisgo landing page.

スクリーンショット 2013-12-16 18.25.23

This is the new landing page look for http://lisgo.org/. The video must stand out compared to the previous one.

スクリーンショット 2013-12-17 21.00.05

Again, thank you David and your friends for taking your times to make the video.

*I make an Text to Speech app, one-tap timer and more. About Me.

How do you say No to users without annoying them?

It’s often said that you should listen to your users to improve your product. However, the reality is, it’s a really tough challenge, and I believe you need lots of practice and experience to do it well.

I still find it difficult to say NO to users, but I want to share my thoughts about this.

I feel bad about saying No to user requests

When I was watching the iPhone5s Apple video, Jonathan Ive said something like this.

We are as proud of the things we have said No to as the things we have done.

I believe this is really important thing for product design.

When your users request or suggest some ideas, usually, every one of them makes sense in their contexts, and I can understand why they want that in most cases.

However, if I execute every great idea, eventually, the product becomes messy one with lots of noises. It ends up being a product nobody wants by trying to make something everybody wants.

We should choose what to execute very carefully.

Having said that, even though I know the principle in my brain, when I get requests from users, it’s still hard to say No to them. Users like your product, and took their precious time to write something to you, but you have to say NO most of the times.

This is not easy.

When I read the 37 signals book “getting real”, I remember they say “It’s hard to say No, but you have to be good at it”.

As a Japanese person, we have a stereotype image about Americans that they are good at saying No. But, even if they think that is hard, for Japanese people who are really bad at it, it must be really tough challenge.

So, what can I do.

How do you reply?

So, how can I say No to users.

To people who took their time to give me feedbacks and requests, how can I reply? I always find it really hard.

For example, one person say like “I need this feature because..”, and you know that is useful, but you want to protect simplicity of your product.

Let’s say you explained like, “I understand the value of the feature, but I cannot make it since I need to add features which will be used for 80% of users at least.”

In this case, for users who requested the feature, it doesn’t matter if they are in the 80 % category or not, I might end up pissing them off by explaining to them with data.

I really want to say “I will do it in the near future!”, but making a promise about future plan is the last thing you want to do in product development.

You never know how your product goes, and you cannot avoid changing priorities of product often. If you make a promise, and turned out you couldn’t make it later, users would be upset.

Again, in the “getting real”, it is recommended to say “we’ll think about it” basically.

“Think about it”… this carried me back to my childhood when I was blaming Japanese politicians always saying “I’ll think about it” without promising anything. I now know why they needed to say in that way somehow.

Basically, I try not to promise anything to users, because I can never tell what I am going to do for my products in the future.

Even if I expect I would definitely implement one feature, I try not to say I am working on that.

However, I feel bad to say the same template sentences like a robot to users, so at least I try to understand why users request some features and explain my situations sometimes.

How do you say why?

It’s important to say “why” to understand the backgrounds of each requests well. Some people say we should repeat why, so we can dig into the needs behind the requests.

However, in the real world, it is easier said than done. Don’t you think you get tired if you are asked “why, why?” when you just request one feature?

In this case, I try to confirm reasons, just like, “you are requesting this feature, because you have this issue, am I right?”

I believe it’s less annoying to users instead of being asked with why, and of course, this attitude can minimize risks of implementing new features without knowing the real reasons behind feedbacks.


It sounds convincing when you say that “I cannot do that since I should protect simplicity of my product…”, but, it could not be a real reason for not doing something in many cases.

Sometimes, implementing some feature takes too much time, or I cannot see any corresponding benefit for the time. Especially when you are selling apps for a few dollars with one time purchase business model.

In this situation, it is much harder to explain this to users.

Having said that, it’s really worth listening to feedbacks from users as much as you can, since you can learn something you have never thought of. Even if you get opinions you expected, that means you are validating your hypothesis.

If you seek for feedbacks from nowhere, it’s gonna take a time to meet people which are your target users.

When they come to you and ask for something, this is a golden opportunity to learn a lot and get valuable insights.

Plus, you feel great when you see people who actually care about your product. This is why, I set a feedback box using Helpshift for Taxnote, Zeny, and other apps.

I understand you want to avoid getting support emails for apps when you stopped updating in the future, but, at least when you are working on that constantly, it’s worth putting a feedback box inside of your apps.

Related articles

This is a really good article related to this topic.

“Avoid Setting Publicly Visible Deadlines” part of this article.
Running A Software Business On 5 Hours A Week

37 Signals Getting Real. One of the best in product development.

I got an email from Gergana of SANSMAGIC saying this issue resonated with her. Her book about how you can reply to customers includes very detailed tips on this topic, and she shares her own experiences in the real world.

*I make an Text to Speech app, one-tap timer and more. About Me.