Posted by David Hamrick on

I’ve read several news stories about Coin, a card that aims to replace all of the magnetic swipe cards in your wallet and wondered whether it solves a problem that is worth solving?

I carry around a lot of stuff in my wallet. I have 3 credit cards, a debit card, driver’s license, health insurance card, car insurance card, a few business cards, and of course cash. Coin could replace all of my credit and debit cards, but I would still need to carry around all of my other items in a wallet. Is the goal of coin to replace my wallet or make it a little less thick?

I don’t use each of my cards on a daily basis. If I really wanted to slim down my wallet for a specific occasion—going to a bar perhaps—I could just bring my ID and one credit card. There isn’t an instance where I need to bring all of my credit cards to a specific place.

There may be some people who want to have access to many cards, and not have a hemorrhaging wallet. I hope that none of these people live outside of the United States, since the Coin won’t work there. Coin uses a programable magnetic stripe that can change on the fly, which should work fine in the United States. In Europe and other places around the world, credit cards use an embedded EMV chip that requires users to enter a pin number when their card is used. Coin doesn’t have this chip, so people won’t be able to use it where an EMV card is required.

The security aspects of Coin are interesting. If you leave your Coin at a restaurant table, the Coin smartphone app will send you a push notification once you have walked a certain distance away from it. You can also lock the card so that you need to enter a pin before using it.

Do people need to carry around so many cards that they are willing to pay $100 for a consolidated card? Will the security features lure people in? I personally don’t think that the problem is large enough, or the solution is good enough to make this product enter the mainstream.

Thoughts on Google Glass

Posted by David Hamrick on

Joshua Topolsky wrote a great article about Google Glass and what it was like to use. I think Google is making a great decision investing in such an innovative product. But will people like it, or want to use it?

Google Glass appears to use voice as the primary input device. This is a very large departure from almost every other consumer electronics device. While there are devices that use voice as an input device (Apple’s Siri, Google Now), they are generally an ancillary way to use the device. Will somebody feel comfortable talking to their headset on a bus, walking down the street, or in a bar? There are certainly other input methods that are possible. There appear to be buttons on the side of Glass (directional pad?) and you could use head tilts to navigate menus. And to input text you could use your smartphone paired with the device to act as the keyboard.

One of the primary use cases that has been highlighted in Google’s promotional videos has been instant 1st person video. This is a very nice feature for the person wearing Glass, but what about for the people around them? Will others be comfortable that at any moment a person wearing Glass could be filming them? There are certainly ways to solve this problem, something like a red light indicating filming that has been on camcorders for decades. There are also social consequences for newsworthy events. Instead of a person shoving a camera in your face, clearly indicating that they are filming you, they can now just stand there looking at you. How will police officer react to someone wearing Glass? It’s difficult to rip them off your face and destroy the tape when you’re on a Google Hangout and uploading your video for all the world to see.

I agree with the Joshua’s premise, that is not a question of if technology like this will catch on, but when. I can certainly imagine a future of having a heads up display in a contact lens, and this is a step in that direction.

Monday Morning Quarterback – Tweetbot for Mac

Posted by David Hamrick on

Last week, Tapbots released Tweetbot for Mac. They surprised many by charging $20, which many considered to be a high price for a Twitter client. Tapbots wrote a blog post that explained their pricing decision. Twitter recently changed their API policies to limit the number of individual user tokens that an application can have. Once a new application has 100,000 users they have to obtain permission to obtain more user tokens.

This means that Tweetbot for Mac has a constrained supply. The Econ 101 level theory of supply and demand would say that holding everything else equal, if supply is decreased, then the price will increase and a lower quantity will be sold.

Many users say that the price is too high for them, and that they won’t pay $20 for a Twitter client. This is exactly what you would expect to happen. If everybody was willing to pay $20, then Tapbots would sell their 100,000 copies relatively quickly and there would be a shortage for others users who wanted to purchase it, perhaps at a higher price.

Why is Tweetbot being sold on the Mac App Store?

Applications for OS X have an advantage that iOS application do not have. You can sell them directly from your website instead of being forced to use the Mac App Store (MAS). This means that you don’t have to pay 30% of your revenue to Apple, but only a small percentage to a payment processor.

First let’s make a few assumptions about Tweetbot’s userbase.

  1. There is no software piracy (There is)
  2. Each customer only uses one user token (They won’t)
  3. All users of the beta versions will purchase the full version (They won’t)

Tweetbot currently costs $20 per customer, with a maximum of 100k customers. $20/user x 100,000 users = $2,000,000. However, Apple charges a 30% tax for being in the App Store which would result in a theoretical maximum revenue of $1,400,000.

Is being on the Mac App Store worth up to $600,000 in lost revenue?

There are of course several reasons why being on the Mac App Store makes sense.

I personally do not think that any of these factors are important enough to give up that much revenue. Tapbots currently does not have a payment processor set up, but could set it up with Stripe or a similar service with a few days work. Similarly, the update mechanism could have been solved with a framework like Sparkle.

Being featured on the MAS can be big win for developers, and Tweetbot is currently the #2 application (behind Mac OS X Mountain Lion). The crucial question is whether or not Tweetbot would sell out it’s 100,000 tokens without having the Mac App Store. Perhaps it would take 6 weeks instead of 4 weeks. But having hundreds of thousands of dollars in additional revenue seems like it would be worth the wait.

Ultimately Tapbots knows what is best for them, and they decided that being on the MAS was a good decision. Hindsight is 20/20 and things would be much different if they had launched and nobody wanted to buy their app if it wasn’t on the MAS. Tweetbot is interesting because it has a limited supply, something that software rarely has. Do the normal rules still apply? We’ll have to wait and see.

Adding Properties to an Objective-C Category – Revisted

Posted by David Hamrick on

In my last post I wrote about adding properties to a category in objective-c. I have ended up using this feature quite a bit recently so I wrote a macro that will add the appropriate methods.

Before, when I wanted to add a category I would have to manually add the setter and getter.

@interface UIView (DHStyleManager)
@property (nonatomic, copy) NSString* styleName;

@implementation UIView (DHStyleManager)
@dynamic styleName;
- (void)setStyleName:(NSString *)styleName
    objc_setAssociatedObject(self, &kDHStyleKey, styleName, OBJC_ASSOCIATION_COPY);

- (NSString*)styleName
    return objc_getAssociatedObject(self, &kDHStyleKey);


Now, all I need to do is use the macro to create the getters and setters.

@implementation UIView (DHStyleManager)


All you need to do to use this macro is put this in a header file.

Adding Properties to an Objective-C Category

Posted by David Hamrick on

Let’s say you have a category that needs to store some information. Unfortunately you can’t add an instance variable, but you can add something called an associated reference. From the documentation:

Associative references, available starting in Mac OS X v10.6, simulate the addition of object instance variables to an existing class

To create an association you use the objc_setAssociatedObject function and to retrieve an association use the objc_getAssociatedObject method.

Using an associated reference as storage for a property

We can use this technique to make a built in class have a property that we want. In this example, I am storing the name of a style that I want to assign to a UIView.

When instances of UIView are released they will also release their associated references.

This technique let’s use set this custom property on plain old UIViews. If you only need to do something simple like add a property, this provides a nice alternative to subclassing.

David Hamrick is a partner at Hamrick Software, the makers of VueScan, the worlds most popular 3rd party scanner software.