When you apply some relativity equations to atoms, you get results that are not supported by experimentation; and the same happens when you apply some quantum theory equations to objects like planets. It is not that all the relativistic facts do not apply at micro level, or that all quantum facts do not apply in macro level; it is that there is no unifying theory that explains everything, and this quest is the graal of modern physics.

Fast-forward 5 years.

One of the facts I vividly remember of studying Economics in university (this time in Buenos Aires) was a certain disconnection between Microeconomy and Macroeconomy. The models that describe the behavior of the consumer (which is the heart of the study of Microeconomy) yield wrong conclusions when applied to issues like unemployment, foreign trade or other matters that are usually better explained by Macroeconomy; and similarly, well, you get the picture.

As a matter of fact, my Macroeconomics teacher would say that whatever we learnt in Microeconomics class was wrong, and that he had the right answers; of course, the Micro teacher told us the same the year before.

Fast-forward 5 years.

One of the facts that I vividly remember of studying Computer Science during my master degree program was a certain disconnection between small and big software projects. What works in small, simple applications and systems, including human and technical factors, does not usually work in bigger, more complex projects.

It is not the same to work on a startup project with some friends in a garage to create the next social networking site, where coordination is easy, most of the tools required are available for free, where the projects rarely have any dedicated quality assurance team, than working in, say, a bigger organization like Microsoft, together with other 1500 engineers and testers, all dedicated full time to writing and testing the next version of Windows.

The hardware requirements are not the same, either; in small projects you could use a couple of Mac Minis and a cloud hosting service and you are done; at Google they have MapReduce and a couple hundred thousand computers in a datacenter with air conditioning and security 24/7, and they still require more infrastructure every day.

However, and this is my main point, there is no proven recipe that can help a company grow from 10 to 10’000 people and from 10 to 10 million customers in a snap; there are some good techniques and principles, here and there, to make your software grow; but nobody actually knows of a generic recipe for every software company.

There are so many factors in macro problems, that the interaction of those factors has to be taken into account; not only the factors themselves, but also their interdependencies. I guess you see where I am going with this. This problem is usually called scaling in computer circles, and I think that the word can be applied to economy and physics.

As humans, we have trouble scaling. Scale is important in our eyes, because we tend to think that bigger is better. Bigger is more money, in general, but not necessarily better; we have trouble going from small to big and vice versa. Not only in facts; also in concepts. We cannot foresee the implications of scaling. At least, not completely, and not so far.

This disconnection creates lots of problems in our society. Politicians forget the human being altogether, buried beneath tons of numbers and statistics. Voters do not understand that managing a country is not like managing your household economy. Schools do not teach how to solve scalability problems; heck, they do not even properly teach kids how to work in teams to solve small, micro problems.

Small companies do not understand that scaling is neither automatic nor a required process, and that not all companies should grow; some companies work better when small than when they grow up, and that’s why they sometimes fail. Venture capitalists that are not familiar with technology cannot understand this fact, and will sometimes sacrifice good working teams for just making more money or for getting into the stock market.

The knowledge we have about the problem of scaling is limited; I actually sometimes ask myself whether there is a solution to it, that would justify the search of a global theory in physics, a unified theory in economics, or a generic scaling procedure for companies and software systems.

I do not have the answer; the fact is that size matters, and that this pattern has to do with the world we are living in; it does not matter whether you are a physicist, an economist or a programmer; this is how the world works.

If there is something that MoMA can make, is to boost your imagination. Anything is possible; the myriad of options for the expression of human creativity has no end, the mind boggles.

My dream has been, for years, to explain software, its intricacies, to make this part of our world accessible to anyone. Software rules our world, it is one of the most complex creations of man, yet it remains understood (albeit partly) by just a few.

There are many dimensions to software; the first to explore is size. When you tell anyone outside of the field that Windows 2000 took 5 years to a team of 1400 developers to complete, and that the whole thing is about 29 millions lines of code, it is still not enough; however, if you printed the whole code of Windows and put it in a series of books, how many books would it be?

On Kawara has created a piece called “One Million Years”, on display at MoMA; the whole thing is a series of books where the pages show, one after the other, as the name implies, one million years.

At 80 lines per page, at 1000 pages per volume, the source code of Windows 2000 would take… 363 volumes. Given that the Encyclopædia Universalis or the Encyclopædia Britannica consist of 20 or 30 volumes each, we are talking that a single company has been able to pull 12 encyclopædias out of the hat for a single version of a product. I’m not talking about quality or other characteristics; just size, raw and simple.

That’s the magnitude of software. Now we can begin to understand the magnitudes, the cost, the implications.

Another magnitudes worth exploring would be cost, number of people involved, number of errors… Infographies would explain in detail the interconnections and the different dimensions, their relations, their impact. But again, the whole thing remains so virtual, so out of reach, so different of anything else, that we just run out of analogies in no time.

What other dimensions could be used?

1. 1992: QBasic
2. 1993: Turbo Pascal
3. 1994: C
4. 1995: Delphi
5. 1996: Java
6. 1997: JavaScript
7. 1998: VBScript
8. 1999: Transact-SQL
9. 2000: C# + Prolog
10. 2001: C++
11. 2002: PHP
12. 2003: Objective-C
13. 2004: Visual Basic.NET
14. 2005: Ruby
15. 2006: LINQ
16. 2007: Erlang
17. 2008: Python
18. 2009: Go
19. 2010: Lisp
20. 2011: Haskell

The trend has roughly been an evolution from procedural during the 90′s, to object-oriented ones at the beginning of the 2000′s, and finally to functional languages right now.

And thus I realize, I’ve been programming for 20 years this year, 15 of which for a living.

1. Consulting
2. Products

When doing consulting, you write code, and somebody else owns it; you are blamed for its bugs, rarely praised for its benefits, and usually you only sell one copy of your work. When working on products, you write code, and you actually own it; you can brag about it on your blog without pissing anyone, and if you are lucky you sell as many copies of it as you want, all for basically the same production cost.

Now, here’s an insider tip: if your objective is living a nightmare, tearing yourself apart and swear never touching a keyboard again, choose option 1. If your objective is enjoying a healthy life, making money and living long and prosper, choose option 2.

This fact is explained by economists as a “diseconomy of scale”: this means that fixed costs are very low relative to variable costs, which means that the cost of creating a new copy of your finished product is virtually zero. You only have to invest in the building, not on the replication. Actually this is not 100% true, because you should spend on marketing anyway, and you might as well add new features on the way, but the truth is that well-run software companies make more money than drug dealers, and guess what: software is an activity usually considered legal.

However, there is a tacit consensus in Switzerland, apparently, by which there can’t be successful companies doing software in this side of the world. And most companies choose option 1 above. Which has interesting side effects.

Consulting

Consulting, just like the airline industry, succeeds in one particular point: it pisses off everyone involved in it. Let’s be frank; clients are seldom happy of the end result, while consultants have to deal with horrible working environments (read: open spaces). The only ones actually enjoying this market are the (usually non-technical) owners of consulting companies, who take pride in the fact of selling an “expert” to a company for around CHF 1000 per day (much more in the case of SAP), while they pay less than CHF 300 to the same consultant. The remaining 700 go to “operational costs”, of course, including the bonuses paid to managers of these companies on the backs of the workers.

Welcome to “Capitalism 101″. You have to afford that new Porsche somehow.

Not only are consultants screwed from day one, with the typical speech of “we are a human company, people is our first priority”, they also get fired first whenever the market shrinks. They have to beg for training and to be sent to conferences, while their managers go to corporate retreats in Davos or Zermatt. Heck, sometimes consultants even have to ask for a proper computer to do their jobs, or are cynically asked to use their own personal equipment.

Oh, and consultants have to fill timesheets, and get punished if they don’t do it. Timesheets are worth an article of their own, in the sense that they are only used as command-and-control tools, and not, as one would think, as the basis for future estimations of upcoming projects. Timesheets are just black holes of information, where you might as well log 8 hours in the “whatever” category and nobody would really care. And estimations are usually done by your non-technical boss, anyway, so screw those historical data.

(Sometimes consultants not only have to fill their employer’s timesheet, but also the customer’s. I remember that at one time I had to fill 3 different timesheets. I could easily spend 2 hours a week making sure everything was right and coherent. And no, there wasn’t any “timesheet filling” entry in the timesheet software. And even worse, timesheet software – web based or not – usually sucks big time.)

OK, I’m probably being unfair here. There are a couple of benefits to being a consultant. I suppose. I hope. But this is not my point.

Products

As shown, the consulting landscape does not look very promising; on one side, many companies try to eat a small consulting market using the same shitty practices. On the other side, thankfully, there are companies who have understood that you can earn a very decent living by creating a nice product and selling licenses (or subscriptions) of it.

As previously, there are interesting side effects to choosing this strategy:

• Creating products has the ultimate goal of generating a steady income stream. This frees up energy and resources in your team to build new products, which generate more revenue, which you can spend creating new products… and so on and so forth. You get the idea.
• Having to maintain a few products means that you can afford knowing its quirks by heart; you don’t have to context switch from project to project like most consultants do, and you can continuously fix bugs and add new features to it. You feel like the product is your child, and you help it grow and become stronger, more resilient, more powerful. Which helps you sell more copies, etc, etc (see the previous point).
• Google’s much touted “20% project time” becomes, in the case of owning your own products, a “100% project time”. You enter a state of continuous creation. You don’t have to explain your choices to a non-technical (read: incompetent) boss: you respond, at most, to what your market demands (read: your customers).
• You can create a product suite; the synergy created from one product to the other might suffice to drive sales up of both products all by itself.
• You can have a direct contact with your clients, answering their requests and problems, instead of relying on a (usually non-technical) man-in-the-middle strategy.
• You acknowledge the fact that 8 hours of coding work is an illusion. I know no developer capable of sitting for 8 hours in front of a computer and writing coherent code, which is what most consultants are expected to get for CHF 1000 per day (the customer doesn’t usually know that a consultant only gets 30% of that sum). A maximum of 5 or 6 hours of pure concentration is already a big win, and the rest should be spent doing paperwork, playing Wii Sports or doing the groceries. Freeing your mind helps you have more ideas, which in turn become products that generate new revenue streams. When you are in consulting mode, you cannot have this liberty. Actually you have no liberty at all.
• You can have a real quality strategy. I know no consulting firm which really pays attention to quality (even if most fill their mouths with the Q word). Refactoring, unit testing, user testing, writing requirements and specs are just nonexistent tasks in most consulting companies. When you are creating products, you can take time to do them with the depth that you want; and actually, you do it, and you enjoy it.

Again, I’m really being unfair here. I am concentrating maybe too much into this “circle of virtue” called “product -> revenue -> freedom -> product -> rinse and repeat”. Things are never that easy; when you create a product, you have to choose a platform, find a market for it, invest in the creation part, advertise it, maintain it, support your customers, update your website, burn the CD-ROMs, write in your blog, test your product in the next version of the operating system (or browser), fix that weird Unicode bug, set up the eShop for selling your product, troubleshoot PayPal issues, add entries to the FAQ, participate in trade shows, send demos to magazines, fix the damn coffee machine, and many, many other things.

However hard it might seem, the underlying truths are fundamental: when you own the product, your commitment to quality and your enthusiasm will be unparalleled. And your code will be better just because of that.

Conclusion

I would say that consulting is a viable option to start up, as a short term strategy. There’s a lot of demand for custom software out there, and using your brain to generate cash that way can be used as a quick entry point to bootstrap your own company.

However, in the medium and long term, the only viable strategy for sustained growth in the software industry is the creation and sale of software products. This is the only way to create true value in your own company, helping you create a healthy environment for your staff, fostering creativity, engaging customers with a real experience, and creating a win-win situation for you and your customers.

Of course, creating and managing a product requires skills and objectives which are not the same as your usual consulting project; this is the reason why most consulting companies fail when trying to jump on a product mindset. This will be the subject of a future article.

• Microsoft: Windows, Internet Explorer, Microsoft Office, and C#.
• Sun: Solaris, HotJava (sic), StarOffice, and Java.
• Apple: Mac OS X, Safari, iWork, and Objective-C.
• Google: Chrome OS, Chrome, Google Docs, and… Go.

Precisely, Go was the last piece that Google had to create in order to fit into the framework above. And it did, with a bright team including Ken Thompson (of Unix and C fame) and Rob Pike (of Plan 9 and UTF-8 fame). With names like that, and with Google’s own funding and infrastructure, it is normal that the media went into a hype frenzy yesterday.

I think, however, that Google’s engineers got tired of what the current and upcoming versions of their “official” programming languages (Java 7, C++0x and Python 3.0) had to offer, and simply came up with a programming language that fits better their needs and expectations. As one of the slides of the TechTalk says, with current languages “You can be productive or safe, not both.”

Features like built-in support for concurrency or garbage collection hide the real true feature behind the language: faster build times with static typing support. This is important for Google from a software economy point of view: they want more productivity from their developers, or, in other words, more bang for their buck, all together with verifiable quality and speed of execution. Go seems to be designed to deliver in these areas. However, Rob Pike is careful to say that the language is experimental, so time will tell if their efforts were worth it.

In any case, it is worth noting that there was a previous programming language called Go! (whose author even wrote a book about it), and after an InformationWeek article revealed this, a petition has started in the Go bug tracking, asking Google to change the name of the language, all in the name of Google’s own “Don’t be evil” motto.

This paper will provide an introduction to the herb commonly referred to as “Yerba Mate”, and will later delve into the advantages and disadvantages of such practice, in the context of the creation of software products.

Introduction

Yerba Mate is defined by Wikipedia as follows:

Yerba mate or yerba-mate (Br.) (Spanish: yerba mate, Portuguese: erva-mate), Ilex paraguariensis, is a species of holly (family Aquifoliaceae) native to subtropical South America in northeastern Argentina, eastern Paraguay and southern Brazil. It was first scientifically classified by Swiss botanist Moses Bertoni, who settled in Paraguay in 1895.

The Yerba Mate (usually and wrongly spelled as “Yerba Maté” in English-speaking texts) is used in the preparation of a caffeinated beverage described by Wikipedia as follows:

Mate (Spanish pronunciation: [ˈmate]), also known as chimarrão (Portuguese: [ʃimaˈxɐ̃ũ]) or cimarrón, is a traditional South American infused drink. It is prepared from steeping dried leaves of yerba mate (llex paraguariensis, known in Portuguese as erva mate) in hot water. It is the national drink in Argentina, Paraguay, and Uruguay, and drinking it is a common social practice in parts of Brazil, Chile, eastern Bolivia, Lebanon and Syria. In Brazil, it is considered to be a tradition typical of the “Gaúchos”, name given to those born in Rio Grande do Sul. The drink contains caffeine. (…) The multicultural Yerba Mate Association of the Americas states that it is always improper to accent the second syllable, since doing so confuses the word with the unrelated Spanish word meaning “I killed.”

One of the phrases in the quoted paragraphs from Wikipedia brings to mind the importance of such a drink in the creation of software products (no, not the phrase about killing, the previous one). Caffeine is known for its capabilities in waking up inert areas of the brain, particularly during brain-damaging activities.

We consider unfortunate to qualify software development as a brain-damaging activity (although some research arrives to this particular conclusion), however, it is certainly a brain-intensive one, and as such, Yerba Mate has proven, in our tests, to be a particularly interesting option to coffee.

Preparation

To prepare “Mate” (the beverage), three basic elements are required:

1. A recipient, usually also referred to as “mate” (to add to the confusion), but also called “guampa”, “cuia”, “calabaza”, and other names without any translation to English whatsoever. Among these names appears also “porongo”, as it is known in Uruguay; this word is usually avoided in Argentina, for the exact same reason the name “Mitsubishi Pajero” has been a commercial failure there. This element can be made of wood, metal or even be the hollow shell of a dried calabash.
2. A metallic straw, usually also referred to as “bombilla” or less commonly, “bomba”. This element can be made out of metal or wood, and is used to drink the infusion, avoiding to swallow the leaves of Yerba Mate at the same time. The best ones have their top part covered in gold, which protects the lips from the intense heat generated by the water in the metal, and also provides a sense of luxury into an otherwise rather humble activity.
3. Hot water, never boiled, at around 70 to 80 degrees Celsius (160 – 180 degrees Fahrenheit). It is very, very, VERY important to serve the water at the exact temperature, without boiling the water inadvertently. Usually, the best way to keep the water hot is with a thermos or vacuum flask, of which the latest industry benchmarks highlight the Uruguayan brand “Lumilagro” as the most reliable, competitive and durable in the market. European customers are best served by the standard thermos provided by Ikea.

Once all the elements are ready, the preparation process is fairly simple:

1. Add the Yerba Mate leaves in the mate (the recipient);
2. Put the right hand on top of the mate (recipient) covering the entrance, and using your left hand, turn the recipient upside down and shake it a little; then return the recipient to its normal position and dust the mate powder from your hand (it is strongly recommended not sniffing it);
3. Insert the straw in the recipient, creating a small hole in the Yerba at the same time;
4. Pour in hot water, very slowly, in the hole caved in the previous step; on the first serve it is best to avoid filling the mate completely, to leave time to the yerba to get moist and release the flavor slowly;
5. Drink the mate, by sipping at the straw, taking care not to burn your mouth or throat;
6. Pass the mate around, which helps create and spread a sense of teamwork, to bring an ambience of relaxation and self-contemplation, and also to spread many known viruses.

Advantages

In the context of software engineering, such a practice has the following advantages:

• Health benefits: The ingestion of mate (the beverage) contributes positively to the recommended daily intake of water (at least around 2 or 3 liters a day), and thus to the maintenance of a convenient hydration level in the brain, which is recognized by several studies as a major contribution to its productivity. Some recent papers even indicate that the habit of Mate drinking can reduce the risks of cancer, but in any case, Yerba Mate is also a major source of many important elements for a healthy daily diet:

  It contains vitamins A, C, E, B1, B2, Niacin (B3), B5, B… and complex minerals like Calcium, Manganese, Iron, Selenium, Potassium, Magnesium, Phosphorus, and Zinc. It also contains Carotene, Fatty Acids, Chlorophyll, Flavonols, Polyphenols, Inositol, Trace Minerals, Antioxidants, Tannins, Pantothenic Acid, and 15 Amino Acids.

• Prolonged working hours: Instead of having to leave the desk to get yet another cup of coffee, the knowledge worker can sit in front of his computer for hours, particularly when using thermos with a capacity of at least 1 or 1.5 liters (around half a gallon). Mate (the beverage) is also known for reducing appetite, which helps reduce costs in the case of companies providing food to their employees.
• Teamwork benefits: Given the inherent social origins of the habit of drinking mate, in the case of teams, or in the case of agile practices such as pair programming, sharing the mate (the recipient) helps team managers to create a sense of unity and common goal.
• Increased sensitivity: As with all caffeinated drinks, the intake of mate can lead to an improvement in the overall awareness of the mate drinker.

Disadvantages

The following disadvantages of Mate (the herb, the beverage and the recipient) are worth considering:

• Cold water effects: Although common practice in Paraguay (where the infusion of Yerba Mate with cold water is known as Tereré), this variant is known for causing violent reactions in the digestive system of the person drinking it, and it is strongly recommended to never drink it more than 20 meters away from the nearest toilet.
• Bitterness: The strong taste of Yerba Mate is also a factor of considerable debate. Most mate drinkers usually start drinking it with sugar (some even with saccharine or other sweeteners), while most experienced drinkers will dismiss this practice and downplay those doing it as amateurish or otherwise ignorant. It is strongly recommended to have everyone agree on a mate variant beforehand to avoid shallow discussions on the relative merits of different approaches to mate drinking.
• Mate lavado: When the same Yerba has been poured several times (usually above 10 or 12 servings, depending on the quality of the Yerba), it loses part of its taste and must be replaced with new Yerba. Depending on how many people share the same mate (the recipient), this can be a significant problem, leading to reduced productivity and major anxiety and dismay.
• “Matetiquette”: Mate (the beverage) is linked with a complete language, tied up to the history of the southern part of South America. As such, please be aware of the fact that serving a “mate lavado” (see previous item for an explanation of the concept) is considered rude practice, and is strongly discouraged. Serving mate with cold water, as explained above, can also be seen negatively, particularly if the person preparing the mate is not from Paraguay. Finally, talking in front of your recently-filled mate instead of drinking it, is also frowned upon, as you might be greeted with a “it’s not a microphone” protest if you do it.

Conclusion

The importance of the Yerba Mate in the process of creation of software has been greatly dismissed by major research efforts, and we think that more research and mate drinking is needed. In our tests, Yerba Mate has been proven to foster creativity, teamwork, overall happiness, and trips to the toilets.

During a chat session with Stefan Fürst from Media Atelier we put together a quick list of significant Mac applications created in Switzerland (and southern Germany), and indeed the list (in no particular order) is nothing short of impressive; check it out:

• Zattoo, a really great TV player (cross-platform, actually, but the Mac version works really well);
• Cornerstone, one of the best Subversion clients for the Mac OS X operating system (the other being Versions);
• TimeLog and GrandTotal, the two applications used by independent contractors (like me) to keep track of the time spent in projects, and then to generate invoices out of that data – and which I personally prefer and strongly recommend over Billings;
• Distribute by Seven Lakes Software, dubbed the best ERP software available in the Mac, with an impressive feature list and lots of positive reviews;
• Snowtape, an application I’ve become addicted to lately, which allows you not only to listen to internet radio stations… but also to record them as MP3 or AAC files, which are automatically imported into iTunes!
• Waveboard, a Google Wave client for Mac (and iPhone soon, too!);
• Mailplane, a native Gmail clients with awesome capabilities;
• Posterino, Proxymind and Snippet Mind from Zykloid;
• Background Music by infoAtelier, currently in a promising beta test phase;
• iBackup;
• GraphClick, iLocalize, ProVoc, XS and AudioXplorer by Arizona Software (even if they aren’t in Switzerland anymore I think, they are definitely worth including in this list);
• PowerMail and FoxTrot by CTM Development;
• LiquidCD by Maconnect
• Several Mac products by Stephan Burlot’s Coriolis Technologies;
• Don’t forget that most Cocoa apps are unit-tested with Sen:te‘s original OCUnit unit testing framework bundled with Xcode since 2005!
• And last but not least, the diverse suite of Logitech drivers and control panels written by Men in Silicium in Geneva!

It really looks like the Swiss enjoy writing Mac apps (I certainly do and will publish mine soon!). Have I forgotten anyone? Please don’t be upset, and feel free to leave your links in the comments below. I’d love to know who else is creating killer apps for the Mac in a radius of 300 km around Zürich!

Disclaimer: I’m not affiliated with any of these companies (I’m just a friend of Stefan). And if you’re more into “enterprisey” stuff, here’s the “Swiss-Made Software” label site that you migth find more interesting ;)

Update, 2009-10-23: Some more applications added after the publication of this post:

• Luscious SMS, the SMS client for the Mac;
• Special mention for Cyberduck, an open source FTP, SFTP, WebDAV, Cloud Files & Amazon S3 Browser for Mac OS X, or “the poor man’s version of Transmit” :)

Update, 2009-10-24: Sophie Teuschler tells me not to forget the multiple Apple Design Award winners SubEthaEdit and BoinxTV by The Coding Monkeys, not far from Switzerland, in Bavaria…!

Update, 2009-10-25: I’ve just received an e-mail from Cyril Pavillard about his company Mnemis and their product Uniboard which looks absolutely awesome by any standards. Be sure to check out this cool Swiss project!

Update, 2009-11-12: Just found out about noidentity and their MoneyBook iPhone application. It seems that this application is just a copy from another one called “pennies”. Shame on you noidentity.

As the name implies, it’s a simple and easy way to create, keep and find notes in your iPhone, with some bonus: geographical awareness, so that each note remembers where it was created; the ability to publish notes in Twitter (for the moment, only if you have Twitterriffic installed in your iPhone) and send them via e-mail, too. I’m particularly happy of the Twitter integration (which prompted a whole article in this blog) so that I can use Notitas a lot as a “draft Twitter” client.

I’m already preparing version 1.1 with TwitterFon + Tweetie support, as well as a German localization thanks to Sophie from Sophiestication! Stay tuned for more goodies :)

PS: oh, and while you’re using Notitas, try shaking the board a bit and you’ll see what happens ;)

RooiFonts is an evolution of my previous Font Browser application (still open source, still in Github). RooiFonts builds upon that application bringing some more new features, like the ability to send a screenshot of a sample of text in the selected font via e-mail, or being able to compare two fonts side by side. RooiFonts is available in the App Store for USD 3.99 (CHF 4.40, EUR 2.99).

On the other hand, DeviceDNA is a free application for all of my clients, to send me their iPhone device information (including their UDID) via e-mail in a convenient way. No more explaining “open iTunes, click here, paste there…”, just install this, and you’re done.

As usual, both are available in English, French and Spanish.

However, not all editors document the URL schemes they support in their apps, and this blocks reuse and collaboration. I recently came into such a problem, trying to use TwitterFon from my own apps, to post messages to Twitter. The TwitterFon site only specifies the following iPhone URL scheme:

twitterfon:///post?this%20is%20a%20test

The problem is, this URL scheme does not perform an URL-decoding on the message parameter, which means that a phrase like “this is a test” will appear in TwitterFon URL-encoded, that is, as “this%20is%20a%20test”. Clearly not acceptable.

However, thanks to Ashley Mills, I learnt that the USA Today iPhone app is able to use TwitterFon to share articles via Twitter, and does this properly, without URL-encoded characters. How do they do that? Obviously, they are using an URL scheme exported by TwitterFon, but not documented anywhere (*). I finally discovered that the URL scheme sought is the following (“message” instead of “post”!):

twitterfon:///message?some%20text%20here

This is how I found out: I impersonated TwitterFon in my own iPhone with an ad-hoc app created in Xcode, that shows me the URL used by USA Today to launch TwitterFon. These are the steps required:

1. Open iTunes and look for the application whose URL schemes you’re interested in (in my case, TwitterFon Pro); right click on it and select “Show in Finder”;
2. Duplicate the .ipa file in the Finder and change its extension to .zip – yes, .ipa applications are simply compressed .zip files;
3. Uncompress the .zip file and open the folder; inside, navigate to the “Payload” folder, and right-click on the .app file inside; select “Show Package Contents”;
4. Browse inside the package and open the Info.plist file; inside, you’ll find two keys that are interesting for us: CFBundleURLTypes (“URL types”) and CFBundleIdentifier (“Bundle identifier”). Select them and copy them to your clipboard;
5. Create a new Xcode application, using the “iPhone OS / View-based application” template;
6. Open the Info.plist file corresponding to the default target and remove the existing CFBundleIdentifier (“Bundle identifier”) key; paste the two items you’ve copied in the previous step – this means we’re creating an application that will “impersonate” itself as the “real” one;
7. Modify the new Xcode project’s app delegate adding the following method: [source:c] - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url { viewController.viewer.text = [url absoluteString]; return YES; } [/source]
8. Add a UITextView to your viewController (you can do this easily in Interface Builder, editing the .xib file), and expose it through a public property (called “viewer” above) so that the app delegate can access it;
9. Prepare your Xcode project for ad-hoc deployment: add a “distribution” configuration, an entitlements.plist file, etc;
10. Plug your iPhone, select “Distribution / iPhone OS Device”, and “Run” your application; the application will build and Xcode will install it into your device. ATTENTION: this application will overwrite the original one! This is because it has the same bundle identifier. Be sure to backup your data before doing this, as it will be lost completely;
11. Now run the application calling the one you impersonate (in this case, the USA Today one) and force it to call the “impersonated” application (in this case, by “sharing” an article via Twitter). This will trigger the launch of the impersonated application, the call to application:handleOpenURL:, which itself will display the calling URL on the iPhone screen.

You can download a zip file with the Xcode project created above if you want. Be careful if you run it on your own device!

Voilà! Finally, delete your own impersonated app, go to the App Store, re-install the application you’ve impersonated (normally it’s a free download, even for non-free apps), and you are done. The same mechanism could be used to find out similar, hidden URL mechanisms in other apps.

(*) Actually this URL scheme is only shortly mentioned in the changelog of the application…