My title for this blog post is on the technical side but I’m going to keep the discussion high level and non-technical.
Silver bullets kill monsters.
In software development we have a fairly large and insidious monster called Cross Platform Development. This monster shows up when you want an application to work for everyone, like when you want an app that works for both Android phones and iPhones. But despite that example, this monster wasn’t brought to life by the smartphone. Before smartphones, Cross Platform Development could mean Mac and Windows, Windows and Linux, or any such combination. This problem has been around for at least 30 years and software developers have been looking for solutions for nearly as long.
I’m firmly in the “anti-Silver Bullet” camp – I believe that software development is a complex task that cannot be simplified without losing something. By losing something, I mean that to simplify software development you have to compromise somewhere else, in performance, customization, control, or design. I don’t like compromise. I also believe that humans are much more flexible than computers and they should be the part of the system that bends to make things work rather than expecting the machine to do it.
I’ll talk through the benefits of the Cross Platform Development Silver Bullet because, despite my bias, I do see definite benefits.
The biggest benefit of the Cross Platform Development Silver Bullet is that you have a single code base rather than having a separate one for every platform. This is good because it takes time and money to write code, fix bugs, and test applications. Those costs are greatly reduced with a single code base and not just during initial creation of the application but for the years of maintenance that follow. This seems like a simple concept but it is a huge deal.
Another benefit is developers don’t need to learn as many languages. A single code base will probably be written in a single language and you might also need to speak the databases’ language (although the hip thing these days is to have the database speak the same language as the code base.) a single language means it is easier to find software developers that speak that language. If you want to write native (the opposite of Cross Platform) apps for every platform right now, you’d need to speak somewhere between 3 and 5 languages minimum.
In most evaluations this would be the point where I’d share the downsides of the Cross Platform Development Silver Bullet. But it has no downsides. The problem is that it doesn’t exist. In specific, it doesn’t exist for what I need software to do. I do think there are situations where a Cross Platform Development Silver Bullet could work – situations where the compromises are OK. Let me tell you why it won’t work for me.
First, it is too risky. These Silver Bullets are code bases themselves, software written by teams employed by large technology companies. These companies can afford to have very smart people working on open source projects because it makes sense for them at the time. But what if that changes? What if the company changes its priorities or goes out of business? The code you’ve written will become useless, not immediately but over a relatively short time of months or years. You’ll have to rebuild everything. You may be thinking “it is open source, someone else will pick it up!” Which may be true, but will they be as devoted to the project as the original team? Will they be as smart as that team? What are their incentives? Again, too risky.
Second, and this ties in with the first reason, you will only be able to use the tools that the developers of the Silver Bullet give to you. If a shiny new feature comes out and those developers decide not to implement it, or worse, give you just a little control over it but not full control, then you can’t use it the way you’d like to. You may be thinking “well that’s no different than if Apple hasn’t provided the feature” but you’re wrong. It is different because other apps can use the feature and users of your app will see that. If others can do it and you can’t then you’re at a disadvantage.
Third, you will always be a little bit behind the features that native developers will get. The Silver Bullet works because people write code to make it work on multiple platforms. If a new feature comes out you have to wait for those people to write the code to enable it. And what if one platform has a feature that another doesn’t? How does that work? I don’t know, but the Silver Bullet can only solve that in two ways, either making you write that code yourself or not including that feature on either platform (I suppose there is a third way which involves adding a note in bold to the documentation letting you know that it only works on one platform, but that’s not a great option.) Again, you’ll always be behind.
Fourth, your application won’t feel right. This is the mushiest point I’ll make, but we are a mushy species. Each platform has its own design style which is one of the ways that they differentiate themselves. Each platform is motivated and incentivized to keep their style unique. That design style goes further than the way things look, it is the way they function too. The way things look is easier for these Silver Bullets to get right. But the easiest way to make the functionality right across platforms is by limiting options. This means you can’t differentiate your app as much as you might like. It also means that all apps built with the Silver Bullet start looking the same.
Do I believe that every app should be native? No. I believe you need to use a different tool for different situations after weighing the benefits and drawbacks. I don’t believe there is a one size fits all solution.