Category Archives: Apps

What is hidden in positive statements

I just finished reading The Emotion Machine: Commonsense Thinking, Artificial Intelligence, and the Future of the Human Mind by Marvin Minsky It was a really interesting book which I really recommend. I would like to highlight this part from the first chapter “Falling in Love”

On the surface such statements seem positive; they’re all composed of superlatives. But note that there’s something strange about this: most of those phrases of positive praise use syllables like ‘un–’, ‘–less’, and ‘in-‘un-’, ‘-less’, and ‘in-’—which show that they really are negative statements describing the person who’s saying them!

Wonderful. Indescribable,
—— (I can’t figure out what attracts me to her.)
I scarcely can think of anything else.
—— (Most of my mind has stopped working.)
Unbelievably Perfect. Incredible.
—— (No sensible person believes such things.)
She has a Flawless Character.
——(I’ve abandoned my critical faculties.)
There is nothing I would not do for her.
—— (I’ve forsaken most of my usual goals.)

Positive statements might hide what we really are thinking about. Did you heard in a wedding someone saying “He’s a very lucky man for marring her”? What that person probably meant was something like: “He’s lucky because I can’t understand how a woman like her could marry a man like him” or “He’s lucky because she could find a better man”

Reading about iOS7 Design Resources in the iOS Human Interface Guidelines I found a similar approach comparing iOS 7 and iOS 6. Look at the screenshot:

ios7ios6

This looks wrong. One thing is to talk about the improvements of iOS 7 and the changes they made, and another thing is to trash your previous product. They are not doing it explicitly, but they are doing it indirectly.

  • Deference. The UI helps users understand and interact with the content, but never competes with it. (The previous design competed with the content and wasn’t clear)
  • Clarity. Text is legible at every size, icons are precise and lucid, adornments are subtle and appropriate, and a sharpened focus on functionality motivates the design. (Icons weren’t precise and adornments were not appropriate)
  • Depth. Visual layers and realistic motion impart vitality and heighten users’ delight and understanding. (Previous design lacked vitality and was hard to understand)

These three positive statements would be just fine if they were announcing iOS 7 as a new product for the first time. In that case the listener wouldn’t have a previous model to compare with and would use the hidden negative statements on the competition. But comparing in this way your current product with the previous one is just trashing your previous work. That damages the credibility of what Apple continually claims about their products, depicting them as the best in the market. How could they say they have the best Mobile OS if they are trashing it when the next version comes out.

I think that the right thing to do should be to avoid direct comparisons between your own products and only point out the evolution, the improvement, the new features instead of sending subliminal messages to costumers saying “today we sell you gold and tomorrow we will call it shit”.

The challenge of user interfaces simplification

iOS 7 is here. I’ve been using it since the first beta. As far as user interfaces are effective, I don’t care too much about aesthetic, also because it’s totally subjective. What is ugly for you is beautiful for someone else. In a previous post I shared a couple of screenshots showing the difference between icons in Xcode 3.2, 4.6 and 5.0. You can see a progressive simplification of the interface. First flatting colors then flatting depth. The challenge with this design is to avoid reaching the point of maximum simplification. Let’s look at the icons in detail:

simplify

Symbols don’t have any meaning by themselves, we give meaning to symbols and icons which simply are symbols, ideograms, pictograms. If we keep the design around the first icon on the left, it’s possible to change its look without changing its meaning. It’s not a practical need, but an aesthetic one, and I understand that’s more a marketing choice than a practical one. Even if nothing really changed inside the application, a new look gives you the idea that you have a new and fresh product.

The problem with the icon on the right is that simplification reached the limit. It’s so simple, so minimalist, that a change of its design means also changing the symbol and therefore removing the meaning. Symbols are powerful and that’s why many people over the years in history tried to steal symbols and change their original meaning, like the the Nazis did with the swastika. We should avoid changing symbols too often, because that removes semantic consistency in the interface and creates confusion.

Another example:

simplify02

The icon in 5.0 is a simplification of the correspondent in 3.2. The icon in 4.6 is a change in the previous symbol, creating confusion and inconsistency. Then they changed it back again to the original one. The new one has very little room to evolve or change without changing the symbol. It’s the extreme simplification of the original one.

I think that iOS 7 and the OSX interface and design are great. They are simple, effective, intuitive and fun but over simplifying hides the potential risk of reaching a point where simplification cannot be accomplished anymore and the only possible choice is changing the symbol, therefore breaking consistency.

I’m curios to see if, at this point, they will be able to update the design in the future without breaking the symbolic consistency.

OSX flat design doesn’t mean cryptic.

Xcode 4.6.x had already some sort of flat design. They removed the colors and everything was flat and grey but at least it had some sort of depth. Look at these screenshots:

Xcode 4.6.x

xcodeorg01

xcodeorg02

Now look at the new Xcode 5.0 flat design. I don’t see an improvement. It looks like an old fashioned GUI of the 90’s. It’s even hard to understand what the icons mean. It’s so abstract that someday we’ll need an ideogram dictionary to understand what those icons mean.

Xcode 5.x

xcodenew01

xcodenew02

Now look at a very old version of Xcode 3.2.x and tell me which one do you prefer. Honestly I don’t see an evolution in the look and design from colorful and self explanatory icons to cryptic flat ones. Flat design is not bad and it doesn’t even matter if it’s flat or not. The point here is that an user interface should be self explanatory, an icon should be worth a thousand words.

Xcode 3.2.x

xcodeold01

xcodeold02

Devobots available in the App Store!!!

Finally DevoBots is ready for sale in the App Store. Download it here!!

DevoBots App Store

DevoBots is a robot builder and a music synthesizer featuring unreleased Devo music & sounds from their archives. DEVO is an American New Wave band formed in 1972 and since then it has maintained a cult following throughout its existence. It’s not only for DEVO fans, it’s also a nice toy for adults and children, allowing you to create a huge number of robots accompanied with electronic loops recorded back in the 80’s with analog synthesizers.  Continue reading

Precautions before creating a server dependent mobile application

A server costs money. Not only the monthly rate you have to pay to keep it alive, also maintenance and system administration takes time, so it takes money.
If you plan to develop an app that uses a server to read/write data, be very careful and before starting anything, take into account these considerations.

  1. Does your server need HA (High Availability)? How to know that!? Does your application need to connect to your server to operate? In the answer is yes, you need HA! That means that your application, to do what it has to do, needs to be able to connect to the server. You can’t prevent when the user will do that and the last thing you want is a bad rating and some complain in the App Store.
    HA is more expensive than conventional systems. It’s more difficult to configure and to administer. If you don’t have experience as a system administrator, and you have a great idea for an app that needs a server to work, think about partnership with a good friend with experience as sysadmin.
  2. Is your server able to scale? What about if your app is a great success and your current configuration is not ready for the overload? Even if your app is great it can become a great deception for the users just because your system wasn’t able to scale when it was needed. Remember, the user doesn’t know and doesn’t care about technical issues. For the user all technical explanations are just excuses. So try to avoid to be in such situation.
  3. Is your app a paid or free app? If it’s a paid app, think about including in the price, not only the expenses to maintain the server. Think also about the expenses for scaling! The same reason of the previous point. Maybe you need to provide 2xTimes or more the performance of your current system. That will cost you money and you have to include that expense in your app price as well. It’s important to plan for an eventual future scenario. It doesn’t depend only on how many times your app was downloaded. How will people use the app? Does it help on common repetitive daily tasks? Does it make intense network use with the server (for example a photo sharing service)? The amount of data to read/write, just text? multimedia? It’s not easy and a mistake can costs not only money but also reputation and bad ratings.
  4. If your app is free, well good luck! It’s a free app and the number of downloads could be huge. Who is going to pay for the server?? Ok you can use ads but remember, a paid app will cost a specific amount of money that you can control. You know exactly how much money you will get for each app and that makes prospection easier. For ad-based apps, you know you will get paid but you don’t know how much and when. If a customer buys the app, he paid for it in that very moment. Even if he’ll never use the app again, the transaction has been made and you got paid. For ad-based ones, maybe he will start using the app next month or never. So risks increase for server dependent free-apps.
  5. Even if your system administrator is a guru, as a developer you have to think about the possibility that your application architecture could create some constrains if time to scale comes. So the whole plan has to be discussed with your admin as well.

Just try to think about how your system will react in case of the worse and best scenario. Don’t let you go only by the enthusiasm of your idea. Keeping a cold mind, will save you from bad headaches.

Making your app free or paid

Before making your app free-ad based or paid, or both, it’s better to spend some time thinking about how people will use your app.

Ads need a network connection and need to be visible. Your app has to be used under this two circumstances. So, the perfect app for ads is an app that needs to connect to Internet and that the user spends a lot of time using it. Apple has two common business models for ads: “Cost Per Mille” (CPM) which basically counts impressions, that means views. You get money just because the user views the advertisement. The other model is “Cost Per Click” (CPC). You get paid only when the user interacts with the iAd banner (the ad). So, more time using the app, more time seeing the ads or eventually more possibilities to interact with the ads = more money.
For example, news, blogs, feeds, entertainment and social networking are perfect apps for ads. The user will be connected to Internet, and will spend time everyday using the app. For Games, it depends. If it’s a simple game, that people use in dead times, you are sure that they will use it several times per day. In this case, ads are convenient. For more complex and time consuming games, people usually play them when they have time. This doesn’t happen quite often. So, making a more advanced game and the revenue from the ads, maybe is not worth the effort. There is a difference between free time and dead time. I’ll explain it later.

There are applications that the user wants to have but don’t use them everyday or many times per day, like reference, productivity and tools. For this type of applications, following the paid pattern is better. For example take Photographers Rights. If you are a photographer, you may want to have this app because you never know when you will need to know your rights in another country or in your own country as a photographer. For this reason, Photographers Rights App is a good reference, and a must have for a pro photographer. However, it will be used on specific situations. That’s why making it free with ads is not the business model for an app like this. It follows the paid app pattern.

It’s important to understand the concept of free-time and dead-time. When you are in the train, waiting for an appointment, lunch time, quick break in your job, waiting in the airport and so forth. Those moments are forced inactivity moments. You have to stay there, doing nothing more than just wait. Instead of wasting our life as plants doing the photosynthesis with artificial light, people always try to do something during those short periods of time. That’s dead-time. You didn’t plan for it, and it’s imposed to you by the circumstances. You usually don’t know how much time will take a dead-time period. That’s why those dead-time periods are perfect for a time-free app (I’ll talk later about time-free-apps and time-fixed-apps). Dead times are perfect for ad based apps. People have countless dead time periods during the day and that’s the moment they will look for some app to spend that time with. For example, reading a blog, playing a simple game, using social network or checking some rss. It’s OK to interrupt these activities at any moment. You really don’t know when the dead time is going to end, so you also don’t know if you will have full concentration during that dead time. Perfect to put ads on them.

Free time is different. You know when you have free time and you usually know how much free time you have. During free time, people will, eventually, decide to use a more immersive app. In this case I think that ads based apps, like reading news, blogs, rss, social media, multimedia entertainment, are more profitable. The user can use them in dead and free time as well, because the user can spend more than one hour reading news or just 5 minutes. On the other hand, games played when you have more time ahead, usually are more immersive, complex and content rich. In that case, maybe it’s better to go for a paid model. People willing to spend time playing games, usually spend money on games. Ads, in these cases, are a distraction that nobody want to see. Remember people hate ads! So, usually an ad is accepted on something they don’t give a huge value, like a time-dead app.

All this is related with other two concepts: time-free-apps and time-fixed-apps.
Time-free-apps are those that you can interrupt at any moment because the task never ends. For example, reading the news. You can read them later as the process of reading news “never ends”. Everyday you have more news to read. Watching a movie also is a time-free activity, you can interrupt and continue it at any moment. But time-fixed-apps are related with activities that you cannot interrupt without loosing something. For example, even if every app can be stopped at any time, nobody likes to stop a game in a very important moment. If you are a game player, how many times did it happen to arrive to the destination station, and get out of the train and keep playing? Players also hate to receive a call in the most exciting-adrenaline-consuming moment! Think also about edition apps, from writing or image editing, which, in reality, are time-fixed apps. You start writing and at a certain point the concentration flow is full. If you interrupt the process in that very moment, it’s hard to come back as fresh as you were before. That’s why, usually time-fixed apps are used during free-time and time-free apps are used during dead-times.

Of course it depends on everybody. There are people able to dictate several letters at the same time, like Napoleon. But those cases are exceptions. Usually people loose concentration very easily.

To conclude:

During free time, people tend to use time-fixed apps and not always an ads based model makes sense. Reading news, rss, blogs, social media and entertainment are the best for ads because those apps can be used during dead times and during free time.

During dead-times, people tend to use time-free apps, that they can interrupt at any time and continue later on. Furthermore, simple apps that are just less boring than waiting staring at a wall, go under this category. These apps are good for ads, because people have countless dead-time moments.

I didn’t want to use the the terms of synchronous apps and asynchronous apps, for time-fixed and time-free apps. Mainly because all apps in a phone are asynchronous. The user can always interrupt them and come back to the same point later on. The synchrony is just psychological, not related with the apps.

This has nothing to do with LITE apps. These apps have a different approach. When to use ads on a LITE app or create a LITE and a Full app is a topic for another post :-)

Best iOS development books and references

After reading many books about iOS development, these are the ones that I found most useful and enlightening. Apple documentation is very good as well, but, unfortunately, they don’t have an easy progressive path. It’s more like a modular, self contained reference repository.
Learning how to program for iOS is a huge topic that not only requires understanding of a concrete programming language and a framework, it also requires the understanding of the philosophy behind Apple products. Coding of iOS devices also opens the door to learn how to program for MacOS X as well. If you are a Windows developer, this is a great opportunity to learn how to code on a powerful UNIX platform.
I strongly recommend to read these books or at least, try to use them as a point of reference to understand what you need to learn to create a strong base that will help you, coding any application you want, and also saving a lot of time while being more productive and taking advantage of this technology.


Programming iOS 4 is, by all means, the best book I’ve ever found about iPhone/iPod/iPad development. It covers almost everything. For more esoteric stuff you have to search your way in Apple documentation, but this book will give you a clear understanding about the whole picture. It’s a dense book, with a lot of content. If you are looking for a quick guide, this is not the book for you. Anyway, if you plan to do something serious quick guides or for dummies series are not for you either.


For a more practical approach, Beginning iPhone 4 Development is like a quick reference and a learning guide at the same time. It’s really practical and has ready to use code recipes for most common patterns, such as: navigation controllers, pickers, table views and so on. This is not the book that will give you a strong understanding. For that you have Programming iOS 4, which is much better, in that sense. Anyway, I recommend Beginning iPhone 4 Development, I used it a lot and I still use it when I forget how to use common controls.


You have to read Programming in Objective-C period! The content of this book or an equivalent is essential. You can go ahead taking a dummies series and build an View Based app or a Table View app, but if you want to do something different, you will have no idea about what’s going on without Objective-C.


Learn Objective-C on the Mac covers the same content as Programming in Objective-C, but from a more practical approach. I recommend both. In fact they complement each other. Anyway, Programming in Objective-C gives a more deep theoretical explanation of the language. Believe me, you’ll need it!


If you only plan to code for iOS, you won’t need Cocoa Programming for Mac OS X. This is the best book to learn Cocoa I’ve ever read. It gives a little approach to iPhone development as well, but its main purpose is MacOS X platform. The App Store is available also for Mac, so it’s not a bad idea to learn how to code for Mac as well. Anyway, you need a Mac to develop for the iOS, so I think it’s a good idea to master these skills as well.


To be honest, Head First iPhone and iPad Development was a very big deception for me. The Head First Java and Head First Design Patterns are amazing books. But don’t let the reputation of those books influence your judgment if you plan to buy Head First iPhone and iPad Development. The book is too practical, so practical, that it’s like a funny recipe book that you can use to build apps similar to those explained… but nothing more. Table Views are a topic of tremendous importance. It’s a pattern that you can use to build countless applications but, for some reason, the topic is not deeply covered. Just to mention an example, the book spends several chapters talking about a Table View based reference application (a drink mixer) but it didn’t cover how to create hierarchical tables in a proper way. I expected more from this book, based on the great reputation that Head First series has. I found several erratas as well.

To end with this post, here you have these good online references. The one that always you have to give precedence is Apple official documentation, so I suggest you to read as much Apple docs as you can. Specially HIG (iOS Human Interface Guidelines). If you don’t follow what the HIG says, don’t complain later if your app is rejected in the App Store.

Apple documentation staring point.

iPhone Dev SDK Forum

iPhone SDK Articles One of the best code examples and references out there.

Stackoverflow well, you know it! :-)

To conclude. If you plan to develop and sell apps for iOS, you will sooner or later join the Apple Development program. The forums in the portal are a huge, amazing source of information. It’s an amazingly active community. I’m sure you can find an answer for your problem in those forums.

Let me know if you have more suggestions, links and books you would like to mention.
I would love to hear about good book titles for developing games by the way :)