This post will outline the recipes that we have applied to obtain the best results in the collaboration with our clients.

Principles

What are the principles that guide our work?

• To begin with, we do not work for our customers; we work with them. This means that we are both collaborating in our projects, in equal terms, with as many expectations as our clients have.
• Creating software is hard. If you “have a friend that can make your application for 100 dollars in 2 days”, don’t call us.
• If you are a “creative agency”, and “your first class client” wants an application, and you try to push our rates down, “for the sake of our future collaboration”, don’t bother calling us. We’re not interested.
• Similarly, if you are an agency and you are going to shield us and proxy (or “manage”) all communications between us and the final customer, we are not interested. We only work in projects where we have full access to the customer. We are not interested in other kinds of collaboration.
• We do not outsource projects. Period.
• We do as much as we can to reduce our carbon footprint. And you should, too.

How we work

akosma software has a well defined workflow to help its clients bring their ideas to life; if you are into buzzwords, you could say that we use a mix of iterative and sequential approaches:

• We ask our clients for a single point-of-contact person, or a “Product Owner” as some methodologies call it; this person will be our sole communication proxy with the organization. We ask our clients to always forward questions and remarks through this person at any times. Doing so helps us work more efficiently and faster.
• We ask our clients for a well defined Statement of Work. We believe that the final product can only be as good as the Statement of Work provided. This document must provide as many details as possible about the final project. This helps us keep our costs low, it reduces misunderstandings, and helps us deliver features faster.
• For ad-hoc development projects, we usually work in “fixed time / fixed price” mode. We will provide you a cost and a deadline for your project, and we’ll stick to it (that’s why the Statement of Work is so important!) We can also work in “time and materials” mode if you need it.
• We try to [manage project risks][5] from beginning to end. For that, we require your commitment, understanding and collaboration.
• We ask our clients to avoid email and phone as a communication and coordination medium. We use our project management site instead, which features forums with threaded conversations, bug tracking and wikis. This allows us to centralize all the information of the project, as well as the communication with the client, in a single repository, to avoid losing information in crowded email inboxes.
• We provide feedback about our work continuously. Our clients can check the advancement of the project at any time in our project management site without even having to contact us. Everything we do is logged in the screens of the “Activity” panel, at any given time. This helps us reduce interruptions, which are costly, and also helps us increase customer satisfaction, because the client can always know what’s going on.
• We divide small projects (with a duration less than one month) in one-week long iterations, while longer or more complex projects are divided in two-weeks long iterations. At the end of each iteration, the client is able to test the application in their own devices and infrastructure, and we expect feedback from this. The clients’ feedback is fundamental; without it, we will assume that everything is going according to plan and continue working in the next iteration.

Expectations

From each client that we agree to work with, we have as many expectations as you have.

• We expect you to provide us with clear explanations of what you need. We mean it. In written form. With diagrams. Color. Details. Everything.
• We expect your feedback, quickly, because every week we are going to use this feedback to make your product better.
• We expect you to take care of your project as we do. In particular, do not mess with the source code of what we provide to you: not only this breaks the warranty (yes, we provide one), but even worse, it breaks our trust in our relationship.
• We expect that you pay our invoices in time. As simple as that.
• We expect you to have a smile in your face, just like we want to have one when we work with you. That’s why we do what we do.

If you would like to work with us, then just contact us!

[5]:http://akosma.com/2009/08/03/risk-management-in-iphone-projects/Similar Posts:

• Why do not we outsource projects overseas?
• digital2.0 iPad Application
• Senbei, a Fat Free CRM iPhone Client
• New Project Request Form
• Integrating iOS Applications with Backend REST Services

Some subtle differences appear, don’t you think? Similar Posts:

• Wordle
• Senbei 1.3 hits the App Store!
• Attending SenchaCon 2011
• QCon London 2012: Call for Papers in the Cross-Platform Mobile Track
• GOTO Copenhagen 2012 – Call for Speakers!

In Switzerland, the big craze of mobile apps began with the introduction of the iPhone in June 2008, and then the waves of new Android devices that have been introduced in the past 2 years. Everybody has a smartphone these days, and now everyone is jumping to buy a tablet (usually an iPad) as fast as they can.

But the mobile market is highly fragmented. I’m not talking about the Android hardware market, which is inherently fragmented by nature; we are talking about the app market in general. Companies want to have their services and products in as many smartphone platforms as possible these days, and the iPhone is no longer enough.

To put things in context, the latest statistics of smartphone platforms roughly show that:

• 40% of the market is held by Android devices, with a large proportion of Samsung devices, and apparently with some signs of starvation;
• 30% by iOS, with a small growing trend; not taking into account the iPod touch and the iPad, which are iOS devices, but not really smartphones; and
• 20% by BlackBerry devices, although this proportion is actually on a negative slope these days.

If we consider the “mobile market” as the sum of smartphones and tablets, and if we include the iPod touch into the mix, then iOS holds more than 40% of the whole mobile market. Impressive, but still, not even half of the market.

Given this split, companies want to maximize the return of their investments. In other words, they want more bang for their buck. They are still going to spend money for mobile applications, for sure; but they are not so sure these days about the “iPhone only” or even “iPhone first” approach that was common until now; they want an app that works in as many platforms as possible. Certainly the grim economic situation also plays a role in these decisions!

This is a reality; this is something that we have been experiencing for the past months, and the trend is going in this direction. 2012 is going to be the year of the mobile cross-platform app, but because the market said so, not because some technology fashionista decided it, so we need to prepare to bring this vision into reality.

In our case, at akosma software we have chosen a few technologies to bet our company on:

• The whole HTML5 standard, including the amazing suite of tools that the new generation of browsers are making available for us!
• Sencha Touch, the mobile evolution of the Ext JavaScript framework of yesteryear, of which Adrian has been a great fan for years!
• jQuery Mobile, the promising new framework based on the non less amazing jQuery project!
• PhoneGap, the open source mobile web app packaging framework now becoming a de-facto standard!

Are we dropping the iOS platform for web technologies? Not at all; we are still going to provide iOS application development services, simply because (at least right now) not everything can be done with web apps; but we are proud to add Sencha, jQuery Mobile and PhoneGap as part of our formal offering, because we firmly believe in the huge potential of these platforms.

Moreover, some clients still want to provide custom-tailored experiences to iOS devices, and we fully support those initiatives with our skills and imagination!

In the short term, watch out for this:

• Adrian is going to talk about web apps from an iOS developer perspective at a SkillsMatter event in London, on November 22nd.
• We will be attending SenchaCon 2011 in Austin TX (USA), from October 23rd to the 26th, to learn more about Sencha and the next generation of web technologies.
• We will be presenting in the next Mobile Developer Summit in Bangalore, India, in November 2nd.

In the next few months, expect more around web technologies from akosma software!

Similar Posts:

• Talking at the Scandinavian Developer Conference 2011
• “jQuery Mobile: multiplatform mobile webapps” – by Maximiliano Firtman!
• Announcing EERV cal, an iPhone, Android and Web Application!
• Mobile Development with jQuery, Sencha and PhoneGap, 15 – 17 November 2011
• News for this week: Training + Interview

akosma software does not outsource its projects.

Against the common opinion of most IT newspapers and blogs, we think there are several reasons to not doing it:

1. Outsourcing is a modern variant of that old north-south dependency relationship. In the XIXth century it was about cotton, coal or food. These days is about software. But the schema is the same; the north buys cheap goods and services from the south, but the added value remains always in the north. We believe that this state of things is one of the main reasons of the current state of the world; and thus, we prefer to teach the south how to create their own value, rather than selling it to companies who will, in turn, build a name upon your own effort. We think that talking about sustainable development also means refraining from outsourcing.
2. Making software is our core business. We do not think that outsourcing our core business is a good idea. We have seen many software companies struggle with the management of outsourced projects, and we do not want that. We do not care if you are agile, waterfallish or CMMI level 42.
3. We work in a close relationship with our clients; we seek their input several times a day, we ask for their feedback continuously, and we insist in having them participate in the development of their products. Working in an outsourcing schema adds a third layer of communication in the whole process, and we do not work well in such situations.

Are we losing money in the process? Sure; but that money would be built upon the effort of others than us. We believe in (and work with) networks of independent peers, providing value at each step of the way: designers, user experience experts, marketing people, creative teams. Not remote companies where the only driving mechanism for the whole relationship is a mere economic advantage.

At akosma software we do not work for others, neither want others to work for us: we work with others, both clients and suppliers, in equal terms. The final product is a joint effort of equal commons. That’s how we see things.

Of course, this is our policy, and your mileage and opinions may differ from ours. Maybe outsourcing works in your case; well, good for you, but it definitely does not fit our values, that’s all.

PS: message to all outsourcing companies and offshoring firms anywhere in the planet; you can stop contacting us (phone, email, etc). We are not going to work with you, for the reasons above. We think you should probably start developing your own products and services rather than selling them to Europe or the USA.Similar Posts:

• immedia: the leader mobile solutions provider in South Africa
• How we work
• A Shift In The Market Towards Mobile Web Apps
• Retrospective 2010
• Retrospective 2011

Similar Posts:

• Wordle 2012
• Mobile Application Training in South Africa
• More Mobile Application Training in South Africa
• Soft-Shake 2010
• Announcing EERV cal, an iPhone, Android and Web Application!

Article paru dans le numéro d’Octobre 2010 de com.in Magazine (télécharger le PDF) Similar Posts:

• Rezonance First: Panorama et enjeux du marché des applications iPhone
• Applications iPhone: il est temps de s’y mettre!
• Application iPhone ThierryWeber.com
• How to buy iPad apps outside of the US
• Soft-Shake 2010

A quick search in the Xcode documentation browser brings in an interesting list of classes including this initializer (with or without additional parameters):

• NSArray
• NSManagedObjectModel
• NSData
• NSDictionary
• NSXMLParser
• NSMappingModel
• NSString
• AVAudioPlayer

Don’t get me wrong, the title of this post is a bit misleading; it’s not that this method is always problematic, particularly when the URL passed as parameter has been built using the fileURLWithPath: family of initializers. In this case, the URL will point to a local resource, and the worst thing that can happen in that case is that the filename is wrong, or that the file does not exist for some reason (NSFileManager to the rescue!).

However, when using external URLs referencing resources somewhere over the network, using this method is definitely a recipe for disaster.

The main problem with these methods, of course, is the fact that they are synchronous; this means that the thread executing them (usually the UI thread) will block completely until they return, and in most applications this means that you are de-facto blocking the whole application for an unknown amount of time. This means that no buttons or UI widgets will react to input, no navigation will be possible, no touch events will be delivered or executed, nothing will happen at all until the network operation completes.

Even worse; when using initWithContentsOfURL:, there is no timeout, there is no meaningful feedback for network failures, and no way for the user to cancel the current network operation. This last factor justifies by itself not using initWithContentsOfURL: at all; you must never ship code that leads to a bad user experience. Your users will resent this and will complain!

As Joel Spolsky explained in his classic article Three Wrong Ideas From Computer Science,

One example of network transparency is the famous RPC (remote procedure call), a system designed so that you can call procedures (subroutines) running on another computer on the network exactly as if they were running on the local computer. An awful lot of energy went into this. Another example, built on top of RPC, is Microsoft’s Distributed COM (DCOM), in which you can access objects running on another computer as if they were on the current computer. Sounds logical, right? Wrong. There are three very major differences between accessing resources on another machine and accessing resources on the local machine:

1. Availability,
2. Latency, and
3. Reliability.

(BTW, read this article, it’s really a good one, like many others in his blog)

In summary, never assume that the network is available, never assume that anything behind the network is available, and never assume that a network has any particular speed. This is particularly true in the case of mobile platforms, where network conditions can vary tremendously from one minute to the other!

The problem with the initWithContentsOfURL: methods is that some online tutorials use them as a quick-and-dirty way to load resources from the network (for example this one on iCodeBlog), and I have myself seen production code using this method.

This is very, very bad. Using initWithContentsOfURL: with remote network resources in a tutorial like this is simply a horrendous, almost irresponsible approach towards developers new to the iPhone platform.

You must not use synchronous connections in any way in your code, unless you are 100% sure that you are running it in a non-UI thread – and even so, as Jeff LaMarche explained recently, you should avoid such multithreaded approaches. The NSRunLoop architecture of Cocoa and Cocoa touch allows you to bypass threading altogether when dealing with networking operations. Remember this! And read Jeff’s article for more details.

This exact same problem can also be created with other APIs and libraries, for example when using NSURLConnection’s sendSynchronousRequest:returningResponse:error: method (as explained today in The Apple Blog.)

Do not block the main UI thread. Write this on your whiteboard, on a post-it on your computer monitor, in your agenda with a reminder every day. Do not use this approach. As Cédric said, these methods should only be used for prototyping!

One popular example of a network library that support asynchronous connections is ASIHTTPRequest, which I tend to use in nearly all my projects (instead of the standard NSURLConnection classes bundled in Cocoa and Cocoa Touch.) I prefer it because it has a nicer, smaller interface, it’s fast (I’ve benchmarked it in my iPhone Web Services Client demo project on Github), and it provides handy queueing capabilities. FTW!

By the way, Ben Copsey (the creator of ASIHTTPRequest) has published today an article in his blog, in which he exposes the approaches used to queue network connections in his library. Designing a library for concurrent, queued network connections is not trivial, and his current approach (subclassing NSOperationQueue) might soon be deprecated for a new, NSRunLoop-y, more Cocoa-friendly, way.

In any case, I hope I have made my point: avoid synchronous operations when loading content from the network, remember what Joel said, and use a library providing asynchronous connections. Happy coding!

PS: by the way, the title of this blog post is a reference to many other classic articles, so many that there’s even a Wikipedia entry about them and a great rant about them by Eric Meyer! Similar Posts:

• A Proposed Architecture for Network-Bound iOS Apps
• How knowing C and C++ can help you write better iPhone apps, part 1
• iPhone Dev Day in Geneva on April 28th
• Objective-C Categories as Stylesheets
• The Dawn of Couch Computing

The iPad is a disruptive device. Not in the sense of groundbreaking, because there is nothing on the iPad that you couldn’t find in other devices. I mean disruptive in the sense of creating a new blue ocean, a new category of devices where the interaction with the machine is done through a completely different kind of approach. Apple is, once again, redefining the word “personal computer”, setting itself apart from the competition, and making us drool all over again.

The iPad is the dawn of couch computing, with all what this phrase means. The critics to the iPad are doing the same level of noise you can hear whenever Apple releases a new product. Remember: it all started with Dvorak critisizing the first Macintosh because of the mouse. Then it continued with the iMac not having a floppy disk. Then it was the iPod and its hard drive or its lack of a color screen. Finally it was the iPhone, which has generated as many critics as sales. All what is written around the iPad follows the same pattern.

To help to filter the noise produced by all the opinions, keep in mind the following elements:

• We geeks are a very small portion of the human population. A noisy one, but very small anyway. Our opinions are biased and most of the time are not the same as the average user. The iPad is not a device for geeks. This is a device for common people, who want a lightweight computer that starts fast, can be used on a couch, looks beautiful and can even be used to create small documents.
• The average user wants to hold in their hands whatever new gadget seen in the movies. One of the best reviews of the iPad I’ve read so far stated that the device is a step in a trend to bring gadgets found in “Star Trek”, “Star Wars” or “2001″ to the market.
• The iPad is the ultimate simplification of the user experience. This device completely isolates the user from the underlying hardware. The user interface is the computer. No file system, no files, no folders, just apps, documents within those apps, and as much multimedia as possible: videos, images, sound. The same hardware is used for both primary input and primary output.

Is there a use case for the iPad? You are pretty damn sure there is: right now I’m typing this blog post on MarsEdit on a train. I use my MacBook Pro for that. But I know I would use an iPad instead if I had it. I know designers planning to buy some iPads to showcase their portfolio in them. Not to mention on-demand business opportunities, gaming, social networking, and much more.

Couch computing means more than dumb consumption of media: it is also a whole new relationship with the way humans create and share information. The iPad is the first real electronic canvas, and its übersimplification of the user interface, together with an übersimplification of the distribution of software, will create a whole new market. A whole, new, different paradigm. The iPad is not a computer, it is not a netbook, it is not a laptop. It’s an iPad. The user experience patterns will be different, the use cases are yet unforeseen.

I have been contacted by many clients already to take their iPhone apps to the next level, and some ideas are just incredible. In any case, akosma software is your partner of choice for your next iPad application! Contact us, we’d love to hear about your next idea.

PS: by the way, did you know that in the next Dev Days for iPhone in London and Geneva (if the iPad NDA drops) Daniel Steinberg will talk about the iPad instead of Core Data? Similar Posts:

• Mobile Advertising, by Edipresse
• digital2.0 iPad Application
• nib2objc Featured on The Changelog
• Why Some Analysts Don’t Get The iPad (Yet)
• How to buy iPad apps outside of the US

However, this does not mean that designers coming from a web or print background are ready to tackle design projects for the iPhone ipso facto. I’ve seen too many horrors so far, and that is why I am making public this list of tips and tricks that I keep repeating to all the designers I work with.

1. Read the iPhone design guidelines. Thoroughly. Twice or even better, three times until you know them by heart. Depending on the budget and the timeline, it might be impossible to create custom components or to achieve all your fancy animations and effects; in that case, you should stick to the UIKit widgets catalog for your designs, including all of their limitations. Once you’ve read the guidelines, buy these books and read some more:
   • Programming the iPhone User Experience, by Tody Boudreaux;
   • Best iPhone Apps, by Clark Josh;
   • iPhone User Interface Design Projects by David Barnard, Joachim Bondo and others.
2. The iPhone is more like a motion picture than a static image. Even the most basic applications feature animation, beautiful scrolling and swiping and pinching. Thus, that gorgeous Photoshop file is not enough; you will have to explain to me your idea, frame by frame, like if you were writing a screenplay; every animation, every step, every transition must be as documented as possible for the developers to be able to bring your design to life.
3. Fingers are bigger than mouse pointers. The minimum size for an area that should be tapped is 44 pixels wide. Smaller buttons or icons are simply unusable. And since we’re talking about sizes, the status bar is 20 pixels high, toolbars and navigation bars are 44 pixels high.
4. The iPhone has a limited set of fonts. Not all the fonts you have on Photoshop are available on the iPhone, and at least so far, there is not an easy way to integrate external fonts in an iPhone application. Grab a copy of RooiFonts and learn which fonts are available on the iPhone. And avoid Marker Felt altogether. Please.
5. The four golden screen sizes:
   • Portrait without status bar: 320 x 480
   • Portrait with status bar: 320 x 460
   • Landscape without status bar: 480 x 320
   • Landscape with status bar: 480 x 300
6. Think PNG. Whenever you have to provide graphics for the iPhone, remember that PNG is the best solution. It supports transparency, lossless compression, lots of colours, and the iPhone can optimize them even further. By the way, every app needs a “Default.png” file (shown during startup) of one of the four golden screen sizes enumerated above. And an “Icon.png” file, 57 x 57 pixels wide.
7. Create your icons using the biggest possible resolution you can. The App Store requires you to provide a 512 x 512 TIFF file, at 72 DPI, but if your application is successful, they might ask for a higher resolution file for a commercial. Your best idea then is to design your icon as if it were to be printed in a huge banner.
8. The status bar on top of the application can be removed altogether. Unfortunately it can’t be customized beyond a small set of options, and basically you can only have it gray, black or translucent. You can apply a bit of color to the status bar by having a coloured view underneath, but it might not look the way you want.
9. The iPhone OS provides some functionality for free, including all the widgets and some more obscure behaviour, for example, tapping the status bar makes lists scroll to the top, and tapping a tab bar item makes the navigation return to the root controller. Some other things, like Convertbot-like “scrollwheel menus” are not part of the toolkit and might take a bit longer to create.
10. Photoshop is not enough. Use a paper-based design sketchbook, preferably one with a stencil, and draw your application manually. This will help you figure out features and interaction without committing to a visual design. Then ask your nearest developer for the iPhone SDK, install it and play with Interface Builder. I said play: don’t try to understand everything you see, because it’s a rather complex tool. But you can drag and drop components, and the inspector allows you to change styles and move things around. You will learn a lot, and most importantly, you will see things through the eyes of a developer.

I’d like to hear more tips and tricks. Feel free to leave them in the comments below! Similar Posts:

• Trainings 2012: Advanced iOS, Mobile Web Apps and Node.js
• digital2.0 iPad Application
• Migrating iPhone 3.x apps to iPad and iOS 4.0
• Advanced iOS 4.2 Training Course – Zürich, February 7th and 8th 2011 – Enroll now!
• More nib2objc fun

1) iPhone

First we had Rogue Amoeba and Joe Hewitt leaving the App Store, and then we have the autobot in the review process rejecting apps including Joe’s Three20 library (which is a highly ironic fact, if you think about it), and then rejecting apps with method or property names apparently similar to those of private APIs, then app rankings going bezerk for a little while, then the release dates having hiccups, and so on, and so on.

All of this sucks. Ask Paul Graham if you don’t believe me. And check the improvements suggested by Enormego. There is a consensus about the fact that things aren’t working – at least from the developers’ point of view.

However, let’s be even more honest, things don’t look better on the other side of the fence.

2) Web Apps

According to Peter-Paul Koch (of Quirksmode fame, all in all a highly respected web developer), the problem of the App Store is not Apple, but the stupid developers who insist in writing native apps when they could just write web apps using good ol’HTML 5 and CSS.

I agree that for a small range of applications, this approach would work, going from simple to-do lists, and even some social networking applications. I’ve enumerated the option of web apps in a recent article of mine about alternatives to the native SDK.

But, there’s always a “but”:

• The money is in native iPhone applications. My clients, at least, they want them, they are ready to pay for them, just like they paid for websites back in 1997. And the monetization of iPhone apps is simply brilliant. Submit your app, cross your fingers, charge a few bucks, and you have potentially 50 million clients ready to buy it. Try finding a monetization model for your web app based entirely on the iPhone.
• Games: although I’m not a game developer (yet) at least for the moment it’s plain unthinkable to create fun, appealing games using HTML and JavaScript.
• Hardware access: you can access the GPS information, but that’s more or less everything you can do. Try to access the camera, the local network stack (think Bonjour-based apps), or the microphone, or the speakers, or the iPod music library, or the address book of the user, or the accelerometer, or complex UI animations or transitions, and you’re toast. The point is, many complex apps are based on those elements. Complex user experiences involve some or all of these elements, not just plain data. I do hope that Apple will allow access to some of these native features in the iPhone soon, particularly the accelerometer and the camera, which would be in my opinion perfect candidates for a JavaScript API.

There certainly is a business case for web apps, as I explained in my presentation last year at Geneva’s iPhone Conference 2008:

In short: yes, web apps are a perfect alternative in some cases; yes, Apple is unpredictable and the App Store must be improved; and finally no, developers aren’t stupid. There’s a great deal of personal taste in the choice of a development platform, and in this case, the tradeoff is sometimes worth the pain.

John Gruber says it even better than me:

But the best proof is what I pointed out above: Apple itself created almost no iPhone web apps. Successful iPhone developers don’t just want to write software that works on the iPhone. They want to write software for the iPhone that’s just as good as Apple’s. Today that means using Cocoa Touch and the native SDK. When you write a Cocoa Touch app for the iPhone, you’re not starting from scratch. You’re starting with the Cocoa Touch framework. As Faruk Ateş astutely points out in his response to Koch, to discount the framework is to discount everything that sets the iPhone apart as a development platform. Not only are native iPhone apps faster and more capable than their web-app equivalents, but they’re easier to write.

Anyway.

3) Android

I think, without any doubt, that Android is one of the most important platforms of the past few years (I agree with Tim Bray in this point). Android has many characteristics that are, at first sight, extremely appealing:

• It’s open source, based on open standards and proven technologies;
• It’s backed by a company known by its technical expertise and innovation;
• It’s growing faster and faster every day;
• It is proving popular among users, too – and this is not a minor element!

But, of course, not everything is green: Android basically trades off a shitty review process with a shitty programming environment (at least until IntelliJ IDEA 9 ships*). Not only that: the whole platform is threatened by Google releasing its own device, or by the fragmentation of the platform by the device vendors, or by the low numbers of app sales (which is somewhat surprising, given the apparent strong sales of some devices like the Droid).

Of all the drawbacks I enumerated above, I want to focus in one aspect: the problem of platform fragmentation is, in my opinion, so big, so important, that voices are raising to explain that this single factor might blow the whole platform:

Can you write an .apk application that runs on all devices? Theoretically, yes. But not without testing on an ever-increasing number of gadgets. This is the problem that Symbian and J2ME phones have, and the road that Android is headed down if Google doesn’t reign in control and quickly. Differing OS versions, different manufacturer and carrier customizations, and various app stores are going to hobble the OS before too long. All that said, I still believe it’s got a real future after using it regularly on my Archos, but Google needs to get control quickly. I had originally suggested using the Android logo and trademark (which they may or may not own) as a way of ensuring compatibility, but it seems the logo is creative commons. So maybe they need to come up with an “Android Approved” logo or something.

At least in terms of programmer experience, though, Android still has a long way to go. To begin with, it’s based in Java; and I will never get tired of quoting this paragraph from His Highness Steve Jegge (Google employee, by the way):

I’ll give you the capsule synopsis, the one-sentence summary of the learnings I had from the Bad Thing that happened to me while writing my game in Java: if you begin with the assumption that you need to shrink your code base, you will eventually be forced to conclude that you cannot continue to use Java. Conversely, if you begin with the assumption that you must use Java, then you will eventually be forced to conclude that you will have millions of lines of code.

You can’t be more clear. More code leads to higher maintenance costs, higher chances of bugs, and in general, harder-to-maintain code bases. The choice of Java in the long run will hurt Android more than anything else. In a similar way, the current App Store policies are doing a similar harm, which is, as Graham said, to make developers run away from either platform.

Additionally, I might also point out the fact that currently the only way to write Android apps, is using Java (with a small subset of functionality available through the Android Native Development Toolkit); compare this with the amount of alternative frameworks for the iPhone, and the discussion of the “openness” of the Android platform takes a different spin.

Finally, there’s this factor Gruber discusses, this syndrom called the “year of Android”, similar to the “year of Linux” promised since the early years of this decade… and which every year turns out, inexorably, in favor of other platforms.

I’ll just say that if the consensus winds up that the Droid isn’t a great Android phone, this is the sort of attitude that’ll sink Android. It’s the same attitude desktop Linux has always had, that the future is going to be great, so don’t worry about the present. Like a sports team that’s always saying “Wait until next year”, meanwhile, Apple has won another championship this year.

4) The Others

Just to name them, a bit further away in the finish line, we have a Windows Mobile base of millions of devices without any serious roadmap, and which looks more like a neglected child than anything else. Or the Palm Pre which is, hum, nonexistent (at least in this side of the world). Or BlackBerry, which is, hum, off the radar (but which I think is the real third alternative to the iPhone and Android). Or Symbian and J2ME, which are, well, Symbian and J2ME.

So, in short, this means that programming for mobile platforms is both shitty and complex, no matter how you look at it.

Great.

Meanwhile, in a small town in Switzerland…

akosma software does and will concentrate mobile development efforts on the iPhone and Android platforms. We think, given all the facts we could chew so far, that these two are more likely to dominate the mobile software development business in the years to come than all the others combined.

Nevertheless, in terms of absolute and relative numbers, current projects and cash at stake, iPhone is the clear winner at the time of this writing (something said a couple of months ago in an interview on the Swiss newspaper Le Temps).

In terms of potential for growth, we cannot and we do not underestimate Android (hence our interest). Particularly, there are some factors that could boost Android’s appeal, which are huge opportunities for growth, somewhat neglected so far:

• Google should promote the platform more, including ads on TV, and also allowing paid apps in more countries;
• Developers should be capable of creating Android apps in as many languages as possible. Compiled or not, scripting or not, object-oriented or not, it doesn’t matter – I vote for C++ and Ruby;
• We need a better IDE, now (and a faster emulator, too. The current one sucks).

Above all, there’s one important fact: programming is still fun, creative and interesting. And we’ll keep on creating new stuff (and ranting about it), no matter what platform we choose.

(*) I have tried the current beta, and I don’t think it will change the game that much. No visual GUI editor (something that even Eclipse has, albeit in a primitive way), and the configuration of a single project, well, it’s IntelliJ IDEA. I couldn’t even run a simple project with it. Let’s see when the final release ships.

Update, 2009-11-26: This article in CNN (French version) talks about the problem platform fragmentation represents for small shops. It brings a strange feeling: the “open” Android platform might be only open to those with enough means to have a whole testing framework with the most popular devices, leaving out small shops who wouldn’t be able to support their applications in all devices, given the famous fragmentation. Similar Posts:

• Talking at the Scandinavian Developer Conference 2011
• A Shift In The Market Towards Mobile Web Apps
• “jQuery Mobile: multiplatform mobile webapps” – by Maximiliano Firtman!
• Mobile Development with jQuery, Sencha and PhoneGap, 15 – 17 November 2011
• Mobile Web Training in Zürich Once Again!