Cross-Platform Mobile Development with no Frameworks — Part 1: Why?
When we talk about “mobile” development, generally what we mean is the development of a two software products with identical feature sets on two distinct platforms, Android and iOS. Developing for these two operating systems requires different tools and programming languages, and that usually translates into isolated development environments where teams build duplicate applications with the same requirements and design with almost no overlap in actual engineering.
In this two-part series, we’ll talk about converging the architecture and code of mobile apps across platforms — no third party frameworks or libraries needed. In this first part, we’ll talk about traditional methods of multi-platform mobile development, and why they fail. We’ll also discuss the benefits of cross-platform code and architecture convergence. In the next part, I’ll show you how we actually achieve it.
Cross Platform Frameworks
There have been many attempts to collapse the 2 tracks of mobile development into one, but most of them are geared at developing one set of code and then generating two apps, one on each platform. Many cross-platform solutions use a third party framework — a system or set of tools and libraries that is provided by some other company or organization, which you use to develop your app on both platforms. The idea here is that you write your code in the language or system of the framework, and then the framework generates an app for you, based on the framework-code you wrote. In general, these involve some non-native language (like javascript or Dart), and then the system uses that code to create an app for you. There are two main problems with this approach.
Risk
The first is risk: you are basically devoting time and money to developing inside a system that you don’t control. If the system maintainers decide to stop maintenance, you have to either rebuild everything, or start your own system maintenance work. And since most frameworks need to be updated as OSes and SDKs add new features, that unexpected maintenance could be a major investment. In addition to risk of not being in control of the framework, there’s the additional risk that an OS will update and add new features, but you might not be able to take advantage of them until your framework also is updated to support them. If you’re trying to stay on or ahead of the curve of mobile technology evolution, this could be a continuous headache.
Talent
The second problem is that, to develop inside a third-party framework, you need to either hire or train engineers that know how it works. This can be time consuming and/or expensive and also adds on to the first problem. If the framework can’t keep up with the pace of mobile tech or loses adoption or goes away for some other reason, you’re right back where you started. But now you’ve hired or invested in training a bunch of developers with very specific skills that you no longer need.
Performance
Some cross-platform solutions are really just some combination of web sites and web-based components masquerading as native mobile apps. These solutions tend not to be as fluid and natural feeling as genuine native apps, and can also encounter difficulties using some aspects of the device hardware that your app might need. This limits the scope of what your app can potentially do, what features it can provide your users, and how those features will feel to use.
Organizational Divide
The thing about mobile development teams is that, since they are literally building the exact same product, they tend to grow closer together and more collaborative all on their own. Unless, of course, they are artificially separated, which they frequently are. Here’s what many mobile development organizations look like:
There are two teams, one each for Android and iOS. These teams might collaborate on assembling requirements and may even be built using the same set of designs; but in a lot of cases, that’s where the overlap ends. Android and iOS teams frequently have different engineering managers, and engineers from the two teams may never see the other team’s code, even though it is intended to do the exact same thing as their code.
The problem with this structure is that is actually enforces the separation between platforms, by building that separation into the org chart. Remember Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
— Melvin E. Conway
So, great — you get it… Android and iOS teams operate in separated vacuums, and produce similarly separated software. So, why should you care?
Benefits of Cross-Platform Collaboration
Cost
A move from two different software products to a single software product that executes on two platforms is a drastic shift in thinking, planning, and execution, but the benefits are undeniable. When the software is the same — that is, it follows the same architecture, utilizes the same patterns, and implements them the same way for the same context — things become much easier and more predictable.
That means that development is faster and therefore, less expensive.
Predictability
And when I say “a single product operating on two platforms,” I don’t just mean that they have similar organization. I mean that the file names, class names, method and variable names, and literally lines of code for the majority of the application are almost identical. Kotlin an Swift are so similar that, in many cases, lines of code in one can be reproduced almost verbatim in the other. This means that if a bug is found in one platform, it become a near certainty not only that it will exist in the other, but that it will be in the same file, the same class, and even on the same line. Imagine the time advantage of knowing where a bug is before you even fire up the IDE.
Talent
Since the code is largely the same, mobile teams that work on converged code bases naturally grow closer together. Since structure and code are matched, the only barrier to entry for one platform’s engineers to the other platform’s code is the syntax of the language itself. Lowering that barrier so dramatically makes it easier (and almost inevitable) to convert your Android and iOS devs into Mobile Devs. A collaborative team of cross-platform engineers working on a single product across two OSes. These engineers now have additional skills and value, and can jump the lines of platform to assist when needed.
To demonstrate the value of this, imagine our team above of three each Android and iOS devs. Now imagine that one of the Android engineers goes on vacation, and at the same time, another gets sick. Now you’re down to one engineer, with no one to review their code. Everything grinds to a halt.
On a converged Mobile team, the “iOS” devs can now pitch in too fill the gap. One of the devs can switch to Android for a short time, or all the iOS devs can help out with code reviews and bug fixes. The point is that the risk of small development teams is mitigated by the fact that any of the developers can write on any platform.
What’s Next
So, now we know that if we could converge mobile product code, somehow, we could potentially reap enormous benefits — mobile development could be faster, easier, and cheaper. In addition, the mobile engineers will be more skilled and flexible, and the overall product would be more stable and easier to maintain and change, plus we’ll reduce some of the risks of “traditional” mobile development, and hopefully, avoid the risks of third party frameworks.
Cool, so… how do we do it?
Next time, I’ll tell you.