upbeat.it

UX, mobile, entrepreneurship

Percentage of Apple Watch Apps

How many watch apps are there? While searching for the answer I stumbled upon this report by AppAnnie. On June 8th there were 6,352. When I found it I felt it wasn’t a lot interesting. So I came up with a different question:

In the countries in which the Apple Watch has been released, which is the percentage of apps that have a companion Watch app?

I extrapolated some of the data that I have via AppVersion and http://canihazawatchapp.com and then I started crunching. The Apple Watch is on sale in 15 countries so far:

  • Australia
  • Canada
  • China
  • France
  • Germany
  • Hong Kong
  • Italy
  • Mexico
  • Singapore
  • Sounth Korea
  • Spain
  • Switzerland
  • Taiwan
  • United Kingdom
  • United States

For each of these countries I pulled the first 10 positions of the following ranks:

  • Top Paid
  • Top Free
  • Top Grossing
  • New Applications
  • New Free Applications
  • New Paid Applications

I didn’t pull genre by genre, so these are “top of the top”, essentially the first screen that you see on iTunes when you open the “Apps” section. All the data were pulled yesterday, June 29th.

I ended up with 1082 apps. Some of them are iPad only apps, for which you can’t technically build a watch extension. So I filtered those out and I was left with 939. How many of those have a Watch app?

… drum roll …

61

That’s 6.5%. I have mixed feelings about this number. Here is how I tried to rationalize it:

  • A good chunk of apps in the top ranks are pretty heavy graphics games, for which a Watch app probably doesn’t make sense.
  • It’s still early, I know many developers that have bought a Watch but it has not been delivered yet. They probably wanna test it on the device before submitting the app to the store.
  • The news about Watch OS 2 probably changed the plans of those who were planning to release a Watch app soon.
  • Everybody is cautious, the Apple Watch is a totally new device and requires some time to understand what people expect from this kind of apps.

I am planning to do some study like this genre by genre in the future. What do you think? Let me know on Twitter.

Sandbox Is Bad Sandbox Is Good

I love the Mac App Store, I hate the Mac App Store. The review system makes me angry, the review system makes my machines safer. I am a developer, I am a user, I am thorn.

You might have read a lot of posts about how it’s hard to make a living in the App Store. The most common reasons are the usual ones:

  • no paid upgrades
  • long review times
  • inconsistent rules
  • no access to customers emails

As a developer I perceive all these as obstacles to my business.

BUT

As a user, I love the App Store, especially the MAS. At least once a year I reinstall OS X on my machines, from scratch. Most of the apps I use are on the MAS and it’s a pleasure to click Get and see they just get installed. I have a few other apps that are not on the store and the installation is a pain as in:

  • download
  • find the key
  • enter the key
  • the key is for an upgrade
  • find the key of the previous version
  • enter the ley
  • activate
  • then enter the key of the new version

Some of those apps probably will probably never be on the App Store and I really need them, so I go through the pain. Fortunately it happens just once a year.

There’s more. You never appreciate what you don’t see or doesn’t happen. I think I never heard something like “Thanks to the Mac App Store I feel (a bit more) secure”. All the anger that the developer in me throws at the MAS was largely mitigated a few weeks ago when I read this bug report in Chromium. Chromium is the open-source project on which Google Chrome is based. The report is related to Debian, one of the most secure Linux distributions. The report shows that Chromium (Google Chrome for Linux) silently downloads a binary executable blob, by default. There’s a lot of speculation on the role of this “thing”. A Google engineer chimed in to clarify that the “thing” was just downloaded and not executed, unless the user turned on the “Ok Google” feature. Fair enough, but sneaky to say the least. Only a few hours ago we got the announcement that the download will be disabled by default. Oh, I forgot a little detail. The “thing” was supposed to record audio for the Ok Google feature.

[Insert your preferred NSA joke here].

Something like this would have never happened on the App Store, because the app would have been rejected right away. Especially now that Apple is putting a lot of focus on privacy.

And so here I am, even more thorn. As a user I keep enjoying the MAS. When I wanna buy a new app on the store I feel pretty sure, because somebody has checked it for me.

As a developer I should probably learn that those that seem obstacles are meant to protect users. It’s pretty clear to me that Apple lives by “users first, developers after” kind of principle. To be fair, if I were Apple, I’d probably adopt the same principle.

My WWDC Week Was About People

WWDC was two weeks ago. I watched some of the videos while I was in SF. I don’t remember anything, and I will watch them again.

What I remember vividly is the people that I met, so many and so passionate. I don’t remember what’s new in Swift 2.0 but I clearly remember who I met in SF, where and what we talked about.

The essence of a conference is not the new APIs or tools presented but the people you meet and the relationship you create or nurture.

If I had a WWDC ticket I’d have been worried to get the most out of it. Attending as many presentations as possible and asking as many questions as possible at the labs. Without a ticket I was free to organize breakfast with friends or to join somebody for a coffee, a hike or just a chat.
I am not saying there’s no value in a WWDC ticket, but with all the videos published on line so quickly, most of the value is in the labs.

The biggest value is in the side effect generated by WWDC. Tons and tons and tons of people that you usually “meet” online are in SF that week, in blood and flesh. And you don’t need a ticket to hang out with them.

Rob Napier on Taylor Swift and Apple

The web is full of unneeded and useless words about the “Taylor Swift convinced Apple with a blog post” episode. Among all the crap I found a gem, a post by Rob Napier

The difference is that musicians had a money problem and devs have a not-money problem.

The App Store is an engineering problem, not a money problem. Engineering problems are hard and messy.

And that’s why one artist can move all of Apple. Yes, she’s big and important, but she also brought a simple problem.

I agree 100%. Developers don’t have a money problem with Apple. I am trying to frame developers’ problems with Apple in terms of money, but the only thing I came up with so far is making the smallest price tier 4.99$. I feel it’s not gonna happen. I’ll keep thinking. Help me out on Twitter.

UPDATE: iMore has an interesting post about this topic but unfortunately most of the listed solutions are related to engineering problems. The only money related suggestion is reducing Apple’s cut. While it would be welcomed, I don’t feel it’s gonna solve the sustainability problem of indie developers.

My Plan for Twitter

Now that Dick Costolo stepped down, everybody has a plan for Twitter. So why should you read mine? Because it’s simple and effective.

We (developers) made Twitter was it is because of its APIs. Remember when 80% of iOS demo apps were a Twitter client? Yes, that was PR, for free. Now Twitter does not need PR anymore but it needs tools so that people can use it in a meaningful way. So what’s my plan?

Open up the APIs by loosening the tight limits (presumably) imposed to make Wall Street happy.

Developers are pretty far from the Wall Street mentality. We need tools to build products. Give us decent APIs, some time and Twitter will shine again.

If that’s not still clear let me make a concrete example. Change the APIs so that Manton Reece uses them again. That’s it.

Get Rid of the Ceremony

I am following the stream of consciousness started yesterday. I’ll talk about an attitude that has helped me to deal with the concerns before shipping AppVersion.

I am not a fan of ceremonies. There’s usually a “protocol” to follow. There’s something you can do and something you can’t.

I worked a lot on iOS apps. When you have to submit one, there’s a ceremony. I call it the “App Store dance”. Prepare screenshots, description, icons, keywords and then repeat for every language. You think you are done but then you need to upload the binary, answer questions about rating, encryption and then … wait till someone approves it. I feel kind of trapped, like wearing a suit during a hot summer day.

Sometimes the ceremony is in my head, in the form of the following (totally irrational) concerns:

  • If I ship this and then tweet about it they are gonna hog the server (I wish!)
  • I can’t ship now, it’s midnight, nobody is gonna notice
  • Maybe if I include this feature with that other feature the customers will perceive a bigger value

The truth is: none of that is relevant. People will read your announcements on the blog/mailing list when they can/want. Customers will notice the new feature when they stumble upon it. If you wanna “control the narrative”, write books or find a different medium. The web is asynchronous, fortunately or unfortunately.

That’s why I have come up with a simple ceremony for AppVersion:

  • does new feature (of bug fix) pass tests?
  • ship it
  • announce it (if relevant)

No waste of time, no complicated dances. As a user I appreciate products that get fixed/updated fast. It is a sign of taking care. I am gonna adopt the same approach for my products. The absence of ceremony fosters the idea that shipping is nothing special, it’s a normal action, much like drinking coffee.

And … it’s very liberating to roll out a bug fix or a new version without waiting for any kind of 3rd party review.

Do you have ceremonies when you ship a product? Can you get rid of (some of) them? If you ever write about this topic let me know on twitter.

Fear to Ship

You are ready. The servers are running, the credit card is a bit more empty, buttons are aligned as you wanted. You have waited for this moment. You are ready to press “Publish”. But you are not alone. Sometimes of the shelf, sometimes right on your desk. Fear. All kinds of questions cross your mind.

  • Will the server keep up?
  • Did I schedule backups?
  • Did I run all the tests?
  • Can’t I hold it a bit more?

I know, paranoia. Then I compared it with some other situation that I am comfortable with: traveling. When I travel I pack and I go, without looking back.

I asked a few friends about their concerns when traveling:

  • Will the luggage arrive at destination?
  • Will the train/bus/plane be on time?
  • Did I remember to bring the passport?
  • Is it expired?
  • Will the hotel/apartment be like in the pictures on line?
  • Will I get lost?
  • Will the bed/pillow be comfortable?

Most of the concerns come from people that travel less than me, and that is totally fine because they are less used to it. It’s exactly the point: getting used to it, to deal with the unknown and change your plans if needed.

So I took I deep breath and hit publish. AppVersion, my first product, is on line. I feel like the plane took off, I feel better, one less weight on the chest.

Now curiosity took the place of fear: how will it go? I am eager to know and I’ll keep you posted.

On Forcing

“You have to wash your teeth”.
“No”.

If you are a parent this might be a common scene to you. This happens pretty often with my kids when I try to force them to do something. Usually my technique to persuade them is argumentative.

“If you don’t floss daily you will probably have a bad tooth, that will hurt, and we’ll have to go to the dentist”.

It takes a while but eventually they understand.

I apply the argument strategy also with clients.

“If we do it the way it’s designed it’s gonna take ten more hours than planned. If we modify it like this we stay on budget”.

Some understand and accept the modification. Others “force me” to do it as designed, often because the design is bound to a contract signed with blood. I am not a fan of these situations but when I have to pay the bills I do it, clearly with a bit of reluctance. The reason is simply because they are forcing me without providing an argument or, if you like, the argument is simply “because we say so”.

Now think of iOS release cycles. There’s a new one every year and it forces everybody to update your apps at least once a year (but probably more often). Again there’s no argument behind this. Clearly Apple knows the rationale about this crazy pace, but we have no access to it. It sounds like a parent that says “you have to do this because I say so”. I swear that if the App Store were a place where you can still build a sustainable business I’d probably accept the yearly pace.

Then I look outside of the App Store. I see developers and small companies building sustainable businesses while deciding their pace. You are probably using some service that is built on top of Ruby 1.9.3, Postgres 9.0 or Ubuntu 10.04 and “they just work” (zing). Nobody forced anybody to update to a new version. You still might need to tweak the CSS to deal with some new browser release but if you keep the UI simple I am sure it’s not gonna take a long time. Not to mention that you can roll out your modifications instantly, without going through a review process (zing). Coding is just 20% of a product. The rest (marketing, support, growth just to name a few) deserves a lot of time which you shouldn’t spend updating your code to prevent crashes or weird behaviors due to a updated SDK/API.

Am I the only one on this boat? No. Somebody even quit because they couldn’t keep up with the pace.

Honestly, the complexity of every single thing we do has shot up in the last few years. My brain no longer has the time and energy to deal with Apple forcing me to relearn how to program every few years.

Icons Are a Language

Brilliant post by @designjokes. Some icons are verbs, some are nouns. I have recently written about icons and labels but I skipped the part about the grammar, which is covered in the linked post.

Icons Labels or Both

A few days ago I stumbled upon an interesting thread that started with this Tweet:

I studied semiotics so this discussion resonated quite a bit with my studies. I looked up some of the notes I took at the time and got back to the roots of semiotics, to the founder Charles Sanders Peirce. He classified signs in three categories:

  • Icon. It imitates what it stands for. It was exploited very well in the early days of user interfaces. For example the icon of a printer stands for the printer itself and thus represents the print action.

  • Index. Less coupled to what it stands for but still related. It is not “in place of an object” as the icon, but rather “points to an object”. For example dark clouds are index of upcoming rain. For a dog the whistle of the owner might be the index for “time to eat”. As you can see the link between the index and the object is weaker and related to a sort of statistical regularity.

  • Symbol. It is associated to the object by convention and repeated usage over time. There’s no particular correlation between the symbol and the object it stands for. A pretty common example is the eagle for the USA.

With this classification in mind we can say that:

  • the floppy disk was an icon, because in the past you actually had to insert a disk in a computer to save something. Now it’s more of a symbol, which by convention we associate to the save action.

  • the AT sign in the context of Twitter is a good icon, because its essence represents a reply to somebody.

  • the sign of an envelope is probably an index and can be ambiguous, in that different applications use it with a different “meaning”. In Mail on Mac OSX it means “get mail”, but in other apps like Tweetbot it stands for “direct messages”.

In user interfaces we tend to call an icon whatever is not a word. That’s a convention that we built over time but a quick analysis (as in the envelope example) shows that not every icon in a UI is an actual icon in the Peirce’s sense.

Should you use an icon, a label or both? These are my very personal opinions.

A label is the safest choice. Text is universal and also accessible on any platform by default. A label carries some cognitive load, because a user has to actually parse all the shapes of a word to make up the meaning, but still it’s the most generic means. For example when I prototype I only use labels. This allows me to avoid any distraction or tentative to start optimizing the aesthetics of the product while I am devising the “how it works”. Clearly labels need to be translated in different languages though.

An icon is the best choice if it’s an icon in the Peirce’s sense, that is if it’s closely related to the object it stands for. A printer for the print action or a pen to indicate write are both good icons. Some other signs are becoming symbols, on which we conventionally agree, for example the lens to indicate search or the avatar/silhouette to mean account/user. Unfortunately there are not many “universal” icons. Most have sense in a specific context, like the at sign in Twitter.

Icon plus label … well it depends. For example if the Mac App Store didn’t have labels I’d be very confused. The icon for the “Featured” tab is a symbol that is often used to mean “favorites”, whereas the “Purchases” tab shows an icon frequently used to mean “tags”. If your icons are not icons or symbols in the Pierce sense definitely complement them with labels. On the other hand, if you context is well delimited (like Twitter), you can probably get away with just icons.

Of course I am happy to discuss these opinions on Twitter. Hit me!