UX, mobile, freelancing, entrepreneurship

Choices and Consequences

I recognize that by writing this I may be disqualifying myself from some future CEO role. Will that cost me tens of millions of dollars someday? Maybe. Life is about choices. Right now, I choose to spend more time with my family and am confident that I can continue to have an meaningful and rewarding work life while doing so. At first, it seemed like a hard choice, but the more I have sat with the choice the more certain I am that it is the right choice.

You look at the CEO of a big company as a sort of “Superman”. He/she manages many ideas/teams/meetings/dollars. And yet he is human, struggles like everybody and makes hard choices. I am impulsive by nature but sometimes I feel that the more you struggle the wiser is the choice you make.

Simple Idea and Simple Design

I like simple, very much so. I usually tend not to publicize kickstarter projects on this blog, but this tool looks very interesting. How many times you had to slightly hear better the audio coming from your iDevice? Countless times I thought I could use something like SpeakerSlide. A video is worth a gazillion words.

Key takeaways for designers and product makers:

  • Solve a problem
  • Solve a single problem
  • If your product is simple, marketing is easier.
  • Simples allows you to focus on key aspects like price. 10$? Instabuy!

I really hope it gets funded, although there are just three days left. I am really thankful to the guys behind this because it’s a great source of inspiration.

It’s Not C, It’s the API

I’d like to order 10 pizzas”.

We have dough just for 5 pizzas, so we are gonna send you 5 pizzas plus a bunch of private data about other users that ordered pizza tonight”.

This is, in a very simplified way, the flaw behind Heartbleed. XKCD explained it even better, in slightly more technical way.

In my opinion the bug (which was introduced in this commit if you are interested) is not simply due to the code. Sure, as suggested in this advisory, the way to fix it is to change the code by implementing a bound check, but what I see it as a design flaw in the API. Notice that the client, when requesting data, wants a reply of a given length. Meg (the client) should never be able to specify the length of the response in the question.

When you call a 3rd party API exposed via HTTP you can ask ”give me the last 10 posts of user X” but implicitly you are asking ”if the posts are less than 10 give me those you have”. There is no server that, in case posts are fewer, fills the response up to 10 with someone else’s posts, unless the server guys are on drugs.

There has been an interesting discussion between Brent Simmons and Mark Bernstein.

My argument is that bugs like Heartbleed should be prevented by a better design of the APIs, regardless of the programming language.

Hit me on Twitter or App.net. I’d really like to know your opinion.

On Why I Am Not Gonna Buy Any Smartwatch

There are many rumors that Apple is designing a smartwatch, while Motorola has already announced moto 360. I work on a Mac, I have a few iPhones and also an Apple display. I am already hearing you screaming “fanboy”. According to your cliché I should line up as soon as Apple announces the alleged iWatch. Wrong!

Even if Apple is really going to ship an Smartwatch I am not gonna buy it. I quit wearing a wristwatch twenty years ago, when cell phones became popular and I am not gonna go back. For the record I don’t wear anything ornamental like bracelets, necklaces, earrings and even though I am married I don’t wear a ring (my wife knew that before we got married). Why? I am mimimalist and I like to “feel free”. A precious bracelet would require me to worry about it, like paying attention to not loose it, remember to take it off before the shower, etc. I solve the “problem” by now wearing it. The same holds for a wrist watch: I don’t need it. I always have an iPhone with me to check the time when I need, plus asking people around you is not a bad thing.

Are you gonna build a smartwatch? Are you gonna put in it a feature that simplifies my life? Like what? Let’s see:

  • mail notifications. I don’t care. They are turned off on every device I own.
  • tweet notifications. I don’t care. While I have push notifications turned on my iPhone I don’t let them distract me. I check them when I want/can.
  • payment system? I don’t care much. The time to swipe a card and put a signature is around 30 seconds most of the time. Are you sure you wanna optimize on that?
  • Fitbit-like tracker. I don’t own a Fitbit or the like. I walk enough and I burn enough calories every day. I “designed” my days to include walking or biking. If, in the future, I am gonna use one of those trackers I’d use one specific for the job, not one that tells you also time/weather/tweets/etc, thus not a watch.
  • I could go on …

When the iPhone was released I bought one because it solved a pain that I had. Browsing content on a mobile device was a PITA. I remember I used to take a break to smoke a cigarette and check RSS feeds. That was supposed to be a pause to stress out but when I was done I was more stressed than before. Authentication via WEP was a mess, font rendering was horrible and I don’t wanna mention how painful it was to select an item from a list. I had a problem, I presume many others were more or less on the same boat, and we all welcomed the iPhone.

Which pain point is a smartwatch trying to solve? I don’t see one. Do you? Tog has a long list. Every item listed in that post doesn’t look like a problem to me. That’s why I feel the iWatch might end up like the Apple TV (which I don’t own), a hobby.

I think it’s fair to say that Apple’s design process has been “pain driven” lately. Mp3 players sucked before the iPod. Smartphones were horrible before the iPhone.

Which pain is a smartwatch gonna solve? I don’t see any.

As usual I’d like to discuss it on Twitter or App.net.

On Naming Macros in Objective-C

Right after my latest post on naming methods with blocks my friend Murray asked for some feedback on the names for his collection of macros. Without even blinking I suggested ALL_CAPS, having in mind mostly the following macro by Apple


I think it’s pretty ugly to read but I guess it’s meant call out the fact it’s a macro. If you check UIDevice.h though, you’ll find the following:


#define UIDeviceOrientationIsPortrait(orientation) ... #define UIDeviceOrientationIsLandscape(orientation) ...


The first is all caps and the subsequent two are named like classes. Again, not even Apple is consistent in naming. So far I have seen many styles in different projects:

  • UA_invalidateTimer
  • NSStringFromBool

My take? The first looks like a method in a category and the second looks like a class or a C function. I’d stick with all caps, ugly to read (and type) but at least it clearly says “I am a macro”. And you? How do you name your macros?

Get in touch on Twitter or App.net if you like.

On Naming Methods With Blocks

Recently I have been very busy with the implementation of the BaasBox SDK for iOS and I had to come up with lots of method signatures. It’s 2014 and we all love blocks, so I used them quite extensively. When consolidating the upcoming version I noticed I wasn’t consistent with the naming. Some method was like this:

-(void) loadCurrentUserWithCompletion:(BAAObjectResultBlock)completion;

and some other was like this:

- (void) updateUserWithCompletion:(BAAObjectResultBlock)completionBlock;

Notice the different naming for the last part, the name of the parameter. Sometimes I even used the “Handler” suffix like this:

- (void) logoutWithCompletion:(BAABooleanResultBlock)completionHandler;

I am 100% aware that it doesn’t matter for the correct execution of the app. You can define a method like this

- (void) updateUserWithCompletion:(BAAObjectResultBlock)completionBlock;

and then implement it like this in the .m. It will perfectly work.

- (void) updateUserWithCompletion:(BAAObjectResultBlock)a {

      a(); // call block


Nonetheless, it is pretty likely you are going to use autocompletion to implement the method and a parameter named “a”, although working, doesn’t sound professional, does it? Anyway, my concern here is pretty much on the style, or aestetics if you like, which still matters to me.

So I popped a simple question on Twitter and I got an interesting set of replies.

One good point is brought up by Colin

No, if the second parameter were an int I’d not suffix with it. But when I teach I constantly have to explain to newcomers how to correctly read this method:

- (void)loadPath:(NSString *)path completion:(BAAObjectResultBlock)completion;

The source of the confusion is that “completion” is used both in the signature of the method and to name a parameter. In this case I am prone to write the method like this:

- (void)loadPath:(NSString *)path completion:(BAAObjectResultBlock)completionBlock;

so it’s more explicit. After spending a few minutes on this, as replies came in, I thought I should check up what was Apple’s take on the matter. A pretty known method is:

+ (void)animateWithDuration:(NSTimeInterval)duration delay:(NSTimeInterval)delay options:(UIViewAnimationOptions)options animations:(void (^)(void))animations completion:(void (^)(BOOL finished))completion

and, as you can see, there is no “completionBlock”. Then, how did I come up with it? Well, digging a bit more in the documentation it’s easy to find out. NSOperation for example has a property named completionBlock and so has CATransation. AssetsLibrary has a method named

- (void)writeVideoAtPathToSavedPhotosAlbum:(NSURL *)videoPathURL completionBlock:(ALAssetsLibraryWriteVideoCompletionBlock)completionBlock

The new NSURLSession class has

- (NSURLSessionDataTask *)dataTaskWithURL:(NSURL *)url completionHandler:(void (^)(NSData *data, NSURLResponse *response, NSError *error))completionHandler

and I could go on. Unfortunately there is no consistent naming, not even in Apple’s code.

So I went for what I thought made sense for me. Objective-c is verbose per se, people are most likely going to exploit autocompletion, and I like descriptive method names. That’s why I went with completionBlockin my code. I feel it makes everything more readable in general.

And you? How you do name your methods with blocks? Feel free to yell at me on Twitter or App.net.

Detecting Screen Brightness in iOS

I am a huge fan of small libraries that do just one thing but well. Sure you can detect when screen brightness changes by listening to the UIScreenBrightnessDidChangeNotification, but ASCScreenBrightnessDetector by aschndr is the right sugar on top of that. All you need is to create an instance, set a delegate and implement the - (void)screenBrightnessDidChange:(CGFloat)brightness; method, like this.

If you are already using Cocoapods, including it is a breeze.

I am gonna use it in Neater.

Objective-C Categories for Regular Expressions

I am not a heavy user of regular expression but I have tried this new library by John Wright and I find it very handy.

It basically allows you to write 75% less code. Here is an example taken from the Readme page

While I suggest to know what happens under the hood before using these kind of “shortcut libraries”, I am totally in favor of them when it comes to save yourself some typing.

So here is my general recipe:

  • get the basics right first
  • experience the pain of some API (I am looking at you Auto Layout!)
  • use (or even better build!) shortcut libraries/frameworks.

See you to the next library.

Building a Business Outside the App Store

Written by a solopreneur, this article is not just for solopreneurs, but for everybody noticing that something has changed in the App Store.


I must say it’s easy to stare at a shelf and complain about the price of a product. I did it many times and I still do it sometimes. Whenever I see a high price it’s kinda hard to not think the producer is cheating on me and charging too much. I have started changing my mind when I began building products, thus becoming the guy to makes the product that get placed on the shelves. I have always been a “what’s behind” kind of guy, trying to imagine the production process behind a product and making guesses on the production costs, but I have never been an active part of that process. Since 2008 I have been an active (and sometimes the only) contributor to digital product (mostly apps) and my perspective has changed radically. When I got started I thought designing and coding were the most stressing tasks, now I find them the most relaxing. Pricing, besides marketing, is probably the most demanding activity when I build a product.


App pricing is a kind of science. Finding the “right” (whatever that means) price for an app means dealing with a mix of competitor analysis, time you spent actually building the app, fixed costs to keep the app running, plus a surcharge to keep paying your bills. In the mobile community the discussion about pricing takes places every two or three months, usually triggered by some bold blog post or a report. A few months ago, Jury’s presentation and Cingleton 2012 was the trigger for the discussion. The morale was “we should charge more”. A few weeks ago the discussion has been revived by a Flurry report, whose conclusion is essentially: ad supported apps are the future. I totally disagree. The 90% of free apps mentioned in the reports includes apps with in-app purchase. That’s very misleading, but still a detail compared to what I am gonna say.

Applications in the App Store are too cheap and developers behave like they are doing a clearance sale. Hey guys, wake up! I don’t believe you didn’t spend at least a night pouring sweat to get that feature working as it is meant to be. If you did, and you are selling your app for free, look in a mirror and you will see a jerk. Raise the damn price of your app, do it right now. I am not saying that because you are ruining my market and forcing me to charge less. I really don’t care. Even if the conclusion of the flurry report were true (and it’s not), I could not care less. My goal is to build a long-term business and I think it does not get along with selling apps in a one-shot fashion. I was very glad to see that Apple charged a full price for a completely new version of Logic Pro. I was also very happy when the guys at MartianCraft charged 199$ for the Briefs app. Those are the prices I’d like to see but I realize both are complex and hard-to-build-solo Mac OS X applications. On the iOS side I know of a few solo devs that make a living off of the App Store. One is Loren Brichter. There are probably a few more, but I think it’s fair to say they are a handful.

Building a Sustainable Business

If you want to raise the sustainability of a long-term solo business, in my opinion you should not focus on the app. iOS and the ecosystem behind it has payed my bills so far (building apps for clients), yet I can’t picture building my core business on it.
We can’t beg users to help us fixing the price on the App Store. Customers pay because we make decisions on their behalf, and price is included in that bunch of decisions. The App Store model was devised six years ago and the options are still the same: sell apps one shot, use in-app purchase, include iAd. Six years is a century in the technology field. Apple has improved a lot of its devices and development tools. I am really thankful for that, but now we need a revamp of the App Store. They have had the guts to radically change the design of iOS with the seventh release. If some of that boldness is left, please invest it on a revolution of the App Store. If they introduce a recurring subscription fee for apps I’d jump on immediately. Let’s hope for that. In the meantime here is how I plan to build a sustainable business.

A Long-term View

At the moment I see two winning pricing models for a long-term business: consumable in-app purchases and recurring fees for a service. Both are aimed at getting in a situation where there is a constant stream of incoming money in the pockets of the developer. The first is probably best applied to games. The app is free, the first levels are free, to go on with the game you have to buy something recurrently, e.g. food for an animal, a virtual coin to build a new farm in a village, etc. People that get engaged with the game will progressively buy more assets. People who don’t like it won’t. It’s a win-win situation, in which you get the attention (and money) of those who care about your app. As “Underscore David Smith” points out, there might be moral concerns related to the way you sell consumables. At the moment I have no plans for games and this brings me to the other option.

The second way of building a long-term business is the one I prefer and keeps the core outside of the App Store. It is based on selling a service for a monthly or yearly fee. You can even sell the app (Instapaper did it), but the core thing is the service. Even if the App Store closed tomorrow you’d still have your service working and you could write apps for other platforms. Some services following this business models are FeedWrangler, Cheddar and Instapaper (all built by solopreneurs). Customers are billed for the service. The App Store gets wiped out? The service is still there, and you can use it via a web app. In this case the app in the store is just a view, a kind of accessory if you like. This model of business seems very viable to me, and has a series of advantages.

  • You are in touch with your customers. You can talk to them via email.
  • The income is steady. You are not selling a product once, you are selling a service recurrently. The customers that go for the yearly fee will give you room to improve the service and add new features.
  • The core is the API.
  • There is no 70/30 split. All you charge is yours (minus the maintenance costs of course)

There are also disadvantages:

  • You can’t be just the front-end guy. Either you partner with some server guy or you need some competence in server stuff.
  • the initial investment (either time-wise or money-wise) is a bit bigger
  • you have to deal with house-keeping stuff like invoicing and payment processing.

There is a third option, but it’s a very long run. The fact that Logic Studio Pro was a brand new application for which people had to pay the full price is a clear move. Apple is trying to educate people that upgrades are not free for life. Everyday new people that have never bought software are getting on board thanks to the iDevices and iOS. They will get familiar with a different pricing for software, one in which you pay full price for major releases. In my optimistic view this might take more than five years, and honestly I can’t wait that long.

Time to Broaden your View

Once the App Store was announced I was extremely happy, for a 30% of the income Apple managed payments, hosting and a part of marketing. A heavily guarded little place, where people went to buy good stuff, seemed a great idea. In the beginning things were great, like the in gold rush, there was some golden dust for everybody there on day one. Things have changed a lot since then. The App Store just had a face lift but it’s essentially the same. Competition has grown a lot, along with crappy released-once-and-never-updated applications. Like Adam and Eve, everything looked great in the walled garden. Now there are ways to cheat on search results.

Outside of the App Store, things moved on. We now have services like Stripe or Paymill that dramatically simplified the processing of payments. Web frameworks have improved a lot and allow you to build and refine a product very quickly. The price of hosting has plummeted. For example Amazon announced an 80% drop of the cost for reserved instances. Spinning up new server machines to enhance the performance of a web application is getting more and more easy.

Curiously, two of the web applications I have mentioned (Instapaper and Cheddar) have been sold. As far as I understood, in both cases that was due to the fact that running them as a solopreneur was very demanding. That does not mean the business model was wrong. Indeed, if they were sold it’s because the business model was working. You’d not buy something if it’s not well done and in good shape, right?

Growing up

All this considerations make sense if I also put myself in the mix. I undoubtedly changed. Six years ago it was ok to rush for one week, get an app in the store and cash in some money without any plan after that. It’s not my mindset anymore. I prefer to cultivate my business day by day, get in touch with people, talk to them, grow gradually without feeling the need to rush. Family changes you, for the better. I still enjoy rushes from time to time, I like the thrill of short deadlines to get the vibe of self-evident progress. But every step, in a hurry or not, is part of a bigger plan for a sustainable business.

You might wonder: why are you building Neater, which is meant for the App Store? Because App.net is an awesome platform, focused on enabling developers to build a sustainable business. They have a Developer Incentive Program which is a great idea to sustain the business of apps built on top of it. It’s the only platform that does that, as far as I know. That’s why I am building Neater. Just to be clear: it’s not for the cash per se. It’s for what an incentive program like that enables: a long-term view.

The rest of my efforts are geared towards a web application based on a subscription-based business model. I can’t provide many details at the moment. I am working on the infrastructure and experimenting with different architectures. I’ll keep you posted, don’t worry.

I know it’s weird but here is my suggestion: if you are a solopreneur, struggling to find a decent spot in the App Store my suggestion is … don’t do it. Don’t focus just on the App, focus on a core that can live even if the App Store is shut down tomorrow. Build a business.

I am happy to review my opinions if Apple revamps the App Store and introduces new business opportunities like recurring fees, although I have the feeling that most of the applications I have in mind will need a back-end, thus will involve some fixed costs for server, thus won’t get along very well with the one-sale-free-updates-forever model.


Here are a few articles that I kept around while writing this post:

As usual, I’d like to discuss this topic on Twitter or App.net.

On Excitement in the Apple Land

Last year I wrote about boredom in the Apple land. Essentially I said that we were getting used to the patterns adopted by Apple and that a stretched iPhone was built just to show off. I still think we didn’t need a taller iPhone but I definitely changed my mind about boredom.

It looks like Phil Schiller read my post and replied on stage with “Can’t innovate anymore, my ass”. That was just referring to the new Mac Pro, of which we had a preview during the last WWDC. Unlike the iPhone 5, a device that I bought because I needed to test apps, the Mac Pro is something I will probably buy even if I am aware I don’t need it. Why? First of all, because it’s cool. Second, I’d really like to have something more powerful (now I am working on a MacBook Pro). Third, I think innovations deserves to be nurtured and buying a Mac Pro is my contribution to that cause.

That was just one thing shown at WWDC. The one that has impacted my life most so far is the introduction of iOS 7. Here is Federighi’s implicit reply to my post: “Boredom, my ass”. iOS 7 is the most disrupting update since iOS 3. The latter has changed our lives, given us the possibility to build and sell native applications. iOS 7 is pushing us all (designers and developers) to start over. Craig Hockenberry has rightly compared it to the introduction of Aqua in 2000, a revolution. Believe me when I say that, in this exact moment, there are tons of developers and designers cancelling vacations and spending nights to revise all their plans.

I don’t know how many companies can afford to start over. Apple had done it many times recently: with the iPhone 4, the iPhone 5 and will do it again with the Mac Pro. Those are all “internal revolutions”. The teams at Apple were probably told: “forget what you know, get far away from your comfort zone, we start from scratch”.

With the release of iOS 7 Apple is asking the same of third party developers. Forget about the design solutions you are used to, forget about the interaction language we have used so far, start from scratch. And we are following along. I don’t know how many companies can afford that. Apple, for sure, can. Respect.

If you think it helps I will write more angry posts reporting boredom. My last one worked pretty good :)

Happy to discuss what you think of the Mac Pro and iOS 7 on twitter and app.net.

Now I gotta go back learning a new design language.