Let’s squash the stupid: “60% or more iOS apps don’t break even”
So it goes, apparently, that 60% plus of iOS apps barely break even.
I have been hearing for a while the “mobile app development is a lottery” proclamation and largely agreeing with it. People telling me that making money on the app store is like having a hit song.
I couldn’t disagree with it, it seemed to make sense… until I plugged in my sorry excuse for brain.
It’s time to hit this messed up, insanely brain-dead FUD with the stupid stick
Code generators all the way down: Why the Web sucks for Apps
You may have read my previous posts (here, here and here) on why, at a very fundamental level, I think the open web is a terrible way to make applications.
It is my day to day work to create free tools for web developers and help my clients build web applications, so please do not make the mistake of thinking I am waging some anti-Web war here. This is years of web development talking.
I was musing about the nature of the modern web-app stack the other day and suddenly it hit me.
I think I finally got to the root of what makes me feel so uneasy about using the web to develop applications (applications as opposed to pure document presentation which is what the web is pretty good for).
We have such amazing advanced tools now for web apps. You pick a powerful framework like Grails or Rails or Node, you use tools like Less, Moustache, Twitter Bootstrap, you write your JS in something like CoffeeScript or maybe even Objective-J etc.
The diagram above shows what a web app used to be, and really what it should be.
The reality of modern web apps is very, very different and looks something more like this:
What I realised is that we are now in some evil kind of place where we are using a great many code generators in an attempt to simplify our working lives. Why is this happening? Because it is too hard to make the kind of apps that people deserve with standard web tech. The standards always, always, always lag well behind real world needs.
So we may typically have at least 5 code generators in our app stacks now:
- A tool like Less or Sass to generate one or more CSS files from a CSS-like language that preserves our sanity. Don’t bother to tell me that CSS variables are coming soon. This outputs CSS files.
- A tool like CoffeeScript to make, in some peoples’ opinions, JavaScript more maintainable and productive – outputting JS
- Some kind of JS and HTML friendly templating tool like Moustache – generating JS and/or HTML output
- A view layer like GSP, JSP, HAML or whatever else you like – which is generating HTML output
- Often a view aggregation/decoration layer like Sitemesh – which is generating HTML output from multiple HTML inputs
This is not even the end of it. CSS and JS optimisers and bundlers are a form of code generation. CSS Sprite generators create images and/or CSS files. Some of these are code generators that process the output of other generators. Its like the dev toolchain from hell.
We’re not even talking here about client-side JS that generates markup or DOM nodes, or that your server-side app stack is likely generating byte code from your source code, and that itself runs inside a VM.
Look at this powerful stack of tools we have now, and teleport yourself back to the year 2000.
Someone says to you that they’ve got this great web app stack you can use and it needs at least 5 different code generation tools, and you’ll have to write in at least 4 but probably 5 or 6 languages. You. Have. Got. To. Be. Kidding. Me.
There’s nothing they could have shown you that would have persuaded you it was worth this crazy complexity or investment. What have we done? We’ve flogged this broken “solution” for making cross platform apps so hard and for so long that we cannot see the wood for the trees.
Obviously, in terms of what we can do with web apps this is indeed progress. But only in the context of a completely, utterly broken platform for making applications.
No wonder Flash was so popular.
But here is the question: How complex does this stack have to get for the perceived cost trade-off vs. native for mobile and/or desktop to fall down?
You need to factor in the type of web application – most are not complex, perhaps easier to implement with native UIs – and revenue generation models. Also the availability of people with the skills. At what point does it become easier to hire people with native skills than people with ‘hit the ground runnings’ skills in say 5 different languages.
Remember that the web is supposed to be our “single language” cross platform solution, even when single means a minimum of 4; app code e.g. PHP/Java/Groovy/Ruby/Python, and UI with CSS/JS/HTML. The fact we can’t do anything “good” with it these days without an extra handful of processing and languages on top is a pretty sad indictment.
In the old days when I’d trawled through the minutiae of the SMTP, NNTP, NTP, POP3, HTTP and MIME RFCs, the web was not touted as the solution to cross platform app development in any way whatsoever.
In fact the response of that time to the problems we have now would have been to create something new. Something fit for purpose. A real cross platform UI based-application RFC and new protocols and standards to hang off it. Something that didn’t require a zillion complex tools and dependencies.
Something more like a native environment. But that’s not possible because all the O/S vendors need to differentiate.
So it is because of them that we are stuck with this stack from hell – or we choose a native platform or two and go with it.
Grails Platform Core 1.0.M1 Plugin – highlights
A few days ago we released Platform Core Plugin 1.0.M1 for Grails. The platform will provide APIs and utilities to help us take the Grails ecosystem to the next level.
Even though it is a milestone release, it has very functional Configuration and Security APIs that are already in use in some production apps.
To pique your interest, here are a few of my favourite things available in this release of it:
- the pluginConfig variable added to all artefacts declared in plugins. This receives the namespaced Config values for the plugin, tying into the cool new doWithConfigOptions hook that lets plugins declare the configuration values that are valid – as well as default values and validators. See the docs
- The displayMessage method added to controllers and the g:displayMessage tag that renders the messages set by controllers. Along with their flash scope variants this eliminates more boiler plate from controllers, and provides a uniform mechanism for plugins and apps to use – your app views don’t need to know how a plugin passes a message to the view if the plugin uses these methods. See the docs
- The securityIdentity variable added to all Controllers, Services, Domains and TagLibs to provide the identity of the current logged in user, independent of the security plugin your code is using. This opens up app-defined security integration to all plugins – and using something like this would make the recent dependency injection exploits less likely. No need to inject any services into your domains to get the current user. See the docs
There’s a lot more to come, we’re really excited about the M2 release which will expose the public API for Navigation and Events.
Note that if you want to use the security API now in your apps and plugins, you will need to implement the security bridge for your chosen security provider.
Inside the Grails dependency injection binding vulnerability
You may have seen the recently announced vulnerability in Grails binding relating to dependency injection.
I wanted to explain this in a little more depth so that everybody knows how to tell whether or not their current systems are vulnerable to it and what this might mean. It is worth noting that new releases of Grails 1.3.x and 2.0.x have already been made by the team – upgrading to those now and redeploying your app will close this particular hole for you.
How the development community killed quality for themselves
Businesses need great software libraries and components.
Businesses can get that stuff, free for that last ~10 years or so, but in reality the quality is very variable whether they know it or not. Also, because it is free people typically do not have the high bar they should apply to something they purchase.
Furthermore, it is hard to really feel that you value something if it cost you nothing.
It is also pretty intuitive that people who get stuff free usually don’t want to pay for it later, especially if it is still available for free.
People all over the world make free stuff.
But surely businesses don’t really want to base their commercially important systems on stuff created by hobbyists to which they have no actual connection or provenance, do they? That wold be crazy right?
Of course a lot of free open source is created by people at work. These people are usually paid to work on stuff the company needs or sells – but sometimes they are paid by a company that produces open source and sells consulting and support. Sometimes they just do it under the radar.
Sometimes, just sometimes, some big organisation may bankroll/sponsor some free stuff for a while.
What is the end result here?
How does it affect the quality of the software we use, and what code is developed?
How does it affect our forward progress in this field of software development?
It certainly means most companies get to build their products without paying for a lot of the code they use. However the cost of this software (that they are not paying) split among all the people worldwide using it, would be miniscule.
By jumping on the no-cost open software model, we developers have basically stymied hardcore progress on quality globally.
This is because hobby projects must be sufficiently small for hobbyists to manage at a high quality – or it becomes low quality, perhaps only later down the line. Companies the world over are using the hobbyist stuff that is between both ends of that spectrum – usually without even thinking about it.
Bigger projects that cannot be sustained by hobbyists or become commercially important to somebody, or an attractive bit of commercial bling, may survive through team acquisition / sponsorship and related commercials mentioned above.
But what does that mean?
It inevitably means the direction of those bigger projects follow a course commensurate with the commercial interests of the backers, whatever that may be. It often means increased quality and robustness, which is good.
However it also means that effectively the large high-quality successful projects that we all have access to for free are implicitly filtered and chosen by those backers.
And we really have no way to change this by choosing to pay for stuff to support developers to make it their full time occupation to develop, refine and support their users.
Why? Because someone else will always be doing it free and everyone’s become used to free.
Of course commercial software does not guarantee quality. But without financial returns you cannot get the dedicated minds of smart people to make “insanely great” code for you to use, on an ongoing basis. At some point it will end.
I miss the days when people would pay you ~$50 for a library and get support from you bundled in.
You could dedicate yourself to your users.
[Note that I make a good living from consulting, and I am floating the Grailsrocks support product too. What I'm saying is I'm not whining about how I can't make money - I care about quality, innovation and strong community]
