Monument Valley & Developing for Android

I read an article on MacRumors about Monument Valley's sales numbers and revenue and thought it (again) proved a point I try to make to my friends all the time: iOS users and Android users are not created equally. The other thing I hear all the time that drives me crazy is that I should be developing for Android in addition to/or instead of developing for iOS. As a single developer shop, that's just the craziest advice anyone can give. Market share does not mean access to more paying users. It just means way more Android devices exist out there, which makes sense--Cell carriers push those devices because they get to load them up with junk, they're cheap to subsidize and they come with expensive data packages which is where the real money is for them.

As seen in the graphs on the MacRumors page, over 81% of their revenue came from iOS. Of the 2.4M sales, only 300K came from Android--and this is for a monumentally popular game that was featured everywhere. 

So for a developer like me, working for Capparsa, writing only paid professional apps for a B2B market, why would I waste my time writing for Android and trying to sell my apps in a market that just doesn't pay for apps?

You could say maybe I should just make it free for Android and sell ads but that goes against everything I'm about with my products. I hate ads. I think they destroy user experience. Also, for B2B apps, ads make very little sense. You'll never get the huge market numbers that you need for it become profitable, and nobody using products professionally wants an ad interrupting their workflow or taking up screen space. I understand that for some products ads are likely the only realistic way to make money but they're just not for me.

In either case, I'm glad more and more developers are releasing their sales numbers. Making a living off writing apps is tough without an underlying service layer to keep things more sustainable. It also sucks to live and die off Apple featuring you and the fact that the App Store app discovery is so terrible, but that's a whole other topic. 



Computer Engineer Barbie makes me want to quit humanity

Update (Nov 20): The Internet has won one! TechCrunch has reported that Mattel has pulled the book from Amazon. How it got there in the first place is still beyond me...

Even with the warning from others that this book (I can a Computer Engineer (Barbie)) is even more offensive than you think it's going to be, it's still more offensive than you think it's going to be. 

This is such a misguided attempt to show that Barbie (and more generally, women) can be computer engineers. I can't help but breakdown why this just so appallingly bad:

  • In their definition, a computer engineer is apparently someone who just sits in front of a computer and knows when it's on and when it's off.
  • As the article linked below highlights, she is only designing the game and needs her guy friends to actually create "a real game". Yes, because engineers are designers and don't actually code or create or do anything. There's no way a woman can code, right? I mean this is fiction but let's not get ridiculous, am I right?
  • Honestly, how is it still a thing that viruses are the reason for computers acting up? I can't think of the last time I got a computer virus, including the dark era in my life before OS X.
    • Computer viruses are what your non-technical friends think cause all their issues. "Oh my computer is super slow, so it must be a virus". No, it's not a virus, it's because you installed 500 Flash games that are all running in the background while you're actively watching Netflix and installing even more junk to put in your Internet Explorer toolbar.
  • She is apparently a great engineer because she keeps a USB drive around her neck. Any real engineer knows that USB drives are outdated technology, super insecure, and not a way to transfer data in the world of Dropbox/iCloud/Box/OneDrive/AirPlay/Literally any other way to send data digitally through the Internet or P2P protocols)
  • This whole book reads like a novel written by Norton Anti-Virus or Sophos. Seriously, how many times is it mentioned that computers need "good security software"?

I can go on but the article below really does a good job of ripping it apart further. Why isn't Barbie a full-stack programmer that is making her second or third successful app? Game or otherwise, why can't she be the lead developer of a team of devs? Why isn't it Brian that effs everything up and she's the one to fix it? 


Migrating Blog...

I'm in the middle of migrating this blog over to its new home at Squarespace.

I was on Tumblr but decided that since I primarily just write text entries, and also rarely ever reblog things, it just wasn't the right platform for me.

Plus, Squarespace's designs are just so pretty. I've been a customer of theirs with my company, Capparsa, for some time now. 

Check back soon for more updates!

Are payments the killer app for wearables?

I was having a great discussion earlier with my friend & co-founder of Capparsa (Omar) and he asked a great question: Are payments the “killer app” of wearables? In other words, is using your watch or wrist band or ring-pop to pay going to be the reason that people want to buy them?

It’s a very interesting question and one that I think the answer is a resounding yes. The problems right now with a lot of wearables, in my opinion, are that they:

  1. Are marketed towards gadget nerds
  2. Don’t really do anything all that useful
  3. Are making people focus on health and fitness when I think that’s a whole separate market than things like the Apple Watch.

When the Apple Watch finally arrives, I really do believe what will make owning one so compelling is the ability to use it to do things like checkout at retail locations, enter into ticketed events like concerts and movies, and board a plane. 

Right now the most personal piece of technology we own is our phone. It’s almost always with us, we’d rarely if ever lend it out to someone else, and with the TouchID on the latest iPhones, it’s so personal that only our fingerprints unlock it (1). We personalize them to an extreme, we put all our data and content on them, and a phone number is way more strongly tied to an individual than say an email address. (You can easily have multiple email addresses, if not an infinite number of them, but it’s considerably harder to have multiple phone numbers).

So a phone is a very personal piece of technology, and wearables (like the Apple Watch) are the next extension to that. A watch is something that literally wrapped around your wrist and won’t leave there until you’re asleep and you need to charge it. Just like your phone, you’d rarely if ever lend it to someone. You will personalize it, not just with the outer bands and faces, but also with all the apps and data you let it access. It will also read your heart rate, and presumably one day other biometric data.

Your watch becomes the technology identifier for you as a human. That’s where I see Apple going that other companies do not see yet. Others are viewing wearables as a gadget that can do a couple of cool things, or parlor tricks, but I think Apple is positioning itself as a personal technology company, not just a tech company. The difference is subtle but huge. They are not in the business of producing tech for the sake of it—they’re in the business of making you feel ownership and identify with your devices. Some people treat their iPhones like their children, and I think the Apple Watch is the next extension of that.

So we get back to payments and ticketing, and other identification forms. I recently heard in a great Podcast (Around the Coin) that one day he foresees us being able to wave our wrist on a door entry way, and it will open for us. Imagine this at lounges in hotels, airports, and other VIP areas. Or imagine having a line where you can wave your NFC watch to verify your ticket at a baseball game vs. a line where you have a paper printed ticket, and it’s backed up and taking forever. You create an experience where the individual *is* the form of identification— no additional paper or barcode needed.

That’s why I think payments will be the killer app of the wearable market. 

(1): Yes, you can also unlock it with a passcode, but once you set TouchID, you pretty much always use that rather than tap out your code.

Starting a Business 2.0

I recently read the (short) book Rework by Jason Fried and it really got me excited for what I’m working on. I feel very much aligned with a lot of what he wrote in the book—that you don’t need to kill yourself to start a company, you can work remotely, you can keep a small team, and you can do it all without raising capital.

I’m seeing the value of not raising money when wanting to start a project, and instead finding any way you can to self-fund. If you get the sales strategy down early, and can reproduce it and scale it, then you’re on your way to growing the company organically. I’m aware this doesn’t work with every type of business, but with software and how relatively easy it is to ship code these days, it seems like it’s the only way to go.

I’m lucky enough to be sitting on several products already in the App Store, some of which have been downloaded tens of thousands of times, and are all received positively. I recently began getting emails from numerous users of my TimeTag app that all reference how long they’ve been users—in some cases, since its launch in 2010!

It’s quite amazing to really think about that for a moment: People have been using the same app for over four years. Think about what apps have existed on your iOS devices longer than a month or a year. It’s great that people love my time sheet app as much as they do, and I’m happy to have kept up with it through the years—even as a full time student, and then working full time this past year.

Now I have the very wonderful opportunity to take some time to code it full time again and launch its syncing service, and then enter into the b2b space with it. I see a demand for it in the enterprise space (professional contractors, software shops, law firms, accounting firms, etc) and I’m eager to take a stab at marketing it to them. A lot of my users are people in this space, but they use it independent of their business because they like it so much. I see a real opportunity to take an app-only approach to time sheet management and take advantage of a lot of device-specific things, like TouchID to secure records, and geolocation to give you reminders if your timer is still running outside of a “geofence”.

In either case, it’s an exciting time. I’m lucky to live in a world where you can code from your home, on your personal computer, and press a button and have people world-wide see and use (and hopefully appreciate) your creation. It’s fun to create things.

Syncing engine for TimeTag

Syncing for TimeTag has been a long requested feature—and something I have wanted myself for the past four years.

I’ve written before about why syncing is such a challenge…and it still remains a challenge today. Tons of other developers of apps have written about why it was so difficult to make their apps sync with one another. Unfortunately, while the complexity hasn’t gone down, the requirement for apps to sync has gone up.

People are on the go, and own way more devices than they did in the past. They want everything to be “as they left it”, and without having to put too much thought into it. I agree with this—I’m upset when I have an app that I love that works in a silo from other copies of it.

So I finally sat down and got to work: I was determined to come up with a good syncing formula for TimeTag for the iPhone, iPad and Mac.

The database isn’t too complicated—in fact it’s pretty simple. It has time records, tags and categories. It always seemed like it should be easy enough to sync, but there were always tons of issues that popped up. Issues like:

  • Which record would win in the event of a conflict?
  • What happens if the user’s network is down?
  • How do you associate all the right records with tags, and the right tags with categories? (What happens if a tag is deleted, or a category changes color?) 
  • How do you deal with deleting objects, and not allowing zombies to come back? (infinitely re-generating items)

Things like that were always an issue. The very first attempts used a kind of looping algorithm that Compositions uses today. It goes something like this:

  • Pull down everything from the Internet
  • Get everything from the local database
  • Loop through all the online documents, and check for a matching local one. Figure out what’s updated, or if the local document is missing, and if it is missing, figure out why (like maybe it was deleted?)
  • Loop through all the offline documents, and check for matching online ones. If there is no matching online one, figure out if we need to upload it (or maybe it should be deleted?)
  • Loop through any conflicted documents that raised as a result of those two loops and do some final cleanup

As you can see, it’s a real mess. It works, but wow it’s buggy and prone to error. Today it’s pretty stable, but it wasn’t without months of work and a few upset customers letting me know a document was lost.

So that was the approach I wanted to take with TimeTag, but big surprise, it proved really prone to error. I was getting infinitely duplicating time records, tags that wouldn’t upset but instead create new copies of themselves, and zombie records (after deleting them, they’d re-appear everywhere due to how deleting/syncing works).

I needed a new way to do it. I still liked the idea of comparing local to online, and taking action on that, but I needed a much cleaner way to do it. Then the idea hit me: Why not create a wrapper object?

Since every record has what I call a “universal ID” that is supposed to be the same across every single device (and the cloud), I could use this as the way to match up records of any type—whether it’s a time record, tag or category.

I created a wrapper class, and did the following:

  • Go online and pull down all the online objects of type X, and stick them in a newly created wrapper of X
  • Pull the local copies of objects of type X, and attach them to the matching wrapper of X if it exists already (or create a new copy if it didn’t)
  • Iterate through wrappers of X

When I iterate through wrappers of X, one of three things can be true:

  1. Both the online and local X objects are there
  2. Just the online version is there
  3. Just the local version is there

If 1) is true, then I need to check edited dates and sync status markers, and update both as appropriate.
If 2) is true, then I need to update or create the local version
If 3) is true, then I need to create the online version

This proved to be a very reproducible algorithm. Once I got it working with categories, i was able to get it working with tags and then with records. Even better, as I began to reproduce the code, I was able to make it more generic and refactor a lot more of the code.

What I have now is a really cool syncing engine that uses Parse as a backend. It will update properly, login a new user and get everything just fine, and stay in sync with one another. It uses a model of “last in wins”, so whoever edited last will win out. Not always ideal, but it keeps the syncing model clean, and as long as users are aware of it, it should cover almost all cases/scenarios. As time goes on, I’ll definitely work on making it more robust to deal with conflicts.

What to do about deleted objects? Well, what I decided was the the best way to know something was deleted was to actually not delete it—but instead mark it as deleted. Then every now and then I can do a cleanup of old deleted records so that they don’t sit around taking up space for no reason. The benefit though is that you can now check if a record is deleted (because it says: Deleted) and remove it from devices. This makes it totally unambiguous that the user intended to delete a record, so you won’t ever incorrectly remove something that shouldn’t have been removed…and you won’t get re-created objects!

That’s all the detail I have for now. I need to get back to testing and implementing. I hope to have TimeTag sync shipping this month—first for iPhone and iPad, and then for Macs. Stay tuned for more updates!

Customers might not always know best

Here’s an all too common scenario.

A customer will email a company and say something along the lines of: “Hey, I like your app/product/service, but I’d like it so much more if it does this super awesome feature that is very important to me.”

Often, you read an email like that to mean something like: “Hey, build this feature, otherwise I’m going to find another app/product/service and use them instead!!”

So what do you want to do? The natural want is to go out and build it as soon as possible, of course! This customer is paying you money (hopefully) and the customer always knows best, right?

Well, no. And I’ve come to discover that this is why they don’t know best.

It’s not that you don’t want to build products that your customers want…you definitely do. If you aren’t building something to solve problems, then yes, people will eventually leave you and go to a competitor.

However, more often than not, these customers are asking for a feature that’s really only important to them. So, I suggest, wait on it. Or dig deeper. Why do they want this feature? What are they really asking for? Is it really the described feature, or is it because of some problem you can solve in another way? (Sometimes the feature actually already exists, but they can’t find it…which could signal a failure of your UI).

The problem with immediately jumping in and building what they requested is that it very dangerously assumes that individual customers know what’s best for all your OTHER customers.


You run an app that generates reports…like let’s say a time sheet app.

Customer Bob emails you and wants you to build a new exporting format for his business, because that’s how he runs his business—it has to always be in a particular format. But what if Bob is the ONLY business that works with that format? You would have spent the engineering and design resources to build that feature, test it and ship it…only for Bob to be happy, and for thousands of other customers to look at this new export format and say: “Huh?” [Or maybe you just have it as an ‘option’…but now you’ve added complexity to your app needlessly. People need to decide what type of export format they want, when in reality they just want to export it].

So what can you do about it?

As I mentioned, I think there’s real value in sitting on suggestions (at least for a few days). Maybe more emails will roll in and more people will suggest the same or similar thing. What I do is actually put every suggestion into my Wunderlist app, in a special list for requests. As more requests come in, I’ll add notes to the ones I see repeating. Even then I’ll evaluate it—does it fit? How do I make it work, given the scope of the product? Does it make sense for what I believe in? [Because honestly, sometimes you just never want to build that feature or fulfill that request, because it’s just not what you’re about].

So, all the times that people say “it’s about saying no more than saying yes”…what I really think they’re saying is that be smarter about what you say yes to. Maybe you get 50 great suggestions, and you DO need to say yes to them. But more often than not (at least in my experience), you’ll get 50 suggestions, and only 5 are really worth doing.

Sit on ideas a few days. Dig deeper. Know your values and core product mission. Your customers (both present and future) will appreciate it!